When an AI agent changes a record, the audit log should name the agent.
Many early agents ran on a developer's API key or a shared service account. Nobody could separate what the agent did from what its owner did. We give each agent its own identity in Okta or Microsoft Entra, with a sponsor, a scope and an off switch. MCP servers go behind proper OAuth, and agents join access reviews.
Agent governanceSailPoint · Entra access packagesAudit logwhich agent · for whom · which token
OktaMicrosoft Entra IDSailPointAnthropic Claude
in short·15-second read
AI agent identity gives each agent its own account, credentials and permissions instead of a borrowed user login or shared key.
Cohash registers agents with Okta Agent SSO and Cross App Access or Microsoft Entra Agent ID, secures MCP servers to the MCP authorization specification, separates on-behalf-of access from autonomous access, and governs agents in SailPoint or Entra ID Governance with sponsors, reviews and deactivation.
you probably need this if
Agents run on a developer's personal API key or a shared service account.
The audit log can't tell what an agent did from what its owner did.
Teams have stood up remote MCP servers with no authorization in front of them.
terms on this pageService accountdefinitionA non-human account that software signs in with. Shared ones tend to pick up years of extra permissions.explained in a field note →
From the first call to a setup your own team can run.
Here's what usually prompts a call about your AI Agent Identity, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · ai agent identity3 open
openAgents run on a developer's personal API key or a shared service account.
recurringThe audit log can't tell what an agent did from what its owner did.
blockedTeams have stood up remote MCP servers with no authorization in front of them.
exposure
Okta Agent SSO and Cross App…Microsoft Entra Agent IDMCP server authorizationOn-behalf-of versus autonomous…Agent governanceKill switch and audit trail
startrehearsehandover
Inventory agents
Choose the identity pattern
Build and enforce
Govern
we are here
ready to hand over
No agent depends on a stored secret now.
Each CRM call now traces to one agent and one user.
Agent inventory with current credentials and target pattern
Agent identity architecture for Okta, Entra or both
chapter 01 · where it hurts
Why teams reach out
Agents run on a developer's personal API key or a shared service account.
The audit log can't tell what an agent did from what its owner did.
Teams have stood up remote MCP servers with no authorization in front of them.
chapter 02 · what we change
How we solve it
Okta Agent SSO and Cross App Access
Microsoft Entra Agent ID
MCP server authorization
On-behalf-of versus autonomous access
Agent governance
Kill switch and audit trail
chapter 03 · how it runs
Our approach
Inventory agents
Choose the identity pattern
Build and enforce
Govern
chapter 04 · where you end up
What changes
No agent depends on a stored secret now.
Each CRM call now traces to one agent and one user.
Agent inventory with current credentials and target pattern
Agent identity architecture for Okta, Entra or both
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
Okta made Agent SSO generally available on 24 August 2026, as part of its core SSO plans. With it, agents that support Cross App Access stop relying on stored user credentials. They get short-lived, admin-governed tokens for enterprise apps and MCP servers instead. We configure the apps, policies and agent registrations.
Agent identity blueprints, agent identities that authenticate only through federated credentials issued by the blueprint, and Conditional Access templates for autonomous and on-behalf-of agents. We also move agents built on ordinary app registrations or Copilot Studio onto Agent ID.
We build or wrap remote MCP servers to the 2026-07-28 authorization spec. That means OAuth 2.1 and Protected Resource Metadata, plus resource indicators that bind each token to one server. Client tokens are never passed through to downstream APIs.
A clear rule for when an agent acts with a user's delegated rights and when it uses its own, with scopes and approvals sized for each case.
We govern agents and their entitlements in SailPoint Identity Security Cloud with Agentic Fabric, or with Entra access packages and sponsor lifecycle workflows. So access is reviewed, and a new sponsor is named when the old one leaves.
A single, tested way to switch an agent off everywhere, plus logs showing which agent acted, on whose behalf, and with what token.
capability 01 / 06in production
Okta Agent SSO and Cross App Access
Okta made Agent SSO generally available on 24 August 2026, as part of its core SSO plans. With it, agents that support Cross App Access stop relying on stored user credentials. They get short-lived, admin-governed tokens for enterprise apps and MCP servers instead. We configure the apps, policies and agent registrations.
Agent identity blueprints, agent identities that authenticate only through federated credentials issued by the blueprint, and Conditional Access templates for autonomous and on-behalf-of agents. We also move agents built on ordinary app registrations or Copilot Studio onto Agent ID.
We build or wrap remote MCP servers to the 2026-07-28 authorization spec. That means OAuth 2.1 and Protected Resource Metadata, plus resource indicators that bind each token to one server. Client tokens are never passed through to downstream APIs.
We govern agents and their entitlements in SailPoint Identity Security Cloud with Agentic Fabric, or with Entra access packages and sponsor lifecycle workflows. So access is reviewed, and a new sponsor is named when the old one leaves.
We pieced these together from AI Agent Identity situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Copilot Studio agents on app registrations with client secrets
composite · not a client story
Beforethe situation
A dozen Copilot Studio and custom agents authenticate as ordinary Entra app registrations using client secrets. Several have Graph application permissions like Sites.Read.All, granted to get a pilot working and never looked at again.
What we dothe work
Start with each agent's granted permissions and compare them with what the audit logs say it really touched. Move the agents to Agent ID, using blueprint-issued federated credentials. Replace tenant-wide application permissions with delegated or narrowly scoped grants, then apply the agent Conditional Access templates.
Afterwhere you end up
No agent depends on a stored secret now. Each runs as its own identity with permissions that fit the job, and its access review goes to a named sponsor.
case file 02
Remote MCP server in front of the CRM on one shared API key
composite · not a client story
Beforethe situation
One internal team put CRM search and update tools behind a remote MCP server over HTTP. All clients share one API key, and the server hands it straight through to the CRM API.
What we dothe work
We put the server behind an authorization server that issues audience-bound tokens per the MCP authorization spec, and the server publishes Protected Resource Metadata. It gets its own downstream token instead of forwarding the client's. Every tool call logs both the agent and the user.
Afterwhere you end up
Each CRM call now traces to one agent and one user. A token taken from this server won't work anywhere else. And cutting off one bad agent doesn't mean rotating a key that every other client needs.
How an AI agent gets its own identity and scoped access
The agent signs in as its own identity, acting for a user only when that user delegates access. The identity platform issues short-lived tokens bound to one MCP server or app, and governance and audit logs track what the agent did and for whom.
01 · Agents and users
AI agentClaude · OpenAI · Copilot Studio → Agent identity platform · agent sign-in
We don't start a step until the last one has produced something you can check.
step 01
Inventory agents
We list agents in Copilot Studio, Amazon Bedrock, custom code and SaaS platforms, and the credentials each one uses today.
step 02
Choose the identity pattern
Platform-native agent identity, Cross App Access or workload federation, decided per agent and per target system.
step 03
Build and enforce
We put the registrations, scopes, policies and MCP authorization in place. Only then do the old shared keys get revoked.
step 04
Govern
Assign sponsors and schedule reviews. Then test deactivation across every connected app before go-live.
you keep
What you're left with
We write these for your AI Agent Identity setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
inventory01
Agent inventory with current credentials and target pattern
yours to keep
design02
Agent identity architecture for Okta, Entra or both
yours to keep
design03
MCP authorization design and server checklist
yours to keep
design04
Scope and consent model for delegated and autonomous agents
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
00:0006:0012:0018:0000:00
roles we staff
Identity architect for AI agents
OAuth and OIDC engineer
Okta or Entra ID engineer for agent identities
AI engineer (MCP, tool use)
IGA engineer
due diligence · ai agent identity
Questions to ask any partner, including us.
Put these to anyone bidding on your AI Agent Identity work. The ones who've done it answer differently from the ones who've read about it.
Q1
For each agent, will it act on a user's behalf or with its own rights?
Delegated access inherits the user's permissions and consent. Autonomous access needs its own narrow scopes and approvals. Put both in one credential and the audit trail stops meaning anything.
Q2
How will our MCP servers make sure a token only works at one server?
The MCP authorization spec uses resource indicators so a token issued for one server can't be used at another. A server that accepts any token from your IdP is open to replay.
Q3
What is the tested procedure to disable one agent across every app it touches?
Disabling an identity in one IdP can leave tokens, API keys or SaaS-side grants working. The kill switch should be rehearsed, with a written list of what it covers and what it misses.
Q4
If we run both Okta and Entra, which platform owns each agent's identity?
Split an agent's record across two platforms and you'll review it twice and still miss things. Give each agent one owning platform.
Q5
How will agents appear in access reviews, and who reviews them?
Agents pile up scopes over time, the same way service accounts do. A named sponsor, a review cycle and a proper handover when people leave keep that under control.
01Does Okta Agent SSO cost extra?
Okta says Agent SSO is included in its core SSO plans at no additional cost. Okta for AI Agents is a separate subscription that adds shadow-agent discovery, connections to custom authorization servers, service accounts and secrets, and agent governance. Which you need depends on whether your agents support Cross App Access.
02We built agents on regular Entra app registrations. Do we have to rebuild them?
Not from scratch. Microsoft publishes guidance for migrating custom app registrations and Copilot Studio agents to Agent ID. Most of the work is moving credentials to blueprint-issued federated credentials, re-granting permissions and testing Conditional Access.
03Do local MCP servers need OAuth?
No. The MCP specification makes authorization optional, and says servers on the STDIO transport should take credentials from the environment. Remote MCP servers over HTTP are another matter. If one of those can reach company data, it should implement the authorization spec.
04Should our MCP clients still use Dynamic Client Registration?
The 2026-07-28 spec deprecates it in favor of OAuth Client ID Metadata Documents and keeps it for backward compatibility. For new servers we'd support metadata documents and keep dynamic registration only where existing clients depend on it.
05We run both Okta and Entra. Which should own agent identity?
Usually the platform closest to where the agent runs and what it touches. Copilot Studio agents fit Entra Agent ID naturally. Agents that mostly reach SaaS apps federated through Okta fit Agent SSO. We record one owning platform per agent so reviews don't happen twice.
related
Often paired with
Projects on AI Agent Identity usually end up touching one of these, so they're worth a look.
