Bounded

The property

Bounded asks whether authority and approval requirements are explicit. Not documented, not intended, but expressed in a form something enforces.

This is the property that separates an agentic system you can deploy against real systems from one you can only demonstrate. It is also the property most commonly claimed on the basis of something that does not provide it.

The mistake this exists to prevent

Teams write the boundary into the system prompt. Do not delete anything. Do not send email without asking. Only query these tables. Never modify production.

This is not enforcement. It is a request to a system that is capable of not honoring it, and it fails in three predictable ways.

It fails on misinterpretation. An instruction not to modify production meets a task where the model concludes this particular change is not really a modification, or that this system is not really production. No malice required.

It fails on unusual input. Instructions that hold across ordinary tasks stop holding when a task is strange, which is exactly when the consequences are largest.

It fails on injection. An agent reads a document, a web page, an issue description, or an email. That content contains text addressed to the agent. If the system treats retrieved content as anything other than data, anyone who can put text where the agent will read it can influence what it does. A prompt instruction is not a defense against this, because the attacker is writing into the same channel.

What real enforcement looks like

Authority is enforced outside the model, by the code that executes the action. Five mechanisms cover most of it, and they compose.

Capability scoping

The agent is given only the tools it should have. A tool that is not registered cannot be called. This is the simplest and most effective control, and it is frequently skipped because giving an agent everything is easier during development.

Argument constraints

The tool itself limits what it accepts. This file tool writes only under this directory. This query tool reaches only these tables. This email tool sends only to internal domains. Enforcement at the point of action, testable like any other code.

Credential scoping

The credentials the agent operates with cannot perform the forbidden action. A read-only token cannot write regardless of what the agent attempts. This is the strongest form because it holds even if every other layer has a bug.

Approval gates

Certain classes of action pause and wait for a person, with the proposed action displayed clearly enough to judge.

Process isolation

A container or sandbox bounds what the agent can reach at all, which matters most for broad capabilities such as shell access or code execution where argument constraints are meaningless.

A deployment with capability scoping, scoped credentials, and isolation has defense that does not depend on the model behaving well. That is the goal.

The adversarial test

There is one question that cuts through every discussion about agent safety, and it is worth applying literally.

If the model were replaced with one that behaved adversarially, what could it actually do?

Whatever the answer is, that is your real security boundary. Everything else is a preference. The exercise is useful because it forces you to ignore every control that depends on the model cooperating, which is usually most of them.

Applied honestly, the answer for many systems is uncomfortable. An agent with shell access can do anything the user can. An agent with a broad database credential can read everything in the database. An agent driving a logged-in browser can reach everything that browser is signed into.

The point is not that these capabilities are unacceptable. It is that they should be chosen with the answer in view, and paired with isolation and scoping that reduce it.

Approval that means something

Approval gates are the mechanism most often implemented badly, in a way that produces the appearance of control without the substance.

A prompt asking whether to proceed, without showing exactly what will happen, trains people to approve reflexively. After the twentieth confirmation, nobody is reading. The gate has become a delay rather than a check.

Three properties make an approval real. It must display the specific action, with the actual arguments, in a form a person can evaluate. It should be bound to that action, so an approval cannot be reused for a different one. And it should be rare enough that people still read them, which means gating on irreversibility and consequence rather than on everything.

The last point is a design constraint people resist. Gating too much is a failure mode, not a safe default. A system where everything requires approval trains the reviewer to stop looking, which makes the important gates less effective than having fewer of them would have been.

Reversibility as a boundary

The cheapest form of bounding is often not a restriction but a change of action.

Where a reversible form of an action exists, prefer it. Draft rather than send. Open a branch rather than push. Propose a change rather than apply it. Soft delete rather than hard. Write to a staging table rather than to the production one.

This converts a class of failure from an incident into a review item. A drafted email that should not have been written costs nothing. A sent one costs a conversation. A system built so that the agent's output is a proposal by default, with a separate step to commit, needs far fewer approval gates because the default action is already safe.

It also changes the economics of autonomy. An agent that can only produce reversible outputs can be given much more freedom, because the worst case is wasted work rather than damage.

Whose authority is it

A question that determines whether the rest of this holds together: when an agent acts, whose permissions apply?

The common arrangement is that an agent has its own credentials, typically broad ones, and acts as itself regardless of who asked. This produces two failures at once. The agent becomes a way to reach data the requester could not reach directly, which is a governance hole no prompt discipline closes. And the access record shows the agent rather than the person, which makes attribution impossible.

The stronger arrangement is delegated authority: the agent acts on behalf of a person, with access scoped to what that person could do. Then an agent cannot become a privilege escalation path, and the record names a principal rather than a service account.

This is harder to implement and it is the difference between an agent that is bounded and one that merely has limits. It also has an unexpected benefit: with delegated authority, the question of what an agent may do becomes the question of what its users may do, which is a question the organization has usually already answered.

Composition creates paths nobody designed

Individual tools can each be reasonable while their combination is not, and this is the failure mode that per-tool review does not catch.

An agent with a tool that reads internal documents is fine. An agent with a tool that posts to a public channel is fine. An agent with both has a path from private to public that neither tool author considered, and that path is exercised the first time someone asks it to summarize something internal in a public thread.

The general shape is a read from a sensitive source combined with a write to a less sensitive destination. Once you look for it, the pattern appears in many ordinary configurations:

• A database reader plus a web request tool, which can send query results anywhere.
• A file reader plus an email sender.
• A credentials-bearing browser plus a form-filling capability.
• A ticket reader plus a code-writing tool, where ticket text is untrusted input that reaches a repository.
• Any read tool plus a memory write, since memory is a durable destination and often a shared one.

Three responses help. Review the agent's configured tool set as a whole rather than tool by tool, asking what combinations produce a path out. Scope tools per task rather than exposing everything, so the combination only exists when the task actually needs it. And treat any write to a destination outside the current trust boundary as a gate, regardless of how ordinary the individual tool looks.

This is also the strongest argument for keeping tool surfaces small. The number of possible combinations grows much faster than the number of tools, which means an agent with forty tools has a review problem nobody is going to solve by inspection.

Boundaries per layer

• Data and semantics. Access through a catalog that authenticates the caller and vends short-lived, scoped credentials. The boundary is that the agent cannot reach storage without going through it.
• Models and routing. Rules about which classes of content may reach which endpoints, checked in the router before dispatch rather than described in a policy document.
• Harnesses and brokers. The main event. Capability scoping, argument constraints, limits on steps and spend, approval gates, and isolation.
• Open standards. Formats that express authority in a reviewable way, with rules that prevent the format from becoming an escalation path. A profile that can only narrow, and that an agent cannot rewrite, is a standard designed with this property in mind.

Keeping narrow permissions sustainable

Least privilege has a well-known failure mode. Narrow permissions block legitimate work, friction accumulates, and eventually someone widens the grant to stop the complaints. The wide grant then outlives the reason for it.

Three practices keep narrow permissions workable rather than aspirational.

Make denials visible and explicable. A system that can explain why a specific action was denied turns an obstacle into information. Policy that cannot be interrogated becomes policy nobody trusts.

Provide a structured request path. When an agent needs a capability it lacks, recording that as a proposal with a written rationale produces exactly the artifact a reviewer needs. A request with a reason is a decision; a blocked task with no channel is pressure.

Narrow against evidence, not speculation. Start with roughly what people already had, then reduce based on what access records show is actually used. Narrowing against usage data is achievable. Narrowing against a guess produces a stream of requests and eventually a wildcard.

Practices that preserve it

1. Start read-only. Most of the value and almost none of the risk. Add write capability one action at a time.
2. Never rely on prompt instructions for limits. Write them if you like, and do not count them.
3. Scope credentials rather than trusting behavior. The control that holds when everything else has a bug.
4. Bound steps, time, and spend. A confused agent without limits runs until something external stops it.
5. Prefer reversible actions. The cheapest boundary available.
6. Gate on irreversibility, not on everything. So that gates keep being read.
7. Apply the adversarial test before deployment. And write down the answer.

A progression that works

Teams that end up with well-bounded agents rarely design the whole authority model up front. They follow a progression, and the order is what makes it survivable.

1. Read-only, narrow scope. Useful tools that change nothing, over a small set of sources. Most of the value, almost none of the risk, and it teaches you what agents actually reach for.
2. Limits before the second tool. Steps, wall-clock time, spend, and repeated-failure detection. These take an hour and are the difference between a confused agent that stops and one that runs until a bill notices.
3. Recording from the start. Not a boundary itself, and the thing that makes every subsequent decision evidence-based rather than speculative.
4. One reversible write. Draft, branch, or staging table. Learn what goes wrong when the agent produces output that persists, while the worst case is still wasted work.
5. Scoped credentials before broader access. Before widening what an agent can touch, make sure the credential itself cannot exceed it. This is the control that holds when others have bugs.
6. Approval gates on irreversible actions. Showing the specific action, and only for the actions that warrant it.
7. Delegated identity when more than one person uses it. The point at which a shared agent account becomes a privilege escalation path is the point at which several people can trigger it.
8. Narrow against usage. After a few months of records, reduce grants to what was actually used. This is the only version of narrowing that survives contact with real work.

The progression matters more than any individual item. Teams that start at step six, with elaborate approval machinery over an agent whose credentials can do anything, have built friction rather than a boundary.

What it is not

Bounded is not the same as restricted. A well-bounded agent can have substantial capability. The property is that the capability is deliberate and enforced, not that there is little of it.

Bounded is not the same as safe. Boundaries limit what can go wrong; they do not make the work correct. An agent perfectly constrained to the wrong action performs it reliably.

Bounded is not achieved by a model provider's safety training. That training reduces the likelihood of certain outputs. It is not a boundary, because it depends on the model, and your boundary should not.