Islands of Agents: Why One IAM to Rule Them All Doesn't Work

This week I was at the [un]prompted AI security conference, put on by CSA’s very own Gadi Evron. It was an amazing event with stellar presentations and awesome networking. It was also a bit weird to be at a conference, wondering if everything we were learning and discussing would be out of date in 6 months.

On the second day of the show I participated in a Birds of a Feather session on agentic IAM. The attendees picked the topic pretty overwhelmingly, and it’s probably the top topic in my discussions with other AI security experts (and CSA members). Sitting there, listening to the discussion, it really hit how large a problem agentic identity is on both a technological and an organizational level. It’s something I’ve been thinking of a lot, and I’ve been burning cycles trying to break the problem down into manageable chunks.

I could see some people getting hung up on the broad spectrum of agent use, and the wide range of identity implications. I raised my hand to share my thoughts on how I think we can use categorization to understand how different agent types will need different IAM technologies and processes. Each type of agent has fundamentally different relationships with users, different levels of autonomy, and different identity architectures.

Once you see that, the problem becomes a series of more-manageable problems instead of one impossible one.

 

Not All Agents Are Created Equal

We keep using the word “agent” like it means one thing, but in practice there are distinct categories that create what I’m starting to call islands of identity — clusters of IAM patterns that share more in common with each other than they do with the other clusters. Here’s how I break them out:

Personal desktop agents are the tools that live on your device and act as you. Think Anthropic’s computer use, OpenAI’s Operator, Google’s Project Mariner, and even scary open source tools like OpenClaw. These agents generally operate with your credentials, on your machine, in your context. They can see your screen, click your buttons, and access whatever you can access. From an identity perspective, the agent essentially is you — it inherits your permissions, your sessions, your access tokens. The IAM pattern here is user delegation at the most fundamental level: the agent acts on behalf of a specific human, with that human’s full (or nearly full) set of permissions (unless you add in constraints, which you should definitely be doing).

Coding agents are a constrained subcategory of personal desktop agents. Tools like Claude Code, Cursor, and GitHub Copilot’s agent mode operate in your development environment with access to your filesystem, your git credentials, your CLI tools. The identity model is similar to personal desktop agents — the agent acts as you, but the scope is narrower and more technically specific. The interesting IAM wrinkle here is that coding agents often need access to cloud infrastructure, CI/CD pipelines, and production systems through the developer’s credentials, which means a compromised coding agent has a blast radius that extends well beyond the laptop.

SaaS agents are a fundamentally different animal. These are agents that live inside a SaaS platform — Salesforce’s Agentforce, ServiceNow’s AI agents, Microsoft’s Copilot agents. The critical difference: the SaaS provider controls the identity architecture. The agent might work on behalf of a user within that platform, or it might operate autonomously on tasks. Either way, the enterprise has limited visibility into and control over the agent’s identity model. You’re trusting the SaaS provider’s implementation of permissions, scoping, and audit logging.

Here’s where it gets particularly thorny: SaaS agents increasingly reach across platform boundaries. A Salesforce agent that can pull context from your connected Slack workspace, or query data from a linked Google Drive, creates cross-platform delegation chains that nobody’s IAM architecture was designed for. The identity question stops being “what can this agent do in Salesforce” and becomes “what can this agent do across every system Salesforce is connected to.” That’s a materially different problem, and we’ve already seen cross-cloud permission issues used in real breaches. Abusing these grants (usually with OAuth) is  increasingly an attack technique used by adversaries.

Enterprise agents are agents that an organization builds and deploys within its own infrastructure — in its cloud accounts, data centers, and application stacks. This is the category that spans the widest range of identity patterns, and it’s where I see two important variants:

• The first is the on-behalf-of (OBO) pattern: An enterprise agent that acts in the context of a specific user. Think of a custom agent that helps an analyst run security queries, where the results are scoped to what that analyst is authorized to see. The agent needs delegated identity, audit trails that trace back to the human, and permissions that don’t exceed the user’s own access.
• The second is the autonomous pattern: Agents that aren’t tied to any particular user. A pipeline agent that continuously monitors for threats, an automated remediation agent that responds to alerts, a data processing agent that runs batch jobs. These need their own identity — something more than a service account, because they’re making decisions, not just executing scripts. They need lifecycle management, credential rotation, scope constraints, and attributable audit logging, just like any other principal in your environment. The recent CSA survey on securing autonomous agents found that only 18% of organizations are highly confident their current IAM can handle these agent identities, and nearly half are just extending human IAM models to agents,.

 

Islands, Not Continents

Each of these different agents has its own operational nuance, and they run in different technology environments. Each agent type has a different answer to the core IAM questions:

Who is the principal? For personal desktop agents, it’s the user — the agent is a proxy. For SaaS agents, it might be the user or it might be the platform, and the enterprise often can’t tell the difference. For autonomous enterprise agents, the agent itself is the principal (sometimes), often without a human in the loop.

Who controls the identity architecture? For personal desktop agents, it’s mostly the user (and their device management). For SaaS agents, it’s the SaaS provider — you get whatever IAM model they give you. For enterprise agents, it’s your security team, which is both an advantage and a responsibility. (And yes, these agents can also change across environments and potentially require transitive trust across systems).

What’s the appropriate scope? Personal desktop agents might legitimately need broad access (they’re acting as the user, after all). Coding agents need deep but narrow access. SaaS agents should be scoped to their platform but often aren’t. Enterprise agents need fine-grained, task-specific permissions that traditional role-based models struggle to express.

What does “human in the loop” mean? For a personal desktop agent, the human is hopefully right there (or getting notifications) to approve actions (unless they use that pesky “YOLO” mode). For a SaaS agent working autonomously in the background, there might not be a human involved, and heck, the human who originally configured it may not even work there anymore. For an autonomous enterprise agent running in a pipeline at 3 AM, “human in the loop” is really “human maybe on the loop later but probably not until something breaks.”

The underlying technology stacks are different too. Personal desktop agents interact through UI automation, CLI, and local credentials. SaaS agents use the platform’s internal APIs and OAuth scopes. Enterprise agents use cloud IAM, service identities, and potentially new standards like the IETF’s OAuth extension for agent on-behalf-of flows or Microsoft’s Entra Agent ID. There’s 0 chance of making any one of these work everywhere, and we probably can’t even have a single authoritative directory (with current tech).

 

Don’t Forget Agent-to-Agent

I’d be remiss if I didn’t mention that all of these islands exist in a world where agents increasingly talk to other agents. A personal desktop agent might invoke a SaaS agent, which triggers an enterprise agent, which delegates to another enterprise agent. These delegation chains cross island boundaries and create identity propagation challenges and transitive trust relationships that are genuinely hard.

It’s a tough problem, but it’s manageable if we think in terms of bridges between the islands. And, really, it’s not much different than any other federated identity problem once we get that core “identity” hook that defines the agent itself.

I had a sidebar with someone about this and plan to write a lot more on it. Essentially when bridging from A to B we should be able to constrain to the least privilege based on the federated trust relationship. We actually mostly have the protocols and tech we need for this, it just isn’t always widely used or understood. Super messy now, but I do think it will get better over time.

 

Hard, but Manageable

We already have federated identity standards. We already have some robust IAM in the various islands, emerging agentic frameworks, and new standards on the way (well, https://xkcd.com/927/). Many of us can’t really wait for everything to settle down so we have to work with what we have.

Thus my short, overly-trite advice is to think in terms of these islands and solve the problems within each island using existing technologies. Don’t zoom out too far and get vertigo from trying to solve everything. It will get better, but it’s going to take a while, and odds are we’ll pivot technologies a few times due to the insane rate of innovation. But hey, that's what makes this security profession fun!

*Note: the author has strange definitions of “fun.”