Learn · Enforcement
Operational boundaries for AI agents, enforced at runtime
A config file that lists what an agent should do is a wish. An operational boundary enforced at runtime is a wall. This covers what a boundary is, and why where you enforce it matters more than where you declare it.
What an operational boundary is
An operational boundary is the precise envelope of what an agent may do: which operations it can perform, which resources it can touch, which systems and audiences it can reach, and under what conditions. It is the concrete expression of least privilege for one agent. A good boundary is specific — "read records of type X in system Y" — rather than broad — "access the database." The narrower and more explicit it is, the smaller the damage any single agent can cause.
Config time vs runtime
There is a world of difference between declaring a boundary and enforcing one. A boundary written in a config file and read once at startup tells you the intended behaviour, but nothing stops the agent from doing more if its credentials permit it. Runtime enforcement means the boundary is checked on every request, by something the agent cannot bypass, right before the action would happen. Config-time declarations describe; runtime enforcement prevents. For agents driven by models that can be nudged off course, only prevention counts.
If the only thing holding an agent inside its boundary is the agent itself, you do not have a boundary — you have a hope.
How runtime enforcement works
Enforcement lives at a gateway that every agent request passes through. On each request the gateway verifies the agent's identity, looks up its boundary, and checks the specific operation and resource against it. In-scope requests proceed; out-of-scope requests are refused and logged. Because the gateway sits outside the agent and re-checks every time, there is no moment where the agent operates unobserved or unconstrained. Combine this with filesystem and network confinement at the runtime layer — for example sandboxing the agent process — so the boundary holds even for actions that never reach the gateway.
How to set it up
- Derive the boundary from the task. List only the operations, resources, and audiences the agent needs.
- Express it as policy. Keep it in version control, reviewed like code; see OPA for agents.
- Enforce at a gateway per request. Verify identity, evaluate the boundary, deny by default.
- Confine the runtime. Sandbox the agent so filesystem and network access match the boundary too.
- Log and expire. Record decisions and rely on short-lived identity so authority never outlives the task.
OATHERA derives sandbox and gateway policy from each agent's boundary. See features and the integrations page.
FAQ
What is an operational boundary for an AI agent and how do you enforce one at runtime rather than just at config time?
An operational boundary is the exact set of operations, resources, systems, and audiences an agent is allowed to touch — the concrete form of least privilege for that agent. You enforce it at runtime by routing every agent request through a gateway that verifies the agent's identity and checks the operation against the boundary before it runs, and by sandboxing the agent so filesystem and network access match too. A config-file declaration only describes intended behaviour; runtime enforcement actually prevents out-of-scope actions.
Why isn't a config file enough to enforce a boundary?
Because nothing checks it after startup. A config read once describes what the agent should do but cannot stop it from doing more if its credentials allow. Runtime enforcement re-checks every request at a point the agent cannot bypass.
Where should the boundary be enforced?
Outside the agent: at a gateway in front of your systems for API calls, and at the runtime/sandbox layer for filesystem and network access. Enforcing inside the agent you are trying to constrain is not a real control.