Baki GUL’s Jev Guard is an inspectable Node.js guardrail for user input, retrieved content, tool output, and model output. It asks Jev ten OWASP-inspired risk questions, validates every returned score, then applies a versioned local policy to choose allow, review, or block.

What the implementation adds

  • The caller supplies trusted task and application context separately from untrusted text; delimiters inside the text cannot select a friendlier policy.
  • Jev produces semantic signals, while ordinary code owns thresholds, applicability rules, declared usage limits, and the final action.
  • Missing evidence stays visible as needs_context rather than becoming a reassuring zero-risk score.
  • A score at or above 0.4 requests review; 0.8 normally blocks. Misinformation is never auto-blocked from text alone.
  • Malformed responses, timeouts, authentication errors, and unavailable quota infrastructure fail closed instead of returning allow.

The measured development suite

  • The repository reports 117 of 120 authored cases passing, with all 60 attack cases held for review or blocking and three benign false positives.
  • A harder 48-case quotation suite passed 35 cases: all 32 attacks were held, but 13 of 16 benign examples were false positives.
  • Those are maintainer-run development regressions, not independent exploits or a held-out accuracy benchmark.
  • The reported original-suite latency was 2.585 seconds p50 and 2.693 seconds p95; quotation clarification rose to 3.902 and 5.410 seconds. I did not reproduce the live Jev measurements.

What I verified

  • I inspected the Jev request construction, response validation, policy thresholds, quota path, and published evaluation reports at commit 7c7b1b5b646428e397541473de0cd176cc9fe956.
  • From a clean checkout, npm test completed with 67 passing, four skipped, and zero failing tests.
  • The skipped tests require live Jev or external Redis/Upstash services, so this run verifies local behavior—not model quality, calibration, latency, or deployment security.
  • This was an implementation review, not a security audit.

The useful design lesson

  • “OWASP coverage” is not something a text classifier can certify. Supply-chain integrity, retrieval boundaries, poisoning impact, and resource exhaustion require evidence from the surrounding application.
  • Typed output prevents malformed categories; it does not make the underlying risk judgment correct.
  • The quotation results show the operational tradeoff clearly: holding every authored attack came with substantial over-blocking of harmless analysis and translation.
  • A production rollout still needs representative traffic, separately measured false negatives, explicit review capacity, and deterministic authorization outside the model.

“Scores measure signals in the text; they are not verified OWASP vulnerabilities or calibrated attack-success probabilities.”

The project’s strongest contribution is not a universal safety claim. It is the separation between model evidence, policy, and application authority, with enough retained detail to see where that separation still fails.