intelligence_src_cdcffed32aa78fd61f
- Source-provided label
- Publisher RSS metadata
- Evidence class
- mentioned in report
- Confidence
- Not reported
- Observed
- Oct 08, 2026 13:05 UTC
- Retrieved
- Oct 14, 2026 03:27 UTC
Throughout this year, Amazon Web Services (AWS) has repeatedly had to patch autonomous agent security holes, which have then reemerged in slightly different forms, according to cybersecurity researchers at Palo Alto Networks’ Unit 42 and at Zenity Labs. But the problem is not with AWS, which seems to be reacting quickly to address security reports, as much as it is with the essential nature of autonomous AI agents and the difficulty in controlling those agents. The fact that a hyperscaler with Amazon’s massive resources can’t seem to get ahead of the problem illustrates the agentic challenge for all enterprise IT and cybersecurity executives. AgentCore issues On September 18, 2026, for example, Palo Alto Networks’ Unit 42 cybersecurity researchers reported an issue “where using default configurations in AWS AgentCore Harness could allow attackers to steer an agent’s actions through prompt injection to exfiltrate plaintext credentials managed by AgentCore Identity.” The description of the issue revealed in the report illustrates the quintessential agentic flaw: the very access that allows agents to perform their functions also creates a major security risk. “The harness’s own built-in shell tool, which is enabled by default, reaches into the same memory space where credentials are resolved to plaintext,” the report explained. “The built-in tools are a big part of what makes the harness so autonomous and productive. The agent can write files and run code to get real work done. But the same reach that makes the built-in tools useful makes them dangerous when people leave them on unintentionally.” “We’ve found that the shell tool runs as root inside the harness, so the moment an attacker gets the agent to run a command, that command inherits the same root access,” it added. “Nothing has to be misconfigured for this to happen. It is the out-of-the-box state.” The Unit 42 report said that Amazon’s response was ambiguous about whether it had actually plugged that hole: “We disclosed this finding to AWS. AWS reviewed and closed the report as informative under the AgentCore shared responsibility model,” it noted. Several months earlier, on April 7, Unit 42 had also alerted AWS to a different path to credential exfiltration. In its description of that issue, it said it had found a critical security regression in which the AgentCore Runtime used a microVM Metadata Service (MMDS) that lacked session token enforcement. “Prior to our disclosure and AWS’s fixes, this configuration could have allowed an attacker to exploit standard web vulnerabilities, such as server-side request forgery (SSRF), to directly extract sensitive credentials, putting the entire environment at risk,” Unit 42 wrote at the time. Today Zenity Labs published its own report, an advance copy of which it provided to CSO, detailing its findings about AWS agents that surrendered credentials to an attacker who asked for them. Zenity was able to get an agent to return a full set of temporary STS credentials: an access key ID, a secret access key, and a session token belonging to the agent’s execution role. “These credentials aren’t scoped to the sandbox. We exported them onto our own machine, outside AgentCore entirely, and confirmed they were live,” the report said. The agent delivered data that included ECR read permissions, “so we authenticated to the registry and pulled the image. From there, the agent’s source code, its dependencies, and whatever its developers baked in were ours to inspect, as root,” the report said. “At this point, a reasonable reaction is ‘So don’t give agents a raw HTTP tool.,’” Zenity noted. “That doesn’t help. The isolation failure is at the platform level, not the tool level, so anything that can generate outbound traffic reaches IMDS just the same. We reproduced the identical result through several tools, including Strands’ built-
ae6e10b890a5c1df774f60aa28dcfdabbcf248e84e1ddcc549c9d5c8557b0fa7Network indicators are visibly defanged. This page does not make them clickable or send them to another service.
No validated file hashes or network indicators are stored for this record.
This record contains metadata and attribution only. It does not host, download, unpack, render, or execute malware samples.
Sources represented on this page. Publication and observation dates describe the content; successful batch dates describe local collection. A recent batch does not certify complete coverage or current provider availability.
1 sources: 0 stale, 0 needing attention, 0 paused, 0 unverified.
Stale means older than twice the recorded collection interval, with a minimum of one hour; without an interval, the threshold is 24 hours. Cached content remains available while a feed is stale, paused, or unverified.