AI agent identity governance needs blended identity controls now

At a glance

What this is: Aembit's analysis shows AI agents are moving into production faster than IAM controls can separate agent activity from human activity or govern access at request time.

Why it matters: IAM, PAM, and governance teams need to treat AI agents as identity-bearing actors because user-only or workload-only controls cannot safely scope, audit, or revoke agent access.

By the numbers:

• 80.9% of teams have AI agents in active testing or production.
• 68% of organisations can’t clearly distinguish between agent and human activity.
• 74% say agents often end up with more access than they need.
• Only 21.9% treat them as independent, identity-bearing entities.

👉 Read Aembit's analysis of IAM for Agentic AI and Blended Identity

Context

AI agent identity governance is the discipline of deciding how an agent is identified, authorised, constrained, and audited when it can call APIs, query data, and trigger workflows at machine speed. The problem is not that agents exist. The problem is that most enterprise IAM stacks still assume a stable human behind the request or a fixed workload identity with predictable access boundaries.

Aembit's framing is that agents need a blended identity model because user-only identity and workload-only identity each fail in different ways. That matters for IAM teams because the control question changes from who logged in to which user, through which agent, may access which resource, under which policy, right now.

Key questions

Q: How should security teams govern AI agents that act on behalf of different users?

A: Security teams should authorise AI agents at request time using a combined view of the user, the agent, and the resource being accessed. That prevents one agent from inheriting broad access across all users. The governance rule is simple: the same agent does not deserve the same access in every context.

Q: Why do shared API keys create the wrong trust model for AI agents?

A: Shared API keys make the agent look like a reusable service rather than an accountable actor. Once the key is copied, every request shares the same trust boundary, so access cannot be scoped, attributed, or revoked cleanly. That is a poor fit for agents that operate at machine speed across multiple workflows.

Q: What breaks when AI agents are treated like normal workloads?

A: User context disappears, per-request scoping disappears, and revocation becomes blunt. Normal workloads usually map to a stable service identity, but AI agents can serve different people and move across tasks in the same session. Treating them as ordinary workloads hides the real access decision and weakens auditability.

Q: How can IAM teams tell whether agent governance is actually working?

A: Look for dual attribution, ephemeral downstream credentials, and policy decisions made on every request. If logs show only a generic service account, governance is too coarse. If a single credential can still be reused across users or sessions, the agent is still operating inside a standing privilege model.

How it works in practice

Blended identity in agentic AI access control

Blended Identity is an access model that evaluates the human user and the AI agent together at request time. That matters because an agent can be acting on behalf of different users, across different sessions, with different trust levels and resource scopes. Traditional IAM usually resolves either user identity or workload identity, then applies policy once. Agentic AI breaks that split because the same agent can legitimately serve multiple people, yet each request may need a different authorisation outcome. The technical shift is from static identity binding to per-request contextual binding, with the policy engine deciding on the combined actor state rather than either identity alone.

Practical implication: Map access decisions to the user-agent-resource tuple, not to the agent alone.

MCP authorization server and identity gateway

The Model Context Protocol creates a standardised way for agents to reach tools and services, which makes the authorization layer the critical control point. An MCP Authorization Server handles token issuance through OAuth 2.1 and federates user identity from existing IdPs such as OIDC or SAML. An MCP Identity Gateway then validates those tokens on every request and exchanges downstream credentials so the agent never directly holds them. This architecture separates authentication, policy enforcement, and credential presentation, which reduces direct secret exposure while preserving request-level control over third-party and self-hosted MCP servers.

Practical implication: Place policy enforcement at the MCP boundary and prevent agents from ever storing reusable downstream credentials.

Policy-based just-in-time access for autonomous tool use

Just-in-time access for agents is not the same as human JIT access. The agent may invoke tools repeatedly and at machine speed, so the control must issue scope-limited credentials only for the exact request path and then remove them immediately after use. Conditional policy inputs such as time, geography, and runtime posture become more important because they can constrain automated tool use without creating standing privilege. The kill switch is also notable because it gives teams a fast way to revoke a specific agent's access without rotating shared credentials or breaking unrelated workflows.

Practical implication: Use ephemeral, per-request credentials and a policy kill switch to contain agent misuse without shared-secret fallout.

NHI Mgmt Group analysis

Blended identity is the right control frame for agentic access because the actor is neither purely user nor purely workload. User-only IAM collapses the agent into the human behind it, while workload-only IAM erases the person whose permissions and intent still matter. That creates a governance blind spot at the exact point where access decisions must be made per request. Practitioners should treat blended identity as the baseline model for AI agent governance.

Identity does not select or combine tools dynamically mid-session was designed for a world where access could be pre-scoped at provisioning time. That assumption fails when the actor is autonomous because the agent can alter its path, tool selection, and timing during the same session. The implication is not just a missing control, but a broken premise in least-privilege design for machine-paced actors.

Standing credential exposure window is the named failure mode this architecture is trying to eliminate. Shared API keys and inherited service accounts turn every agent session into a reusable trust object, which makes blast radius depend on how long the secret survives. Policy-driven, request-scoped credential exchange narrows that window and gives IAM teams a defensible revocation point. Practitioners should stop treating reusable secrets as acceptable agent plumbing.

Request-time authorisation is now the dividing line between governed agent use and uncontrolled automation. When policy is checked only at login, the organisation has no visibility into what happens after the first token is minted. Dual attribution of user, agent, resource, and policy decision is what turns agent activity into an auditable identity event. Compliance teams should require that level of attribution before broad production rollout.

The agent identity market is converging on platform controls, but the governance problem remains cross-domain. Agentic AI cannot be governed by a single siloed control team because the same access pattern touches human identity, workload identity, secrets, audit, and policy. That convergence is useful only if teams preserve per-actor accountability rather than flattening everything into a generic automation layer. IAM leaders should design for shared governance, not shared identity.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how easily machine identities drift outside governance.
• For the rotation and offboarding angle, review the Ultimate Guide to NHIs alongside the 52 NHI Breaches Analysis to connect privilege scope with real-world incident patterns.

What this signals

Blended Identity will push IAM programmes toward request-time policy evaluation rather than one-time onboarding decisions. Once agents are treated as identity-bearing actors, the old assumption that provisioning defines the access boundary no longer holds. Teams that keep relying on shared secrets or inherited service accounts will find their audit trails too coarse to support compliance or containment.

Standing privilege is becoming a design smell for agentic systems. As agent use grows, the operational risk is not just unauthorised access, but unrecoverable ambiguity about which user and which agent caused it. Programmes should prepare for a governance model where revocation, attribution, and conditional policy enforcement sit closer to the MCP boundary.

With 68% of organisations unable to distinguish agent from human activity, the reporting gap is already large enough to distort policy decisions. That means IAM, GRC, and security operations need a common view of agent identity before production scale turns that blind spot into normal operations.

For practitioners

• Classify agents as identity-bearing actors Create an explicit inventory of AI agents, the users they represent, and the systems they can reach. Do not leave agents buried inside shared service accounts or generic application identities.
• Bind authorisation to the user-agent-resource tuple Require policy decisions to evaluate the authenticated user, the specific agent instance, and the target resource on every request. Reject any design that authorises the agent once and reuses that decision across users or sessions.
• Eliminate reusable downstream secrets Use credential exchange or other ephemeral access patterns so the agent never stores direct credentials for MCP servers or enterprise systems. This reduces blast radius when an agent behaves outside its intended scope.
• Instrument dual attribution in logs Capture who the user was, which agent acted, which resource was accessed, and what policy decision was made. Feed those events into SIEM and compliance workflows so audit teams can separate legitimate agent use from scope drift.

Key takeaways

• AI agent governance fails when teams collapse user identity and workload identity into a single access model.
• The evidence shows the problem is already live, with most teams reporting agents in testing or production and many seeing excess access.
• Per-request policy, ephemeral credentials, and dual attribution are the controls that make agent access governable rather than merely observable.

Key terms

• Blended Identity: A blended identity model evaluates the human user and the AI agent together when making an access decision. It is designed for cases where the agent acts on behalf of a person but still needs its own governance boundary, so authorisation can be scoped to the exact request context.
• MCP Authorization Server: An MCP Authorization Server is the control point that issues access tokens for Model Context Protocol requests under policy. It sits between authentication and downstream tool access, allowing organisations to apply identity-aware decisions before an agent reaches a server or enterprise system.
• MCP Identity Gateway: An MCP Identity Gateway validates tokens and exchanges credentials at request time so an agent does not hold reusable downstream secrets. In practice, it becomes the policy enforcement layer for agent-to-tool traffic and the place where attribution, revocation, and boundary control are enforced.
• Request-time Authorisation: Request-time authorisation is the practice of checking policy at the moment an action is attempted rather than only at login or provisioning. For AI agents, this matters because identity context and tool choice can change during a session, so earlier decisions may no longer be valid.

Deepen your knowledge

AI agent identity governance and blended identity are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are moving agents from testing into production, that governance baseline is worth formalising early.

This post draws on content published by Aembit: IAM for Agentic AI and the Blended Identity model. Read the original.