Agentic identity governance for AI clients is becoming an IAM problem

At a glance

What this is: This is an analysis of agentic identity governance for AI clients, with the key finding that enterprise controls must account for runtime tool use, federated identity, and auditability.

Why it matters: It matters because IAM teams now need to govern AI clients alongside NHI and human identities, or they will miss how agentic access expands privilege paths and weakens review models.

👉 Read Strata Identity's analysis of agentic identity and MCP access control

Context

Agentic identity governance is the problem of controlling what AI clients can access, which tools they can call, and how their actions are traced. The article focuses on a growing gap: existing IAM patterns were built for users and static machine identities, not software that chooses actions at runtime.

Strata Identity frames the issue around enterprise workflows that use MCP connections, federated identity, and gateway-style runtime controls. That makes the topic relevant to NHI governance, but also to broader identity programmes that must decide where human approval ends and agent execution begins.

Key questions

Q: How should security teams govern AI clients that use MCP to reach enterprise tools?

A: Security teams should treat MCP-connected AI clients as governed identities with explicit scope, owner, and revocation controls. The key is to enforce identity and policy at the MCP boundary, then compare runtime behaviour with the approved purpose. That approach preserves traceability when an agent interacts with multiple tools.

Q: Why do AI clients complicate traditional IAM models?

A: AI clients complicate IAM because their access is not always static or fully predictable at provisioning time. They may choose different tools and data paths as tasks evolve, which makes ordinary entitlement review incomplete. IAM teams need runtime visibility, delegated authority, and stronger audit trails to govern them effectively.

Q: What do security teams get wrong about agentic identity?

A: The common mistake is assuming an AI client can be governed like a normal service account with one stable use case. In practice, agentic systems can change their tool choices and timing within a task, so static policy alone does not explain behaviour. Governance must cover the session, not just the credential.

Q: How can organisations reduce risk from AI clients without blocking adoption?

A: Organisations should reduce risk by removing shared secrets, narrowing tool scopes, and making delegation reviewable. That lets AI clients operate with less standing privilege while still preserving business value. The goal is not to stop agent use, but to make every access path attributable and revocable.

Technical breakdown

MCP as an identity and authorisation boundary

Model Context Protocol creates a structured path between an AI client and enterprise tools, but the protocol itself does not solve identity assurance. Once an agent can invoke downstream systems through MCP, the critical question becomes whether the resource server knows who is acting, on whose authority, and under what scope. In practice, this turns MCP endpoints into identity-enforced access points rather than simple integration connectors. Without that boundary, visibility fragments across logs, tokens, and tool APIs, which makes audit and revocation much harder than in conventional service-to-service access.

Practical implication: Treat MCP servers as controlled access surfaces and require explicit identity, scope, and audit enforcement at the boundary.

Federated identity for workforce AI clients

Federated identity lets an enterprise AI client operate with delegated authority instead of shared secrets or broad static credentials. That matters because agentic systems often need access to multiple tools across domains, and one long-lived credential becomes an oversized trust object. Federation changes the governance model: access can be asserted, constrained, and observed through standard identity flows instead of being embedded in application code. The hard part is not the protocol itself but the governance around who can mint, delegate, and revoke the resulting access path.

Practical implication: Use federation to eliminate embedded secrets and force AI client access through accountable identity flows.

Runtime visibility is the control that makes agentic access governable

Agentic systems are difficult to secure because their effective privilege is not fixed at provisioning time. A client may choose different tools, different data, and different timing based on task context, which means static entitlement review only captures part of the risk. Runtime visibility closes that gap by showing what the agent actually accessed, which actions it took, and whether those actions stayed inside policy. For identity teams, this is the difference between governing a declared permission set and governing observed behaviour.

Practical implication: Require session-level telemetry and policy decisions that can be reviewed against actual agent behaviour.

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 distinct governance category, not a variant of service identity. The article shows why AI clients with tool access cannot be managed as ordinary workload identities once they begin selecting actions at runtime. That changes the control problem from simple authentication to delegated authority, traceability, and constrained execution. Practitioners should treat these clients as a separate governance class with their own lifecycle and review model.

MCP connectivity creates an identity boundary that must be enforced, not assumed. The real risk is not the protocol name but the fact that tool access becomes brokered through a new runtime surface. If that surface does not assert identity, scope, and audit detail at every call, existing IAM controls lose their ability to explain or contain action chains. The implication is that MCP governance belongs in the identity architecture, not at the edge of application operations.

Federated access for AI clients will accelerate the shift away from shared credentials. Once an agent needs access across systems, token reuse and hardcoded secrets become poor governance choices because they obscure accountability and widen blast radius. Federation does not remove the risk, but it makes the access path reviewable and revocable in ways static secrets cannot. Security leaders should expect this to become the default design pressure for enterprise agent deployments.

Runtime visibility is the named concept that separates agent governance from traditional IAM. Static provisioning tells you what an AI client could do; runtime visibility tells you what it actually did. That distinction matters because agentic behaviour can diverge from the expected path within a single task. The implication is straightforward: identity teams need to review agent behaviour as executed reality, not as intended configuration.

Agentic sprawl will force IAM teams to redesign review and accountability workflows. The source material points toward a future where AI clients become numerous, persistent, and operationally embedded across business functions. That means access review, attestation, and exception handling will need to account for non-human actors that can scale faster than the governance process around them. Practitioners should prepare for governance load to grow faster than manual review capacity.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented policies to govern AI agents, even though 92% agree that agent governance is critical to enterprise security.
• For a broader control model, see OWASP Agentic Applications Top 10 for the runtime risks that matter most to identity teams.

What this signals

Agentic identity will force governance teams to move from static permission review to runtime accountability. The practical issue is not whether AI clients are useful, but whether the organisation can explain their actions after the fact and revoke access before the next task begins. With agent behaviour already exceeding intended scope in most environments, the gap is becoming operational rather than theoretical.

Runtime visibility is the control plane that separates manageable agent deployment from blind trust. If an AI client can call tools without a reviewable record of what it did, IAM and security operations lose the ability to contain misuse quickly. That is why the strongest programmes will pair delegated access with session evidence, not rely on entitlement snapshots alone.

The governance pressure will also spread beyond security teams. Compliance, legal, and business owners will need to understand which AI clients can reach which systems, because agent behaviour now affects auditability, data handling, and accountability in the same workflow.

For practitioners

• Classify AI clients as governed identities Assign each AI client an explicit identity owner, access purpose, and revocation path before it is connected to enterprise tools. Do not let application teams treat agent access as an implementation detail.
• Enforce policy at MCP boundaries Require identity assertion, scope checking, and audit logging at the MCP server or gateway rather than relying on downstream tools to interpret agent intent. Make the boundary the enforcement point.
• Replace shared secrets with delegated access Remove hardcoded tokens and reused credentials from agent workflows wherever federation or short-lived delegation is possible. Shared secrets hide accountability and make blast radius larger than the task requires.
• Review actual agent behaviour, not just entitlements Compare observed tool use, accessed data, and action timing against the approved purpose for each AI client. If the runtime path drifts, treat it as a governance exception, not just a logging event.

Key takeaways

• Agentic identity changes IAM from provisioning control to runtime governance.
• AI clients already exceed intended scope in most organisations, which makes reviewable access paths urgent rather than optional.
• Federated identity, boundary enforcement, and runtime visibility are the controls that make agentic access governable.

Key terms

• Agentic Identity: The identity assigned to an AI client that can choose actions and use tools during runtime. It is governed as a non-human actor with explicit scope, accountability, and revocation needs, because its behaviour can change as tasks unfold.
• MCP Boundary: The control point where an AI client reaches external tools through Model Context Protocol. It is where identity, authorisation, and logging need to be enforced so that downstream systems do not receive uncontrolled or untraceable requests.
• Runtime Visibility: The ability to observe what an AI client actually accessed, which tools it used, and how it behaved during a session. It is more useful than entitlement snapshots for agent governance because it captures executed reality, not just approved access.
• Federated Access: A delegated access model that lets an AI client act through controlled identity flows instead of embedded long-lived secrets. For agentic systems, federation improves accountability because credentials can be scoped, tracked, and revoked more cleanly.

Deepen your knowledge

Agentic identity governance and runtime access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI clients, it is a practical next step for your team.

This post draws on content published by Strata Identity: Agentic Identity and MCP governance for workforce AI clients. Read the original.