AI agent security breaches: Why the agent's credentials are the blast radius

The prompt injection was the trigger. The agent's credentials were the blast radius.

Across AgentCore, Agentforce, Amazon MQ MCP Server, and Meta Muse, the attack paths were different, but the outcome was consistent: attackers inherited whatever authority the agent already possessed

We've argued before that the prompt injection problem isn't solvable, but the permissions problem is. In September, the OpenAI agent that breached an Australian Medicare portal showed what happens when nobody can tell whose agent is on the other end. This month's disclosures make the permissions argument better than we could.

Same pattern, four products

A fifth case needed no attacker at all. Glow Security reported that AI coding agents exposed thousands of internal screenshots from hundreds of organizations by creating public GitHub repositories during normal workflows. GitHub has no API for attaching images to pull requests, so the agents created public repos instead, using developers' own tokens. Nobody told them to. Nothing stopped them.

How the AgentCore attack worked

The attack demonstrates how a seemingly minor entry point can cascade into total credential compromise. It begins with hidden prompt injection in a user submission, moves through local tool execution to harvest active session tokens from memory, and concludes with outbound exfiltration and unauthorized API access from an external location.

Prompt injection isn't the variable: Scope and access are

The injections in these disclosures were ordinary. What varied was the reach: a root shell in one case, CRM read and Slack write in another, or broker credentials handed to any hostname in a third. Every vendor fixed the specific trigger. None of those fixes change what the next injection will find when it lands.

Vendors are telling you whose problem this is

AWS's response to Unit 42 is worth reading as policy. It closed the report under shared responsibility: tool scoping and egress filtering are things customers configure. Meta described the Muse flaw as local privilege escalation that requires code already running as the user. Apple, meanwhile, is tightening Full Disk Access protections amid growing concerns about the risks introduced by AI agents and highly privileged applications.

The message is consistent. Platforms will patch their bugs. What an agent is allowed to hold, and for how long, is your decision.

What an agent should hold

The AgentCore case shows the alternative clearly. The token that leaked was a standing service-account credential available to the harness at runtime and capable of authenticating to downstream services. Its reach exceeded any user's. Compare a token issued per session, scoped to the tools that session needs, carrying the identity of the person the agent is acting for, and expiring in minutes. Steal that from memory and you get a few minutes of one user's access to one tool.

Five questions for identity and security leaders

1. Inventory: Can you list every agent operating in your environment, including vendor agents with OAuth grants or API keys?
2. Holdings: For each, what credentials does it hold, and whose permissions do they represent?
3. Defaults: Which built-in tools (shell, file access, messaging, repo creation) are on by default, and does each agent need them?
4. Binding: Are agent tokens tied to the user and the task, or shared across every session?
5. Exits: Can your agents send data anywhere on the internet, post messages externally or create public resources without a person confirming?

The Oleria POV: Decide what the agent holds

1. Short-lived tokens bound to a principal

Oleria Maestro is a zero trust access gateway for AI agents. Using OAuth 2.0 Token Exchange (RFC 8693), it issues each agent action a short-lived, tightly scoped token that carries both the agent's identity and the human it acts for. A token lifted from memory expires quickly and only covers one task.

2. Every agent in the graph

The TrustFusion Identity Context Graph inventories agents alongside human and non-human identities, including third-party agents with OAuth grants or API keys, with their owners and what their credentials reach.

3. Removing grants agents don't use

Oleria Adaptive Identity Governance compares what each agent is allowed to do with what it actually does, and recommends removing the rest.

What to do this week

• Inventory your agents, including vendor agents with OAuth grants or API keys. If that takes more than an hour, it's your first finding.
• For each, write down which credentials it holds and whose permissions they represent.
• Turn off default tools agents don't need. On AgentCore, set allowedTools on every invocation.
• Require confirmation before agents send external messages, create public repos or push data outside your domains.
• Put egress allowlists on agent runtimes.
• Replace shared, standing agent credentials with per-session tokens tied to the user.

If someone slipped an instruction into the next ticket your support agent reads, what could it reach?

If you're not sure, we should talk.

Oleria unifies human, non-human and AI agent identities in one context graph and issues agents short-lived, principal-bound tokens through Maestro. Discover how Oleria secures and governs AI agents