Overview & result
Interlock wraps an agent's tool calls: the model keeps planning, and a kernel decides whether a bash, HTTP, write or send action actually runs. The model only ever holds canaries and placeholders; real keys stay in a vault process and are swapped in at egress for allowlisted hosts. Per the README, Jev scores hazards and a policy file picks allow, ask or block.
From the original post
The kernel the LLM is not allowed to talk to. Capability kernel for untrusted agents — canaries, closed action space, Jev as the sensor.
How Jev fits in the loop
- Your agent's tool call is passed to gate() before it runs.
- The agent environment holds only canaries and placeholders; real keys stay in a separate vault process.
- Jev scores the hazards of the call, and a policy file picks allow, ask or block.
- On an allowed call to an allowlisted host, the placeholder is swapped for the real secret at egress, outside the model.
How to reproduce
- Inspect the original showcase and source material at https://github.com/somoore/interlock
- Verify the bounded prompt and input candidate schema configured for Jev
- Benchmark decision latency and classification accuracy against baseline models
Why this build matters
Instead of only asking whether a call looks dangerous, it removes real secrets from the model's reach, so any use of a canary off the allowlist is itself a catch.
Limitations
- The 38-case suite is a regression set; the README says it is not a blind evaluation.
- The author tells readers to wire Jev and run their own held-out attacks before trusting a number.
- It gates the tool calls you route through it; it is not an app you run.