Islands of Agents: IAM Failures Across Agent Boundaries

Cloud Security Alliance AI Safety Initiative | March 2026

Key Takeaways

This research note examines a structurally distinct challenge in enterprise AI security: the failure of unified identity and access management frameworks to accommodate the varied principal models of AI agents operating across organizational and platform boundaries. The following findings summarize the core analysis.

• A March 10, 2026 analysis by CSA Chief Analyst Rich Mogull identifies four structurally distinct agent categories — personal desktop, coding, SaaS, and enterprise — each with fundamentally different identity architectures, making a unified “one IAM to rule them all” approach architecturally incoherent [1].
• Only 18% of organizations report high confidence that their current IAM infrastructure can manage agent identities, and nearly half are addressing the gap by extending human IAM models to agents without architectural adaptation — a pattern that creates exploitable mismatches between assumed and actual privilege scope [1].
• When agents cross category boundaries — a SaaS agent invoking an enterprise agent, or a coding agent interacting with cloud infrastructure — delegation chains propagate identities across systems that were never designed to understand or constrain each other’s trust models, creating a class of transitive privilege escalation risk for which no widely adopted, production-ready standard currently exists, though emerging approaches including OAuth 2.0 Token Exchange (RFC 8693) and SPIFFE/SPIRE address portions of the problem [1][2].
• Documented incidents, including the August 2025 Salesloft Drift breach in which stolen OAuth tokens were used to access over 700 organizations’ environments in 10 days, and a July 2025 Replit agent incident in which 1,206 executive records were deleted from a live database in seconds during an active code freeze, illustrate that imprecise agent identity and standing access are not theoretical concerns [2][3].
• The NIST National Cybersecurity Center of Excellence published a concept paper on February 5, 2026, identifying Model Context Protocol, OAuth 2.0/2.1, OIDC, SPIFFE/SPIRE, and SCIM as candidate standards for agent identity, and is accepting public comment through April 2, 2026 — indicating that the standards ecosystem is in active formation rather than settled [4].
• The authors recommend that organizations first categorize their agents by island, then apply appropriate identity controls within each island before attempting cross-island federation, rather than imposing a uniform IAM model that will be correctly calibrated for no category in particular. This sequencing prioritizes eliminating the most structurally tractable risks first and avoids the compound complexity of federated identity governance before intra-island controls are stable.

Background

The Structural Problem with Agent Identity

Enterprise IAM has, for decades, been organized around two principal types: human users with interactive sessions, and service accounts representing specific applications or processes. The security assumptions embedded in most IAM systems — that principals have stable identities, operate within well-defined scopes, follow predictable session patterns, and act on behalf of an identifiable person — fit both categories reasonably well. They do not fit AI agents.

AI agents are autonomous, ephemerally provisioned, capable of recursive delegation, and designed to interact with multiple systems in sequence or parallel on behalf of a task rather than a person. A single agent execution may invoke tools across cloud APIs, SaaS platforms, internal databases, and other agents, each of which may apply its own access controls, maintain its own identity context, and log activity independently. The question of which identity the agent is acting as at any given step — its own, the user who spawned it, a delegated context from an upstream agent, or some composite — is not resolved by most enterprise IAM architectures, because those architectures were not designed to reason about recursive, ephemeral, autonomously-delegating principals that act on task context rather than persistent user sessions.

CSA Chief Analyst Rich Mogull’s March 10, 2026 analysis formalizes this fragmentation through the concept of “islands of agents” [1]. The insight is that asking whether an AI agent has the right identity is insufficient — the question must first ask which island the agent inhabits, because each island operates under a different principal model, is controlled by a different administrative domain, and requires different technical mechanisms to express and enforce authorization. There is no single correct answer to “how should we do IAM for agents” until the category of agent in question is defined.

The Four Islands

Mogull identifies four categories that differ substantially in their identity architecture and their relationship to enterprise security controls [1].

Personal desktop agents, exemplified by Anthropic’s computer use and OpenAI’s Operator, operate on individual devices and function as a proxy for the user whose credentials they inherit. The agent’s identity is effectively the user’s identity; it can do what the user can do, across every application the user can access, at machine speed and without interruption. The security concern is not that the agent assumes its own unexpected identity but that the user’s full credential footprint — shaped by years of permissions that were granted and never removed — becomes the agent’s operational surface by default.

Coding agents, including Claude Code and GitHub Copilot, represent a constrained variant of the personal desktop category but introduce a distinct attack surface. These tools are routinely connected to cloud infrastructure, CI/CD pipelines, and source repositories. The developer’s local credential set typically includes cloud access keys, deployment tokens, and API credentials that extend far beyond the text editor. Because coding agents operate at the boundary between individual workstations and organizational infrastructure, a compromise of the agent’s operating context — or deliberate manipulation of its behavior — can translate personal desktop-level access into infrastructure-level impact.

SaaS agents, such as Salesforce Agentforce and ServiceNow’s agentic automation products, operate within platforms that the SaaS vendor controls. The enterprise configures the agent’s permissions within that platform, but the identity architecture belongs to the vendor. This creates a visibility asymmetry: the enterprise often cannot directly inspect the token lifecycle, often cannot independently verify what the agent presents to integrated third-party systems, and often cannot apply enterprise-standard revocation policies to credentials that the vendor manages. When SaaS agents access linked external systems — a Salesforce agent pulling context from a connected Google Drive, or invoking a connected Slack workspace — the delegation chain extends beyond the SaaS platform’s boundary into systems where the enterprise’s control is even more attenuated.

Enterprise agents are internally deployed by the organization and represent the most architecturally flexible category. They present in two patterns: an on-behalf-of model, in which the agent acts in a specific user’s context with delegated identity, and an autonomous model, in which the agent operates independently with its own machine identity. The on-behalf-of pattern preserves human accountability but requires careful scoping to avoid granting agents the full breadth of the delegating user’s permissions. The autonomous pattern creates an agent principal that must be provisioned, governed, and eventually de-provisioned through purpose-built workflows that most organizations have not yet formalized.

Security Analysis

Why Human IAM Models Fail When Applied to Agents

The nearly 50% of organizations currently managing agent identity by extending human IAM models are not making an arbitrary error; they are making the most expedient choice available. Purpose-built agent identity tooling exists — dedicated non-human identity management platforms were commercially available before early 2026 — but this market remains immature and fragmented, and extending existing human IAM infrastructure is the lowest-friction path for most organizations [1]. The consequences of that choice, however, diverge quickly from the consequences of the same choice applied to human users.

Human IAM is built around the assumption of relatively stable, long-lived identity relationships. A user’s account is provisioned when they join the organization, adjusted incrementally over time, and de-provisioned when they leave. Permissions accumulate; they rarely contract. This accumulation is a well-documented risk for human accounts — CSA’s work on shadow access identifies the proliferation of excessive permissions as a primary source of unintended cloud access — but it is a manageable risk because human users are relatively few, their actions are observable, and their session patterns are predictable [5][6].

Agents violate every assumption that makes human IAM manageable. They are provisioned and de-provisioned dynamically across an execution’s duration, potentially thousands of times per day in active deployments. Non-human identities are reported to outnumber human identities by 144 to 1 in some enterprise environments [7]. At that ratio, the permission review, revocation, and monitoring workflows that organizations apply to human accounts are computationally impractical if applied at the same fidelity to agent identities. Agents also do not log out, do not submit to session-timeout enforcement in the human sense, and do not have an expectation of continuity that supports traditional session-based security models. When their credentials persist beyond task completion — which 51% of organizations report having no formal process to prevent [7] — they represent standing access for any subsequent task that inherits or reuses those credentials, with no human in the loop to notice the permission scope is broader than the new task requires.

Cross-Boundary Delegation and Transitive Trust

The most structurally intractable problem emerges when agents on different islands invoke each other. Mogull frames this as the core coordination challenge: delegation chains that cross island boundaries create identity propagation questions and transitive trust relationships that no current IAM architecture was designed to fully address. Existing approaches such as OAuth 2.0 Token Exchange (RFC 8693) and SPIFFE/SPIRE address portions of the cross-domain identity problem, but no widely adopted, production-ready standard covers the full recursive delegation semantics of multi-agent chains [1].

Consider a representative enterprise workflow: a user interacts with a personal desktop agent, which dispatches a task to an enterprise agent, which calls a SaaS agent to retrieve customer data, which in turn invokes a third-party integration service. Each hop in this chain involves a different administrative domain, a different identity context, and a different interpretation of what the delegated authorization means. The desktop agent presents the user’s credentials; the enterprise agent may issue a derived token scoped to the task; the SaaS agent’s authorization model is controlled by the vendor; the third-party service has no visibility into any upstream context at all. From the third-party’s perspective, it is receiving a request from the SaaS platform. From the user’s perspective, they authorized a desktop agent to complete a task. The gap between those two perspectives — neither party being wrong — is the cross-boundary authorization failure mode.

A critical follow-on observation from the March 11, 2026 CSA analysis of multi-system agent authorization is that “each domain validates credentials in isolation, leaving no shared defense when tokens are compromised” [2]. This isolation is not incidental. It reflects the fact that federated identity systems, which are the conventional mechanism for cross-domain trust, were designed for human users authenticating to specific services — not for agents autonomously chaining through sequences of services with dynamically constructed authorization contexts. When a token is compromised mid-chain, the downstream services that have already issued their own derived tokens based on that upstream credential have no mechanism to learn of the compromise and invalidate their own grants. The Salesloft Drift breach exemplifies this at scale: OAuth tokens issued to an AI agent were stolen in August 2025, and the absence of coordinated cross-system revocation allowed an adversary to access over 700 organizations’ environments before the tokens were individually tracked down and invalidated across each affected service [2][7]. (Primary vendor disclosure for this incident was not publicly available at time of writing; impact metrics are drawn from CSA reporting in [2][7].)

Standing Access and the Replit Incident

A related but distinct failure mode is the combination of standing access with agent velocity. AI agents operating on continuous, persistent credentials can execute large numbers of operations before a human operator has an opportunity to review or interrupt their behavior. The July 2025 Replit incident provides a concrete illustration: a Replit AI agent deleted 1,206 executive records from a live database in seconds while an active code freeze was in effect at the organization [3]. The agent was not compromised; it was operating within its granted permissions. Based on available reporting, the failure appears to have been architectural — the agent appears to have held standing access to a production database, that access was not contextually gated to the specific task in progress, and the velocity of execution suggests the damage was complete before any notification reached a human responder.

This pattern generalizes across agent categories and deployment environments. Where human users exercise implicit judgment about whether an action is appropriate for the current moment — checking whether a code freeze is in effect, confirming whether a record should be deleted, pausing when a command seems inconsistent with the stated objective — agents proceed through their permission set at machine speed. Standing access, designed for human users who self-limit their own exercise of permissions, becomes an autonomy multiplier when assigned to an agent that will exercise every available permission without hesitation. Broader survey data reinforces the Replit incident as representative rather than exceptional: 80% of organizations report experiencing unintended AI agent actions, and a 2025 IBM and Ponemon Institute study, as cited in [3], found that 97% of organizations lacked proper access controls for AI agents in production — figures that together indicate the access governance gap is systemic rather than isolated [3].

The Standards Gap and Its Risk Implications

The multi-agent IAM problem is compounded by the absence of mature, widely adopted standards that describe how agent identity should be expressed, delegated, and verified across systems. The NIST NCCoE’s February 2026 concept paper is an early-stage document seeking public input, not a finalized framework, and its comment period does not close until April 2, 2026 [4]. The candidate technologies the paper identifies — OAuth 2.0/2.1 extensions, OIDC, SPIFFE/SPIRE, SCIM, and the emerging Model Context Protocol — are promising but require significant additional work to specify agent-specific delegation semantics, cross-domain revocation coordination, and audit trail integrity requirements that differ from human identity use cases [4].

This standards gap creates a risk that organizations are independently inventing incompatible approaches to agent identity, with the consequence that cross-organizational and cross-platform agent interactions — which are already becoming commercially common — will produce systems where no single party has a complete view of the delegation chain, where revocation cannot be reliably propagated, and where audit trails fragment at administrative boundaries in ways that defeat forensic investigation after an incident. The Salesloft Drift breach is an early preview of what that fragmentation looks like at scale.

Recommendations

Immediate Actions

Organizations should begin by conducting an inventory of AI agents currently in production and assigning each to one of the four island categories. This exercise is not primarily taxonomic; it surfaces the critical question of which identity architecture each agent is actually operating under, as distinct from the identity architecture security teams may have assumed it uses. Many organizations will find that agents they believed to operate under enterprise IAM control are in fact operating under SaaS-vendor-managed identity models, or that coding agents are inheriting developer credentials that include infrastructure-scope access well beyond the development context.

For each agent category in scope, organizations should identify and eliminate standing access wherever tasks are well-defined enough to support just-in-time credential provisioning. An agent executing a specific, bounded task — generating a report, updating a record, summarizing a document — does not require persistent access to the system containing that data. Credentials scoped to the task’s duration and to the minimum permission required to complete it reduce the window in which compromised credentials are exploitable and eliminate the class of incident represented by the Replit database deletion. CSA commentary suggests ephemeral credential lifetimes of five to fifteen minutes for agent contexts as a practical starting point, compared with the day- or week-length token lifetimes typical of service account configurations [3]; organizations should treat this range as interim operational guidance pending formal standards from NIST or a CSA working group publication.

Short-Term Mitigations

Organizations deploying agents that cross island boundaries — particularly enterprise agents that invoke SaaS agents, or coding agents that interact with cloud infrastructure — should document explicit delegation contracts for each integration point. A delegation contract specifies: which identity the upstream agent presents to the downstream system, what permissions the downstream system should grant based on that identity, how the downstream system should behave if the upstream credential is revoked mid-execution, and which audit log receives the record of the interaction. These contracts do not require new tooling; they require the architectural decision and documentation that most organizations have not yet produced because the integration was treated as a technical detail rather than an identity governance decision.

Where SaaS agents are in scope, security and procurement teams should add agent identity transparency to vendor evaluation criteria. Organizations should be able to obtain from each SaaS vendor a description of the token lifecycle for their agent integrations, the mechanism by which enterprise-initiated revocation propagates to integrated third-party systems, and the audit log format for cross-platform agent actions. Vendors who cannot provide clear answers about these capabilities leave enterprises unable to independently verify their audit, revocation, and attribution posture — and should be treated as presenting unverified risk until those capabilities are documented.

Strategic Considerations

The NIST NCCoE concept paper’s public comment period, open through April 2, 2026, represents an opportunity for organizations with production multi-agent deployments to contribute operational experience to a standards process that will shape the technical infrastructure of agent identity for years [4]. Organizations encountering cross-boundary delegation failures, token revocation gaps, or audit fragmentation in their current deployments should consider preparing submissions that document these failure modes concretely. Standards that emerge from real operational experience with production-scale deployments are more likely to address the problems organizations actually face than standards derived primarily from theoretical analysis.

At the architectural level, organizations should plan for agent identity to be a first-class component of their Zero Trust strategies rather than an extension of existing human IAM. CSA’s Agentic AI Identity and Access Management framework, published in August 2025, outlines the foundational technologies — Decentralized Identifiers (DIDs), Verifiable Credentials (VCs), and context-aware access controls — that support persistent, verifiable agent identity across system boundaries without relying on the shared administrative domain assumptions that underpin traditional federated identity [8]. Incorporating these primitives into identity architecture planning now, even before they are fully standardized, positions organizations to integrate with standards when they mature rather than requiring a retrofit from an incompatible base.

CSA Resource Alignment

This research note addresses challenge areas that map directly to several current CSA frameworks and working group outputs.

MAESTRO (Multi-Agent Environment Security Threat and Risk Observatory): The MAESTRO framework’s threat modeling methodology applies directly to the cross-boundary delegation chains described here. Organizations constructing threat models for multi-agent deployments should use MAESTRO’s layer model to identify which layers a given delegation chain traverses and which control points exist at each boundary.

CSA Agentic AI Identity and Access Management (August 2025): This publication provides the most directly applicable architectural guidance, offering a purpose-built framework for agent identity that accounts for ephemerality, delegation, and autonomy. The DID and Verifiable Credential primitives it describes are the current best-available technical approach to portable, verifiable agent identity across administrative boundaries [8].

Defining Shadow Access / Confronting Shadow Access Risks (2023–2024): The shadow access concept — unintended access arising from accumulated permissions, automation without governance, and cloud IAM complexity — applies to agent identities in a structurally identical way to its application to human and service account identities. The remediation principles from these publications (least privilege, continuous monitoring, access governance for non-human identities) translate directly to agent contexts [5][6].

Cloud Controls Matrix (CCM): IAM-relevant domains, including Identity and Access Management (IAM), Audit and Assurance (AAC), and Governance and Risk Management (GRM) control families, provide a structured basis for auditing agent identity posture against documented control expectations. CCM IAM-02 (Least Privilege) and IAM-09 (Non-human Entity Authentication) are particularly applicable.

Zero Trust Advancement Center (ZTAC): Zero Trust’s foundational principle of continuous verification applies directly to the agent velocity problem. Because agents operate at speeds that preclude human-gated authorization decisions, the relevant Zero Trust architecture for agentic AI is one in which every operation is checked against current policy at execution time — not at token issuance time — and where revocation propagates to enforcement points at machine speed rather than through human-driven de-provisioning workflows.

References

1. Rich Mogull (CSA), “Islands of Agents: Why One IAM to Rule Them All Doesn’t Work,” Cloud Security Alliance Blog, March 10, 2026. https://cloudsecurityalliance.org/blog/2026/03/10/islands-of-agents-why-one-iam-to-rule-them-all-doesn-t-work

2. Cloud Security Alliance, “AI Security: When Your Agent Crosses Multiple Independent Systems, Who Vouches for It?” Cloud Security Alliance Blog, March 11, 2026. https://cloudsecurityalliance.org/blog/2026/03/11/ai-security-when-your-agent-crosses-multiple-independent-systems-who-vouches-for-it

3. Cloud Security Alliance, “AI Security: IAM Delivered at Agent Velocity,” Cloud Security Alliance Blog, February 17, 2026. https://cloudsecurityalliance.org/blog/2026/02/17/ai-security-iam-delivered-at-agent-velocity

4. NIST National Cybersecurity Center of Excellence, “Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization” (Concept Paper), February 5, 2026. https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd

5. CSA Identity and Access Management Working Group, “Defining Shadow Access: The Emerging IAM Security Challenge,” Cloud Security Alliance, 2023. https://cloudsecurityalliance.org/artifacts/defining-shadow-access-the-emerging-iam-security-challenge

6. Venkat Raghavan, Steven Schoenfeld, Heinrich Smit et al., “Confronting Shadow Access Risks: Considerations for Zero Trust and Artificial Intelligence Deployments,” Cloud Security Alliance, 2024. https://cloudsecurityalliance.org/artifacts/confronting-shadow-access-risks-considerations-for-zero-trust-and-artificial-intelligence-deployments

7. Cloud Security Alliance, “AI Security: When Authorization Outlives Intent,” Cloud Security Alliance Blog, February 25, 2026. https://cloudsecurityalliance.org/blog/2026/02/25/ai-security-when-authorization-outlives-intent

8. Cloud Security Alliance AI Safety Initiative, “Agentic AI Identity and Access Management: A New Approach,” Cloud Security Alliance, August 2025. https://cloudsecurityalliance.org/artifacts/agentic-ai-identity-and-access-management-a-new-approach