A model can be persuaded. A signed policy cannot.
AI agents no longer just converse — they act. They read files, send mail, push code, move money, and they do it holding real credentials. For most deployments today, the only barrier between an agent and an irreversible action is a set of instructions written into its own prompt: never delete files, always ask before sending, do not touch production.
Prompt injection is, precisely, the art of defeating those instructions. This is not a bug that better models will fix, because it is not a bug. A language model's job is to be influenced by its input; the attack and the feature are the same mechanism. Every month brings a new technique — indirect injection through a fetched web page, instructions hidden in a document the agent was asked to summarize, a slow redefinition of context across a long session. The defenses improve too, but they improve the odds. A security boundary is not supposed to be a matter of odds.
Moving the decision outside the model
There is an older, less exciting way to think about this: do not ask the component you cannot trust to police itself.
That is the premise behind AgentLaw. Critical decisions are not requested from the model — they are verified outside of it. Every tool call an agent attempts passes through an external evaluator before it executes, and that evaluator produces one of three verdicts: allow, approve (a human decides), or deny.
Two properties make this a boundary rather than another opinion in the loop:
The evaluator is not another AI. It is a deterministic engine: compiled rules and typed conditions that produce the same verdict for the same input, every time. It does not interpret, tire, or get talked into anything. Where a model can be deceived, a compiled rule cannot. An injection can persuade the model; it cannot persuade an if.
The policy is signed. The rules live in a manifest sealed with Ed25519 cryptography, and the private key never lives where the agent runs. Loosening a rule requires the key — not a convincing argument. This closes the obvious next attack: if the policy were a plain file on the same machine, an agent with file access could simply be persuaded to edit it.
Everything not covered by a rule is denied by default. Fail-closed is not a configuration option; it is the design.
What a policy looks like
A manifest is meant to be read by the person who signs it. A payments rule, from one of the example policies in the repository:
rules:
- id: pay-decision
match: { tool: create_payment }
when: [{ arg: amount, op: gte, value: 100 }]
effect: approve
else: allow
Payments under the threshold go through on their own. At or above it, a human answers before anything moves. There is no built-in list of forbidden actions — every deployment declares its own, which is the honest shape of the problem: what is dangerous for a coding agent on a workstation is not what is dangerous for a billing agent.
Every decision — including the refusals — lands in a hash-chained audit log that cannot be altered without leaving a trace. That log is worth a post of its own.
What this does not claim
No serious tool promises total protection, and the scope here is published rather than implied. A signed policy stops tool calls induced by prompt injection, confused or overly diligent agents, and unauthorized loosening of the rules. It does not stop an attacker who holds the private signing key, an attacker with administrator privileges on the host, or hostile content returned by a permitted tool — the policy stops that text from acting, not from being read.
Drawing the line clearly is part of the point. A boundary whose limits are unknown is not a boundary; it is a hope.
Where to start
The specifications come before the code — RFC-0001 defines the policy manifest, RFC-0002 the audit log — and one command scaffolds a signed, ready-to-run policy:
npx @agentlaw/gateway wizard .
The engine, the signing, the enforcement and the audit are open source under Apache-2.0, free and self-hostable — always. The project is at version 0.1 and its RFCs are in Draft: critical readings of the spec are as valuable as code.