An AI agent may need to read a record, prepare a response or update a system. Each operation raises a basic question: whose authority is being used, and what is the agent allowed to do? Identity and permissions give the application a way to answer that question at the point of action.
An agent can operate on behalf of a signed-in person with appropriately delegated access, or it can use its own limited service identity for background work. The right choice depends on the task and the systems involved. A model instruction saying “only access this customer” is not a substitute for a permission check.
Choose An Identity For The Task
For a user-initiated request, delegated access can let the application check what that person may view or change. For a scheduled background task, a service identity may be more appropriate, with permissions assigned for its specific job. In either case, the downstream service must enforce the permitted action and resource scope.
Imagine a hypothetical support agent helping with an order. It can retrieve the relevant order for an authorized user and draft a response. A refund uses a separate operation with its own permissions and, if company policy requires it, a person's approval. The review should show the order, amount and proposed action before it is executed.
A service identity should not quietly inherit an administrator's broad access for convenience. Give it only the operations and data it needs, document the reason and review the grant as the workflow changes. Credentials need secure storage, rotation and revocation; do not place broad secrets in prompts or untrusted execution environments.
Enforce Access Where Tools Run
Authenticate the caller and authorize each tool request on the server. Check both the operation and the target resource: permission to read one order does not grant access to every customer record. Validate inputs separately, and do not trust a model-produced user ID as evidence of identity.
If the agent retrieves documents through multiple search paths, apply the user's access rules consistently before content reaches the model. Caches and indexes need to reflect permission changes. A document or tool result may contain instructions, but it cannot expand the agent's rights; see prompt injection in AI agents.
Make Approval Specific And Time-Bound
For an action requiring human review, present the actual change and its context. Record the approval decision and who was authorized to make it. Before execution, check that the approval still applies, the record has not changed in a material way and the agent still has permission to act.
An approval is not a general grant to perform unrelated actions later. If a request times out after a side effect may have occurred, check the destination before retrying. When the result cannot be determined reliably, preserve the uncertainty and route it for review.
Audit And Revisit Permissions
Keep a privacy-conscious record of the identity, tool, target, outcome and relevant approval. Avoid logging secrets or full private records when an identifier is enough. Review unused permissions and revoke access when an agent or integration is retired.
Test denied and expired access, changes in a user's role, cross-customer requests and attempts to use a read tool for a write. Evaluate both the final answer and the actions attempted. Clear tool design supports the workflow, but the enforced permissions remain the system's responsibility.
