TypeSafe released Jev this month — a classifier that assigns risk probabilities to actions and immediately the ecosystem built hundreds of guardrails and projects with it. Claude Code plugins, LangChain middleware, custom hook scripts, all asking Jev some version of the same question: is this action about to hurt me?
Every guardrail has two jobs: judge the action, and enforce the verdict. Jev just made the first job, judgment, nearly free. However, it specifically does not enforce the actions it scores. That is because enforcement is a question of placement: where does the verdict get applied, and what can route around it?
There are two places to put it.
Inside the agent
Claude Code, LangChain graphs, and custom loops all expose hooks — code that fires before and after each tool call. A plugin on those hooks sends the proposed action to Jev and turns the score into allow, deny, or ask a human.
jev-guard, one of the most-starred new Claude Code plugins, does exactly this: it asks Jev a batch of questions about each shell command and never auto-allows shapes like rm -rf or DROP TABLE. LangChain's AutoModeMiddleware is the same idea inside an agent loop.
This layer has an advantage nothing outside the harness can match: it sees the action next to the agent's own task and plan. It can stop a dangerous command before it executes anywhere — even inside the agent's own sandbox — and it can scan a fetched web page for prompt injection before the payload steers the next step.
Its authors are honest about the boundaries. jev-guard's README calls it "not a security boundary": it covers the tools that pass through the hooks, it fails open by default, and it protects the one agent it is installed in. If a second agent — or a cron job, or a developer's laptop — holds the same database credentials, the hook never fires.
On the wire
The other place to enforce a verdict is the connection itself. hoop.dev is a sidecar: a lightweight proxy attached to your database. The agent's connection string points at the sidecar, and nothing else changes on the agent's side — no SDK, no plugin, no prompt changes.
Because the sidecar speaks the database's own protocol, it reads every statement in the context of the tables it touches and the data coming back. A model scores each statement's intent and risk, and you decide what each level does: allow, warn, block, or hold for a person. A blocked statement is refused before it reaches the database — returned as an ordinary database error carrying a message you wrote. Sensitive values are masked in the response before the agent ever holds them. And every statement leaves a record the agent cannot edit.
The sidecar does not know or care what is on the other end of the connection. A second agent, a different framework, a shell script, a human with psql: same wire, same rules.
What each layer stops
Both — in this order
The two layers barely overlap; each one stops things the other never sees. So run the in-agent layer: it is cheap now, thanks to Jev, and it is the only thing that can judge an action next to the intent behind it.
But notice which column the hooks layer depends on: every "yes" comes with a condition — if the command goes through a hooked tool, if the plugin is installed, if this is the agent you configured. The wire has no conditions, because it binds to the credential, not the agent. And if your agents hold credentials to production data, the credential is the thing that does the damage.
hoop.dev is the wire-level enforcement layer. We'll walk through it on your own setup — your agents, your database: hoop.dev/meet.