The question people ask about agents is how capable they are. The question that determines whether an agent is safe to deploy is what it is allowed to do without asking. Those are different questions, and the second one is answered by engineering rather than by model choice.
Instructions in a prompt are not a permission system. They are a suggestion that a sufficiently confused or sufficiently manipulated model will disregard. Real constraints live in credentials, scopes, and approval gates.
What changed in 2026
- Agent identity separated from user identity. Running agents under their own service accounts, with their own scoped tokens, moved from best practice to baseline expectation.
- Reversibility replaced risk as the sorting axis. Teams found that classifying actions by how hard they are to undo produced far more usable approval tiers than trying to rank abstract risk.
- Approval fatigue got measured. Data on how quickly humans stop reading approval prompts pushed designs toward fewer, better-targeted gates.
- Audit expectations tightened. Regulated industries began requiring per-action attribution for agent-initiated changes, which is impossible when the agent uses a human's credentials.
Tiering by reversibility
| Tier |
Examples |
Control |
| Trivially reversible |
Reading, searching, drafting, generating a preview |
Autonomous, logged |
| Reversible with effort |
Creating a branch, adding a calendar event, filing a draft |
Autonomous, logged, notify after |
| Reversible but visible to others |
Sending an internal message, commenting on a ticket |
Autonomous within a rate limit |
| Hard to reverse |
External email, payment, production deploy, data deletion |
Explicit approval every time |
| Irreversible |
Wire transfer, public post, destructive migration |
Approval plus a second factor or second human |
The discipline this table enforces is that the top three rows should be genuinely autonomous. If everything requires approval, users learn to approve without reading, and the gate on the bottom two rows — the ones that actually matter — stops working. Spending your approval budget on low-stakes actions is how the control fails.
Credentials over instructions
The single most effective control is not telling the agent what not to do; it is not giving it the ability. An agent with a read-only database credential cannot drop a table regardless of what a poisoned document tells it. An agent whose token is scoped to one calendar cannot read the whole workspace.
That means the design work is in credential scoping, not prompt writing. Give each agent its own identity. Scope its tokens to the narrowest resource set that lets it do its job. Use short-lived credentials that expire rather than long-lived ones that leak. Where the agent needs elevated access occasionally, make that a separate credential behind an approval step rather than a permanent grant.
This matters especially when agents reach external tools. Every connected server is a capability grant, and the risks in MCP security risks are largely permissions problems wearing a protocol costume. Combine that with the reality that any retrieved content can carry instructions — the defenses in prompt injection defense assume the agent cannot do catastrophic things even if the injection succeeds.
Common mistakes
- The agent runs as a human user. Now nobody can tell from the audit log whether a person or a model made the change.
- Approval on everything. Fatigue sets in within days and the gate becomes a formality.
- Permanent elevated credentials for occasional needs. Scope the common case tightly and gate the exception.
- No rate limits on autonomous actions. An agent stuck in a loop sending messages is a permissions failure even though each individual action was allowed.
- Approval prompts that do not show the actual payload. Asking a human to approve "send an email" without showing the email is not review.
FAQ
Should approval be per-action or per-session?
Per-action for the hard-to-reverse tiers. Session-level grants sound convenient and remove exactly the control you were trying to keep.
How do I stop a runaway agent mid-run?
Design a kill path before you need one: a flag the agent checks, revocable short-lived credentials, and rate limits that fail closed. Do not rely on being able to catch it manually.
Does a human approving every risky action defeat the point of automation?
No, if the tiers are right. The value is in the autonomous majority of steps. Gating the handful of irreversible ones costs little time and prevents the incidents that would end the program.
How much should be logged?
Every action with its arguments, the agent identity, and the run it belonged to. Redact sensitive payloads but keep the fact of the action and enough to reconstruct what happened.
Where to go next
For the tracing that makes agent actions auditable, read AI agent observability. For the connector risks that permissions have to contain, MCP security risks, and for structuring multi-agent chains safely, AI agent handoff patterns.