Question 1

Is this actually a security boundary, or just another prompt filter?

Accepted Answer

A signal layer, by its own admission. The README says outright that it is not a security boundary, that determined attackers can try to evade the semantic layer, and that sandboxing, least privilege and human approval stay in place for high-stakes actions. What it returns is a probability, and your policy decides what that probability means.

Question 2

What does this cost and add to my tool calls?

Accepted Answer

One Jev call per screened event at roughly $0.00003, adding about 0.5 to 1.3 seconds per tool call or result. The bundled demo records 10 verifications for $0.0003 total at 558 ms median. Local Read, Grep and Glob calls are exempt by default. Pricing comes from TypeSafe early access via AI Gateway, so the number can move.

Question 3

If the Jev API is down, does my agent just stop working?

Accepted Answer

That is a decision you make in code. `fail_mode` is `open` by default and can be set to `closed`, and `JEV_FAIL_MODE` overrides it. `JEV_HOOK_OFF=1` is a kill switch for the hook and plugin layer, which is opt-in through `install-hooks` and merges rather than clobbers existing files.

Question 4

How is this different from the pattern-matching proxies already out there?

Accepted Answer

The README's argument is that deterministic proxies catch payloads that look like known attacks, and that paraphrasing defeats them. Jev scores the meaning of a payload and returns a calibrated probability rather than a boolean. In the demo, a novel-phrasing exfiltration attempt inside the allowlist is blocked on payload sensitivity while a legitimate email to ops passes on semantic grounds.

Question 5

What exactly gets screened, and what does the bundled demo catch?

Accepted Answer

Three surfaces: tools/list, where a poisoned tool description is flagged on tool_poisoning around 0.9x; tools/call, where structural rules and a Jev battery cover exfiltration, destructive actions, injection in arguments and credential sensitivity; and the result, which is annotated or redacted. The demo catches a poisoned search result at contains_injection 0.98, a novel-phrasing exfiltration at payload_sensitivity 0.98, and a destructive call on severity 2.11 against the 2.0 gate.

Question 6

How does the agent skill differ from the hook enforcement?

Accepted Answer

The skill is cooperative: install-skill writes into ~/.claude/skills and ~/.config/opencode/skills plus a /verify command, and an agent has to choose to call it. Enforcement is opt-in and automatic: Claude Code gets PreToolUse deny or ask plus PostToolUse, opencode gets a tool.execute.before plugin that throws to block, and Codex, which has no hook API, is covered only when jev-shield wrap becomes the MCP server command. install-hooks merges into existing files and uninstall-hooks leaves the skill in place.

Question 7

What does the audit trail record, and what is session taint tracking?

Accepted Answer

The audit layer writes a JSONL trail per event with the hazard, its severity, latency and cost. Session taint tracking is the free third layer: once a tool result is flagged, the calls that follow are verified under an escalated policy rather than the default one. Policy itself lives in config/policies.json as code, with review at 0.35, action at 0.7 and severity_block at 2.0, plus per-tool recipient_allowlist and require_flag entries, so probabilities stay the same and only the thresholds move.

Jev Shield — caiovicentino

About this project

Highlights

Questions about this entry

Other listings of this project

More Jev resources like this

From the Jev community