Topic starter
06/06/2026 2:33 am
TL;DR: AI agents are already in production, yet most enterprises still govern them with shared API keys or inherited service accounts, while 68% of organisations cannot clearly distinguish agent and human activity and 74% say agents get more access than needed, according to Aembit and Cloud Security Alliance. Existing IAM assumes one identity context at a time, but agentic access now requires per-request decisions that bind user, agent, and resource together.
Editorial analysis by NHI Mgmt Group, based on content published by Aembit: “Aembit IAM for Agentic AI Is Now Generally Available”.
By the numbers:
- 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.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: AI agent governance fails when organisations treat agents as ordinary workloads and lose the link between user intent and machine action.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
06/06/2026 4:17 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent identity governance needs blended identity controls now
This post was modified 4 days ago by NHI Mgmt Group