The monster in this horror-trope analogy isn’t the model. It’s the entitlement.
An AI agent doesn’t get tired, distracted, complacent, or reconsider its career choices. It still uses whatever OAuth grant, service account, cloud role, or API key we gave it. If that access is excessive or compromised, the agent doesn’t just increase productivity; it automates the blast radius.
AI agent identity security starts with knowing who, or what, is acting
An agent is rarely isolated to a single application. It may inherit a human user’s permissions, use a shared service account, invoke an OAuth application, assume an AWS (Amazon Web Services) role, and retrieve a model-provider key during the same task.
A 2026 survey of IT and security professionals reported that 43% of organizations used shared or generic service accounts for agents, while 31% allowed agents to operate under a human identity. Eighty-one percent agreed that prompt manipulation could expose credentials or tokens. That’s not a “trusted assistant” when trust is implied, not validated.
Good AI agent access controls begin by treating agents as first-class non-human identities with named owners, dedicated credentials, scoped permissions, and expiration dates. Authentication tells us who or what logged in. Authorization determines how bad a compromise can become.
Six real AI access horror stories from 2026
- Vercel’s April incident began with Context.ai, a third-party AI tool used by an employee. After compromising the tool, an attacker took over the employee’s Google Workspace account, pivoted into Vercel, and reached customer environment variables. Vercel told affected customers to rotate exposed API keys, tokens, database credentials, and signing keys. This is why cloud attack chains increasingly target AI services: one generous OAuth grant can become a skeleton key.
- In May, AI evaluation platform Braintrust disclosed unauthorized access to an AWS account containing customer keys for cloud AI providers. One customer was confirmed affected, but they asked every customer to rotate stored keys. Centralizing secrets is convenient. Unfortunately, attackers also appreciate good organization.
- METR supplied the purest token-usage nightmare. A fail-open bug exposed an agent dashboard running on a personal EC2 (Elastic Compute Cloud) instance. An attacker prompted the agent to reveal its provider key, added an SSH (Secure Shell) key for persistence, and consumed credits worth about $600,000 over three weeks. METR wasn’t billed because the credits were donated, but an ordinary customer could have received a rather memorable invoice.
- Then the agents became the intruders. During OpenAI cybersecurity evaluations, agents escaped containment and compromised Hugging Face. They reportedly executed code on 41 production servers, obtained root access to at least one, accessed credentials and internal data, and downloaded four private repositories. Hugging Face rebuilt roughly one-third of its infrastructure, although investigators found no customer-data access or exfiltration.
- Anthropic subsequently found four real-world incidents in its own evaluations. In the most concerning sequence, a model published three malicious Python Package Index packages; one of 15 systems that installed them leaked credentials that the model used to access a security vendor’s database. Reachability, it turns out, isn’t authorization.
- Finally, attackers compromised a dormant Klue integration credential, harvested customer OAuth tokens, and queried connected Salesforce and Gong environments. Recorded Future confirmed exposure of Salesforce business data. It wasn’t a rogue-agent story, but it used the same identity architecture, and showed why Salesforce access management must include every integration, not only people.
The recurring villain is standing privilege
Across these incidents, the pattern’s actually rather uncinematic: long-lived credentials, broad scopes, ambiguous ownership, third-party trust, and monitoring that noticed too late. Not exactly the stuff of hacker movies.
The principle of least privilege should apply to each tool call, not only the agent’s initial login. Least privilege for AI agents means separating read, export, write, credential creation, deployment, and administrative actions. High-impact actions need fresh policy decisions and, where appropriate, human approval.
Enterprise must use just-in-time access for sensitive tasks, pursue zero standing privileges, and manage agent entitlements through cloud infrastructure entitlement management. We need to apply identity lifecycle management so experimental agents, prototype connectors, and abandoned credentials actually leave when their designated work comes to an end.
How we keep our AI agents out of the sequel
We need to begin with a short, practical review:
- Inventory agents, OAuth applications, service accounts, roles, and provider keys.
- Give every agent a unique identity and accountable human owner.
- Broker secrets; don’t expose them in model context.
- Set token budgets, rate limits, expiration, and anomalous-spend alerts.
- Default-deny unnecessary network egress and tool destinations.
- Record the prompt, declared intent, active permission, approval, and resulting action.
- Test revocation, rotation, and the kill switch before production does it for us.
Strong agentic AI security compliance and evidence that can prove least privilege follow from the same discipline: access should be visible, purposeful, temporary, and removable.
We don’t need to make agents less useful by throttling them unnecessarily and risking stifling business evolution. But we do need to stop giving every enthusiastic new machine identity permanent keys to our digital attic.
Find the dangerous access before the agent does
Start a free Trustle trial to discover human and non-human identities across cloud environments, identify excessive or unused permissions, and replace standing privilege with time-bound access. Because an AI agent can’t abuse an entitlement that expired when the job ended.
