Guardrails With a Decision Model: jev-guard, jev-mcp, Safer with Jev

Agent security has a cost problem. A frontier model can review every tool call and every fetched page for danger, but nobody runs that on every step because it is slow and expensive. So the check gets skipped, and the agent reads a hostile web page with no screening at all.

Jev changes the economics, at least on paper. It returns a probability for a question you define: is this call destructive, does this text carry instructions aimed at an AI? A cheap, fast, typed answer can run on every step. This article looks at three open-source projects that use that idea for safety, what evidence they offer, and one listing that is not what its category label suggests. For the basics, see what Jev is and typed decisions vs free text.

Key Takeaways

• Guardrails are a natural fit. Bounded yes/no and severity questions are exactly what a typed classifier answers well. Free-text generation is not needed.
• jev-guard scores every tool call. Three typed questions (risk, user-requested, from-untrusted) drive allow, ask or deny, across several coding agents.
• The numbers are the authors' own. Latency, cost and calibration examples come from the project's READMEs and one-day runs. None is independently retested.
• Guardrails, not sandboxes. jev-guard says so itself: "a guardrail, not a sandbox... Jev can be wrong. Keep your other controls."
• Check what a listing really is. jev-shield, filed under safety on some directories, is a Chrome ad blocker.

jev-guard: risk scoring for every tool call

jev-guard (MIT, 2 stars as of September 2026) is a security hook for coding agents. Its README says it works with Claude Code, Codex, Copilot CLI, Gemini CLI, Cursor, pi, OpenCode and editors using the Agent Client Protocol. (Some directory summaries describe it as a trading tool; the README says otherwise.)

The design is three typed questions per call. risk is a four-level score from read-only up to destructive. user_requested asks whether the user actually asked for this. from_untrusted asks whether the call carries out an instruction planted in content the agent read. Simple code rules follow: deny at risk 2.5 or above, ask at 1.5 or above, and a "yes" on from_untrusted is a deny on its own.

The context idea is the strong part. The user's recent prompts are stored per session, so after a user writes "force push main to origin now," that exact push goes from ask to allow. After a fetched page contained a planted note, a git remote add mirror command was denied while npm test stayed allowed. Those are the README's own measured examples, and the table shows rm -rf / at risk 3.0 and ls -la near zero.

The README reports about 580 ms per call through the Vercel AI Gateway and roughly 0.75 s directly from Taiwan, on runs from 2026-09-17 and 18. It cites TypeSafe's published price of $0.042 per million input tokens, which the author converts to roughly 4 cents for a 1,000-call session. Those are estimates, not our measurements. It also fails open by default if the API is unreachable, and offers a fail-closed setting.

jev-mcp: screening what the agent reads

jev-mcp (MIT, 67 stars as of September 2026, listed at /skills/jev-mcp-jkudish) includes jev_screen, which scores fetched text for prompt injection, substance and relevance before an agent reads it. In the README's example, a pricing page hiding a note to disregard the user's instructions returns an injection probability of 0.99 and a block recommendation.

Two design choices deserve credit. The recommendation is advisory: the server never blocks, and enforcement stays with the calling agent. And the README says thresholds (block_at 0.75 and review_at 0.25 by default) are starting points from TypeSafe's cookbooks to tune on your own data, and that typed output "guarantees the interface, not the truth." The author reports roughly 150 to 500 ms per call. See how to wire jev-mcp and its siblings into an agent.

Safer with Jev: a gateway you can call

Safer with Jev (3 stars as of September 2026, no license listed) is a small public showcase. It exposes endpoints such as /block-prompt-injections and /block-unsafe-replies. A request is inspected by Jev, and only if it passes is the same body forwarded to a target URL you choose. Per its README, review and block verdicts never forward; a request with a target returns 403.

Note the gap between listing and README. A directory summary describes a router that dispatches queries by difficulty and claims zero cold start. The README describes a safety gateway and shows no evidence for either claim. It is a demo of the pattern, not a hardened product, and it is at /skills/safer-with-jev-andrelandgraf. For genuine difficulty routing, see routing by difficulty.

The misfiled one: jev-shield

jev-shield (MIT, 2 stars) is sometimes grouped with safety tools. It is a Chrome Manifest V3 extension that uses Jev's noul primitive to estimate whether a page element is a native ad or sponsored post, then collapses it. It bundles network rules for 20 ad networks and a bring-your-own-key model with no telemetry. It is a content filter, not a security control, and it is the wrong tool for stopping prompt injection.

What to do next

1. Start in advisory mode. Log jev-guard or jev_screen verdicts for a week before you let them block anything.
2. Tune thresholds on your data. Every default here is a starting point.
3. Decide on failure behavior. Fail open keeps the agent running; fail closed protects you when the API is down. Pick deliberately.
4. Keep hard controls. Sandboxes, least privilege and human approval for irreversible actions still matter.
5. Use the checklist. How to evaluate Jev projects honestly covers how to weigh these claims, and the Awesome Jev radar lists more.