Instructions are not access control.

A prompt can guide behavior. It cannot revoke permission.

“Never delete production data.” “Do not send an email without approval.” “Only read this folder.” These are sensible instructions. They may reduce accidental behavior when the model interprets the situation correctly.

But if the agent still holds a credential that can delete the database, send the email, or read every folder, the instruction has not changed what the system is authorized to do. It has asked a probabilistic component to police itself.

Real access control exists where the action is executed: the database role, OAuth scope, API policy, filesystem boundary, approval service, or downstream authorization check. The model should be unable to cross that boundary even when it hallucinates, misunderstands a request, follows malicious content, or is directly manipulated.

Why good instructions still fail

Language models produce outputs from context. That context can contain ambiguity, missing facts, adversarial instructions, poisoned documents, tool output, or previous model mistakes. Even a well-written system prompt competes with a long and changing chain of information.

The failure does not need to look dramatic. An assistant may misread which customer record is active. A document summarizer may encounter an indirect prompt injection embedded in a file. An operations agent may correctly identify a task but choose the wrong account or environment. The model can be sincere and still be wrong.

Security controls therefore need to assume that the model will eventually produce an undesirable instruction. The job of the surrounding system is to keep that instruction from becoming an unacceptable action.

OWASP calls the risk excessive agency

OWASP LLM06:2025 defines excessive agency as the ability of an LLM-based system to perform damaging actions after unexpected, ambiguous, or manipulated model output. It identifies three root causes:

Build the boundary outside the model

The safest pattern is not a smarter warning. It is a smaller capability surface. Give the agent the minimum tools, minimum functions, minimum data, and minimum authority needed for the current job.

Five controls that materially reduce the blast radius

1. Remove capabilities the workflow does not need.

   A summarizer needs read access, not send and delete. A quote builder needs draft creation, not authority to execute a purchase.

2. Use narrow, task-specific credentials.

   Create a separate identity for the agent. Scope it to the specific tables, mailboxes, repositories, actions, and environment required for the task.

3. Require approval at the action boundary.

   High-impact actions should become pending requests. Approval belongs in the extension or downstream system, where the model cannot waive it.

4. Execute in the user's context.

   When an agent acts for a person, preserve that person's authorization scope rather than routing every request through one privileged service account.

5. Log, rate-limit, and make recovery real.

   These controls do not prevent excessive agency, but they shorten detection time and cap damage. Backups must be isolated from the same credential and failure path.

Approval gates should match consequence

Human approval is not necessary for every action. Requiring confirmation before reading a public FAQ would make the system unusable. The gate should appear where the consequence becomes difficult to reverse or affects another person.

What to ask before connecting an agent

• Which exact actions can the agent perform—not merely which actions is it instructed to perform?
• What identity and scopes does each tool use?
• Can the agent reach production directly?
• Which actions require approval, and can the model bypass that approval path?
• Are authorization checks enforced by the downstream system on every request?
• Can one customer's context or data be reached from another customer's session?
• Are backups isolated from the credentials capable of changing production?
• Can operators reconstruct what the model saw, decided, and attempted?

Standards are moving toward identity and authorization

OWASP's mitigation guidance centers on minimizing extensions, functionality, permissions, and autonomy; executing tools in the user's context; requiring approval; and enforcing authorization downstream rather than asking the LLM to decide whether an action is allowed.

NIST's AI Agent Standards Initiative similarly identifies agent authentication, identity infrastructure, authorization protocols, and security evaluation as foundational work for secure agent adoption. The direction is clear: trustworthy agency depends on enforceable identity and policy around the model.