Permission drift is what happens when an AI agent slowly becomes more powerful than the team intended. It rarely starts with one dramatic mistake. More often, a support agent gets a new CRM field, a browser agent receives a broader allowlist, a tool schema gains an export option, a temporary incident override never gets removed, or a test credential stays active after launch. Each change looks reasonable in isolation. Together, they can move the agent from controlled automation to a system that can read too much, send too much, or act without the review the team originally promised.
This is a common production problem because AI agents sit between product workflow and security policy. Product teams keep adding capabilities because users ask for fewer handoffs. Engineering teams add tools because the old flow was too manual. Support teams ask for more context because partial answers create frustration. None of that is wrong. The risk is that permission changes often happen faster than the review process around them.
This checklist is for teams that already have an AI agent in pilot or production. Use it monthly, after any major tool change, before expanding the agent to a new customer segment, and whenever the agent moves from read-only assistance to write-capable workflow execution.
1. Start from the permission baseline
Do not begin the review from memory. Pull the actual baseline: tool list, OAuth scopes, service-account roles, database permissions, browser origins, file-store access, queue permissions, outbound destinations, approval rules, and tenant boundaries. The baseline should describe what the agent is allowed to read, transform, write, send, delete, purchase, publish, or execute.
The most useful format is a simple inventory with four columns: capability, owner, current scope, and approval requirement. If the team cannot produce that inventory quickly, that is already a finding. A production agent should not depend on one engineer remembering which credential or workflow setting controls a risky action.
2. Compare declared permissions with runtime reality
Many teams document one permission model but run another. The README says the agent can only draft replies, but the integration token can send messages. The policy says exports require approval, but the tool accepts an export parameter without a reviewer. The workflow says the agent is tenant-scoped, but logs show cross-tenant search results in the prompt context.
Review runtime evidence, not only configuration pages. Look at recent tool calls, approval logs, browser traces, API audit logs, and failed attempts. The question is not “what did we intend?” It is “what could the agent actually do last week?”
3. Check tool schema growth
Tool schemas tend to grow. A harmless lookup tool may gain update fields. A ticket tool may gain assignment, tagging, and close actions. A document tool may gain export and share options. An email tool may gain arbitrary recipients instead of approved internal queues. These small schema changes are one of the easiest ways for permission drift to enter an agent system.
Diff the current tool schemas against the last approved version. Pay special attention to new write parameters, free-text destinations, file attachment support, bulk actions, admin fields, and “advanced” options that were added for one customer. Any new action category should trigger a review of approvals, logging, tests, and rollback.
4. Revisit approval boundaries
Approvals often drift in two directions. First, teams reduce approvals because early users complain about friction. Second, approvals stay in the UI but lose the context needed for a real decision. A reviewer may see “approve response” without seeing the source records, external destination, customer tier, policy rule, or data being sent.
Review the last twenty approvals for high-risk actions. Could a reviewer understand the business effect in under thirty seconds? Could they edit the output, reject it, or escalate it? Are approvals required before the action, or only logged afterward? If the approval screen has become a rubber stamp, the boundary has drifted even if the checkbox still exists.
5. Find stale temporary access
Temporary access is one of the most reliable sources of drift. During incidents, demos, migrations, and customer onboarding, teams grant broader access to keep work moving. The problem is not the emergency change. The problem is forgetting to remove it once the emergency ends.
Search for permission grants with names such as test, temporary, migration, demo, backfill, support override, incident, beta, or admin. Check service accounts, API keys, feature flags, allowlists, browser profiles, queues, and internal tools. Every temporary grant should have an owner, reason, expiry date, and removal evidence.
6. Review data movement paths
A permission review that only checks read access is incomplete. Data movement is where many agent failures become real incidents. The agent may need to read customer records, but that does not mean it may paste them into a browser form, send them through email, attach them to a ticket, include them in a public issue, or store them in long-term memory.
Trace where sensitive data can go after the agent reads it. Include tool outputs, generated drafts, logs, traces, analytics events, support notes, exports, screenshots, downloaded files, and memory stores. If the agent can move data to a new destination, the destination needs its own policy check and test case.
7. Separate tenant expansion from feature expansion
An agent may be safe for one customer segment and unsafe for another. Internal users, small pilots, enterprise tenants, regulated customers, and admin workflows do not share the same risk profile. Permission drift often appears when a feature built for a narrow group becomes available to a broader group without a fresh review.
List which tenants, plans, roles, regions, and workflows can access each agent capability. Then compare that list with the original launch decision. If a capability moved from internal beta to all customers, or from read-only customers to production administrators, treat that as a new launch, not a routine rollout.
8. Test negative paths, not only happy paths
Permission drift is hard to see if tests only confirm that normal tasks still work. Add tests that ask the agent to exceed its current authority: send data to a new address, skip approval, update a restricted field, search another tenant, export a bulk file, use a browser page outside the allowlist, call an admin tool, or remember sensitive details for future use.
Each test should have an expected outcome: refuse, redact, ask for approval, stop, or escalate. Run the tests after tool changes, prompt changes, model changes, permission changes, and customer-segment expansion. When a negative test starts passing as a normal task, you have permission drift.
9. Check logs for silent boundary crossings
Logs can show drift before a user reports it. Look for blocked tool calls, repeated approval denials, tool calls with unusually broad parameters, cross-tenant search attempts, large exports, external destinations, high-risk browser clicks, and sensitive fields appearing in generated output. These signals do not always mean the agent caused harm, but they show where the boundary is under pressure.
Good logs record the policy decision, not only the final action. A reviewer should be able to see what the agent attempted, which rule matched, what data was involved, whether approval happened, and what the final result was. Without that trace, permission drift can hide inside successful-looking automation.
10. Assign an owner for every risky capability
Permissions without owners decay. Every tool, credential, broad scope, external destination, memory store, and approval exception should have a named business or engineering owner. The owner is responsible for deciding whether the capability is still needed, whether the current scope is too broad, and whether the tests still match the risk.
This does not need to become a large governance process. A monthly thirty-minute review can catch a lot if the inventory is current and the evidence is easy to read. The important point is that the owner reviews actual usage, not just a static configuration list.
Minimum review packet
For a practical permission drift review, keep these artifacts together: current permission inventory, last approved inventory, tool schema diff, approval-log sample, sensitive-data movement map, tenant and role exposure list, negative test results, stale-access cleanup list, and owner signoff. If a buyer asks how the agent remains controlled after launch, this packet is much stronger than a general statement about least privilege.
Related resources
- AI Agent Trust Boundary Review Checklist
- AI Agent Data Exfiltration Checklist
- AI Agent Tool Permissions Checklist
- OWASP Top 10 for Large Language Model Applications
- MITRE ATLAS
For a broader launch and post-launch review, use the AI Agent Readiness Self-Assessment or request an AI Agent Readiness Audit.