AWS has tightened AgentCore’s metadata requirements and generated permissions. That does not prove an older agent’s execution role was updated. Following Zenity’s October 8 security disclosure, Superpower Daily’s bounded public-document review finds concrete improvements, but unresolved coverage for previously created customer roles. Stricter defaults are not evidence that every existing agent received the same protections.
One control governs whether a runtime—the environment running an agent—can accept calls. Another changes permissions generated by AWS’s starter toolkit. The configuration that permits an invocation and the authority carried by an execution role answer different security questions.
Our review covers Zenity’s disclosure, AWS’s security, runtime-permissions and workload-identity documentation, toolkit pull request 554, and execution-role templates v0.3.10 and v0.3.14. The cutoff is October 9, 2026, at 02:31 UTC. We compared documented applicability and conditional template branches, without testing customer accounts, deployed policies, active sessions or attacks. This is a documentary finding, not a determination that any deployment remains exploitable.
A metadata requirement is not a credential barrier
Zenity’s AgentCorruption disclosure supplies the stakes. Researchers Tamir Ishay Sharbat and Lana Salameh described prompting an exposed agent with a web-request tool to retrieve temporary credentials from its internal metadata service. They said the default execution role then allowed access beyond that agent, including other agents, private conversations, memory and stored secrets.
AWS calls the internal service the MicroVM Metadata Service, or MMDS. It supplies execution-role credentials that let agent code act on AWS resources. An execution role is the permissions-bearing role AgentCore assumes to run the agent. Each user session runs in a dedicated microVM, an isolated computing environment.
The security guidance sets a concrete requirement: starting June 30, 2026, runtimes without MMDSv2 enabled cannot be invoked and return a ValidationException. AWS directs customers to call UpdateAgentRuntime and set requireMMDSV2 to true within metadataConfiguration. That is an explicit configuration step, not a conclusion operators should draw from a deployment’s age.
MMDSv2 enforcement should not be read as removal of credential access inside the VM. AWS explicitly warns that any code or actor inside that environment can obtain the role’s credentials through the metadata endpoint. Its recommendation is to limit execution-role permissions to what the agent requires. The role still determines what those credentials authorize.
The dates describe different changes
Zenity attributes an earlier metadata change to AWS correspondence. Its account says AWS responded on April 12 that newly deployed agents had launched with IMDSv2 since February 14, 2026. Zenity uses IMDS terminology where AWS’s guide uses MMDS. The February statement concerns new deployments; it does not establish migration of older runtimes.
Role hardening has a separate chronology. AWS merged toolkit pull request 554 on July 27. Zenity says permissions were unchanged in its June 22 review, but it observed substantial restrictions during a final review on September 29. That September date is an observation date, not an established rollout date. Nor do the two records identify the same role-generation path or coordinated change.
Narrower templates, with important exceptions
The version-tagged templates provide a reproducible before-and-after comparison. Their conditional branches determine which permissions enter a generated policy. Agent-to-agent invocation is one branch; memory access is another. These conditions matter because a template does not produce the same permissions for every configuration.
These patterns narrow access from all matching runtime or memory resources to resources sharing an agent-specific naming prefix. They are not necessarily a single-resource permission: the runtime pattern covers the agent’s runtime family. The pull request limits its changes to generated policy documents and their unit tests. AWS separately documents console-created roles and policies in customer accounts, another creation path that should not be treated as interchangeable with the toolkit.
Secret access supplies concrete counterevidence. Zenity says the default role it reviewed in September no longer allowed access to secrets stored in AWS Secrets Manager. Yet the v0.3.14 template retains GetResourceApiKey and secretsmanager:GetSecretValue. The latter is scoped to AgentCore Identity’s OAuth2 and API-key secret namespaces, not unrestricted secret access. This prevents generalizing Zenity’s observation to every updated creation path; it does not prove that observation was wrong.
A separate, explicit migration boundary concerns workload identity. AWS says agents created before October 13, 2025 retain manual execution-role identity policies without automatic migration; newer agents use service-linked roles. This documents preserved legacy behavior for that feature, not migration of the later security changes. Missing security-fix migration documentation likewise does not prove that no migration occurred.
Production needs an attached-policy check
AWS’s production guidance is stronger than a recommendation to use newer defaults. Its permissions documentation warns that CLI-generated policies are designed for development and testing, grant broad access and are unsuitable for production. It recommends custom policies restricted to the actions and resources an application actually requires.
Reader comments
Newest comments first. Replies stay oldest first.