An AI agent does not need a permanent identity with a steadily growing set of permissions. It needs a capability envelope for the current intent, valid for the current phase, with an explicit transition when the work changes from reading to mutation.
That sounds like ordinary least privilege. The agent-specific problem is that one conversation often moves through research, planning, implementation, deployment, and verification without acknowledging that each phase has a different risk model.
- Pattern
- Intent-scoped capability envelope
- Output
- Permission model
- Use when
- One agent session may inspect, modify, deploy, or verify across several systems
Delegation did not change the permission
In a read-only repository investigation, the requested evidence required commit history and exact diffs. Shell access was unavailable. Delegating the same request to another agent produced no new evidence because the delegated agent inherited the same harness restriction.
The failure was useful once it was named correctly: model identity was irrelevant. The execution context did not have the capability required for the requested proof.
Repeated delegation is a poor permission strategy. It obscures the policy decision, creates more partial summaries, and encourages the system to treat another model as an escape hatch. The right move is to change the capability envelope or narrow the claim.
Model the envelope as data
The permission decision should be reviewable before the agent acts.
| Intent | Typical capabilities | Explicitly excluded | Transition gate |
|---|---|---|---|
| Inspect | Read files, history, issues, logs, and metadata | Writes, deploys, secret values | Evidence gap requires a new source |
| Plan | Inspect plus create a proposed diff or runbook | Applying changes | Human accepts scope and rollback |
| Patch | Write within named repo paths; run local tests | Production mutation, broad cleanup | Diff and tests satisfy acceptance contract |
| Deploy | Execute one approved deployment path | Unrelated config changes, policy edits | Runtime checks and anomaly thresholds pass |
| Verify | Read runtime, browser, logs, and metrics | Remediation unless separately approved | Finding is reported or a new action is approved |
This matrix should not live only in a system prompt. The runtime should mint or select credentials that match the phase, record the envelope with the run, and reject calls outside it.
A compact envelope can look like:
{
"intent": "patch",
"resources": ["repo:service-a"],
"allow": ["files:read", "files:write:src/**", "tests:run"],
"deny": ["deploy:*", "secrets:read", "files:write:infra/**"],
"expiresAt": "2026-07-11T18:00:00Z",
"promotionRequires": ["reviewed_diff", "passing_targeted_tests"]
}The value is not the JSON shape. It is the separation between a declared intent and the capabilities that make sense for it.
Transitions deserve more scrutiny than commands
Teams often approve individual commands while allowing the session's authority to drift. I would reverse that emphasis. Review the phase transition, then let the agent operate inside the approved envelope without asking for permission on every harmless read.
Examples:
inspect -> patch: approve changed paths, non-goals, and the test plan.patch -> deploy: approve artifact identity, environment, rollback, and runtime checks.verify -> remediate: create a new action envelope. Do not let an observer silently become an operator.
This gives senior engineers a more useful control point. They review risk and blast radius instead of becoming a command confirmation service.
It also improves incident reconstruction. An audit can answer not only which tool call happened, but why the session had that authority at that moment.
Where intent is too coarse
Intent labels can become security theatre. Two "inspect" tasks may have very different sensitivity: reading public source code is not equivalent to reading production customer data. Resource scope, operation scope, time, environment, and data classification still belong in the envelope.
There is also a usability cost. Frequent phase transitions can slow low-risk work and train people to approve prompts mechanically. Use pre-approved envelopes for common bounded tasks, short expiry, and escalation only when the requested authority materially expands.
Finally, capability restriction does not replace output review. A read-only agent can still leak sensitive data into a draft or reach a damaging conclusion from partial evidence.
The policy test
For each agent workflow, ask:
- What intent is active now?
- Which resources and operations are necessary for that intent?
- Which capability would be surprising if it appeared in the audit log?
- What evidence permits promotion to the next phase?
- What happens when the required proof needs a capability the envelope lacks?
The last answer should be "return a precise blocker or request a new envelope," not "delegate until something works."
Authority should follow the work being approved, not the name printed on the assistant.