Action Envelope Enforcement
Enforce, at runtime, the tier-declared boundary of what the agent is permitted to do — before the action reaches the target system.
This page is the complete instruction page for one pattern called "Action Envelope Enforcement." It explains the problem this pattern solves, the idea behind the solution, when you should (and should not) use it, and what happens afterward — both the good effects and the costs.
This matters because building AI agents is not just about making them clever. It is also about making them safe and predictable. Following a well-tested pattern like this one helps avoid common mistakes, and shows you exactly which safety rules and regulations it connects to, listed under "Standards Mesh" on this page.
Context
An agent may have reasoned its way to an action that technically works but exceeds its declared authority — writing to a production table when its tier permits only reads, or transferring above a limit.
Problem
LLM reasoning is non-deterministic. Relying on the model to stay inside its tier is insufficient; policy must be enforced deterministically outside the model.
Forces
- Flexibility of natural-language instruction vs enforceability
- Pre-commit vs post-commit checking
Solution
Wrap every tool invocation in a policy-as-code check that reads the agent identity, the declared tier, and the action parameters. Reject actions outside the envelope with a structured error; surface violations to observability. Never let the agent itself be the final arbiter of its own authority.
Applicability
- Any agent with write access
- Multi-tenant agent platforms
- Regulated sectors
Anti-Patterns
- Policy expressed only in system prompt
- Agent self-approves using a "check" tool it also controls
Consequences
- +Deterministic bound on worst-case behaviour
- +Evidence trail for audits
- −Policy surface must be maintained
- −Can block legitimate edge cases