Notifications
Clear all
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.
NHIMG editorial — what this means for AI and NHI governance
By the numbers:
- 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.
Questions worth separating out
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.
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.
Q: What breaks when AI agents are treated like normal workloads?
A: User context disappears, per-request scoping disappears, and revocation becomes blunt.
Practitioner guidance
- Classify agents as identity-bearing actors Create an explicit inventory of AI agents, the users they represent, and the systems they can reach.
- 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.
- 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.
What's in the full announcement
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- Pricing and feature tier differences for Starter, AI Teams, and Enterprise deployments
- Implementation details for the MCP Authorization Server and MCP Identity Gateway
- Examples of how Blended Identity enforces per-user scoping inside real enterprise workflows
- Deployment paths for teams that want no-code, CLI, or SDK integration
👉 Read Aembit's analysis of IAM for Agentic AI and Blended Identity →
AI agent identity governance: what changes when user and agent split?
Explore further
06/06/2026 4:17 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent identity governance needs blended identity controls now
