Every action that matters, a refund, a change to a payout record, an outgoing message, goes through one checkpoint. The checkpoint looks at the facts of the action (amount > limit, approval_verified == false) and ignores whatever the agent or the customer wrote. The engine below is the real one, running in your browser.
This is the rule engine itself, ported to JavaScript. No server, no model. Pick one of the prepared attacks or build your own action and watch the verdict. The message changes nothing, because the gate never reads it.
The attacker can't add a new payee, so they edit an existing one. The gate checks the edit itself and ties the refund to the record that was just changed.
Write the most persuasive message you can and watch the verdict on the right. It won't move. The gate never reads this box.
Change a fact, the amount or whether the approval is verified, and the verdict flips. Rewrite the message and nothing happens.
An attack on an agent works by changing what the agent believes. The three things below don't depend on what the agent believes, says or is told.
Every rule is a function of structured facts: amount_cents > limit, approval_verified == false, payout_changed_recently. There is no language understanding in the engine, so there is nothing to talk around.
The point is completeness: no action that matters reaches the outside world except through the gate. The list of gated tools is documented, and a check in CI fails the build when a new tool appears that isn't on it.
By default the gate only logs the decision it would have made and lets the action through. The log is hash-chained, so later edits show. You see what it would have stopped on your real traffic before you let it stop anything.
Paste your agent's tool list, one per line or comma-separated. This runs the same classification the gate runs when tools are registered: tools with consequences must be gated, and any raw execution tool (a shell, an exec, a free-form query) is a side door. As long as one of those is in the list, the gate can't be complete.
This is a rough check on tool names only. In a real engagement we go through each tool's parameters and effects with you. It still gives you the shape of the answer in ten seconds: a small, fully gated tool list is something we can cover; a shell in the list has to go first.
This page runs the real v1 rule engine against scripted attacks and a mock agent. It shows that the mechanism is deterministic: the verdict depends only on the facts, and a compromised agent gets the same answer as a misled one. It says nothing yet about your agent.
For that, we wire the gate in front of your agent's real tools in shadow mode. It blocks nothing and logs every action it would have stopped on your live traffic for one to two weeks. You get a report from your own data: the actions it would have caught, what they could have cost, and the log behind it. You switch to enforcing only if that report convinces you.
We don't claim to make the agent itself safer, to stop every attack, or to guard actions that don't go through the gate. We guard a defined set of actions and check that the set is complete. For everything else you need other tools, and we'll say which.
Two weeks, nothing gets blocked, and you keep the report either way. If it would never have stopped anything, all you've spent is the time to wire it in.
Book a shadow-mode pilot →