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 an operational 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 behavior, 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 the Gateway MCP that every agent request passes through. On each request the Gateway MCP verifies the agent's identity, looks up its operational boundary, and checks the specific operation and resource against it, returning a signed boundary decision. In-scope requests proceed; out-of-scope requests are refused and recorded. Because the Gateway MCP 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 derived from the same boundary — a NVIDIA OpenShell sandbox policy and Landlock kernel confinement — so the boundary holds even for actions that never reach the Gateway MCP.
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 the Gateway MCP per request. Verify identity, evaluate the boundary, deny by default.
- Confine the runtime. Derive a NVIDIA OpenShell sandbox policy and Landlock confinement from the boundary so filesystem and network access match too.
- Record and expire. Capture boundary decisions and rely on a short identity-token lifetime so authority never outlives the task.
Oathera derives sandbox and gateway policy from each agent's operational 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 the Gateway MCP, which verifies the agent's identity and checks the operation against the boundary before it runs, and by deriving a NVIDIA OpenShell sandbox policy and Landlock kernel confinement from the same boundary. A config-file declaration only describes intended behavior; 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 the Gateway MCP in front of your resource servers 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.