A malicious support ticket moved an AgentCore agent's vault token to an attacker endpoint

Three capabilities compose into the AgentCore exfiltration, and each was granted deliberately. Step by step, a monitor sees an ordinary run. The ticket was untrusted text. Running code and making an outbound request were both tools the agent held ^[1][3].

AWS closed the report as "informative" and said locking down agent tools is the customer's job ^[2]. Taken literally, that locates the control point in the tool grant and the egress allowlist, both written by whoever deploys the agent. The credential came out of the platform's encrypted vault ^[1]. The caller was authorized, so the encryption never came into it.

The steady state the dev.to post proposes is four assertions written down before any attack ^[5]. Two can be graded from logs alone: every tool call inside the grant the task required, and no outbound call outside the allowlist ^[10]. The other two need a judgement about model output, namely that a suite of benign tasks completes end to end and that ambiguous instructions escalate to the user instead of executing ^[10]. "Without a defined steady state, every experiment result is a matter of opinion," the post says ^[6].

The fault catalog lists six injections, all landing at the tool boundary, which the post says is where a real attacker aims ^[7][13]. Three need attacker-crafted content: an instruction hidden in retrieved content, poisoned tool output, and a request from data that the agent paste a credential into an outbound call ^[11]. The other three are failures your own platform already produces, a tool that answered yesterday and returns 403 today, a tool that hangs, a response shape nobody validated ^[11]. Those three you can inject with a proxy, so one harness covers reliability and security faults. Timeouts are a security property, according to the post, because an agent that blocks the user session waiting on a tool that never answers is a self-inflicted denial of service ^[14].

The freshness argument is the strongest part of the case. A report dated before you added a tool describes a different agent. PromptArmor showed the same shape against Atlassian's Rovo in August, with attacker-controlled content directing the assistant to search Jira and Confluence and exfiltrate the results to an attacker URL; Varonis found a separate path, RovoBlast, which Atlassian fixed ^[8]. Agents ship weekly, the post argues, and a point-in-time assessment rots at the speed of the deploy pipeline ^[9], picking up a "new MCP server from a vendor you evaluated for twenty minutes" along the way ^[12].

The evidence here is one write-up, and it does not date the Unit 42 finding or name the AgentCore setting that scopes a tool grant ^[16]. So the thing I would want tested is whether the default policy attached to a new AgentCore agent permits arbitrary egress. Until that is published, "The defaults, in other words, leak" ^[15] is the author's reading of AWS's triage, and the part you can act on is the written steady state. That steady state holds on any platform you run.