Skip to main content
Private Beta — Contact us to get set up.
Autonomous execution raises a question: whose identity does the agent use? The identity determines what the agent can access—both browser-based applications (via token injection) and remote MCP servers (via ID-JAG token exchange). Three models are supported.

​
User-scoped execution

The agent acts as a specific user. Their identity, their permissions, their audit trail—just without them present. This is session inheritance extended to unattended execution. The agent can only do what the user could do—in browser applications and in remote MCP servers. Audit logs show the user as the actor. When to use it:
  • Tasks the user would do themselves, just automated
  • Accessing resources the user already has permission for
  • When accountability should trace back to a specific person
The tradeoff: The user’s permissions must cover everything the agent needs—both browser access and MCP server access. If the agent needs access the user doesn’t have, you either grant the user broader permissions (security risk) or the task fails.

​
Agent identity

The agent has its own identity in your IDP—a service principal, workload identity, or machine account registered specifically for this agent. The agent authenticates as itself, not as a user. It has its own permissions for browser applications, its own role assignments for MCP servers, its own audit trail. When it acts, the logs show the agent as the actor. When to use it:
  • Agents that need permissions no single user should have
  • Cross-functional workflows spanning multiple users’ domains
  • When the agent’s decisions are its own, not a user’s automation
  • Compliance scenarios requiring clear human/agent separation
The tradeoff: You need to provision and manage agent identities in your IDP. The agent needs its own role assignments for both browser apps and MCP servers. This is more infrastructure, but cleaner accountability.

​
Hybrid: Agent acting on behalf of user

There’s a middle ground. The agent has its own identity, but the token also preserves who authorized it. This uses the act (actor) claim pattern from RFC 8693 Token Exchange: 
{
  "sub": "user-123",           // Who the data belongs to
  "act": {
    "sub": "agent-456"         // Who decided to act
  }
}
The sub is the user—their permissions apply (for both browser apps and MCP servers). The act is the agent—visible in audit logs. This separates “whose authority is being used” from “who made the decision to use it.” When to use it:
  • When you need user-scoped permissions but agent-attributed actions
  • Compliance scenarios that require distinguishing human actions from agent actions
  • Multi-agent workflows where you need to track which agent did what
This is what Microsoft Entra’s Agent ID OBO flow implements, and what standards-based token exchange enables.

​
Choosing between them

ConsiderationUser-scopedHybrid (OBO)Agent identity
PermissionsUser’s accessUser’s accessAgent’s own roles
Audit trail”User did X""Agent did X (as user)""Agent did X”
AccountabilityUserUser authorized, agent actedAgent (and sponsor)
IDP setupToken exchangeToken exchange + agent registrationAgent registration
Best forSimple automationAttributed automationAutonomous decisions
Many organizations start with user-scoped execution for simple automation, move to hybrid OBO when they need attribution, then to full agent identities as agents become truly autonomous.

​
Further reading