{"id":9955,"date":"2026-10-08T13:05:00","date_gmt":"2026-10-08T13:05:00","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=9955"},"modified":"2026-10-08T13:05:00","modified_gmt":"2026-10-08T13:05:00","slug":"awss-repeated-problems-with-ai-agent-controls-illustrates-the-autonomous-agent-dilemma","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=9955","title":{"rendered":"AWS\u2019s repeated problems with AI agent controls illustrates the autonomous agent dilemma"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

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\u2019 Unit 42 and at Zenity Labs.<\/p>\n

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<\/a> and the difficulty in controlling those agents<\/a>. The fact that a hyperscaler with Amazon\u2019s massive resources can\u2019t seem to get ahead of the problem illustrates the agentic challenge<\/a> for all enterprise IT and cybersecurity executives.<\/p>\n

AgentCore issues<\/h2>\n

On September 18, 2026, for example, Palo Alto Networks\u2019 Unit 42 cybersecurity researchers reported<\/a> an issue \u201cwhere using default configurations in AWS AgentCore Harness could allow attackers to steer an agent\u2019s actions through prompt injection to exfiltrate plaintext credentials managed by AgentCore Identity.\u201d<\/p>\n

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.<\/p>\n

\u201cThe harness\u2019s own built-in shell tool, which is enabled by default, reaches into the same memory space where credentials are resolved to plaintext,\u201d the report explained. \u201cThe 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.\u201d<\/p>\n

\u201cWe\u2019ve 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,\u201d it added. \u201cNothing has to be misconfigured for this to happen. It is the out-of-the-box state.\u201d<\/p>\n

The Unit 42 report said that Amazon\u2019s response was ambiguous about whether it had actually plugged that hole: \u201cWe disclosed this finding to AWS. AWS reviewed and closed the report as informative under the AgentCore shared responsibility model,\u201d it noted.<\/p>\n

Several months earlier, on April 7, Unit 42 had also alerted AWS to a different path to credential exfiltration<\/a>.<\/p>\n

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.<\/p>\n

\u201cPrior to our disclosure and AWS\u2019s fixes, this configuration could have allowed an attacker to exploit standard web vulnerabilities, such as server-side request forgery (SSRF<\/a>), to directly extract sensitive credentials, putting the entire environment at risk,\u201d Unit 42 wrote at the time.<\/p>\n

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.<\/p>\n

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\u2019s execution role. \u201cThese credentials aren\u2019t scoped to the sandbox. We exported them onto our own machine, outside AgentCore entirely, and confirmed they were live,\u201d the report said.<\/p>\n

The agent delivered data that included ECR read permissions, \u201cso we authenticated to the registry and pulled the image. From there, the agent\u2019s source code, its dependencies, and whatever its developers baked in were ours to inspect, as root,\u201d the report said.<\/p>\n

\u201cAt this point, a reasonable reaction is \u2018So don\u2019t give agents a raw HTTP tool.,\u2019\u201d Zenity noted. \u201cThat doesn\u2019t 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\u2019 built-in shell tool.\u201d<\/p>\n

But, according to the Zenity report, the agent also shared the credentials of other agents.<\/p>\n

\u201cAgentCore names each repository after its agent (`bedrock-agentcore-`). So running our automated tool on all the discovered agents got us all source code of all agents in the region within a few seconds,\u201d the Zenity report said.<\/p>\n

\u201cWe discovered that the role held permissions with READ, WRITE and DELETE access to various AgentCore and AWS services across the AWS region,\u201d it said. \u201cThis allowed us to invoke other agents and move laterally within the region, read all private conversations for all users and agents, poison memory and keep persistence, harvest credentials and API keys that can unlock access beyond AWS and run destructive actions within the same region.\u201d<\/p>\n

Patch status unclear<\/h2>\n

It is not entirely clear how much of that exposure still exists today. Zenity\u2019s published timeframe has its researchers discovering much of this in late 2025, reporting the details to AWS on December 25. AWS responded with an update in February 2026, but Zenity said it may have simply closed one limited path to the exposure, leaving others open to attack.<\/p>\n

Zenity confirmed that as of Oct. 8 the AWS environment\u2019s permissions had been fixed and it was no longer exposed to the attack path that they had discovered.<\/p>\n

But a more precise timeline provided by Zenity illustrates three things: the complexity of securing agentic environments; the challenges of fixing that hole and having the hole remain fixed; and the difficulties in determining whether a hole has been truly closed.<\/p>\n

After the Zenity and the Palo Alto reports, AWS updated its environment in February, thinking it had fixed the issue. But an Oct. 8 email from Tamir Ishay Sharbat<\/a>, director of security research at Zenity, said that the February fix did not in fact resolve the flaw.<\/p>\n

\u201cAfter our disclosures, AWS quickly updated AgentCore to use IMDSv2 only on Feb. 14, 2026. This update patched the initial entrance vector which allowed us to access the credentials in the first place,\u201d he wrote, but \u201con June 22, we checked AgentCore\u2019s default role and found its permissions remained unchanged.\u201d<\/p>\n

However, he wrote, Zenity\u2019s subsequent checks confirmed that AWS fixed the permissions issue between June 22 and Sept. 29.<\/p>\n

Asked what CISOs and CIOs should do about the problems referenced in the report, Zenity CTO Michael Bargury<\/a> said in an email that the issue is challenging because, on the one hand, a strong defense means strong agent isolation. But, he noted, \u201cagents require autonomy and connectivity to be useful. The two are at odds with each other, as this research shows. Enterprises should be mindful of that inherent conflict, and plan their security controls accordingly.\u201d<\/p>\n

AWS declined a request for an interview, but emailed a short statement in which it again stressed that the agents did what they were supposed to do. It was also asked to comment on the Zenity report; in response, a spokesperson said, \u201cAWS is aware of the research published about Amazon Bedrock AgentCore, which inaccurately paints expected and documented behavior as a vulnerability. An agent can access resources in another AWS account only if the developer explicitly grants permissions on both the agent\u2019s execution role and the target resource. As a best practice, we recommend that customers grant their execution roles only the permissions their agents need.\u201d<\/p>\n

Analysts and consultants found both reports\u2019 details concerning, but not surprising, given the large number of agentic issues they have so far observed. But of all of the published details, the memory problem was the most disconcerting to some.<\/p>\n

Frank Dickson<\/a>, principal analyst at Dickson Research, said, \u201cthe memory poisoning worries me most. A poisoned memory turns a helpful agent into a Manchurian Candidate, waiting for the right conversation to send it somewhere it should not go. You can rotate a stolen key. It is much harder to know which memories to trust.\u201d<\/p>\n

Nik Kale<\/a>, a member of the Coalition for Secure AI (CoSAI) and part of ACM\u2019s AI Security (AISec) program committee, also felt that the memory issue was the most serious.<\/p>\n

\u201cA stolen credential expires in hours, and a poisoned memory doesn\u2019t,\u201d Kale pointed out. \u201cIt keeps steering conversations long after every key has been rotated.\u201d<\/p>\n

Old mistakes surfacing in new ways<\/h2>\n

Fred Chagnon<\/a>, a principal research director at Info-Tech Research Group, said he saw the various AWS agentic problems as \u201ca lesson in how old platform configuration mistakes reappear in new platforms and in new ways.\u201d<\/p>\n

For example, he said, the AWS security hole that used SSRF to reach the metadata service and steal a workload\u2019s credentials \u201cis essentially the pattern behind the 2019 Capital One breach<\/a>: SSRF, stolen role credentials and an overprivileged role that turned one foothold into far broader access.\u201d<\/p>\n

But with the current problem, Chagnon said, \u201cthe trigger is different: an agent with a shell or HTTP tool will fetch a URL when asked, so the prompt itself is the exploit.\u201d<\/p>\n

And, he added, \u201cthe bigger issue is blast radius. One compromised agent reached every agent, conversation and secret in the account and region.\u201d<\/p>\n

The harder part is what enterprise CISOs and CIOs should do about this. One of the oldest challenges in IT is juggling environments where authority, controls and access are shared, with the hyperscaler, as in early initial cloud deployments, making some decisions without the knowledge or permission of its largest corporate tenants.<\/p>\n

\u201cResponsibility here is shared. Isolating the sandbox and keeping platform material out of instance metadata is AWS\u2019s job, and no customer can fix that,\u201d Chagnon explained. \u201cDefault permissions are something the cloud engineer can and should replace, but most won\u2019t. A default role with wildcard access remains the risk. AWS could ship least-privilege defaults scoped per agent and constrain metadata access from the sandbox.\u201d<\/p>\n

However, he said, in the shared responsibility model, the onus for these controls is on the enterprise. CISOs should write their own least-privilege rules and treat shell and HTTP tools as high-risk. They should restrict egress, keep secrets out of images, and baseline each agent\u2019s identity and tool usage so anomalies stand out.<\/p>\n

\u201cEnterprises cannot fix cloud platform flaws any more than they can fix or compensate for the litany of enterprise software flaws,\u201d he said. \u201cBut they can decide and design for how much damage one compromised agent can do.\u201d<\/p>\n

The big problem: Agents worked as designed<\/h2>\n

Dickson added that the big problem with the AWS situations was not that the agents malfunctioned, but that they performed precisely as designed.<\/p>\n

\u201cThe agent did exactly what it was asked to do. That is the problem,\u201d he said. \u201cZenity Labs found a chain: an agent that can reach the network, a metadata service that answered it with the agent\u2019s own cloud credentials, and a default execution role with far more permission than any one agent needs. Each link is a familiar mistake. Chaining them turns one public-facing agent into a hotel key card that opens every room in the building.\u201d<\/p>\n

Kale agreed.<\/p>\n

\u201cPulling credentials from a metadata service is cloud hacking 101, and what\u2019s new is that the researchers didn\u2019t need to find a bug to get there. They just asked the agent in plain English,\u201d Kale said. \u201cOnce that\u2019s possible, the strength of the sandbox walls stops being the interesting question. The real boundary is whatever identity the agent carries, and if that identity reaches across other agents, one conversation can impact an entire environment.\u201d<\/p>\n

Justin Greis<\/a>, CEO of consulting firm Acceligence, said what he would stress to enterprise CISOs is the importance of controlling secondary data access.<\/p>\n

\u201cThe blast radius of a poorly governed agent can be far greater than most organizations are accustomed to with traditional applications,\u201d he said. \u201cWhat stands out in this research is the amplification effect. The issue was not simply that one agent could be manipulated. The concern is that compromising one agent potentially creates a path to broader credentials, other agents, source code, sensitive information and persistent manipulation of behavior. That is where this becomes an executive issue rather than just another technical vulnerability.\u201d<\/p>\n

He suggested that CIOs and CISOs ask, and insist upon answers to, key questions such as the identity the agent operates under, what it can access, what it can change, what it can remember, and what other agents or systems it can reach.<\/p>\n

\u201cAnd,\u201d he said, \u201cmost importantly, what happens if it is compromised?\u201d<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

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\u2019 Unit 42 and at Zenity Labs. But the problem is not with AWS, which seems to be reacting quickly to address security reports, […]<\/p>\n","protected":false},"author":0,"featured_media":9956,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-9955","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/9955"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=9955"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/9955\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/9956"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=9955"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=9955"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=9955"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}