One prompt, every agent: blast radius is the agent question that matters now
Researchers showed that one prompt to one exposed agent on Amazon Bedrock AgentCore could reach every agent in the same account and region, because they all leaned on a broad default role. As vendors ship thousands of prebuilt agents and Microsoft heads into Ignite calling agent adoption “a trust decision,” the question for banks, insurers and private equity portfolios is the same: if this agent is turned, what else does it reach?
What happened
On 8 October, Zenity Labs published research on Amazon Bedrock AgentCore, AWS’s service for running AI agents. An agent tool that makes web requests could be steered by a prompt to call the cloud instance metadata service, which handed back the temporary credentials of the agent’s execution role. The default role allowed far more than one agent needed: listing other agents, invoking them, reading their conversations, writing to their memory and retrieving stored secrets. Zenity’s conclusion was that a single exposed agent could lead to takeover of every AgentCore agent in the same AWS account and region.
Zenity reported the issues starting in December 2025. AgentCore moved to the more protected version of the metadata service in February, and by 29 September AWS had removed the cross-agent, conversation-reading and Secrets Manager permissions from the default role. AWS described the behavior as “documented and expected,” which is a different reading from Zenity’s.
Two other events this week raise the stakes. On 10 November, IBM and Microsoft announced Imagine Enterprise, a platform for building, running and governing agents, with more than 6,000 prebuilt agents and assets and initial frameworks for financial services, insurance and retail. It uses Microsoft Entra for identity and Purview for governance. The release doesn’t say whether it is generally available or in preview. And Microsoft heads into Ignite, 17 to 20 November in San Francisco, describing the adoption of an agent as “a trust decision,” with Agent 365 positioned as a registry and least-privilege control for agents.
My view
The AgentCore finding isn’t really about AWS. It is about a pattern every platform invites: agents that share one broad role because it was the default, and that nobody scoped down because the pilot worked.
Most agent risk discussions start with the model. Will it hallucinate, will it follow instructions, can it be jailbroken. Those matter. But the AgentCore research shows why the more useful question is about reach. Prompt injection will keep working some of the time against some agents. What decides whether that is an incident or a catastrophe is what the agent’s credentials can touch once it has been turned. That is its blast radius.
Three things set the blast radius, and each is a decision, not a property of the model:
- Whose identity the agent runs on. Its own, scoped to one purpose, or a shared role, a service account or a person’s login.
- What that identity can reach. One system and one dataset, or other agents, their memories, their conversations and the secrets that unlock everything else.
- What it can do without a person. Read, draft, or act: send, pay, approve, change a record.
Prebuilt agents make this more urgent, not less. Six thousand agents and assets is a catalog. Each one installed will need its own identity, owner and limits, or it will inherit whatever the platform’s defaults allow. Defaults are tuned for a demo that works on the first try, not for production.
Why it matters
For the industry. The control that matters is boring and specific: one agent, one identity, one purpose, with permissions that match the purpose and nothing that lets one agent read or steer another. Registries and policy tools like Agent 365 help you find agents and enforce limits. Deciding what each agent’s purpose and limits should be still falls to its owner.
For banks
The OCC’s new framework, issued 4 November, asks examiners to consider whether a provider’s agents can access bank systems and customer information, whether permissions are restricted, and whether the bank can suspend or terminate an agent’s activities. It also asks whether contracts give the bank rights to monitor, test, restrict or terminate third-party systems. An agent that shares a broad role with its neighbors makes every one of those answers harder. A bank should be able to say, for each agent, what it would reach if it were compromised, and show that stopping it stops only it. My earlier piece on how the OCC will judge bank AI by what it can do covers the framework itself.
For insurers
Claims and underwriting agents sit next to the most sensitive data an insurer holds: medical records in claims files, financial details in submissions, payment instructions. An intake agent that only reads first notice of loss is low risk on its own. On a shared role that can also invoke the payment agent or read the fraud model’s conversation history, it isn’t. Platforms like Imagine Enterprise that ship insurance frameworks out of the box should be accepted the same way a new adjuster is: with a defined role, a supervisor and access limited to the files they work.
For private equity and portfolio companies
Portfolio companies rarely have a dedicated AI security team, and they often adopt the same agent platforms on the same defaults. That means one weakness can repeat across a portfolio. Two practical moves: make “each agent has its own identity, owner and scoped permissions” a standard item in the portfolio’s technology playbook, and ask for an agent inventory with blast radius as part of the value creation review. A buyer’s diligence team will ask the same question at exit, and an inventory is far cheaper to keep than to reconstruct.
How it connects to our work. Agent Onboarding sets out how to admit an agent like a new employee: its own bounded identity, a named owner, a stated purpose and an expiry. The Agent Patterns builder lets you describe an agent’s data, tools and autonomy and see the pattern and controls it calls for. When you are choosing between platforms, Choosing an Enterprise Platform for AI Agents treats per-agent identity and least privilege as hard gates to prove before you commit, not features to configure later. Before you widen any agent’s reach, I’d check four things:
- Own identity. No agent runs on a shared role, a person’s login or a platform default.
- No lateral reach. An agent can’t list, invoke or read the memory of another agent unless that is its stated job.
- Secrets out of reach. Credentials for connected tools are issued per task, not readable by the agent at will.
- A clean stop. Suspending one agent is tested and stops only that agent, as I argued in the kill switch piece.
This is part of a short series on putting agents into production safely, written for banks, insurers and private equity portfolios. If you want the next one, the sign-up is below.
Sources
- AgentCorruption: how a single prompt collapsed the entire cloud security model, Zenity Labs, 8 October 2026
- IBM and Microsoft announce a new AI agent platform designed for industry-specific transformation, IBM, 10 November 2026
- Microsoft frames its Ignite security week around AI agents with real access, MarketScale, November 2026
- OCC issues supervisory framework for banks’ use of “super intelligence”, Consumer Finance Monitor (Ballard Spahr), 6 November 2026
Linked sources are the record. Check them for the full reporting.