Prompt and Circumstance: Who Can Prompt Your AI Agent, and Everything It Can Reach

In a previous post we argued that the safe response to shadow AI is to offer agents on the cloud you already run. It boils down to two questions: what can this agent do, and who can prompt it? Those sound like governance questions. They are not. On a real cloud, both of them are privilege-escalation questions, and until recently they were nearly impossible to answer.

This post makes them concrete. Using Amazon Bedrock and its newer agent runtime, AgentCore, as the worked example, we walk the specific lateral-movement paths that PanIAM now detects. The service names are AWS, but the shape of the problem is the same on any cloud that lets you attach a managed agent to an identity.

An agent is an execution role in a costume

A Bedrock agent is not just a model. It is a small bundle: a foundation model, a set of instructions, some action groups (the tools and APIs it may call), an alias that callers invoke, and, crucially, an execution role. That role is an ordinary IAM role with ordinary permissions. When the agent runs, it runs as that role.

That single fact is the whole story. The agent is a costume worn by a role. Anyone who can make the agent act is, for the duration of that action, operating with the role’s permissions. So the two questions from the first post translate directly:

• What can the agent do? Whatever its execution role can reach.
• Who can prompt it? Whoever can invoke, modify, or create it.

AgentCore adds three more building blocks that behave the same way: a runtime (where agent code executes), a gateway (how it reaches tools and data), and a code interpreter (a sandbox that runs code). Each is an identity-bearing resource with actions that map onto the same escalation questions.

Who can prompt it: prompt injection as role inheritance

Start with the path that has no equivalent in traditional infrastructure.

An attacker does not need the agent’s credentials. They do not need to compromise the runtime. They only need to be allowed to invoke the agent’s alias, and then to supply input the agent will act on: a document to summarize, a ticket to triage, a web page to read. Language models cannot reliably separate an instruction from the content they are given, so hostile text in that content becomes an instruction. Guardrails are getting better over time, but so far, no protection achieved perfect security. Moreover, the ways to abuse agents get subtler and subtler. The agent then uses the access it already holds, on the attacker’s behalf.

PanIAM models this as a single escalation path:

attacker  (allowed: bedrock:InvokeAgent on the alias)
   │
   │  BedrockPromptInjection
   ▼
Bedrock agent  ── Assume ──▶  execution role  ── Read ──▶  s3://sensitive-bucket

The middle hop matters. The agent is folded into its execution role, so the path does not stop at the agent. It continues through everything the role can reach: the buckets it can read, the tables it can write, the roles it can in turn assume. “Who can prompt it” inherits the full downstream blast radius of “what can it do.”

There is a reason we treat this as the most stubborn edge in the graph. You cannot fix it by revoking one permission, because the vulnerability is not a permission; it is the fact that a role-bearing agent is exposed to untrusted input at all. The remedy is structural: narrow the execution role, or narrow who may invoke the agent. That is exactly the pair of levers the two questions point at. Many cyberplayers in the field like to call that the principle of Least Agency, but it’s just the good oldfashioned Least Amount of Priviliges principle applied to an agent.

You don’t always need the agent that already exists

Prompt injection assumes a useful agent is already sitting there. Two more paths do not.

Modification: repoint the agent you already have. If an attacker can update an agent (its instructions, its action groups, the role it wears), they can turn a benign agent into a hostile one without ever prompting it through the front door.

Creation: mint a new agent around a powerful role. This is the classic PassRole escalation, now wearing an agent costume. A principal who holds both bedrock:CreateAgent and iam:PassRole for a role that trusts bedrock.amazonaws.com can create a brand-new agent bound to that role, then prompt it. PanIAM detects these capabilities and mints two edges:

passer  ── ResourceCreation ──▶  (new) Bedrock agent  ── Assume ──▶  passed role

Neither the agent nor the role existed as a risk a moment earlier. The danger lives in the combination of two permissions that, read one at a time, look routine. A reviewer scanning a policy line by line sees CreateAgent and PassRole and moves on. The graph sees a path.

AgentCore widens the surface

The same three questions apply to AgentCore, and one of its answers is louder than the rest. PanIAM ingests AgentCore runtimes, gateways, and code interpreters, and emits invoke, modify, and create edges for each:

• Invoke. bedrock-agentcore:InvokeAgentRuntime, InvokeGateway, and InvokeCodeInterpreter are the AgentCore analogues of prompting an agent. One of them, InvokeAgentRuntimeCommandShell, is effectively remote code execution inside the runtime: whoever can call it runs commands as the runtime’s identity.
• Modify. UpdateAgentRuntime and UpdateGateway repoint the runtime or the tools it reaches. (There is no update action for a code interpreter, so PanIAM does not invent one.)
• Create. CreateAgentRuntime, CreateGateway, and CreateCodeInterpreter stand up new identity-bearing infrastructure the same way CreateAgent does.

A gateway is worth singling out. It is the agent’s path to your tools and data, so the right to invoke or modify a gateway is the right to change what an agent can touch. On a cloud where agents reach production through gateways, that is a first-class lateral-movement vector.

Why your permission review misses all of this

If these paths are real, why do they slip past a normal access review? Three reasons, all of which the recent work hardened PanIAM against.

The permissions look boring in isolation. As with CreateAgent plus PassRole, most of these paths are two or three ordinary grants that only become dangerous when chained. Reasoning about the chain is a graph problem, not a checklist problem. It is the transitive closure of a role’s reach, and humans do not compute transitive closures by reading JSON.

The dangerous edge cannot be cut by deleting one line. Because prompt injection is inherent to exposing a role-bearing agent to input, no single permission removal fixes it. A tool that only knows how to flag over-broad policies has nothing useful to say here. A tool that models the whole path can tell you the cheapest structural change that actually breaks it.

Why PanIAM is the answer

A permission review gives you policies. PanIAM gives you the three things you actually need to reason about an agent, and it gives them to you as a computed model of your live cloud, not a checklist you run by eye.

A clear picture of what each agent can do. PanIAM folds every agent into its execution role and then computes the transitive closure of that role: the buckets it reads, the tables it writes, the roles it can go on to assume. You do not read JSON and imagine the reach. You see the full blast radius of the identity behind the costume, already resolved.

Every lateral-movement path an agent can exploit. Prompt injection, modification, creation, and the AgentCore invoke/modify/create edges (including InvokeAgentRuntimeCommandShell, which is remote code execution as the runtime’s identity) are all first-class edges in the graph. The dangerous combinations that look boring one line at a time, CreateAgent plus PassRole, a gateway you can repoint, are surfaced as the single paths they really are. The graph computes the chains a human never will.

Exactly who can abuse each agent. For any agent, PanIAM enumerates every principal that can invoke, modify, or create it, and therefore borrow its access. “Who can prompt it” stops being a question you guess at and becomes a list you can read, with the downstream reach attached to each name. That is what makes least privilege achievable instead of aspirational.

Offering agents on the cloud you already run is only safe if you can review them, and reviewing them means answering two questions that turn out to be pure privilege escalation: what can this agent do, and who can prompt it. PanIAM answers both, draws you the paths between them, and hands you the shortest cut. That is the difference between hoping your agents are least-privileged and knowing they are.