{"resourceId":"zenity-agentcore-imds-overprivileged-default-role-20261008","versions":[{"version":"external-9d1ff6a63aa052abf2c930cb4689106611581537d7bf80a6c7089537a0c658c2","resource":{"id":"zenity-agentcore-imds-overprivileged-default-role-20261008","title":"Zenity Labs: one prompt to an exposed Bedrock AgentCore agent could pull IMDS credentials and, via an overprivileged default role, reach every agent in the account-region","organization":"Zenity Labs","sector":"Cross-SLED (agentic AI platform security)","geography":"Global (AWS commercial platform)","publishedAt":"2026-10-08","publicationDate":"2026-10-08","eventDate":null,"sourceName":"Zenity Labs","sourceLabel":"Zenity Labs security research (independent; AWS disputes framing)","sourceUrl":"https://labs.zenity.io/post/agentcorruption-how-a-single-prompt-collapsed-the-entire-cloud-security-model","evidenceClass":"independent-research","outcomeClass":"cautionary","topics":["developers-agents","data-security","infrastructure","governance-procurement"],"finding":"Zenity researchers report that AgentCore agents could reach the instance metadata service (IMDS) from inside their Firecracker microVM. Any HTTP-capable tool therefore became a server-side request forgery path, and a single prompt injection returned the agent's temporary IAM credentials. Because the default execution role was scoped to all AgentCore resources in the account-region, those credentials could enumerate and invoke other agents, read all conversations, write persistent memories and retrieve Secrets Manager values. Disclosure began 2025-12-25. AWS moved new agents to IMDSv2-only on 2026-02-14, but the default role was unchanged as of 2026-06-22 and had been substantially hardened by 2026-09-29. Why now: AWS's 28 Oct delegation-audit guidance and the AgentCore CLI 1.0 GA the same day make this independent counterpoint newly relevant for agencies starting AgentCore pilots.","sledRelevance":"State and local agencies and universities building public-facing agents on AgentCore (resident assistants, student help, eligibility helpers) would have faced account-region-wide exposure from one public agent under the old defaults. The overview does not say whether agents created before the fixes were updated automatically.","evidence":"Independent security research with proofs of concept and a dated disclosure timeline, published as a five-part series (only the overview was inspected). Corroborated by The Register (9 Oct 2026, updated 12 Oct), which reports that AWS said the research 'misrepresents documented behavior as a vulnerability' and suggested developer error would be required. Zenity responded that the issues did not cross the account boundary and have been fully mitigated. No public-sector victims are reported.","architectureImplications":"Agent runtimes need network egress controls that block link-local metadata endpoints. Use one narrowly scoped execution role per agent, and separate AWS accounts for public-facing agents and sensitive internal agents to contain blast radius.","governanceImplications":"Vendor defaults cannot be assumed least-privilege; agencies should require configuration review of execution roles before go-live. The months-long remediation timeline argues for contract terms on vulnerability notification for managed AI platforms.","securityPrivacyImplications":"Exposure covered private conversations, memory poisoning (persistent hijacking of agent goals) and credential theft for connected tools. Resident or student conversation logs would be in scope under the old defaults.","caveats":"AWS disputes that this was a vulnerability rather than documented behavior. Zenity is a security vendor with commercial interest in agent security. The issues are reported fixed for new deployments, and residual risk depends on when agents were created and whether roles were customized. Older than the last run; included for its new relevance, not as breaking news.","streamIds":["aws"],"roles":{"sales":"Sales framing: use this as the independent evidence that agent platform defaults need verification, especially for agencies moving resident- or student-facing agents to AgentCore. Present both sides: Zenity's findings and timeline, and AWS's position that it was documented behavior. Offer a bounded security review of existing agents rather than alarm. Do not claim any agency was breached or that current AgentCore deployments are vulnerable. The research says the issues were mitigated, so the value lies in checking older or customized configurations.","engineering":"Engineering framing: check every AgentCore agent's execution role. Replace any broad, region-scoped role with a per-agent policy limited to its own runtime, memory and specific secrets. Enforce IMDSv2 and block link-local egress from HTTP-capable tools. Put public-facing agents in separate accounts from internal ones. Test with a prompt that asks the agent to fetch the metadata endpoint, and confirm it fails. Review logs for DescribeLogGroups, cross-agent invocations and ListEvents calls that would indicate misuse.","delivery":"Delivery framing: run a short remediation sprint across the agency's agent inventory. Record when each agent was created and its role, rescope roles, rotate any secrets the agents could reach, and add IAM drift detection to operations. Make per-agent least privilege and egress controls a go-live checklist item for future agents. Report status to the security officer and governance board, noting the vendor dispute so decisions rest on the agency's own configuration evidence."},"roleDetails":{"sales":{"customerProblem":"Agencies deploying AI agents on a managed platform may assume the default permissions are safe when they were not.","stakeholders":["Agency CISO","Cloud platform owner","AI program lead","Privacy officer","University IT security office"],"discoveryQuestions":["How many AgentCore agents do you run, and when were they created?","Are public-facing agents in the same AWS account as internal ones?","Do agents use the default execution role?","Who reviews IAM for AI workloads?"],"valueHypothesis":"A focused review of agent roles and network egress can close a known class of blast-radius risk at low effort.","potentialEngagement":"Two-week AgentCore configuration and IAM review with a remediation plan and test evidence.","unsupportedClaims":["That any public agency was compromised","That current AgentCore defaults remain vulnerable","That AWS agrees this was a vulnerability","That the issue crossed AWS account boundaries"]},"engineering":{"fit":"Relevant to any agency or university running agents on Bedrock AgentCore, especially with HTTP-capable tools.","architectureIntegration":"Per-agent IAM roles, IMDSv2 enforcement, egress filtering for link-local addresses, separate accounts for public agents, and AgentCore Identity/Gateway with narrowly scoped secrets.","prerequisites":["Agent inventory with creation dates","IAM access to review execution roles","CloudTrail enabled in agent accounts"],"constraints":["Remediation status depends on agent creation date and customization","Account restructuring may disrupt existing agents","Vendor and researcher disagree on classification"],"security":"Primary risks are credential theft, cross-agent lateral movement, conversation exposure and memory poisoning. Mitigate with least privilege, egress control and log monitoring.","proofOfValue":["Metadata-fetch prompt test fails on every agent","Each agent role grants access only to its own resources","No agent can call GetSecretValue for secrets outside its scope","CloudTrail review shows no anomalous cross-agent calls"]},"delivery":{"work":"Inventory agents, rescope roles, enforce IMDSv2 and egress rules, rotate exposed secrets, and add drift monitoring.","dependencies":["Cloud security team availability","Change windows for agent redeployment","Secrets owners for rotation"],"ownership":"Agency cloud platform team, with the CISO accountable.","skillsAdoption":"Upskill agent developers on IAM scoping and metadata-service risks. Add the checks to code review templates.","governanceCheckpoints":["Security review before any new public agent goes live","Quarterly IAM drift review","Incident review if anomalous calls are found"],"acceptanceCriteria":["Proposed: 100% of agents use per-agent least-privilege roles","Proposed: metadata endpoint unreachable from all agent tools in testing","Proposed: secrets reachable by any agent rotated after rescoping"],"risks":["Legacy agents overlooked","Breaking agent functionality when narrowing roles","Complacency because the vendor reports the issue fixed"]}},"retrievedAt":"2026-10-30T22:11:21-05:00","enrichedAt":"2026-10-30T22:17:58-05:00","enrichmentBasis":"retrieved source","accessibilityWorkforceImplications":"Agency developers need cloud-security skills (IAM scoping, IMDSv2, egress control) that low-code agent tooling can hide.","procurementImplications":"Ask vendors and integrators to attest to per-agent least-privilege roles, IMDSv2 enforcement and account separation. Require notification of platform security changes.","operatingModelImplications":"Inventory existing AgentCore agents and their creation dates. Re-baseline roles against current defaults and add periodic IAM drift checks.","sourceVerification":{"openedUrl":"https://labs.zenity.io/post/agentcorruption-how-a-single-prompt-collapsed-the-entire-cloud-security-model","referenceExcerpt":"The default AgentCore role wasn’t scoped to the specific agent.","promptVersion":"sled-research-v4.0","model":null,"basis":"agent-reported inspection"}}}]}