
Key facts.
- AgentDojo (arXiv:2406.13352) shows tool-using agents solve under 66% of even benign tasks, so the range of actions an agent might take incorrectly is wide and needs explicit limits. source
- ISO/IEC 42001:2023, the AI management system standard, requires defining the intended use and boundaries of an AI system and managing it across its lifecycle, which is documentation of what it may do. source
- MAKER (arXiv:2511.09030) shows that without explicit per-step control, errors compound across a long task, so an agent operating freely over many steps drifts in ways a boundary would have caught. source
Why does an undocumented boundary default to yes?
Because the agent's actual limit is its permissions, not your intentions. If you have not written down that the agent must escalate a refund over a threshold and the agent has the permission to issue refunds, then it will issue any refund it decides to, because nothing in the system encodes your intended limit. The boundary you imagined exists only in your head until it is documented and enforced. AgentDojo's numbers make the stakes concrete: agents miss a real share of benign tasks, so the chance that an unbounded action is the wrong one is not small. Every action you did not explicitly gate is an action the agent may take on its own, which is an implicit yes you never decided to give.
A more capable model makes this worse before it makes it better, because a more capable agent attempts more, reaching further into the space of actions where the boundary should have been. MAKER illustrates the underlying dynamic: across a long sequence of steps, errors compound unless something corrects at each step, so an agent operating without documented checkpoints accumulates drift. ISO/IEC 42001 treats this as a management requirement, defining the AI system's intended use and boundaries and governing it across the lifecycle. That is the standard naming what production readiness should already include: a written, enforced statement of what the agent does alone and what it hands to a person.

What does a documented boundary actually specify?
The actions the agent may take autonomously, named explicitly, so there is no ambiguity about its default authority. The actions that require human approval, with the threshold or condition that triggers escalation, so the gate is concrete. The actions it is forbidden to take at all, so some doors are simply closed. And the enforcement point for each, so the boundary is a runtime check and not just a paragraph. ISO/IEC 42001 frames this as defining and managing the system's scope; in practice it is the readiness artifact that turns intended limits into real ones. An agent with this document shipped alongside it has defined autonomy. An agent without it has whatever autonomy its permissions happen to grant, which is rarely what anyone chose.
| Action class | Undocumented agent | Documented boundary |
|---|---|---|
| Routine actions | Implicit yes | Explicitly autonomous |
| Sensitive actions | Taken if permitted | Escalated on condition |
| Forbidden actions | Possible if reachable | Closed by enforcement |
| Limit source | Permissions by accident | Decision on purpose |
The Pattern Intelligence Layer is where the documented boundary becomes an enforced one. The actions an agent takes are checked against its defined autonomy at the pattern level, so an action outside the boundary is escalated or stopped rather than silently allowed. Reliability at the pattern level is what turns a written limit into the limit the agent actually operates under.
Frequently asked questions
Does a more capable model know which actions to avoid?
Permissions decide what an agent does and on AgentDojo even strong agents clear under 66% of benign tasks, so a more capable model widens what it tries, not what it should; write the line first. (arXiv:2406.13352)
Isn't the permission model already the boundary?
Permissions are a blunt boundary. They say what the agent can reach, not what it should do autonomously versus escalate. The documented boundary encodes that finer decision and its enforcement.
Why document it before shipping rather than after?
Because after shipping, you discover the boundary when the agent crosses one. AgentDojo shows agents take wrong actions often enough that waiting means learning the limit through an incident.
Does ISO/IEC 42001 require this specifically?
It requires defining the AI system's intended use and boundaries and managing them across the lifecycle, which in practice is this documented, enforced statement of allowed autonomy.

