Key takeaways
- Give each production agent a distinguishable non-human identity. Borrowing a user's session hides which actor performed the action and inherits permissions unrelated to the task.
- Scope access across resource, action and context. Permission to update a CRM is too broad; permission to update named fields on assigned records during one approved job is testable.
- Separate read, propose and execute. Many useful agent steps need broad reading and narrow writing, with consequential execution behind a person or deterministic policy.
- Grant for the run when possible and revoke on completion, expiry or retirement. Standing credentials turn a one-hour task into an open-ended blast radius.
- Log both allowed and denied authorization decisions with the identity, requested action and policy version. Denials reveal permission drift before an incident does.
Start with a distinguishable agent identity
An agent may act for a person without becoming that person. NIST's 2026 concept paper frames identification, authentication, authorization and delegation as separate questions for software and AI agents. That separation is useful: the event should say which non-human identity called the tool and which user or process delegated the task.
Reusing a human session breaks that chain. The destination system records the employee, while the orchestration layer records the agent, and neither can prove the relationship alone. It also gives the run every unrelated permission the employee accumulated. Production access should use a managed, revocable identity that can be joined to the agent inventory and audit trail.
The six-part permission envelope
| Dimension | Question | Example boundary |
|---|---|---|
| Identity | Which agent and delegated principal are acting? | supplier-intake-prod acting for process owner 17 |
| Resource | Which systems, collections and records are reachable? | Supplier cases assigned to EMEA Operations |
| Action | May it read, propose, create, update, send or delete? | Read case; propose status and reply; cannot delete |
| Field | Which attributes may be read or changed? | May update triage fields; bank fields are excluded |
| Context | Which run, purpose, network or approval must be present? | Only during an approved onboarding run with matching case ID |
| Time | When does the grant begin, expire and revoke? | Issued for the run; expires after 30 minutes or on completion |
NIST SP 800-53's least-privilege control is older than modern agents and still does the essential job: authorize only what is necessary for assigned tasks. The hard part is not agreeing with the principle. It is writing “necessary” at resource and action level before the run starts.
Separate read, propose and execute
Many workflows need wide enough read access to assemble context and very narrow authority to change the world. Treating a tool as one permission collapses those needs. Split it into read, propose and execute wherever the destination allows it; otherwise put an enforcement proxy in front of the broad credential.
The agent may read one customer's order, shipment and support case after the customer authenticates. It may calculate eligibility with deterministic rules and propose a refund with cited fields.
It cannot alter the payment account or execute a refund. A policy service checks amount and reason. Approved low-value cases may execute through a narrowly scoped refund action; everything else waits for a reviewer who sees the exact amount, destination and evidence.
The run's credential expires after use. A repeated request carries the same idempotency key, so a network retry cannot create a second refund.
Test denials and revocation, not just the happy path
A permission review that only confirms intended access misses the edges most likely to fail. Run negative tests: another department's record, a forbidden field, an expired credential, a changed proposal, a tool added after approval and a retry after successful execution. Each should deny or route to a named approval state and write an event.
Review denials as product evidence. Repeated legitimate denials may mean the envelope is too narrow or the process specification is wrong. A sudden absence of denials after a policy change can be more worrying: the enforcement point may have disappeared.
| Attempt | Required result |
|---|---|
| Use the owner's existing browser session | Blocked; agent identity is required |
| Read an adjacent record to improve context | Blocked unless the record filter explicitly allows it |
| Reuse yesterday's approval after changing the amount | Blocked; the proposal binding no longer matches |
| Call the tool after the run completed | Blocked; grant expired and revocation is logged |
Limitations and when not to use this
- This is an architecture pattern, not a configuration guide for a specific identity provider or SaaS application. Available controls vary by destination.
- Short-lived credentials reduce exposure but do not correct an overly broad permission during their valid window. Resource, action and field scope still matter.
- Human approval does not replace authorization. The reviewer should not be able to grant an action outside the agent's maximum policy boundary.
Sources
- Software and AI Agent Identity and Authorization concept paper — NIST NCCoE Accessed 29 July 2026
- SP 800-53 Rev. 5: security and privacy controls — NIST Accessed 29 July 2026
- AI Risk Management Framework Core — NIST Accessed 29 July 2026
Write one permission envelope
List one agent's identity, resources, actions, record filters, time limit and approval boundary, then remove every grant not used by the normal path.
Write one permission envelopeUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.