Agentic AI identity governance needs stronger standards as MCP scales

At a glance

What this is: Descope says agentic AI and MCP are exposing gaps in traditional IAM when software acts autonomously across multiple systems.

Why it matters: IAM, NHI, and security teams need to treat agent identity, policy, and audit as core controls before autonomous tool use spreads beyond pilots.

By the numbers:

• A recent Descope survey of 400+ identity decision-makers found that while 88% use or are planning to use AI agents, only 37% have moved past pilots due to identity headaches.

👉 Read Descope's analysis of agentic identity governance and MCP access control

Context

Agentic AI changes the identity problem because the software is no longer just calling APIs on behalf of a known human workflow. Once an AI agent can decide which tool to call, when to act, and which system to touch, identity governance has to cover the runtime behaviour of the actor, not just the account behind it. That is the core issue in agentic AI identity governance.

Descope's own framing is that MCP and agent-to-tool connectivity are moving faster than enterprise authentication, authorisation, and audit models. For IAM teams, the practical question is not whether agents will be used, but whether access policy and logging can keep pace with systems that act across HubSpot, code repositories, and internal applications.

The same pressure is already visible in broader agent governance research. The challenge is not isolated to one vendor or one protocol. It is a category-level shift that touches NHI governance, access review, secrets handling, and the way organisations prove control over non-human actions.

Key questions

Q: How should security teams govern AI agents that connect through MCP?

A: Security teams should govern AI agents through explicit identity, policy, and audit controls at every tool boundary. That means assigning accountable identities, enforcing authorisation at action time, and logging each call with enough context to reconstruct what the agent touched and why. Without those controls, MCP connectivity can scale access faster than governance can follow.

Q: Why do traditional IAM controls fail for agentic AI systems?

A: Traditional IAM controls fail because they assume stable identities, predictable workflows, and access that can be reviewed after use. AI agents can change tool choice and action sequence during execution, which makes static entitlements and periodic reviews incomplete. Governance has to move closer to runtime behaviour, not just identity issuance.

Q: When should organisations treat an AI agent like a privileged identity?

A: Organisations should treat an AI agent like a privileged identity whenever it can access sensitive data, write to production systems, or chain actions across multiple services. At that point, the risk is not just authentication but delegated execution with real operational impact. The access model should reflect the agent's blast radius, not its label.

Q: What should IAM teams measure to know if agent governance is working?

A: IAM teams should measure whether every agent action can be tied to a specific identity, policy decision, and business purpose. Useful signals include complete audit logs, bounded tool access, and consistent enforcement across connected systems. If actions cannot be reconstructed cleanly, governance is not working even if login succeeded.

Technical breakdown

Why MCP changes the identity boundary for AI agents

Model Context Protocol standardises how agents connect to tools and data sources, but it does not remove the identity problem. The protocol makes it easier for agents to take action across systems, which means authentication and authorisation must now be enforced at the point of tool use, not only at login or API provisioning. In practice, that shifts control from coarse account-level trust to per-action governance. If the agent can reach multiple systems in one session, access scope, auditability, and policy enforcement all need to follow the session, not the user story behind it.

Practical implication: treat MCP servers as identity enforcement points and require policy, auth, and logging at each tool boundary.

Why static machine-to-machine auth breaks down for agents

Traditional machine-to-machine identity assumes a stable service pattern with predictable call paths and bounded privilege. Agentic systems do not always behave that way. They may choose different tools, change sequence mid-task, and expand into adjacent systems as the task evolves. That makes static permission scoping brittle, because the privilege model was defined before the runtime decision path existed. For security teams, the architectural issue is not just credential issuance. It is the mismatch between fixed entitlements and variable agent behaviour across a multi-step workflow.

Practical implication: design agent permissions around task scope and observable action boundaries rather than static service-account assumptions.

What enterprise-ready agent governance needs beyond basic auth

Authentication alone is not enough for an agentic environment. Organisations need policy-based access control, audit logging, and a way to map each agent action back to an accountable identity and purpose. That is especially important where agents can write code, update internal systems, or access sensitive CRM data. The governance model has to show who approved the agent, what it was allowed to do, and what it actually did. Without that, agent deployments may work technically while remaining ungovernable from an IAM, compliance, or incident-response perspective.

Practical implication: require traceable agent accountability, action logging, and policy review before expanding agent access into production.

Threat narrative

Attacker objective: The attacker aims to use compromised or abused agent access to reach sensitive data and high-privilege actions across multiple systems without immediate detection.

1. Entry begins when an AI agent gains authorised access to a connected tool through MCP or a similar integration path, often using credentials or delegated authorisation created for legitimate use.
2. Escalation occurs when the agent expands from a single task into cross-system actions, using its runtime decision-making to touch additional data sources or administrative functions.
3. Impact follows when policy, logging, or oversight is too weak to reconstruct or constrain the agent's actions, creating blind spots across sensitive systems and privileged workflows.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic identity is now a governance layer, not a feature flag. Once AI agents can select tools and act across systems, identity stops being a simple authentication problem and becomes a runtime governance problem. Static machine credentials, human-centric approvals, and after-the-fact audit trails do not describe the behaviour that matters. Practitioners should treat agent identity as infrastructure that must be governed from the first production connection.

The assumption that least privilege can be defined at provisioning time is breaking. That assumption was designed for actors whose intent is known before execution. It fails when an agent decides which tool to call next because the actual privilege path is created during the session, not before it. The implication is that entitlement design must move from static assignment to bounded, observable action scope.

Runtime tool-use governance: agentic systems create an identity boundary that is defined by session-time decisions, not by initial login. That boundary matters because MCP increases the number of places where privilege can be exercised, inspected, or abused. Organisations that cannot map each action to an accountable policy decision will struggle to satisfy both operational control and compliance evidence requirements.

Agent-native standards will increasingly separate governed deployments from experimental ones. The market is moving toward shared patterns for authentication, authorisation, and auditing because ad hoc agent connections do not scale into enterprise controls. That means IAM and security leaders will need to re-evaluate whether their current control stack can handle tool-calling software at production speed. The practical conclusion is that standards adoption is becoming a prerequisite for scale.

Identity teams should stop treating AI agent governance as adjacent to NHI governance. Agents are NHIs, but they also introduce a distinct behavioural risk profile because the access path is dynamic. That makes them a bridge case between workload identity, secrets control, and emerging agentic AI frameworks. The implication for practitioners is to design one governance model that can handle both fixed machine accounts and decision-making software.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments.
• The governance question now shifts from whether agents will scale to whether AI agents as a growing security threat can be controlled with the identity models enterprises already have.

What this signals

Runtime tool-use governance: the enterprise problem is moving from agent adoption to control durability. As more organisations connect agents to business systems, the question is whether identity teams can preserve traceability when decision-making happens inside the session, not around it.

Descope's survey result that 88% of respondents are using or planning to use AI agents while only 37% have progressed beyond pilots points to a familiar pattern: adoption outpaces governance. The programme risk is not abstract AI complexity, but the accumulation of unmanaged access paths that will later be treated as normal.

The practical signal for IAM and NHI teams is to align agent controls with the same discipline used for workload identity and privileged access, while extending those controls to runtime policy enforcement. That is where agentic identity begins to behave like an enterprise control plane rather than an experiment.

For practitioners

• Define MCP trust boundaries Map every MCP server and connected tool to a named business owner, an allowed action set, and a logging requirement before the first production rollout.
• Separate agent identity from shared service accounts Issue distinct identities for each agent or agent class so access reviews can trace behaviour to a specific runtime actor instead of a generic integration account.
• Enforce per-action authorisation Require policy checks at each sensitive tool call, especially where agents can write code, modify records, or query regulated data.
• Build audit trails for agent accountability Log the tool requested, the data touched, the policy decision, and the approval context so incident teams can reconstruct agent behaviour without guesswork.

Key takeaways

• AI agents turn identity into a runtime governance problem because tool choice, access scope, and execution timing can change during a session.
• Descope's survey shows strong AI agent adoption intent, but most organisations are still blocked by identity and governance friction.
• Practitioners need per-action authorisation, traceable audit trails, and explicit MCP trust boundaries before agent use expands into production systems.

Key terms

• Agentic Identity: Agentic identity is the governance model for software that can choose actions at runtime and use tools without step-by-step human approval. It extends identity control beyond authentication to authorisation, auditing, and accountability for each action the system takes.
• MCP Server: An MCP server is a tool-access endpoint that exposes systems, data, or functions to AI agents through the Model Context Protocol. In practice, it becomes an identity enforcement point because every connected tool can expand the agent's accessible attack surface if policy is weak.
• Runtime Authorisation: Runtime authorisation is the decision to allow or deny an action at the moment it is requested, rather than only at account provisioning time. For agents, this is critical because the relevant risk is often the specific tool call, not the existence of the identity itself.
• Agent Accountability: Agent accountability is the ability to link an autonomous or semi-autonomous software action back to an identity, policy decision, and business purpose. Without that chain, incident response and compliance reviews cannot reliably explain what the agent did or whether it stayed within scope.

What's in the full article

Descope's full post covers the operational detail this post intentionally leaves for the source:

• How Descope's Agentic Identity Hub implements protocol-compliant auth for MCP servers in practice
• What the Python MCP SDK changes for teams embedding authentication and authorisation into agent workflows
• How the company describes enterprise-grade access policy and auditing support for agentic systems
• The survey context behind the move from pilot projects to production governance decisions

👉 Descope's full post covers the AAIF context, the Agentic Identity Hub update, and the identity gaps it is designed to address.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.