Identity, scopes and audit for AI agents and MCP servers
We secure AI agents and the MCP servers they call. In practice that means each agent gets its own identity in Microsoft Entra Agent ID or Okta, and remote MCP servers sit behind OAuth to the 2026-07-28 authorization spec with per-tool scopes. Delegated actions pass the user's identity through. Risky writes need a person's approval, and every tool call goes to your SIEM. Once the new path works, we revoke the shared keys.
- 01Agent and server inventory
- 02Agent identities
- 03MCP authorization
- 04Scopes, approvals and negative tests
- 05Audit and governance
The story
Told without the client's name or anything that could identify them.
A software company's platform team had agents calling remote MCP servers over HTTP with nothing in front of them, and several agents shared one service account, so the backend couldn't tell them apart. One server also forwarded the client's token straight to a downstream API. When the MCP authorization spec was revised on 28 July 2026, they asked us to fix the access model before more agents shipped. We started with an inventory of agents, servers, tools and credentials, then gave each agent its own identity and put the servers behind OAuth with per-tool scopes. The shared keys were revoked once the new path worked, and every tool call now lands in the SIEM.
why it was urgentThe 28 July 2026 revision of the MCP spec tightened authorization around OAuth 2.1, protected resource metadata and audience-bound tokens. The identity vendors have moved as well. Okta's Agent SSO went generally available on 24 August 2026, and Entra Agent ID is generally available. If any of your agent setup relies on Entra auto-granting AgentIdentity.CreateAsManager, that stops on 4 November 2026.
- openTeams run remote MCP servers over HTTP with no authorization in front of them.
- recurringSeveral agents share one service account, so the backend can't tell them apart.
- blockedAn MCP server passes the client's token straight through to a downstream API.
- openNobody can list which agents exist, who owns them or what they can change.
The estate, before and after
Before: agents on a shared key and open MCP servers
Agents called business APIs with one shared service account key, so the backend couldn't tell one call from another. Remote MCP servers took HTTP requests with no authorization at all, and handed the client's token straight on to downstream APIs.
Read the diagram as text
- Claude-based agents → Shared API key: static key
- OpenAI-based agents → Shared API key: static key
- Claude-based agents → Remote MCP servers: unauthenticated call
- OpenAI-based agents → Remote MCP servers: unauthenticated call
- Shared API key → Business APIs: same identity
- Remote MCP servers → Business APIs: client token passed on
- Business APIs → App logs: no agent or user
After: agent identities, OAuth-protected MCP servers and audit
An agent's identity lives in Entra Agent ID or Okta, and that's where it gets a token for a single MCP server. The server checks scopes tool by tool, hands risky writes to a person, uses its own downstream token, and writes each call to the SIEM.
Read the diagram as text
- Claude-based agents → Entra Agent ID: agent identity
- OpenAI-based agents → Okta Agent SSO: agent SSO
- Entra Agent ID → Remote MCP servers: audience-bound token
- Okta Agent SSO → Remote MCP servers: audience-bound token
- Remote MCP servers → Human approval: risky write
- Remote MCP servers → Business APIs: separate downstream token
- Human approval → Business APIs: approved write
- Remote MCP servers → SIEM: tool-call log
- Entra Agent ID → Access reviews: agent inventory
How we run it, phase by phase.
5 phases take you from Agents on shared API keys and open MCP servers to Agent identities, OAuth-protected MCP servers and audit. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Agent and server inventory
We write down the agents, MCP servers, tools, credentials and the systems behind them. Each tool gets two tags, read or write, and user-delegated or autonomous.
- phase 02
Agent identities
Register every agent in Entra Agent ID or Okta, with a sponsor, a purpose and an expiry. On-behalf-of access and autonomous access get separate permissions.
- phase 03
MCP authorization
Put remote servers behind your authorization server with protected resource metadata and resource indicators, so a token works for one server only. Downstream calls use a separate token, never the client's.
- phase 04
Scopes, approvals and negative tests
Define scopes per tool, route destructive or high-value actions to a human approver, and write tests for calls that must fail. Over-broad scope only shows up in those tests.
- phase 05
Audit and governance
Send every tool call to the SIEM with the agent, user, tool and target. Then treat agents like accounts. They go into access reviews, and they get switched off when the sponsor leaves or the job is done.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Every agent has its own identity, sponsor and expiry
Every agent now sits in Entra Agent ID or Okta with a named sponsor, a written purpose and an end date. What it does for a user and what it does on its own run on separate access.
- result 02
Remote MCP servers accept only tokens issued for them
Each server publishes protected resource metadata and checks the token audience, so a token meant for one server is refused by the next. Downstream calls get their own token. We tested passthrough and it's rejected.
- result 03
Destructive or high-value writes wait for a person
A person approves risky tool calls. Before any change ships, a negative test suite tries calls outside each agent's scopes and proves they're refused.
- result 04
Each tool call can be traced to an agent and a user
The SIEM holds agent, user, tool and target for every call. Agents sit in the same access reviews as everyone else and get deactivated when their sponsor leaves or their purpose runs out.
Risks we plan for
-
Token passthrough
If an MCP server forwards the client's token to a downstream API, audience checks stop meaning anything and one server can act as another. The spec forbids this. We test for it anyway.
-
Excessive agency
Give an agent write scope on everything and sooner or later it will write somewhere it shouldn't. OWASP lists excessive agency among the top LLM risks. We scope writes narrowly and put a gate in front of them.
-
Prompt injection reaching tools
Any page or document an agent reads can carry instructions to call tools, and you won't filter all of them out. So plan for the injection that gets through. Least-privilege scopes and approval steps decide how much it can actually do.
-
Version mismatch
Mismatched MCP spec versions between client and server often fail in ways that look like network errors. So our transition plans record the version on both sides.
Where AI helps, and where it needs guardrails
Entra Agent ID adds blueprints, sponsors and Conditional Access for agents. Okta Agent SSO swaps stored user credentials for short-lived tokens. Auth0's Auth for MCP covers customer-facing servers. We use these where you already license them. The governance rule is simple. An agent never holds more access than the person or process it acts for, and every tool call can be traced back to both.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Agent and MCP server inventory with owners, tools and credentials
yours to keep - design02
Agent identity design with sponsors, scopes and expiry
yours to keep - code03
MCP authorization checklist and server template
yours to keep - tests04
Negative test suite for calls that must be refused
yours to keep - report05
Tool-call audit logging to the SIEM with a review routine
yours to keep
Platforms and services on this move
Certified engineers, wherever you need them.
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
01Do local MCP servers need OAuth?
No. The spec makes authorization optional and says STDIO servers should take credentials from the environment. Remote servers over HTTP that reach company data should implement the authorization spec.
02Entra Agent ID or Okta for agents?
It mostly follows your existing identity setup. Microsoft 365 and Copilot Studio agents belong in Entra Agent ID. Mixed SaaS estates on Okta tend to suit Agent SSO and Cross App Access. Running both is fine if the boundary is clear.
03Can you secure MCP servers we didn't write?
Often, yes. Put them behind a gateway or proxy that enforces OAuth and does the logging. The awkward ones are servers that can't take a separate token for downstream calls. Those may need a wrapper, or replacing.
04How long does this take?
That depends on how many agents and servers you have, how many of them write to production, and whether your identity platform supports agent identities yet. Once the inventory is done we can size it properly.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyAI pilot to production with forward deployed engineers
Taking an AI pilot into production with forward deployed engineers who work with the business team, build evals, connect real systems and hand over cleanly.
read the case studya745fbb7 - 01Model Context Protocol: Authorization, revision 2026-07-28modelcontextprotocol.io ↗
- 02Okta: Agent SSO generally available (24 Aug 2026)okta.com ↗
- 03Microsoft Learn: What's new in Microsoft Entra Agent ID (GA)learn.microsoft.com ↗
- 04Message Center MC1506728: AgentIdentity.CreateAsManager change (4 Nov 2026)mc.merill.net ↗
- 05Okta newsroom: Auth0 product innovations, Auth for MCP (21 May 2026)okta.com ↗
- 06OWASP GenAI: LLM06:2025 Excessive Agencygenai.owasp.org ↗
- 07OWASP GenAI: Top 10 for Agentic Applications (9 Dec 2025)genai.owasp.org ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it