Why do AI agent attacks keep going for the credential, not the model?

Short answer: because the credential is both the easier target and the bigger prize. Across the major AI agent security incidents of 2025 and 2026, attackers did not need to defeat the model. They went after the standing OAuth tokens, API keys, and environment credentials the agent already held, then used the agent’s own legitimate access to do the damage. The structural fix is to keep reusable app master credentials and refresh tokens out of the agent’s environment: deliver a scoped grant through the human, check it on every call, and keep the authorization decision somewhere no injected prompt can reach.

Watch: why standing credentials set the blast radius in 44 seconds

The Stolen Key, a 44-second film on why standing credentials set the blast radius for AI agent attacks.

Transcript: One compromised AI chat integration exposed standing OAuth access across hundreds of companies. The pattern keeps repeating: broad credentials sit inside automated channels before an attack begins. Then untrusted content becomes an instruction, and the agent uses authority it already holds. User-mediated authorization changes the path: the human chooses the scope, duration, and grant. Every call is checked. The agent cannot grow its own access. A stolen key stops being a master key.

What happened in the biggest AI agent credential breaches?

The clearest enterprise-scale example in this set barely mentioned a model at all. Between August 8 and 18, 2025, a threat group Google tracks as UNC6395 used stolen OAuth and refresh tokens associated with the Drift AI chat agent to access customer Salesforce instances at scale. Google told The Hacker News that more than 700 organizations may have been potentially impacted. Companies that publicly confirmed exposure included Cloudflare, Palo Alto Networks, Zscaler, Cato Networks, Elastic, and Google Workspace customers. Salesloft eventually took Drift offline entirely. And what did the attackers harvest from those CRM instances? More credentials: AWS keys, passwords, and access tokens stored in support cases.

One AI chat agent integration held durable OAuth access and refresh tokens into hundreds of companies. Nobody had to jailbreak a model. The tokens were valid, broad, and reusable. AgentAdmit would not have sat inside Salesloft’s token store, so this is not a literal intercept case. It is the clearest public example of why durable agent and integration credentials can turn one compromise into an enterprise-scale campaign.

The rest of the 2025 and 2026 incident record repeats the theme with different mechanics:

  • OpenAI Codex, disclosed March 2026. BeyondTrust researchers hid a command injection inside a Unicode-obfuscated git branch name. The payload stole the GitHub token Codex was holding. OpenAI classified it Critical P1 and remediated the shell-escape path.
  • Claude Code, CVE-2026-21852. Check Point Research showed that a repository settings file could override the ANTHROPIC_BASE_URL environment variable, so the agent sent its API key to an attacker’s server before the user ever saw a trust prompt. Opening the folder was enough. The record carries a CVSS v4.0 score of 5.3 Medium and an NVD CVSS v3.1 score of 7.5 High. It remains the cleanest example of an automated channel silently redirecting a credential.
  • Amazon Q Developer, July 2025. AWS’s own security bulletin traced the incident to an “inappropriately scoped GitHub token” in a build configuration. With it, an attacker committed a system-wipe prompt that shipped to users in release 1.84.0. The payload failed only because of a syntax error.
  • Amazon Q Developer again, June 2026. AWS disclosed that a malicious workspace could automatically execute project-configuration commands after the user trusted the workspace. Wiz Research found that an attacker-controlled MCP process could then inherit the developer’s live AWS credentials, including session tokens. The issue is CVE-2026-12957.
  • GitHub Copilot Chat “CamoLeak,” disclosed October 2025. Legit Security used GitHub’s own invisible-comment feature to inject instructions into any user’s Copilot session, then exfiltrated private repository contents through GitHub’s own image proxy. Scored 9.6 in the disclosure. The researcher’s key observation: “Copilot operates with the same permissions as the user making the request.”
  • Salesforce Agentforce “ForcedLeak,” CVSS 9.4. Noma Security planted instructions in a web form field; the agent followed them and sent CRM data to an expired domain that was still on Salesforce’s allowlist. The domain cost the researchers five dollars.
  • GitHub Agentic Workflows “GitLost,” July 2026. Noma Labs posted a crafted issue in a public repository and manipulated GitHub’s own agent into reading a private repository and publishing its contents as a public comment. No credential was stolen in this case. The damage came from authority the workflow already held. Adding the single word “Additionally” was enough to get past the guardrails.

What failure pattern do these incidents share?

Strip away the vendor names and the same four steps appear every time.

  1. The agent already holds broad standing authority. An OAuth token valid for months. An API key in an environment variable. The full permissions of whichever user is asking.
  2. That authority is automatically available inside the runtime. A redirect, an environment variable, a config file, a build pipeline, or a workspace-wide identity makes it usable without a new human decision.
  3. Untrusted content became an instruction. A branch name, a PR description, a web form, a public issue. Agents read everything, and everything they read can steer them.
  4. Nothing independent stood between the agent and the blast radius. No per-call check that could shrink the credential’s power, no human-only step for sensitive moves, no fast way to see and kill one agent’s access.

Steps 1 and 2 are the ones that decide severity. GitGuardian made the same point in an August 2026 analysis of the year’s agent incidents: “The exploit created the opening. But it was the stolen credential that extended the attacker’s access.” CrowdStrike’s 2026 Global Threat Report put it even more bluntly in a section header: “Prompts are the New Malware.”

Why don’t guardrails and permission prompts stop this?

Because guardrails are probabilistic and credentials are deterministic. GitLost fell to a one-word change in the injected prompt. Model-side defenses reduce the odds of a successful trick. If a trick lands, the authority already available to the agent decides what happens next.

Permission prompts have a different problem: people stop reading them. Anthropic’s own engineering write-up on sandboxing reported that users approved roughly 93% of permission prompts, and noted that the more approvals a user sees, the less attention they pay to each one. A consent step that fires dozens of times a day is not a consent step. It is a reflex.

The numbers on standing credentials are just as uncomfortable. GitGuardian’s State of Secrets Sprawl 2026 counted 1,275,105 AI-service secrets exposed on public GitHub in 2025, up 81% year over year, with more than 24,000 unique secrets sitting in MCP configuration files. Each one of those is step 1 of the pattern, waiting for steps 3 and 4.

What architecture takes the credential off the attack path?

Change where the credential travels and how long it lives. That is the design AgentAdmit ships, and it is called user-mediated authorization (patent pending). It complements standards like OAuth rather than replacing them.

The mechanics, mapped against the four steps above:

  • The credential is delivered to the human, not the agent. The user requests a connection inside the app they already trust, chooses the exact scopes and duration, and receives a single-use connection token. They hand it to their agent themselves. There is no redirect, no callback, no webhook, no automated path between the app and the agent for an injected prompt to exploit.
  • Grants are scoped and time-bounded. An agent gets the actions the user picked and nothing else, for the duration the user picked and no longer. There are no refresh tokens; when access ends, a human renews it or it stays ended. A stolen grant limited to three actions and a chosen duration is a very different asset from a Drift-style token that covers a whole CRM for months.
  • Every call is checked. Access is validated against the grant on each request, so an out-of-scope action fails at the moment it is attempted, not after the audit. Users can also set usage limits on a grant, and an agent cannot raise its own limits.
  • Revocation is immediate and per-agent. The user sees each connected agent, what it is allowed to do, and what it actually did, and can cut off one agent without touching anything else. An API-key caller can tighten automated protections, but weakening them requires a human presence ceremony.

None of this stops a prompt injection from landing. Filters still matter. What changes is containment: no reusable app master credential needs to sit in the agent runtime, the agent cannot grow its own grant, and every call is checked against what the user already approved. The trick still happens. The blast radius shrinks to the scope, duration, and usage limits of that grant.

FAQ

Are AI agent breaches caused by weaknesses in the models themselves?

In the incidents above, severity was set by what the agent could already reach, not by whether the model was “broken.” Some attacks did exploit instruction-following behavior or weak guardrails, but stolen OAuth tokens, over-scoped build tokens, and inherited cloud credentials decided the blast radius.

Would better prompt-injection filters have prevented these incidents?

They would have reduced the odds, not the consequences. GitLost bypassed GitHub’s guardrails with a one-word change, and filters do nothing about a token stolen from an environment variable. Filters are worth running, but the blast radius is set by what the agent can reach when a trick succeeds.

What is user-mediated authorization for AI agents?

An authorization pattern where the credential is delivered to the human instead of the agent. The user selects scopes and duration, receives a single-use connection token inside the app, and gives it to their agent out of band. The authorization decision lives outside the agent’s execution context, so an injected prompt cannot trigger or escalate a grant.

How does scoping limit the damage from a compromised agent?

A scoped grant means a hijacked agent can only misuse the specific actions the user approved, for the time window the user approved. Combined with per-call validation, usage limits, and per-agent revocation, that can turn a potential mass breach into a contained, visible, and quickly reversible incident.

If you are building an app that AI agents will connect to, AgentAdmit gives your users scoped, revocable, auditable agent access with the credential delivered to the human. Start in Test Mode at agentadmit.com.

Related reading: Prompt injection is an authorization problem, What is user-mediated authorization for AI agents?, and Can an AI agent approve its own permission request?

Get new posts by email

One short email when a new post goes live. No spam, unsubscribe anytime.