Who can an AI agent act for? Design tool permissions for production workflows

Separate the user, agent and service identities

A service account that can read every customer's record makes a demo easy. It also makes the agent's real authority hard to explain. Name three actors separately: the user requesting work, the agent runtime making decisions and the service executing an API call. Record which actor is accountable for the result and whether the agent is acting on behalf of a user or under its own service role.

NIST's 2026 concept paper frames agent identity, authorization and audit as open implementation concerns. It is a draft concept paper, not a finished certification standard. In practice, model instructions should never be the only boundary. Bind delegated access to a specific task, resource, allowed operation and expiry so a later prompt cannot silently expand the grant.

Evidence: NIST NCCoE: Software and AI agent identity and authorization concept paper

Write the permission matrix before writing the prompt

For a hypothetical claims assistant, a matrix might allow it to read an assigned claim and draft a summary, require a reviewer to approve a customer message, and deny payment or deletion outright. Add the resource condition: assigned claim only, within the current tenant and session. The same verbs can have very different risk when the target changes from a draft to a financial record.

Put this matrix in policy code or a service the tool handler calls. Check it again at execution, even if the UI showed an approval earlier; the target resource or user role may have changed. A human approval should name the exact proposed action and its material parameters. A generic 'continue' button is poor evidence of consent to a specific write.

• Record actor, action, resource and purpose for each tool.
• Deny by default when a grant is missing or expired.
• Bind approval to the exact write parameters.
• Keep write and read scopes separate.

Evidence: NIST NCCoE: Software and AI agent identity and authorization concept paper · NIST: RFI response analysis on AI agent security

Keep retrieved content out of the authority path

An email, document or web page can carry instructions that look like part of the user's task. The agent may need to read that content, but it should remain data. Do not let a sentence in a retrieved document change a tool's permission, the approved recipient, or the account being billed. The execution service should use trusted context and policy state, not a generated explanation, to authorize an action.

Test the difference with a hostile fixture: a document asks the agent to send a private attachment to a new address. The model may mention it in a draft, but the send tool must reject the unapproved recipient and attachment. NIST's RFI analysis reports security concerns about agents; it does not establish that one prompt-filtering method is sufficient to prevent this failure.

Evidence: NIST: RFI response analysis on AI agent security

Make grants short-lived and actions reconstructable

Issue permissions for the duration and scope of the task rather than reusing a long-lived, broad credential. When a user revokes access or a reviewer rejects an action, ensure queued work cannot execute it later. For each attempted action, retain a policy decision ID, actor, target, approval reference and outcome. Apply your data retention and privacy rules to the log itself.

Rehearse role changes, expired grants, cross-tenant identifiers and repeated requests. Verify that a denied action produced no downstream side effect and that an approved action can be traced to a real person or service policy. The result is a workflow a reviewer can defend, not merely a transcript of what the model said.

Evidence: NIST NCCoE: Software and AI agent identity and authorization concept paper