Viewpoints

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

SecurityAI agentsIdentity

Linked sources are the record. Check them for the full reporting.

Read next

Viewpoint · · 4 min read

An AI kill switch is only as good as the agent’s identity

CrowdStrike launched an AI Kill Switch that stops a rogue agent, blocks it from relaunching and cuts its network access, and agreed to buy two AI security firms. A stop button is welcome. But it can only stop what it can tell apart, and an agent running on a person’s account or a shared credential can’t be stopped alone.

SecurityAI agents

Viewpoint · · 10 min read

AI finds the flaws faster than you can fix them. Fixing is now the job.

McKinsey argues that frontier AI has moved the security bottleneck from finding software flaws to fixing them. I agree, and the lesson is older than AI: like data defects, software flaws only get fixed when someone owns them and has a budget. That gets hard when the business, not IT, owns the code, and it is the same consequence-and-authority logic the OCC just gave its examiners.

SecurityAI agents

Viewpoint · · 6 min read

Seven vendors now sell agents a semantic layer. Who signs off what the data means?

In six weeks, Microsoft, Dell, Oracle, SAP, Zoho, NVIDIA and Snowflake all announced a layer of business definitions for AI agents to use. The industry now agrees agents need approved meaning before they answer. What most announcements leave out is who approves it, and whether the approval travels when your data sits on more than one platform.

DataAI agents