Authority is explicit

The principle

An agent should know what it may do, what requires approval, and where its responsibility ends. All three expressed in a form something enforces.

This is the property that separates an agentic system you can point at real infrastructure 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

The system prompt says: do not delete anything, do not send email without asking, only query these tables, never modify production.

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

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

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

Injection. An agent reads a document, a page, an issue, an email. That content contains text addressed to the agent, written by anyone who can write to those systems. If the system treats retrieved content as anything other than data, whoever can put text where the agent reads it can influence what it does. A prompt instruction is not a defense, because the attacker is writing into the same channel.

What enforcement actually is

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

• Capability scoping. The agent is given only the tools it should have. A tool that is not registered cannot be called. Simplest and most effective, and frequently skipped because giving an agent everything is easier during development.
• Argument constraints. The tool limits what it accepts. This file tool writes only under this directory. This email tool sends only to internal domains. Enforcement at the point of action, testable like any other code.
• Credential scoping. The credentials cannot perform the forbidden action. A read-only token cannot write regardless of what the agent attempts. The strongest form, because it holds even when everything else has a bug.
• Approval gates. Certain classes of action pause for a person, displaying the specific proposed action.
• Process isolation. A container or sandbox bounds what the agent can reach at all, which matters most for broad capabilities such as shell access 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 target.

The adversarial test

One question cuts through every discussion about agent safety, and I apply it literally before deploying anything.

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 works because it forces you to ignore every control that depends on the model cooperating, which is usually most of them.

Applied honestly the answer is often 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 those capabilities are unacceptable. Plenty of useful work requires them. The point 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 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.

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

That 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 gates that matter less effective than having fewer of them would have been.

Reversibility is the cheapest boundary

The most underused control is not a restriction. It is changing the action.

Where a reversible form exists, prefer it. Draft rather than send. Branch rather than push. Propose rather than apply. Soft delete rather than hard. Write to staging rather than to production.

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 the agent's output is a proposal by default, with a separate commit step, needs far fewer approval gates because the default action is already safe.

It also changes the economics of autonomy in a direction people underestimate. An agent that can only produce reversible outputs can be given much more freedom, because the worst case is wasted work rather than damage. If you want more autonomy, make the actions reversible before loosening the controls.

Whose authority is it

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

The common arrangement is that an agent has its own credentials, typically broad, and acts as itself regardless of who asked. Two failures follow at once. The agent becomes a way to reach things 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 records name a principal rather than a service account.

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

Combinations nobody designed

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

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

The shape is a read from a sensitive source combined with a write to a less sensitive destination. Once you look for it, it appears everywhere: a database reader plus a web request tool, a file reader plus an email sender, a ticket reader plus a code writer where ticket text is untrusted input reaching a repository, any read tool plus a memory write since memory is a durable and often shared destination.

Three responses help. Review the configured tool set as a whole rather than tool by tool. Scope tools per task so the dangerous combination only exists when the task needs it. And treat any write to a destination outside the current trust boundary as a gate regardless of how ordinary the tool looks.

This is also the strongest argument for small tool surfaces. Combinations grow much faster than tools, so an agent with forty tools has a review problem nobody will solve by inspection.

A progression that works

Nobody designs an authority model up front and then builds inside it. What works is 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 rather than what you assumed.
2. Limits before the second tool. Steps, wall-clock time, spend, and repeated-failure detection. An hour of work, and 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. You cannot instrument the past.
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 where it is warranted.
7. Delegated identity when more than one person uses it. The moment several people can trigger an agent is the moment a shared account becomes a privilege escalation path.
8. Narrow against usage. After a few months of records, reduce grants to what was actually used.

The ordering 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.

Keeping narrow permissions sustainable

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

Three things keep it workable.

Make denials 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. Start with roughly what people already had, then reduce based on what records show is actually used. Narrowing against usage data works. Narrowing against a guess produces a stream of requests and eventually a wildcard.

Where I find this hard

I want to be honest that this principle is easier to state than to live with, and three tensions come up repeatedly.

Enforcement points multiply

Every new tool is a new place where argument constraints have to be written, and it is easy for one to be added without them. This is exactly why normalizing resources into a small set of kinds matters: if every filesystem action from any tool resolves to a filesystem resource, one rule covers all of them and a new tool cannot silently introduce a gap. Getting that abstraction right took me longer than building the tools it governs.

Broad capabilities resist constraint

Shell access and code execution are the two capabilities where argument constraints are close to meaningless, because the argument is arbitrary. Containment has to move to the process boundary, which is a heavier and more operational answer than a tool-level check. Any system offering those capabilities and claiming fine-grained control is describing something it does not have.

Delegated identity is a real project

The strongest version of this principle is that an agent acts with the requester's permissions rather than its own. That requires identity infrastructure the agent can consult, credentials it can obtain on behalf of someone, and every downstream system honoring the distinction. For many organizations that is a quarter of work rather than a configuration change, and the intermediate position, meaning a dedicated agent principal with narrow grants and the requester recorded, is a reasonable place to stop while you get there.

None of these are reasons to abandon the principle. They are reasons to expect the work, and to be suspicious of anything that claims this comes free.

What this 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 something a model provider's safety training gives you. That training reduces the likelihood of certain outputs. It is not a boundary, because it depends on the model, and your boundary should not depend on the model.