Your cloud security model assumes that a permission your agent does not hold is a wall. At DEF CON 34 this week it turned out to be a door with a doorman — and the agent knows how to ask.
Across three days at the Las Vegas Convention Center, the Cloud Village and AI Village schedules converged on one finding that should change what you scope next quarter: an AI agent holding standing IAM permissions does not need to steal a credential or exploit a bug to get more permissions. It reasons its way to them through the cloud provider's own authorization APIs. And in at least one demonstration, as the researcher describes it, it did so on behalf of a different agent, running in a different framework and a different environment. Every call in the chain was allowed. Not one of them was denied.
That last detail is the part your controls are not built for. Per-agent least privilege — the thing every agent identity vendor is selling right now — bounds what one agent can do. It does not bound what one agent can arrange.
What "Cross-Agent Escalation" Actually Means
Cross-agent privilege escalation is when one AI agent uses its own legitimately granted permissions to raise the permissions of a second agent, which then performs the action the first agent was never allowed to perform. No credential is stolen and no vulnerability is exploited; the authorization system works exactly as designed.
Muskan Tomar, a Security and Reliability Engineer at Microsoft, presented the demonstration on Friday afternoon in Cloud Village under the title The Polymorphic Agent: From Cross Agent Escalation to Just in Time Defense on Azure. The chain starts with a single poisoned tool description — rewritten to read like routine compliance guidance rather than an instruction — which the agent parses, reasons about, and acts on. The outcome, per the session abstract, is agents granting elevated IAM roles through authorized IAM calls on real Azure identities.
Forkast's write-up of the conference, published August 8, describes the same research as "manipulation of trust between agents": an agent built on one stack is tricked into escalating the privileges of a separate agent running elsewhere. Read that as a second description of the same abstract rather than independent confirmation — its author was not in the room, and as of publication no slides, recording or post-talk write-up has surfaced. What is verifiable today is the claim as its author states it, on a stage where that claim gets made in front of the people best equipped to pull it apart.
The trust relationship being abused is not between a user and a system. It is between two pieces of software that were each individually scoped correctly.
The class is not brand new, which is the reassuring half of the story and the alarming half at once. In September 2025, researcher Johann Rehberger demonstrated one agent escalating another by rewriting its configuration — GitHub Copilot editing Claude Code's MCP config to allowlist commands Claude had never been granted. Two independent researchers reaching the same shape by different routes is what a real class of bug looks like. What DEF CON 34 moves is the plane it happens on: from a config file on a developer's laptop to the cloud provider's own authorization service, where the escalation is a production API call against a production identity.
The Attack Chain Has No Compromised Credential in It
The second Cloud Village talk that afternoon spelled out the full path, and there is no theft anywhere in it. In Trust Fall: How Agentic AI Inherits Your Cloud's Worst IAM Habits, Aravind Sreekanth Pallavoor and Sadhana Sainarayanan walked a chain that runs: indirect prompt injection into the agent's context window → tool misuse via an over-privileged Lambda execution role → IAM policy modification → persistent backdoor.
Their framing is the useful one. Cloud IAM was designed for two kinds of principal, humans and machines, and the autonomous agent plays by neither rulebook. Agent orchestrators are being shipped with execution roles "scoped to whatever the deploying engineer thought was 'good enough,'" inheriting a decade of over-privileged patterns. The difference from a badly scoped Lambda is intent: an agent under adversarial instruction does not misuse a permission by accident. It searches for the one that helps.
Worth naming precisely where the over-privilege usually lives, because it is not where people assume. The service role AWS documents for Amazon Bedrock agents is tightly scoped by AWS's own template — bedrock:InvokeModel, s3:GetObject on a schema bucket, bedrock:Retrieve against named knowledge bases, and nothing resembling an IAM write. The blast radius comes from the action group Lambda behind it, whose execution role is written by you, reviewed by nobody, and frequently carries iam:PutRolePolicy or iam:PassRole because that is what made the deploy work in March.
The Graph Was Already Dangerous Before Agents Arrived
The reason an agent can find an escalation path is that your cloud is full of them, and the industry has only recently finished counting. Datadog's pathfinding.cloud library, published in December 2025 by researcher Seth Art, documents 65 unique AWS IAM privilege escalation paths — and reports that "of the 65 paths currently in the pathfinding.cloud library, 27 of them, or 42%, are not detected by any of the open source tools we evaluated."
Art opened Cloud Village on Friday morning with over a dozen more, across services that had never appeared in public research: AWS Batch, Amazon Braket, Managed Apache Flink, GameLift, HealthOmics. He also released Pathrunner, a framework for chaining the multi-hop versions.
Sit those two facts next to each other. Your IAM graph contains dozens of known escalation edges, a large minority of which the open-source scanners Datadog tested could not find — and you have just placed inside that graph a principal whose entire job is to search a space of possible actions for one that achieves a stated goal. Tenable's Cloud and AI Security Risk Report 2026 puts a number on the overlap: 18% of organizations have IAM roles with critical or high excessive permissions that AWS AI services can instantly assume, and 65% are carrying unused or unrotated keys tied to high-risk identities.
Your Detections Key on a Verb That Never Fires
The reason this reaches production undetected is that almost every agent-security detection in the field triggers on a stolen credential or an access-denied event, and this chain produces neither. There is no AccessDenied in CloudTrail. There is no impossible-travel login. There is no anomalous key. There is a service principal, doing something it is permitted to do, at a time it normally works.
Steel-man the other side, because the cloud providers are not asleep here. Microsoft ships ARM_AnomalousRBACRoleAssignment — "Suspicious Azure role assignment detected (Preview)" — which fires on exactly this operation, alongside ARM_AnomalousServiceOperation.PrivilegeEscalation for high-risk operations invoked by a service principal. Both are real, and both would have a shot at this chain.
Read the detection logic, though. These are anomaly detections: the sibling alert for elevate-access says the activity "is deemed suspicious, as this principal rarely invokes such operations." An agent that legitimately manages cloud resources all day does not rarely invoke such operations. It establishes a baseline in which IAM activity from that principal is normal — which is the same property that makes it useful. The detection degrades precisely as the agent becomes more capable, and most of the privilege-escalation alerts in that catalogue are still marked Preview.
Varonis got at the same asymmetry from the behavioural side. In Pinchy Gets Played on Saturday at 12:20pm, Doron Kapah reported that the target agent shrugged off sophisticated technical attacks and folded immediately against simple social ones. The company's own framing of the takeaway is the sentence to carry into your next design review: what keeps environments secure is "architectural controls — not prompts or policies."
Deny the Verb, Then Measure Two Hops
The control that bounds this is not another identity per agent. It is a hard denial of IAM write actions inside every agent execution path, enforced above the agent so that no instruction — poisoned or otherwise — can reach around it.
On Azure the primitive is already in the box and most teams get it wrong by one dropdown. The built-in Contributor role explicitly excludes Microsoft.Authorization/*/Write and Microsoft.Authorization/elevateAccess/Action in its NotActions. Owner is the same wildcard * with an empty NotActions — that is the entire difference between the two roles. An agent identity assigned Owner because "it needs to manage resources" has been handed role assignment; the same agent assigned Contributor cannot create a role assignment directly, and can still manage every resource it was deployed to manage.
Then apply this article's own argument to its own advice, because Contributor is not a wall either. Its NotActions do not cover Microsoft.ManagedIdentity/userAssignedIdentities/assign/action or Microsoft.Compute/virtualMachines/runCommand/action, and its Actions is * — so a Contributor principal can attach an existing administrative managed identity to a VM or Function App it creates and execute as that identity, reaching role assignment without ever holding the permission. Dropping Owner closes the one-hop grant, and that is worth doing this week. It closes the second hop only if no over-privileged user-assigned identity is assignable in that scope — which is the reachability question below, not a dropdown.
On AWS the equivalent is a permissions boundary, which sets "the maximum permissions that an identity-based policy can grant to an IAM entity." AWS's own worked example is exact: a boundary that omits IAM means the principal "can never perform operations in any other service, including IAM, even if she has a permissions policy that allows it." A boundary attached to every agent execution role, with no iam:* in it, survives a future engineer attaching AdministratorAccess in a hurry. Pair it with an SCP so the boundary itself cannot be removed.
Then measure the thing nobody measures: two-hop reachability. For each agent execution role, enumerate the roles it can reach in one IAM or PassRole action, then what those roles reach. Datadog's taxonomy gives you the edge types to look for — self-escalation, principal access, new PassRole, existing PassRole, credential access. A per-agent permission review that stops at hop one will report every agent as least-privileged while the graph they collectively form contains a path to admin.
This Week:
- List every non-human principal in your cloud that an agent can assume or invoke, and grep their attached policies for
iam:,sts:AssumeRole, andMicrosoft.Authorization/. Do not sample. The point of the DEF CON research is that one edge is enough. - Check whether any agent identity holds Azure Owner where Contributor would do. This is a one-line change with an immediate, verifiable reduction in blast radius.
- Ask your detection team a single question: what fires when a service principal successfully creates a role assignment? If the answer is "nothing" or "a Preview alert we haven't tuned," you have the gap this article is about.
This Month:
- Attach a permissions boundary with no IAM actions to every agent execution role, and wire
CheckAccessNotGrantedfrom IAM Access Analyzer into the pipeline that deploys them, so a policy granting IAM writes fails the build rather than the audit. - Run the two-hop reachability map. Treat any agent role that reaches a role-assignment permission in two hops as a finding with a name and an owner, not a posture score.
- Add cross-agent escalation to your red-team scope. Most agent red-teaming today tests one agent in isolation, which by construction cannot find this class — red-teaming agents before production has to include the multi-agent case now.
Before Your Next Agent Platform Renewal:
- Put one question to the vendor in writing: what in your product prevents Agent A from modifying Agent B's entitlements? Issuing each agent an identity is not an answer to that question. Neither is logging.
The Bottom Line
We have seen this shape before. Microservices were supposed to contain failure by making each service small, and then service meshes had to be invented because the interesting failures lived in the calls between the small things. Container security spent years hardening the image before anyone measured what the orchestrator's service account could reach. Agent identity is at the same point in its arc: the per-unit control is correct, necessary, and insufficient, and the industry is currently selling the per-unit control as the whole answer.
The DEF CON 34 schedule itself made the argument. Friday demonstrated the escalation. Saturday's AI Village session, That's Not Your Agent: Why Zero Trust Can't Tell, took up the identity half of the same problem — whether verification can tell the agent you deployed from the one acting in its name. And the last day, Sunday, belonged to a Meta detection engineer presenting When Machines Attack Machines: Detecting AI-Autonomous Cloud Compromise at NHI Scale — the defensive answer, scheduled after everyone had already gone home.
Buy the agent identity platform if you need it. Just stop treating it as a boundary. The boundary is the verb you refuse to allow, enforced somewhere the agent cannot reason with.
An access-denied error stops malware. It does not stop something that can ask.
Continue Reading
Okta Bought Permiso. Your Leverage Expires Oct 31. Your AI Agents Have Keys to Everything. Nobody's Watching. 9 in 10 Enterprises Breached Through Identity No One Manages Both AI Labs Lost Control of Their Agents. 88% of Firms Will Too. AI Agents Have Admin Access. 57% of Firms Aren't Ready. Agentjacking: AI Agents Hijacked via Fake Bug Reports Zero Trust for AI Agents: Why Implicit Trust Breaks Now Ping vs Okta vs Entra: Best AI Agent Identity in 2026?