From the AWS edition of October 30, 2026
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
Zenity Labs · Cross-SLED (agentic AI platform security) · Global (AWS commercial platform)
- Publisher
- Zenity Labs
- Original publication
- 2026-10-08
- Source retrieved
- 2026-10-31
What happened
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.
Why it matters
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 and measured results
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.
Limitations and uncertainty
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.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-30; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- 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
- Discovery questions
- 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?
- Value hypothesis
- A focused review of agent roles and network egress can close a known class of blast-radius risk at low effort.
- Potential engagement
- Two-week AgentCore configuration and IAM review with a remediation plan and test evidence.
- Unsupported claims
- 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
Pre-sales engineering
Role takeaway
- Fit
- Relevant to any agency or university running agents on Bedrock AgentCore, especially with HTTP-capable tools.
- Architecture and integration
- 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.
- Proof of value
- 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
Role takeaway
- 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.
- Skills and adoption
- Upskill agent developers on IAM scoping and metadata-service risks. Add the checks to code review templates.
- Governance checkpoints
- Security review before any new public agent goes live
- Quarterly IAM drift review
- Incident review if anomalous calls are found
- Acceptance criteria
- 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
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
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.
Governance
Who approves, reviews and stays accountable for outcomes?
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.
Security and privacy
What data, permissions and controls need testing?
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.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Agency developers need cloud-security skills (IAM scoping, IMDSv2, egress control) that low-code agent tooling can hide.
Procurement
What should contracts, pricing and exit terms secure?
Ask vendors and integrators to attest to per-agent least-privilege roles, IMDSv2 enforcement and account separation. Require notification of platform security changes.
Operating model
Which teams own the service once it runs?
Inventory existing AgentCore agents and their creation dates. Re-baseline roles against current defaults and add periodic IAM drift checks.
Publication history
- 2026-10-30AWS · Issue 027 resources
Stable resource ID: zenity-agentcore-imds-overprivileged-default-role-20261008