An AI agent that can explain an invoice and an agent that can pay it are different products, even when they use the same language model. The second needs a clear answer to who authorized the payment, which account can be used, what amount is permitted and what evidence must be preserved. Model quality influences the decision. A permission system determines whether the decision can become an action.
Consider a proposed purchasing assistant. It reads a request, finds a supplier and prepares an order. The organization may want those steps to happen automatically while reserving payment or a new supplier account for a separate authorization. That is a useful product boundary. Giving the assistant a broad finance login and asking it to be careful leaves the boundary inside a probabilistic conversation instead of enforcing it at the action layer.
Separate identity from authority. Identity establishes which agent or workload is making the request and, where relevant, on whose behalf it acts. Authority describes the resources and operations it may use. A recognizable agent identity does not imply permission to touch every account belonging to the user. Likewise, a valid login does not establish that a particular purchase belongs to the approved task.
The permission decision needs enough context to be meaningful. Reading an invoice, changing a supplier’s bank details and transferring funds may all live behind one finance integration, yet their consequences differ. Scope operations individually where the service supports it. Constrain destinations, amounts, resource identifiers and duration where practical. A generic “finance access” switch is convenient to implement, but it gives the product little ability to distinguish routine work from a consequential exception.
Enforcement should sit outside the language model. A tool service can reject an operation that exceeds the granted scope even when the model produces a plausible explanation for it. Credentials can be limited to the necessary resources, and a broker can issue narrower task credentials instead of revealing a permanent account secret. These controls still need careful implementation; wrapping an unrestricted credential in another service does not narrow its power unless the service actually checks and limits its use.
Approval should describe the concrete action. “May I continue?” gives the user little to evaluate. “Pay this amount to this existing supplier for this invoice” carries more useful information, particularly when it includes the source evidence and any differences from the original request. Routine authorized steps should not trigger an endless chain of prompts. Reserve interruption for a real boundary, and make the boundary understandable.
Delegation introduces another question. If one agent asks a second agent to perform part of a task, the second should receive only the authority needed for that part. The original restrictions need to survive the handoff. Otherwise a carefully scoped front-end assistant can become a route to a more privileged background worker. Logging the conversation alone will not prevent that escalation.
Record what the system did as well as what it intended. Useful records connect the initiating request, effective permission, tool operation, destination, result and any approval. Sensitive material in logs needs protection, and credentials should not become incidental debugging output. A failed action should have a clear status so a retry does not quietly repeat an operation that already succeeded. Financial or external actions may need reconciliation rather than blind repetition.
NIST’s work on software and AI agent identity and authorization shows why this deserves its own engineering effort. Its September 2026 update identifies the software development lifecycle as the first implementation use case for demonstrating agent identification, authentication and authorization. That is a project direction, not a declaration that one finished universal agent-permission standard now solves the problem.
A useful evaluation therefore asks two questions side by side. Can the agent understand the task well enough to propose the right operation? Can the surrounding system prevent operations outside the authority actually granted? Better reasoning improves the first answer. A well-designed permission model makes the second answer dependable enough for the product to do useful work.