AI agent identity governance needs blended identity controls now

At a glance

What this is: Aembit’s analysis argues that AI agent governance now needs blended identity controls that evaluate both the human user and the agent together at request time.

Why it matters: IAM and NHI teams need to treat agentic access as a distinct identity problem because shared credentials and workload-only controls do not preserve user-level accountability or limit overbroad access.

By the numbers:

• 80.9% of teams have AI agents in active testing or production, yet only 21.9% treat them as independent, identity-bearing entities.
• 68% of organizations can’t clearly distinguish between agent and human activity.
• 74% say agents often end up with more access than they need.
• 97% of enterprise security leaders expect a material AI agent-driven security incident within the next twelve months.

Context

AI agent identity governance is the problem of deciding who or what is allowed to act, under which context, and with which privileges when software can initiate actions on its own. The old split between human identity and workload identity breaks down once a single request can combine user intent, agent action, and downstream system access.

In this article, Aembit argues that many teams are already deploying AI agents while still relying on shared API keys or inherited service accounts to authorize them. That leaves access decisions too coarse for machine-speed, context-sensitive activity and makes auditability, revocation, and least privilege difficult to sustain.

The practical question is not whether agents can call tools, but whether identity controls can preserve per-user scoping and attribution when the agent executes on the user’s behalf. For agentic AI, governance has to bind identity, policy, and resource access in the same decision path.

Key questions

Q: What breaks when AI agents rely on shared service accounts or API keys?

A: Shared credentials hide which actor actually performed the action, make revocation coarse, and blur accountability across humans and machines. They also let multiple agents inherit the same authority, which increases blast radius and makes incident investigation much harder when something goes wrong.

Q: Why do AI agents on Kubernetes create a different identity risk than normal workloads?

A: Because they can combine tool use, internal connectivity, and credential access in response to a malicious prompt. That makes their behaviour runtime-dependent, not just configuration-dependent. The same service account can be safe in one session and abusive in the next if the agent is allowed to act on untrusted instructions.

Q: How can teams tell whether agentic access controls are actually working?

A: Look for evidence that every privileged action is logged with actor type, target resource, and policy decision, and that denied requests are being blocked before execution. If you can only see the login and not the downstream action, the control is too weak for agentic use.

Q: When should organisations use per-user scoping instead of workload-only identity for agents?

A: Use per-user scoping whenever the same agent platform can reach different systems or data depending on who launched the task. Workload-only identity treats every user of the agent as if they were equivalent, which is too blunt for enterprise access decisions. Per-user scoping is the safer model when accountability, segregation, or policy differences matter.

How it works in practice

Why shared API keys fail for AI agents

Shared API keys collapse distinct identities into one credential, which means the system cannot tell which user, which agent, or which purpose sits behind a given call. In agentic workflows, that is not just an audit problem. It breaks the ability to enforce least privilege because the credential represents a whole class of actors rather than a single request context. Once the same key is reused across users or sessions, revocation becomes blunt and accountability disappears. The access path may still function, but governance no longer has a stable identity boundary to control. Practical implication: replace shared credentials with per-user, per-agent authorization paths that preserve attribution at every request.

Practical implication: Replace shared credentials with per-user, per-agent authorization paths that preserve attribution at every request.

How blended identity changes authorization for MCP servers

Model Context Protocol integrates tools and data sources into agent workflows, which makes the authorization point more sensitive than a normal API integration. A blended identity model evaluates the human user and the AI agent together at request time, then decides whether that specific combination may reach the target resource. That matters because agentic access is not only about whether the agent is trusted, but whether the user, the agent, and the destination are jointly allowed under policy. This is closer to contextual, per-request access than static workload identity. Practical implication: require authorization logic that can see user context, agent context, and resource context in one decision.

Practical implication: Require authorization logic that can see user context, agent context, and resource context in one decision.

Why per-user credential isolation matters for agentic access

Per-user credential isolation prevents one user’s agent session from borrowing another user’s privileges through a shared backend identity. Without that separation, revoking access for one user can unintentionally affect others, or credentials persist longer than the session that justified them. That creates hidden over-privilege and makes post-incident analysis harder because the credential trail no longer maps cleanly to a person or a task. The governance issue is not only standing privilege, but identity collapse across multiple actors using the same automation layer. Practical implication: issue credentials that are scoped to the individual user session, not just to the agent platform.

Practical implication: Issue credentials that are scoped to the individual user session, not just to the agent platform.

NHI Mgmt Group analysis

Blended identity is the right governance response to agentic AI because user-only and workload-only models each fail a different half of the problem. A user-only model cannot bound what the agent does once it starts acting, while a workload-only model strips away the human context that should constrain the request. The field needs authorization decisions that bind human intent and machine execution together at the moment of access.

Shared credentials are not merely inefficient for agents, they erase the identity boundary that makes least privilege enforceable. When multiple users route through the same API key or service account, revocation, forensics, and policy enforcement all lose precision. That is why agentic AI is not just another workload category. It is a governance problem that exposes how much modern IAM still depends on static identity assumptions.

Access decisions for AI agents must move from provisioning-time trust to request-time context. AEMBIT’s model reflects the reality that the same agent can be appropriate in one user context and unacceptable in another. Practitioners should read that as a signal that identity policy must become more contextual, not merely more automated.

Agentic AI forces NHI governance to account for attribution, not just authentication. The ability to prove which user initiated which agent action becomes as important as proving the agent itself was authenticated. That makes audit logs, per-user scoping, and policy-bound credential exchange core governance controls, not optional telemetry.

Context-bound identity is becoming the new control plane for autonomous access. As more enterprises allow agents to query data, trigger workflows, and interact with MCP servers, the decisive question is whether the programme can still explain why a specific access happened. Without that, agent governance degrades into broad platform permissioning.

From our research library:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Context-bound identity is becoming the practical dividing line for agent governance. Teams that continue to treat agents as ordinary workloads will keep overgranting access because the policy engine never sees who is actually driving the request. The programme implication is that authorization logic has to become user-aware and resource-aware at the same time, not just service-aware.

Blended identity is the named concept practitioners should track. It describes a control model where user identity and agent identity are evaluated together before access is issued. That shifts governance from static provisioning to request-time decisioning, which is the only reliable place to bound agentic activity.

For practitioners

• Define blended authorization boundaries Map which decisions must evaluate the human user, the AI agent, and the target resource in one policy decision, especially where agents touch MCP servers or internal SaaS systems.
• Eliminate shared agent credentials Replace shared API keys and inherited service accounts with per-user credential paths so agent actions remain attributable and revocable without affecting other users.
• Require request-time policy checks Move authorization from provisioning-time assumptions to request-time checks that can inspect user context, agent context, and runtime posture before access is granted.
• Separate audit trails by user and agent Log the authenticated user, the agent that acted, the resource reached, and the policy decision so incident response can trace machine actions back to a human sponsor.
• Scope kill-switch controls to individual agents Ensure you can revoke a single agent without disrupting the underlying identity provider or rotating credentials across unrelated users.

Key takeaways

• AI agent governance fails when organisations treat agents as ordinary workloads and lose the link between user intent and machine action.
• The article’s figures show that agent use is already widespread, but most teams still cannot distinguish agent activity from human activity or keep access tight.
• Per-user scoping, request-time authorization, and attributable audit logs are the controls that matter most when user and agent identities split.

Key terms

• Blended Identity: Blended identity occurs when an autonomous system acts partly on behalf of a person and partly under its own machine authority. This creates split accountability because one actor may initiate the task while another identity performs the privileged action across different systems.
• Agentic Access: Agentic access is delegated system access granted to an AI agent or autonomous workflow so it can perform defined tasks across tools and data sources. It differs from human access because the actor can execute continuously, combine actions quickly, and amplify mistakes at scale.
• Per-User Credential Isolation: Per-user credential isolation means each user’s agent session receives credentials that are scoped to that user rather than to a shared automation layer. It preserves attribution, limits blast radius, and keeps revocation tied to the individual session instead of everyone using the same agent platform.
• 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

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 building or maturing an IAM programme, it is worth exploring.