Unit 42 Talked an AWS AgentCore Agent Out of Its Vault

Palo Alto Networks' Unit 42 talked an AI agent running on AWS AgentCore into handing over credentials pulled straight from the platform's encrypted vault.

The weapon was a malicious support ticket. According to a write-up of the finding, the agent read the ticket, ran code, and sent a token to the attacker's endpoint. AWS reviewed the report, closed it as "informative", and said locking down agent tools is the customer's job.

Nothing malfunctioned

Read the sequence again: the agent read untrusted content, used its tools, and talked to the network. That is not a failure mode. That is the job description of every support agent, every RAG pipeline, and every MCP-connected assistant on your stack.

The write-up points at the pattern Simon Willison named the lethal trifecta in June 2025 — private data, untrusted content, and a way to communicate out. Remove any one leg, usually by narrowing the tool grant, and the same attack lands as a harmless misfire. It is the only mitigation in this story that does not depend on the model behaving.

Your annual pen test rots at deploy speed

A point-in-time red-team engagement is stale the week after it lands, because the agent changed: new tool, new prompt, new data source, a new MCP server someone evaluated for twenty minutes. The proposed fix is to run adversarial testing the way SRE teams run chaos engineering — define the steady state, inject one fault at a time, and let the audit trail grade the result.

For an agent, the steady state is behavioral and has to be written down before anything is attacked:

• The agent completes a suite of benign tasks end to end.
• Every tool call stays inside the grant the task requires — nothing extra.
• No outbound call leaves the allowlist: no email, no webhook, no fetch to an unapproved host.
• Ambiguous or suspicious instructions escalate to the user instead of executing.

Skip this and every experiment result becomes a matter of opinion, which is how red teams turn into theater.

The fault catalog

Faults land at the tool boundary, because that is where a real attacker aims. The catalog proposed in the write-up:

Fault	What it tests
Injected instruction in retrieved content	A ticket, doc or RAG result carries an instruction the user never wrote
Poisoned tool output	Whether the agent trusts tool responses the way an app trusts its database
Permission denial (403)	Fail closed and escalate, retry forever, or shop for a tool with broader access
Slow or hanging tool	Timeouts as a security property, not a UX nicety
Confused-deputy credential request	Data asking the agent to paste a credential it legitimately holds
Tool schema drift	Whether anything validates a changed shape before forwarding it downstream

The same write-up notes an earlier instance of the first row in the wild: in August, PromptArmor demonstrated attacker-controlled content directing Atlassian's Rovo assistant to search Jira and Confluence and exfiltrate results to an attacker URL.

Your logs probably cannot settle the argument

Assume an experiment fails. What proves it? A separate analysis of MCP logging argues the protocol documents contain no logging requirement for tool calls at all. The 2025-11-25 revision states that "Tools represent arbitrary code execution and must be treated with appropriate caution" and that "Hosts must obtain explicit user consent before invoking any tool" — both about permission, neither about evidence.

Worse for anyone building policy on metadata: the four behavioral annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) are hints only, and the schema says they are "not guaranteed to provide a faithful description of tool behavior." Clients must treat them as untrusted unless the server is trusted — so a log line reading read-only tool invoked records the tool author's claim, not the tool's behavior.

What to do next

Write the steady state for one agent this week, then arm a single fault — the injected instruction — against it in staging. If the run produces no record you would show to someone who does not trust you, fix the logging before adding the next five faults.