Your organization has AI policies in place. You've documented which data agents can access. But here's what matters: can you prove an agent's access ended when its job did?
If you're preparing for a SOC 2 Type II or ISO/IEC 27001 surveillance audit, auditors will ask exactly that question. They won't accept "we have a policy" as evidence. They'll want logs showing when access was granted, what the agent did, and when credentials were revoked. This checklist helps you build that evidence trail before your next assessment.
Prerequisites
Before you start this checklist, confirm you have:
- An inventory of AI tools and agents currently connected to company systems, including shadow AI discovered through network monitoring or user surveys.
- Access to identity and access management (IAM) logs that capture credential issuance and revocation events.
- Documentation of your data classification scheme so you can map which AI tools touch sensitive data. ISO/IEC 27001 Clause 8.2 requires you to classify information according to sensitivity.
- Named owners for each AI integration who can authorize access and respond when an agent oversteps its scope.
Access Revocation Checklist
1. Map AI Agent Permissions to Specific Tasks
Done when: Each AI tool has a documented scope statement that names the systems it can access, the data classification levels it can reach, and the business function it supports.
What good looks like: Your scope document includes expiration conditions. Example: "GitHub Copilot for the platform engineering team accesses private repositories in the core-services organization. Access terminates when the sprint ends or when the engineer's employment ends, whichever comes first."
Framework tie: SOC 2 CC6.2 requires logical access controls that restrict access to authorized users. Your scope statement is the control design; your revocation process is the operating effectiveness.
2. Implement Session-Based Access for Agents
Done when: AI agents receive time-limited credentials that expire automatically, not persistent API keys that remain valid indefinitely.
What good looks like: An agent receives a token valid for eight hours. When the token expires, the agent cannot make new API calls until a human re-authorizes it. Your IAM system logs both the grant and the expiration event.
Framework tie: ISO/IEC 27001 Annex A 5.18 (Access Rights) requires you to review and adjust access rights. Session expiration is a technological control that enforces time-bounded access without waiting for manual review.
3. Separate Agent Credentials from User Credentials
Done when: AI tools authenticate with service accounts, not with the personal credentials of the employee who launched them.
What good looks like: When an engineer uses an AI coding assistant, the tool authenticates as svc-ai-copilot-eng with least-privilege access to code repositories. The service account cannot access HR systems, financial data, or customer records, even if the engineer's personal account can.
Framework tie: This addresses privilege creep. Service accounts with narrow scope remove ambiguity about what AI tools can access.
4. Log Every Data Access Event with Agent Attribution
Done when: Your SIEM or log aggregation platform captures which AI agent accessed which resource, at what time, and on whose authority.
What good looks like: A log entry reads: 2025-01-15T14:32:18Z | Agent: svc-chatbot-support | Action: READ | Resource: customer_db.orders | Authorized_by: [email protected] | Session_ID: abc123. You can trace this event back to the employee who authorized the access.
Framework tie: ISO/IEC 27001 Annex A 8.15 (Logging) requires you to produce, store, and protect event logs. Your logs must include "who authorized this" to demonstrate accountability during an audit.
5. Automate Revocation Triggers
Done when: Access terminates automatically when predefined conditions occur: task completion, session timeout, employee offboarding, or policy violation detection.
What good looks like: Your IAM system receives a webhook when a Jira ticket closes. The webhook triggers a script that revokes the AI agent's access to the project repository. No manual intervention required.
Framework tie: SOC 2 CC6.1 requires timely deprovisioning. "Timely" means minutes or hours, not days. Automation is the only way to meet that standard at scale.
6. Monitor for Access Outside Intended Scope
Done when: You have alerting rules that flag when an agent accesses data classification levels or systems not listed in its scope statement.
What good looks like: An AI agent authorized to read product documentation triggers an alert when it attempts to access the employees table in your HR database. Your security team investigates within the hour.
Framework tie: ISO/IEC 27001 Annex A 8.16 (Monitoring Activities) requires continuous monitoring of information security events. Real-time detection is the difference between a contained incident and a compliance finding.
7. Conduct Quarterly Access Reviews for Active Agents
Done when: Every 90 days, you produce a report listing all AI agents with active credentials, their authorized scope, and their actual usage patterns. Business owners confirm whether access should continue.
What good looks like: Your Q1 review reveals that three AI tools haven't been used in 60 days. You revoke their credentials before the next audit cycle. You also discover that a marketing automation agent accessed customer payment data, outside its documented scope, and you initiate an incident response.
Framework tie: ISO/IEC 27001 Annex A 5.18 requires periodic review of access rights. SOC 2 CC6.2 requires you to demonstrate that reviews actually happened and that you acted on the findings.
Common Mistakes
Relying on user self-service revocation. Employees who connected an AI tool rarely remember to disconnect it. They won't voluntarily revoke access later.
Treating AI agents like human users in your IAM system. Agents don't have managers to approve access reviews. They don't take vacation. They don't forget passwords. Your user lifecycle management process doesn't fit. Build a separate agent lifecycle process.
Logging authentication events but not authorization decisions. Knowing an agent logged in doesn't tell you whether it was allowed to access sensitive data. Log both the "who" and the "what they're allowed to do."
Next Steps
Start with your highest-risk AI integrations: agents that access customer data, financial systems, or source code repositories. Implement items 1, 2, and 5 from this checklist for those tools first. Then expand to lower-risk agents.
If your next audit is within six months, focus on item 4 (logging) and item 7 (access reviews). Auditors will ask for evidence that you know what your agents did and that you reviewed their access. You can't produce that evidence retroactively.
Your AI policy means nothing if you can't enforce it at the moment an agent acts. This checklist turns policy into verifiable controls.
