AI agents are everywhere now. They’re answering customer questions, filing support tickets, updating databases, and even writing code. But when an AI agent performs an action in your system, whose identity is it really using?
It turns out there’s no simple answer. As organizations rush to deploy AI agents, they’re discovering that agent identity is far more complex than anticipated. Today, we’re pulling back the curtain on three different approaches to AI agent identity – and why this matters for your enterprise.
1. Autonomous Identity: When Agents Stand on Their Own
Let’s start with Salesforce’s Agentforc – a prime example of autonomous agent identity. Here, each AI agent has its own built-in identity, complete with its own user record in the system.
Notice something interesting? The AI agents appear right alongside human users, with their own usernames.
When an Agentforce agent creates a case or updates a record, it’s not borrowing someone else’s credentials – it’s acting as itself. Take a look at this case creation:
The case clearly shows “EinsteinAgent Customer Support” as the creator – not a human user, not a service account, but the agent itself.
This autonomous approach creates fascinating implications. The agent has its own audit trail, its own permissions, and its own presence in the system. It’s essentially a digital employee with its own badge.
But here’s where it gets interesting: even Agentforce doesn’t stick to pure autonomous identity. When agents use Apex actions (Salesforce’s proprietary programming language for custom business logic), for instance, they can embed credentials and act on behalf of other entities. So even in the “autonomous” model, identity can get murky.
2. Delegated Identity: Borrowing Authority Through MCP
The Model Context Protocol (MCP) takes a different philosophical approach. Instead of giving agents their own identities, MCP assumes agents will borrow authority from other – typically the human user invoking them.
The MCP specification supports the following OAuth grant types:
- Authorization Code: When the agent acts on behalf of a human end user (think: an agent calling a SaaS tool for you)
- Client Credentials: When the agent is another application (think: checking inventory without impersonating anyone)
But here’s the kicker – when you look at the official Python SDK implementation, it only supports the authorization code flow. In practice, this means MCP agents are designed to delegate, to borrow, to act on behalf of someone else.
# From the MCP Python SDK
grant_types: list[Literal["authorization_code", "refresh_token"]] = [
"authorization_code",
"refresh_token",
]This delegation model makes sense for many use cases. When an AI helps you book a meeting, you probably want it using your calendar permissions, not its own. But it also means the agent has no persistent identity of its ow – it’s a ghost that only materializes when channeling someone else’s authority.
3. Hybrid Identity: The Copilot Studio Approach
Microsoft’s Copilot Studio introduces yet another mode – one that blurs the lines between autonomous and delegated identity.
When you create an agent in Copilot Studio, it gets provisioned as an enterprise application in Entra ID (formerly Azure AD). This gives each agent a distinct identity footprint in your director – not quite a full user object like Salesforce’s approach, but a legitimate security principal nonetheless.
Yet despite having this autonomous foundation, Copilot Studio agents exhibit chameleon-like behavior when executing actions. Depending on the connector configuration and security context, using OAuth capabilities, the same agent can leverage:
- The invoking user’s delegated permissions
- The agent author’s credentials
- Its own application identity
This creates a shapeshifting scenario where the same agent might use different identities for different actions within the same conversation. One moment it’s sending an email with the user’s delegated permissions, the next it’s accessing SharePoint using the agent author’s credentials, and then it’s querying an Azure Databricks warehouse using its own service principal identity.
The Identity Challenge Unfolding Before Us
Here’s what makes this all so complicated: there’s no industry standard, no common framework, no agreed-upon best practice. Each platform has invented its own approach based on its own assumptions about how AI agents should work.
For security teams, this creates a perfect storm of complexity:
- Audit trails become puzzles: When something goes wrong, was it the agent, the user, or the agent acting as the user?
- Permission models break down: Traditional role-based access control wasn’t designed for entities that can assume multiple identities
- Security boundaries blur: How do you ensure least-privilege when an agent’s privileges depend on whose identity it’s borrowing?
And this is just the beginning. As agents become more sophisticated and start invoking other agents, we’re heading toward nested identity delegation that would make even seasoned security architects reach for the aspirin.
The Path Forward
The current landscape of agentic identity reveals a fundamental gap in our security infrastructure. Major platforms like Salesforce and Microsoft have taken vastly different approaches, while emerging protocols like MCP introduce yet another paradigm. Every vendor is making it up as they go along, leaving enterprises to figure out how to secure this fragmented landscape.
This fragmentation creates real operational challenges. As AI agents move from proof-of-concept to production, organizations are discovering that their existing identity and access management systems weren’t designed for entities that can shift between multiple identities within a single workflow.
What enterprises need now:
- A way to map agent identities across platforms
- Clear visibility into which identity an agent uses when
- Consistent policies that work regardless of the underlying identity model
But it does require rethinking how we approach identity in an agentic work – not just extending existing models (whether human-centric or service account patterns) to agents.
At Cyata, we’ve made it our mission to bring order to this chaos. While the full picture is coming together for an upcoming announcement, we’re building the infrastructure to help enterprises manage their AI agents like the critical identity infrastructure they’ve become.
Because whether your agents are autonomous, delegated, or hybrid, one thing is certain: the identity challenges aren’t going away. In fact, they’re about to get a whole lot worse.
Follow Cyata as we tackle them.
The Control Plane for Agentic Identity
