Overview
A detailed case study published by BleepingComputer and sponsored by Token Security traces the lifecycle of a single AI agent — built in ten minutes by an accounts employee, unknown to the security team — to expose five recurring gaps in enterprise AI security posture. The agent’s task was mundane: read an inbox, reconcile invoices against an ERP, and post a Slack summary. Its security footprint was anything but.
The scenario is not hypothetical. A January 2026 Cloud Security Alliance survey of 418 IT and security professionals found that 82% had discovered AI agents in their environment that they did not know existed — even as 68% reported having strong agent visibility. The disconnect illustrates a governance blind spot growing faster than security teams can respond.
Technical Analysis
The agent acquired access through three of the four common access patterns identified by John Donovan, former Head of Security at Zededa:
- Delegated OAuth grants — The email connection was approved via a single-click consent screen. OAuth scopes granted on this basis typically persist indefinitely unless explicitly revoked, creating durable, unmonitored access.
- Static API credentials — The ERP connection was established using a personal API key generated by the creator following AI-generated instructions. Static keys are reusable by any party who obtains them and are rarely rotated or monitored.
- Builder-managed connectors — Slack access was brokered through the no-code platform’s own connector, adding a third-party dependency to the trust chain.
The fourth and most secure model — purpose-built, short-lived, agent-specific identities — was not used. This pattern is described as the rarest in practice.
Each access path compounds risk differently: OAuth grants expand the blast radius of account compromise; static keys undermine auditability; builder-managed connectors introduce supply-chain dependencies outside the enterprise’s direct control.
Framework Mapping
- AML.T0103 (Deploy AI Agent) — Agent was deployed outside any sanctioned process, with no security involvement.
- AML.T0083 / AML.T0098 (Credentials from / Harvesting via AI Agent) — Static API keys embedded in agent configuration represent credential exposure vectors.
- AML.T0086 (Exfiltration via Agent Tool Invocation) — The agent’s email and ERP access create a viable path for data exfiltration if compromised or misdirected.
- LLM08 (Excessive Agency) — The agent was granted broader access than its narrow task required, with no scope enforcement.
- LLM07 (Insecure Plugin Design) — Third-party builder connectors introduce unvetted integration points.
- LLM06 (Sensitive Information Disclosure) — Invoice and inbox data processed by the agent was exposed to the model and its infrastructure without data classification controls.
Impact Assessment
The risk profile extends beyond the individual agent. Unregistered agents accumulate OAuth grants that survive employee offboarding, API keys that may be reused or leaked, and third-party connector dependencies that bypass network controls. At scale, organisations can find themselves with dozens of untracked agents holding access to sensitive financial, HR, or customer systems. The audit referenced in the article suggests that in many cases, the discovery of the agent occurs only after something goes wrong.
Mitigation & Recommendations
- Establish an AI agent registry with mandatory pre-deployment security review, regardless of who builds the agent.
- Enumerate all active OAuth grants across your environment and revoke any tied to unregistered or deprecated agents.
- Prohibit static personal API keys for agent authentication; require service accounts with time-bound, scoped credentials.
- Classify data before connecting agents — ensure agents do not process data above their authorised sensitivity tier.
- Monitor agent activity logs separately from human user logs to detect anomalous tool invocations or data access patterns.