Runtime Enforcement — why agent security must happen at execution time
Most agent security today happens before the model — input filters, content policies, guardrails in the prompt. Runtime enforcement is different: it sits after the model, at the boundary where a decision becomes an action, and re-validates before anything executes. This is the only place the security decision can actually be enforced.
Retrieval puts content in context. Permission is a separate decision about whether that content may cause an action. Runtime enforcement is where that second decision is made — and enforced.
Why "before the model" isn't enough
Every pre-model control shares the same flaw: it must predict, in advance, that some future action will be unsafe. It has to catch the attack while reading it, which means it's fighting the same context that's attacking the model.
- Input filters miss obfuscated and split payloads.
- Prompt guardrails ("never trust documents") are just more text an injection can override.
- Output validation catches what the model said, not what it did — the action already happened.
The decision that matters is: should this specific action, from this specific provenance, execute? That can only be answered at the moment of execution, with full knowledge of the action's origin and authority.
What runtime enforcement looks like
send_email, http_post, exec, file_write — with its argument.The invariants runtime enforcement can actually hold
- Origin-bound authority — derived content can never outrank its source.
- No derivation amplification — a recalled bundle can't gain authority it never had.
- Retrieval ≠ permission — reading doesn't authorise acting.
- Action-time re-scoring — the actual recalled bundle is re-scored before a tool action, not at ingest.
- Fail-closed tampering — state tampering flips the runtime to
lockdown.