MCP Identity Governance: Securing AI-Agent Actions in 2026

MCP identity governance is the practice of controlling which identity, working through which AI assistant, may invoke which identity tool, under what policy, with what evidence recorded. It treats every tool call an assistant makes over the Model Context Protocol as an identity event. Each one has to be authorized against the requester's real authority, checked against enterprise policy, routed for approval when the action is sensitive, and written down in a form an auditor can use.

The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in November 2024, that lets AI assistants connect to tools and data through MCP servers. Those servers expose three kinds of things: tools the assistant can call, resources it can read, and prompts it can reuse. Enterprises are now connecting Claude, Microsoft Copilot, and other MCP-compatible assistants to systems of record. Once the tools on the other end of those connections are identity tools (reset a password, add a user to a group, disable an account, approve an access request), the key question changes. Whether the assistant can reach the system matters less. Whether this particular action should happen, for this person, right now, matters more.

This article covers that second question. Securing the servers themselves is covered in how to secure MCP servers, the evidence side in the AI agent audit trail and Avatier Ledger, and what an agent's identity is in the agentic identity hub.

What MCP identity governance means

The definition breaks into five questions. A governed MCP deployment can answer every one of them for every identity action an assistant takes.

Which identity? Every action has a principal: a named employee, a manager, a help desk analyst, or a registered non-human identity. "The AI did it" is not an answer. The principal is the person or workload on whose authority the action runs, and it has to be resolved from a real authentication event, not claimed in a prompt.

Through which assistant? The same person might ask in Claude, Microsoft Copilot, Teams, or a custom agent. The initiating assistant belongs in the record, because reviewers need to tell human-initiated outcomes from agent-assisted ones, and some assistants may be approved for some actions and not others.

Which identity tool? The capability being called has to be one the enterprise approved, with a defined purpose, defined inputs, and a defined blast radius. "Unlock this account" is a capability. "Run this directory command" is not.

Under what policy? Each call is evaluated against the organization's existing rules: who may act on whom, which actions need approval, which combinations break separation of duties, and which conditions (time, location, risk) change the answer.

With what evidence? Each outcome, allowed or denied, produces a record showing who asked, what ran, under whose authority, and what policy allowed it. If an organization cannot audit an AI-initiated identity action, it does not fully control it.

Together, the five give the request path a fixed shape. A user asks, the assistant calls an MCP tool, and the tool hands the request to a policy decision the assistant cannot influence. The outcome is completed, routed for approval, or denied, and evidence is written at the moment of decision.

Every governed request follows one path: the assistant asks, policy decides, and the evidence is written when the outcome happens.

How MCP authorization works, at a high level

An MCP deployment has three roles. The host is the AI application the person is using. The client is the connector inside that host that speaks MCP. The server exposes the tools, resources, and prompts. Servers can run locally on the user's machine or remotely over HTTP, and the remote case is the one that matters for shared identity tooling.

For remote servers, the MCP authorization specification builds on OAuth 2.1. In general terms, the MCP server acts as a protected resource. The client gets an access token from an authorization server, typically after the user signs in and consents. The client then presents that token with its requests, and the server validates it before serving anything. OAuth 2.1 folds in years of accumulated practice, such as requiring PKCE for authorization-code flows and dropping older grant types that proved easy to misuse. If you need the underlying concepts, the OAuth explainer for identity governance teams covers tokens, scopes, and consent in more detail.

For an enterprise, the practical goal is to anchor this flow in the identity provider it already runs, so sign-in, MFA, and conditional access apply before any assistant reaches an identity tool. Tokens should be narrowly scoped, short-lived, and issued for the server that receives them, not reused downstream.

Here is what a tool call looks like once authorization has succeeded. The example below is illustrative only. It is not a real product schema:

{
  "tool": "unlock_account",
  "arguments": {
    "target_user": "j.rivera",
    "reason": "Locked out after travel; ticket HD-20418"
  },
  "requested_by": "m.chen (via assistant)",
  "result": {
    "policy": "self-or-direct-report unlock",
    "decision": "allowed",
    "evidence_id": "illustrative-0001"
  }
}

The token showed that this client could call this server for this signed-in user. It did not decide whether m.chen may unlock j.rivera's account, whether that unlock needs a second approver, or whether j.rivera is on a legal hold that freezes account changes. Those are governance decisions. OAuth scopes are usually too coarse to express them, and a token carries no approval chain and no business-level evidence. MCP authorization opens a channel. Identity governance decides each action that travels through it.

The assistant is the interface, never the authority

One principle does most of the work in MCP identity governance: the assistant is the interface, never the authority. The assistant is where a person asks. It understands the request, fills in missing details, and shows the result. It never decides whether the action is permitted. That decision belongs to the identity system behind the tool, which uses the requester's existing roles, the organization's policies, and its approval workflows.

The reason is practical. Language models can be misled by content they read: an email, a document, or a tool description written to steer them. If the model is the authority, anything that can influence the model can escalate privilege. If authority lives in a deterministic policy engine, a manipulated assistant can still only request actions, and a request succeeds only if the person behind it was already allowed to take that action.

Three anti-patterns show up again and again when this principle is ignored:

• The god-mode service account. The MCP server connects to the directory with one broadly privileged credential, and every user's request runs with that credential's rights. The assistant becomes a way to launder privilege: any user can reach anything the service account can.
• Policy in the system prompt. Rules like "only managers may disable accounts" are written as instructions to the model rather than enforced in code. Instructions aren't controls. A persuasive enough input can talk the model out of them.
• The model decides on approvals. The assistant is asked to judge whether an action is sensitive enough for a human to review. The classification that matters most is handed to the component least suited to make it.

Same assistant, same request: one path launders privilege through a shared credential, the other runs on the requester's authority and leaves evidence.

The difference is easiest to see side by side:

Dimension	Ungoverned agent access	Governed agent access
Whose authority	A shared, broadly privileged service credential	The requester's own entitlements, delegated and capped
What the assistant can call	Anything the connector exposes, often raw admin operations	A defined catalog of approved identity capabilities
Where policy lives	In the system prompt, or nowhere	In the identity system, evaluated on every call
Sensitive actions	Run immediately if the model agrees	Routed to existing human approval workflows
Denials	Often silent or unexplained	Explicit, explained, and recorded
Evidence	Chat transcripts and server logs, rebuilt after the fact	A structured record for each outcome, created as it happens
Effect of prompt injection	Can widen what the assistant does	Limited to what the requester could already do

The five governance controls

Five controls turn the principle into something you can operate. None is new to identity teams. What's new is applying them at the MCP boundary, so assistant-initiated and portal-initiated actions meet the same standard.

1. Approved capabilities only. Expose a curated catalog of identity tools, each with a narrow purpose: unlock an account, reset a password after verification, request a role, review a pending approval. Don't expose generic directory write access, arbitrary query execution, or "run this script" tools. Every capability should have a documented owner, defined inputs, and a known blast radius. Assistants should see only the capabilities approved for their context, which is the principle of least privilege applied to tools rather than to people.

2. Delegated authority. An assistant acting for a person should never hold more authority than that person. In practice, what an assistant can do for someone is the overlap of what that person is entitled to and what the approved capability allows. It is never the combined total. Delegation should be explicit and time-bound where it crosses people, for example a manager acting on behalf of a direct report, or a proxy covering for someone on leave. Agents that act on their own authority, without a human in the request, need registered non-human identities with their own owners and scopes. The service account and non-human identity governance reference covers that population in depth.

3. Policy enforcement outside the model. Every call is evaluated by the identity system against existing rules: who may act on whom, organizational scoping, separation of duties conflicts, time or risk conditions, and target-specific restrictions. The model never sees the policy as something it can negotiate. It only receives the decision. Denials should come back with a plain explanation, so the assistant can tell the user why and what to do next, instead of retrying variations until something slips through.

4. Approvals. Sensitive, irreversible, or high-impact actions go to the human approval workflows the organization already uses. Examples include disabling an account, granting privileged access, adding members to high-value groups, and making changes outside the requester's usual scope. The assistant can start the request and report its status. It can't approve on anyone's behalf, and it can't decide which actions skip review. Assisted help desk actions are a special case. Verification should go to the end user, not to whoever is making the request, which is the same principle the Assisted Reset pillar applies to human help desk agents.

5. Audit. Every outcome, completed or denied, produces a record showing who asked, which assistant or experience made the call, what authority was in effect, which policy applied, what action ran, and what the final result was. The record should be created by the system that performed the action, at the moment it happened, not stitched together later from chat logs. That is what makes agent-assisted activity reviewable in an access certification or an audit, alongside everything else.

The five work as a set. Capabilities without delegated authority still launder privilege, and enforcement without audit can't be proven.

A practical MCP identity governance checklist

This checklist is for a CISO or identity architect preparing to let AI assistants perform identity actions. Work through it in order. Teams that start at step seven (turning on logging) usually find they have nothing meaningful to log.

Five controls, one set: drop any one of them and assistant-driven identity actions stop being governable.

1. Inventory every MCP connection that touches identity. List each assistant, each MCP server it connects to, and each tool that reads or changes identity state. Include the servers teams have connected on their own. You can't govern connections you haven't found.
2. Define the approved capability catalog. For each identity tool, record its purpose, inputs, owner, and blast radius. Remove or replace generic administrative tools with narrow, purpose-built ones.
3. Anchor authorization in your identity provider. Require remote MCP servers to use OAuth 2.1-based authorization tied to your existing sign-in, MFA, and conditional access. Use short-lived, narrowly scoped tokens issued for the server that receives them.
4. Eliminate shared privileged credentials. Make sure each action runs on the requester's own delegated authority, capped at what they already hold, rather than on a broadly privileged service account.
5. Move policy out of prompts and into the identity system. Express who-may-act-on-whom, scoping, separation of duties, and conditional rules as enforced policy. Treat any rule that exists only in a system prompt as not implemented.
6. Map sensitive actions to existing approval workflows. Decide ahead of time which capabilities always need human approval, and route them through the approval chains already in use for portal and help desk requests.
7. Require an evidence record for every outcome. Confirm that completed and denied actions both produce a structured record: who asked, which assistant, what authority, which policy, what action, what result.
8. Register autonomous agents as non-human identities. Any agent acting without a human in the request gets its own identity, owner, scope, and review cadence, and it is included in access certifications. For how agents authenticate, see identity for AI agents and agentic authentication.
9. Vet and allow-list MCP servers. Approve servers before they can be connected, review tool descriptions for injected instructions, and pin versions so a tool's behavior can't change silently.
10. Review agent-assisted activity on a schedule. Pull agent-assisted outcomes into regular reviews next to human-initiated ones. Look for denied-request patterns, unusual volumes, and capabilities that are never used and could be retired.

A program that completes these ten steps can answer the five definitional questions for any assistant-initiated identity action.

What Avatier ships toward this pattern

Avatier's MCP connectors are built around the principle this article describes. Avatier describes it as "the assistant is the interface, never the authority," and in the product that means nothing bypasses the customer's existing policies, approvals, and roles.

Avatier Actions is an MCP connector that exposes more than 50 identity outcomes as MCP tools across eight modules: Password Management, Help Desk, Lifecycle Management, User Management, Group Management, Access Governance, Workflow Approval, and Reports. An employee or manager asks in Microsoft Teams, Outlook, Claude, or Copilot, and the outcome runs through the organization's existing policies, approvals, and roles. Assistants don't get unrestricted access. Every request must call an approved Avatier capability and stays subject to authentication, authorization, delegated authority, policy enforcement, and audit controls. Avatier decides whether an identity action is permitted and records what happened.

Avatier Ledger is a separate MCP connector that turns every outcome into evidence and every report into a question. Ledger records who asked, what ran, under whose authority, and what policy allowed it, for both human-initiated and agent-assisted actions. Each completed Secure Outcome records the identity involved, the initiating agent or experience, the authorization context, the policy applied, the action taken, and the final result. That lines up directly with the audit control above. Through Persona Briefings, Ledger tailors the answer to the person asking: a CISO sees compliance frameworks with remediation in 0–30, 30–90, and 90-plus-day windows, a CFO sees identity spend reconciled to completed actions, and a security team sees exposure, dormant and orphaned access, and privileged activity.

Setup is one administrator connection. Permissions are inherited from the identity platforms customers already run (Microsoft Entra ID, Active Directory, Okta, and Ping), which is how delegated authority stays tied to entitlements the organization already governs, with no new permissions model. Avatier runs alongside those platforms rather than replacing them, and alongside SailPoint, Saviynt, ServiceNow, and Moveworks where they are in place. Both connectors work inside Claude, Claude Code, Microsoft Copilot, Avabot, and any MCP-compatible assistant, as part of Avatier Identity Anywhere 2027™.

Commercially, Actions and Ledger are priced under Pay Per Identity Action™. Customers pay only for completed, verified, policy-compliant outcomes, so every charge corresponds to an outcome that already carries its evidence. What is Pay Per Identity Action explains the model. Getting started is free, deployment services are included, and the Avatier Secure Outcome Guarantee™ provides a 45-day money-back guarantee. Full commercial terms are shared with qualified organizations in the invitation-only preview.

The Avatier Trust Center publishes the posture behind this: SOC 2 Type II audited with zero exceptions noted, ISO/IEC 27001:2022 certified, and NIST 800-53 Rev. 5 aligned. The same governed-outcome approach runs across the six Credential Governance pillars, whether a request starts in a portal, at the help desk, or in an assistant.

What MCP identity governance does not solve

Overselling governance creates its own risk, so here are the limits.

It does not govern third-party MCP servers you don't control. Governance applies to the identity tools you expose and the policy engine behind them. If a team connects an assistant to a third-party MCP server that can act on a SaaS application directly, your identity governance never sees those calls. You can limit that with server allow-listing, supply-chain vetting, and managing which connectors assistants may load. What happens inside someone else's server is still outside your policy boundary.

It does not stop prompt injection or tool poisoning. Keeping authority out of the model limits what a manipulated assistant can do. It can only request actions the requester was already allowed to take, and sensitive ones still wait for human approval. But a manipulated assistant can still make requests that are allowed and still harmful, read data the user can see and leak it somewhere else, or mislead the user about what it did. Defense in depth is still required: input handling, reviewing tool descriptions, output controls, least-privilege scoping, and monitoring. How to secure MCP servers covers those layers.

It does not fix entitlements that are already wrong. Delegated authority caps an assistant at what the requester holds. If a user has accumulated excess access, the assistant inherits it, which makes access certification more important, not less.

It does not replace human judgment on approvals. Routing sensitive actions to approvers only works if approvers actually review them. If approval volume grows until people approve by reflex, the control degrades quietly. Keep the approval set focused, and watch approval patterns the way you watch agent activity.

Within those limits, MCP identity governance keeps authority where it already lives, holds assistant-initiated actions to the same policy as every other channel, and turns "the AI did it" into an auditable record. For why the enterprise conversation moved from what models can do to what agents are allowed to do, see the Ai4 2026 perspective on agentic AI identity security.