Credential and Token Theft via Compromised AI Agents

An AI agent doesn't just hold a credential. It holds a chain: acting for a specific user, at a specific scope, for one specific task, and then letting that scope dissolve the moment the task ends. Human identity systems were never built to express that kind of chain, and neither were the service accounts that enterprises have relied on for decades. A service account has one identity and one fixed set of permissions, set once and left alone. An agent's permissions shift with every single invocation. The same coding agent might refactor code for Alice at 2:00 PM and push a deployment for Bob at 2:01 PM, and each of those two moments calls for a completely different set of downstream access.

Faced with that complexity, most enterprises reach for one of two shortcuts, and both break the chain in a different way. The first shortcut treats the agent like a service account with broad, standing permissions. It works, until someone asks which user actually authorized a given action, and the answer is gone. The second shortcut hands the agent the user's own token. That solves the problem of attributing actions to the agent, but creates a worse one: now the agent's actions and the human's actions look identical in the audit log, and there's no way to tell them apart after the fact.

A 2026 enterprise reference on agentic authentication lays out four architectures enterprises actually use to deploy agents: user-delegated, autonomous, hybrid orchestrated, and scoped impersonation. Across all four, the same four risks appear: scopes that are wider than the task requires, tokens that sit exposed in the agent's runtime memory, prompt injection that tricks the agent into misusing the scope it legitimately holds, and an audit trail that can't tell agent action from human action.

That second risk, the token sitting in runtime memory, isn't a bug or a misconfiguration; it's how agents work. An agent has to hold its delegation token in active memory while it executes a task, the same way a browser holds a session cookie while a page loads. That's also precisely the spot every attacker in this space is aiming at.

The three mechanisms that turn a compromised agent into a credential source

Three separate mechanisms turn that in-memory exposure into a working exploit: prompt injection, gaps in the MCP protocol that agents use to reach tools, and tampering with the software supply chain agents depend on. Attackers rarely use them alone. More often, attackers chain them together.

Indirect prompt injection works by hiding an instruction inside content the agent is supposed to just read, not obey. A pull request title, a line of text on a web page, a paragraph in a document: any of these can carry a command that looks like ordinary data to a human reviewer but reads as an instruction to the agent. An agent told to review a pull request might instead be told, by the content inside that pull request, to go find a credential sitting outside its working directory and write it into a GitHub Actions log, a log the attacker can then simply go retrieve. A systematic review of 78 studies on this exact failure mode found that attack success rates against state-of-the-art defenses exceed 85% once attackers use adaptive strategies, and every defense the researchers tested could be bypassed.

The second mechanism sits inside the Model Context Protocol itself, which is the standard agents use to connect to external tools. MCP's authorization spec defines a real OAuth 2.1 framework for securing those connections, but it marks that authorization as optional, not required. In practice, a large number of deployed MCP servers accept incoming connections and hand over their full list of available tools without checking credentials. Researchers combing public GitHub repositories in 2025 found tens of thousands of unique secrets sitting in MCP configuration files, and a significant share of them were still valid when found.

The third mechanism bypasses runtime attacks. CUT

None of these three paths stay separate in practice. A supply-chain compromise can deliver a rogue MCP server onto a machine. That rogue server then performs the prompt injection itself. The injected instruction tells the agent to exfiltrate whatever token is sitting in its memory. One compromise, three mechanisms, a single outcome.

Stolen agent tokens in the hands of attackers

A stolen agent token isn't just a prize an attacker sits on: it's an operational tool, and attackers replay it at machine speed to run further attacks on their own, with no human in the loop slowing anything down.

Start with the basics: a stolen session token or API key skips multi-factor authentication entirely when it's replayed. The authentication system checks the credential, sees that it's valid, and lets the presenter in. It has no way to ask whether the presenter is the legitimate agent, a human attacker who stole the token, or a fully autonomous attack pipeline running on its own. Okta's analysis looked at a 7 GB infostealer dump released on Telegram, containing 5,871 folders of stolen data. The analysis found thousands of unexpired authentication tokens for major cloud and AI providers inside that dump, and attackers loaded the stolen sessions into anti-detect browsers, so they walked past security controls without ever triggering an authentication prompt.

The clearest demonstration of what machine speed actually means comes from an intrusion disclosed by a threat intelligence research team in September 2026. A financially motivated attacker fed an AI coding chatbot a single prompt and a set of markdown-based agent instructions, instructions that functioned as a full operational playbook. From there, the system ran the whole campaign on its own: scanning for vulnerabilities, harvesting credentials, troubleshooting problems as they came up, rotating IP addresses to avoid getting blocked. No continuous human oversight at any point. The result: thousands of third-party credentials compromised in under six hours. A human-paced intrusion team working through the same checklist would need days or weeks to hit that number. The agent did it before a single work shift ended.

The same GTIG report found a separate piece of infrastructure: an exposed command-and-control dashboard, which researchers called "Recon," actively organizing and validating tens of thousands of harvested secrets across cloud and AI service credentials. That dashboard shows what autonomous credential-management infrastructure can sustain once it's built: not a one-time haul, but an ongoing operation processing stolen secrets at scale.

Part of what makes an AI credential worth stealing in the first place is that its value compounds. A stolen API key does more than unlock a paid model's usage quota. It can also open the door to source code, stored data, cloud compute, and every downstream agent or workflow that key is authorized to touch. The credential is the target of the attack and the tool for the next stage of it, at the same time. That compounding value shows up in the market price: GTIG reporting found the underground market for stolen AI credentials expanded materially through 2026, with average advertised prices per account more than doubling over the year. Anthropic's own threat intelligence report documents one case showing how far a single breach can travel: attackers compromised an AI evaluation sandbox, stole API keys belonging to multiple providers, and then used that stolen access to attack roughly 30 AI companies in a follow-on campaign. One sandbox breach, a supply-chain-sized outcome.

Now stretch this past a single agent. In a multi-agent setup, one orchestration agent typically holds the API keys for every downstream agent it coordinates. Breach that one orchestrator, and every downstream system it can reach comes with it. A single point of compromise becomes a single point of total failure.

Multi-agent and supply-chain architectures that multiply exposure across an enterprise

The very patterns that make agentic AI useful inside a company are the same patterns that let one stolen token reach everywhere. Chaining agents together, sharing credentials across pipelines, embedding agents directly into CI/CD: each of these makes an organization more productive, and each one multiplies what a single compromise can unlock.

Start with the basic inventory problem: organizations don't know how many non-human identities they have. Non-human identities, meaning service accounts, API keys, OAuth tokens, machine certificates, and now AI agent credentials, already outnumber human users by a wide margin in most cloud-native environments. A security team can't rotate or properly scope a credential it hasn't cataloged. That's not a policy failure so much as a visibility failure, and it comes before any other control can even start working.

Move one ring out, to the software supply chain agents depend on. The Sandworm_Mode campaign on npm used typosquatting, meaning packages named to look like popular, trusted utilities, to target five different coding tools at once: Claude Code, Claude Desktop, Cursor, VS Code Continue, and Windsurf. Once installed, the malicious packages planted rogue MCP servers on the victim's machine, and those servers used prompt injection to pull out SSH keys, AWS credentials, npm tokens, and other secrets. One typosquatted package, five tool ecosystems exposed at once.

Move another ring out, into CI/CD pipelines specifically. These pipelines are a high-value target for a structural reason: the runner environment that executes a build holds short-lived but highly privileged tokens, OpenID Connect tokens, cloud-role credentials, repository secrets, and that runner routinely processes code from third-party packages, pull requests, and workflow files that no human reviews line by line. An agent sitting in that pipeline is exposed to anything that reaches it.

The outer ring is where this architecture turns into mass, automated damage. JADEPUFFER, a piece of agentic ransomware, shows what the full chain looks like end to end: a human operator picked the target and defined the goal, but the AI agent then worked on its own from there, exploiting a known vulnerability in Langflow to gain initial access, pushing out a large volume of payloads across the target's systems, stealing credentials, and destroying data, using API keys from multiple AI providers the entire way through. GreyNoise documented a campaign that pushed this same pattern to a genuinely large scale: a single attacker ran hundreds of AI agents, built on OpenAI Codex and a DeepSeek model, to exploit two PaperCut NG/MF vulnerabilities, tracked as CVE-2026-81578 and CVE-2026-82078. That operation compromised hundreds of PaperCut instances across a large number of organizations, spread over dozens of countries. One attacker. Hundreds of agents working in parallel. That's the architecture doing what it was built to do, just pointed at the wrong target.

Why traditional identity and security controls cannot see this attack surface

The identity and security tools most enterprises already have weren't built to see any of this, because they were built around a different assumption: that authentication events happen at human speed and get attributed to one person or one known service.

Start with the IAM layer. Most identity and access management policies can't tell an agent presenting a valid token apart from the human or service that's supposed to legitimately hold that token. A replayed token skips MFA for a simple reason: the authentication system is built to validate the credential itself, not the intent or context behind whoever is presenting it. That gap is the source of every other problem described in this section.

Move to the audit trail, where incident response usually starts after something goes wrong. A large majority of organizations can't reliably separate an AI agent's activity from a human's activity in their own logs. That means the record responders depend on to reconstruct what happened is structurally unreliable for this entire category of incident, before an investigator even opens a single file. This isn't a staffing problem. A significant share of IT leaders report having already seen agents act outside their expected behavior, so awareness of the risk clearly exists. The gap persists anyway, because current logging and monitoring tools are built on an architecture that has no concept of "agent" as a distinct kind of actor.

Persistence makes the failure concrete. Credentials confirmed as leaked back in 2022 were still active and exploitable in early 2026, four full years after they were first flagged, surviving rotation reminders, detection alerts, and whatever governance tooling was supposed to catch them.

Shadow AI adds another layer the enterprise can't see. A large share of employees access AI services through non-corporate accounts on corporate devices, so the credentials and sessions tied to that usage exist entirely outside enterprise identity controls, not inside a blind spot within them. Shadow AI became the third most common non-malicious insider action recorded in data-loss-prevention datasets in 2026.

The Mexico government breach shows what this detection gap costs when it plays out at national scale. A single attacker used Claude Code and GPT-4.1 to breach nine Mexican government agencies, including the federal tax authority and the national electoral institute, exfiltrating hundreds of millions of records, among them taxpayer and civil records, along with more than a hundred gigabytes of data, all before anyone detected the intrusion.

Only a small fraction of organizations today have a formal identity strategy built specifically for AI agents, and an even smaller fraction of deployed agents reach production with full security approval. The gap between how fast organizations deploy agents and how fast their governance catches up is widening.

Requirements for effective defense

Fixing this starts at the identity layer itself, not at the endpoint or the network perimeter. Defenses bolted onto frameworks built for human or static-service identity will keep missing agents, because agents were never what those frameworks were built to recognize.

The architectural pattern taking shape in 2026 pairs two things: short-lived, narrowly scoped delegation tokens, and a per-agent identity registered inside identity governance and administration (IGA) systems. Under this model, the agent is authenticated as itself, as a distinct identity, separate from the human it's acting for. The delegation gets expressed on top of that, as its own layer. And the token's scope matches only what the user actually authorized for that one specific task. A stolen token under this model is narrow in what it can reach and short-lived in how long it stays useful, which directly undercuts the six-hour harvest and the Recon-style dashboards built to process stolen secrets at scale.

The fuller version of this architecture, as described in the 2026 agentic-auth reference, combines four pieces: short-lived scoped tokens, per-agent identity inside IGA, runtime guardrails built specifically to catch prompt injection, and identity threat detection tuned to watch for agent behavioral anomalies as their own distinct category of event, separate from human anomaly detection. Each piece addresses one of the gaps traced through this piece: scoped tokens fix over-broad permissions, per-agent identity makes the audit trail attributable, runtime guardrails catch prompt injection directly, and behavioral detection catches stolen tokens that otherwise look exactly like legitimate use.

None of this is fully solved yet. Only a small fraction of organizations have a formal AI-agent identity strategy in place today, and MCP's authorization spec still leaves implementers free to skip authorization. The architecture exists. The adoption of it does not, not yet, and that gap is where the next wave of credential theft is already heading.