A Reddit thread from April 2026 hit the front page of r/sysadmin: "I found 3 AI agents in our Slack workspace that nobody on the team knew about. One has workspace admin scope. How do I even start auditing this?"
The top comment: "Start by checking your OAuth app list. You will probably find more."
This is increasingly common. AI agents do not announce themselves. They accumulate access quietly, through OAuth flows that take 30 seconds to complete, API keys pasted into a config file, MCP servers installed for a one-off productivity experiment. Three months later, someone asks: what actually has access to our systems?
This guide answers that question and shows you how to clean it up.
TL;DR: The 5 most common unauthorized agent access patterns are Slack bots with admin scope, MCP servers with broad filesystem access, n8n/Zapier AI flows, browser automation agents with session cookies, and AI email integrations with full inbox access. The audit covers OAuth app lists, API key usage, MCP configurations, and workflow automation platforms.
Why AI agent access is different from service account access
Traditional service accounts are provisioned by IT, documented in an access management system, and reviewed in access certification cycles. Someone approved them.
AI agent access often bypasses that process. A developer connects Claude to their Slack workspace to help draft messages. The OAuth flow takes 30 seconds. The permissions include channels:read, channels:history, groups:read (private channels), and users:read. Nobody reviewed that. It is not in any system. The developer moves to another project. The connection stays.
The agent identity problem is not about rogue employees. It is about informal access that accumulates without documentation, review, or a clear owner.
The 5 most common unauthorized AI agent access patterns
Pattern 1: Slack bots with admin scope
An engineer connects an AI assistant to Slack to help with drafting or searching messages. The OAuth request includes more permissions than needed, or the engineer clicks through without reviewing the scope.
How to find them:
Slack workspace settings > Manage apps. Filter for any app with channels:history (read all message history), groups:history (read private channels), or admin scope.
Risk: An AI agent with workspace admin scope can read all Slack messages, including private channels, direct messages (depending on OAuth scope), and channel archives. In a 50-person company, this is a significant data exposure.
How to fix: Check which apps actually need message history vs. just being able to post. Revoke and reinstall with minimal scopes for legitimate use cases. Remove apps that are no longer in active use.
Pattern 2: MCP servers with broad filesystem access
A developer installs an MCP filesystem server for Claude Desktop or Claude Code to help with a development project. They configure it with access to their home directory or the project repository root.
How to find them:
See the MCP shadow server discovery checklist in the MCP server security article. Key locations: ~/Library/Application Support/Claude/claude_desktop_config.json (macOS), .claude/ directories in project repos.
Risk: An MCP server with home directory access can read SSH keys, .env files with production credentials, browser cookies, and any other sensitive file in the user's home directory. If an AI session is manipulated via prompt injection, those files can be exfiltrated.
How to fix: Scope all MCP filesystem servers to specific project directories. Never configure root or home directory access for AI agent use.
Pattern 3: n8n, Zapier, and Make.com flows with AI nodes
An engineer builds a workflow automation that includes an AI step (calling OpenAI, Claude, or another LLM API). The workflow is connected to production services: CRM, email, database, Slack, Jira. The AI node has access to whatever data flows through the workflow.
How to find them: Audit your workflow automation platforms (n8n, Zapier, Make.com, Pipedream). Filter for workflows that include AI/LLM nodes. Check what data sources those workflows are connected to.
Risk: AI nodes in production workflows can process sensitive data that was never approved for AI processing. Under GDPR, if the data includes personal data of EU subjects, sending it to a commercial LLM API without a DPA may violate Article 28. Under HIPAA, sending patient data to an AI API without a BAA is a potential violation.
How to fix: Inventory all AI-connected workflows. For each one: what data does the AI node process? Is there a DPA or BAA with the AI vendor? Is the data going to an approved AI vendor?
Pattern 4: Browser automation agents with session cookies
A developer uses a browser-based AI agent (browser-use, Playwright with AI, similar tools) that operates using their current browser session. The agent inherits the developer's full authenticated access to every service they are logged into: GitHub, AWS console, internal admin panels, customer dashboards.
How to find them: These are the hardest to detect because they leave minimal traces. Check developer machines for browser automation tools with AI integration. Ask engineering leads whether anyone has used browser agents for production tasks.
Risk: A browser automation agent running with a developer's session has the same permissions as that developer. If the agent is instructed to perform a task that involves a production system (updating records, triggering a deployment, accessing a customer account), it acts with full developer authorization.
How to fix: Browser automation agents should run with a dedicated service account with minimal permissions, not with developer sessions. Production actions require explicit human approval before execution.
Pattern 5: AI email integrations with full inbox access
An AI email assistant (Gmail AI integrations, Superhuman AI, Claude for email, similar) is connected with full inbox access: read all messages, send as the user, manage contacts. The connection is personal but the email contains company data including customer conversations, contracts, and internal strategy.
How to find them: Check Google Workspace > Security > Third-party API access or check individual Gmail settings under Connected apps. For Microsoft 365, check the Azure AD enterprise applications list.
Risk: An AI email integration with full inbox access can read every email in the connected account, including confidential communications that would never be intentionally shared with a commercial AI vendor. Under GDPR and CCPA, this includes personal data of customers and employees.
How to fix: Require AI email integrations to use least-privilege scopes. Read-only access for drafting assistance is sufficient for most use cases. Send-as access requires explicit approval. Review whether the AI vendor has a DPA for your data.
Access inventory template
After running the audit, document what you found:
AI AGENT ACCESS INVENTORY
Date: [DATE]
Reviewed by: [NAME]
| Agent/Tool | Access Type | Scope | Data Accessed | Owner | Status |
|---|---|---|---|---|---|
| [Slack bot name] | OAuth | channels:history, groups:read | Slack messages | [Engineer] | Formalize / Revoke |
| [MCP server] | Filesystem | /home/[user] | All user files | [Engineer] | Scope to /projects/[name] |
| [n8n workflow] | API key | CRM read/write | Customer data | [Engineer] | Review DPA |
| ... | | | | | |
For each entry in the inventory, make one of three decisions:
- Revoke: Agent is no longer used, access is unnecessarily broad, or there is no legitimate business purpose
- Formalize: Agent is actively used, document it in the authorization register, scope appropriately, add logging
- Escalate: Access involves sensitive data (health, financial, personal data of EU subjects) that requires legal review before deciding
Quarterly audit process
Run this audit every quarter. The first audit is the hardest. Subsequent ones are much faster because you are only looking for changes from the previous state.
OAuth audit (30 minutes)
For each service your team uses (Slack, GitHub, Google Workspace, Notion, Linear, Jira, etc.):
- Navigate to the OAuth app/connected apps list in admin settings
- Filter for apps that include AI-related keywords or that your team does not recognize
- For each suspicious app: identify the owner (who connected it), check the scope, check last activity date
- Revoke apps with no owner, no recent activity (30+ days), or excessive scope
API key audit (20 minutes)
- Grep your codebase and environment variable configurations for patterns that suggest AI tool API keys (OPENAI, ANTHROPIC, CLAUDE, GEMINI, COHERE, etc.)
- Check CI/CD secret stores for AI-related keys
- For each key: which agent or workflow uses it? Is it in the authorization register?
MCP audit (20 minutes)
Use the MCP shadow server discovery checklist from the MCP server security article. Check developer machines and deployment configurations.
Workflow automation audit (20 minutes)
- Open your workflow automation platform (n8n, Zapier, Make, Pipedream)
- Search for workflows containing AI/LLM nodes
- For each AI-connected workflow: what data does the AI node process? Is the vendor on the approved vendor list?
After the audit
Update the access inventory. For each change from the previous quarter, document what changed and why. Present the inventory to your security lead at the quarterly security review.
When to escalate to legal or DPO
Three access patterns require legal or data protection review before you decide what to do:
- AI agents processing personal data of EU residents without a documented DPA with the AI vendor. This is a GDPR exposure.
- AI agents processing health-related data without a BAA with the AI vendor. This is a HIPAA exposure.
- AI agents with access to financial data or payment systems without documented controls. This is a PCI-DSS and potential regulatory exposure.
In these cases, do not revoke access immediately (disrupting a production workflow without understanding the impact can cause its own problems). Document what you found, escalate to legal and the DPO, and give them 5 business days to assess before taking action.
