A model can be persuaded. A signed policy cannot.

AgentLaw MaintainersAugust 17, 20263 min read

If your AI agent can send mail, push code or move money, what actually stops it from doing the wrong thing? For most teams the honest answer is a few lines in its prompt: never delete files, always ask before paying.

The rule lives in the wrong place

Those instructions sit in the same text the model reads to do its job — next to the web page it fetched and the document it was asked to summarize. Prompt injection is the art of slipping new instructions into that text.

It is not a bug the next model will fix. A language model is built to be influenced by what it reads; the attack and the feature are the same mechanism. Better defenses improve the odds. A security boundary should not be a matter of odds.

The rule and the attack arrive through the same channel: the prompt

Move the decision outside the model

The old fix still works: do not ask the component you cannot trust to police itself.

Put a checkpoint between the agent and its tools. Every call passes through it before it runs, and it answers one of three things: allow, approve (a person decides) or deny. The checkpoint is not another AI. It is compiled rules with typed conditions — same input, same verdict, every time. An injection can persuade the model; it cannot persuade an if.

Every tool call crosses a checkpoint with three possible verdicts

Sign the rulebook, keep the key away

If the rules were a plain file on the agent's machine, the next attack writes itself: persuade the agent to edit the file. So the rules are sealed with a signature (Ed25519), and the signing key never lives where the agent runs. Loosening a rule takes the key, not a good argument.

Anything no rule covers is denied. A payments rule reads like this:

rules:
  - id: pay-decision
    match: { tool: create_payment }
    when: [{ arg: amount, op: gte, value: 100 }]
    effect: approve
    else: allow

Small payments flow; from 100 up, a person answers first.

The key signs on another machine; the agent can read the rules but not change them

Know where the boundary ends

A signed policy stops tool calls induced by injection, overly diligent agents and quiet loosening of the rules. It does not stop someone who holds the signing key, an administrator of the host, or hostile text returned by an allowed tool — it stops that text from acting, not from being read.

A boundary whose limits nobody wrote down is not a boundary. It is a hope.

What a signed policy stops, and what it leaves to other layers

Try it on your own agent this week: list the tools it can call, pick the one action you could not undo, and write a rule that sends it to a person. AgentLaw publishes an Apache-2.0 gateway on npm that scaffolds a signed policy in one command:

npx @agentlaw/gateway wizard .