Direct answer: AI agents should use the same identity and authorization principles as other production software: authenticated identities, least-privilege permissions, server-side policy enforcement, explicit approval for consequential actions, short-lived authorization, audit logs, and immediate revocation. A prompt telling an agent to “ask first” is not an approval system.
Identity comes before permission
Every action must be attributable to an authenticated identity. Some agents use a dedicated service identity with permissions tied to the role. Others act on behalf of the current user and inherit that person’s access. Multi-user systems may need both: an agent service identity plus delegated user context.
Avoid shared administrator credentials. They erase accountability and give every workflow the maximum consequence of a mistake. Separate identities by environment and role so a support workflow cannot silently gain finance or infrastructure access.
The connected system or a trusted authorization layer must enforce the decision. The language model can propose an action, but it should never be the authority that decides whether its own request is permitted.
Design tools as narrow capabilities
A tool should expose the smallest useful business action rather than a raw system interface. “Create a support case with these validated fields” is safer than “run any database query.” “Draft a refund request” is safer than unrestricted payment API access.
Validate structured arguments, restrict destinations and value ranges, cap record counts, and reject unexpected fields. Use allowlists for actions and resources. Sensitive operations should require fresh authorization rather than relying on a permission granted during an earlier conversation.
Narrow tools also improve evaluation. Test cases can verify whether the agent selected the correct capability, supplied valid arguments, respected constraints, and handled the result.
Create an authority ladder
| Authority level | Agent behavior | Example |
|---|---|---|
| Observe | Read approved context and report | Summarize an account or queue |
| Draft | Prepare an action for review | Draft a customer response or record change |
| Execute low risk | Act within strict limits | Add an internal tag or schedule an allowed slot |
| Approval required | Pause with evidence and exact proposed action | Send an external message or issue a bounded refund |
| Prohibited | Refuse and escalate | Change access policy or make a final regulated decision |
Assign each tool action to a level before launch. The same tool may have different levels depending on amount, destination, record sensitivity, confidence, or customer status. Policy should be explicit and versioned.
An approval must bind to one exact action
A useful approval request shows the reviewer the affected record, proposed change, evidence, consequence, and reason for escalation. The approval should be tied to a specific payload and expire after a short period. If the action changes, the agent must request approval again.
Record who approved, when, what they saw, and what executed. Prevent replay so one approval cannot authorize repeated actions. Support rejection, edits, timeouts, and reassignment. When nobody responds, the workflow should stop or follow a predefined safe fallback.
Approval interfaces should make review efficient without hiding material context. A stream of low-quality approvals creates fatigue and encourages rubber-stamping, so thresholds must be tuned using observed cases.
Permissions can change during the workflow
Agents often begin with read access, then request permission for a specific write. Use short-lived credentials or capability tokens where practical. Verify authorization again at execution time because the user, record, policy, or approval may have changed while the agent was reasoning.
Context should not expand merely because the agent asks. Retrieval and tool layers should filter data independently. In a multi-agent system, one agent should not automatically inherit another agent’s access; each handoff should carry only the context and capabilities required for the next step.
Revocation must be immediate. Operators need to disable an agent, credential, tool, integration, or action class without waiting for a redeployment.
Audit and evaluate the control plane
- Log identity, requested action, validated arguments, policy decision, approval, tool result, and final status.
- Alert on unusual volume, repeated denials, new destinations, privilege changes, and approval bypass attempts.
- Test that prohibited actions remain unavailable even when instructions are manipulated.
- Test expired approvals, changed records, revoked access, duplicate requests, and unavailable approvers.
- Review whether permissions remain necessary as the workflow changes.
- Run regression evaluations whenever tools, policies, models, or prompts change.
Logs should be understandable to operators and protected as sensitive data. The goal is to reconstruct what happened without granting broad access to prompts, customer records, or secrets.
A production permission review
For each workflow, create a matrix of identities, resources, actions, conditions, approval requirements, and owners. Compare it with the actual permissions in connected systems. Differences between the documented policy and deployed access are defects.
Run the first production phase with read-only or draft authority. Observe which approvals are frequent, which exceptions appear, and where the agent requests unnecessary context. Expand only the smallest action supported by evaluation and operating evidence.
Least privilege is not a one-time launch task. Review access after incidents, workflow changes, employee changes, new integrations, and periods of inactivity.