Notifications
Clear all
Topic starter
06/06/2026 2:30 am
TL;DR: AI access management separates agent entitlements from human access, brokers MCP connections through a vault, and enforces real-time policy on read, write, and delete actions, according to ConductorOne. The deeper issue is that access review, least privilege, and approval workflows assume access is stable enough to govern after the fact, which agentic behaviour breaks.
NHIMG editorial — what this means for IAM teams
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
Questions worth separating out
Q: How should security teams govern AI agents that access enterprise tools?
A: Security teams should govern AI agents with a separate entitlement model, runtime policy enforcement, and full logging of tool calls.
Q: Why do AI agents create more identity risk than normal API automation?
A: AI agents create more risk because their action path is shaped at runtime, not fixed in advance.
Q: What breaks when agent access is treated the same as human access?
A: When agent access is treated the same as human access, organisations inherit a false sense of safety from browser permissions and access reviews.
Practitioner guidance
- Separate agent entitlements from human entitlements Define a distinct policy set for agent actions in each connected application so browser access does not automatically translate into agent access.
- Broker all MCP connections through a control plane Do not let agents connect directly to enterprise tools with user-managed credentials on endpoints.
- Log every tool call with approval context Send request bodies, responses, approvals, and denials into SIEM and DLP workflows so reviewers can reconstruct what the agent tried to do and why the action was allowed or blocked.
What's in the full announcement
ConductorOne's full blog covers the operational detail this post intentionally leaves for the source:
- How the MCP gateway brokers authentication, entitlement checks, and inline policy decisions across connected tools
- How shared credentials and personal OAuth tokens are stored and used inside the platform's vault model
- How self-approval flows work in Slack or Teams for write actions and how those approvals are recorded
- How service principals are reviewed, owned, and tied into lifecycle governance for autonomous enterprise agents
👉 Read ConductorOne's blog on AI access management for agents and MCP governance →
AI access management for agents: what changes for IAM teams?
Explore further
06/06/2026 4:12 am
AI access management is really NHI governance applied to a faster actor. The article’s core contribution is not the MCP gateway itself, but the separation of agent entitlements from human entitlements. That is a familiar identity principle in a new runtime shape: when the actor can call tools directly, the security model has to govern the action path, not just the person who initiated it. Practitioners should read this as NHI governance moving closer to live authorisation.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage. That pattern shows why identity governance has to cover both access paths and credential handling.
A question worth separating out:
Q: Who should be accountable for AI agent approvals and audits?
A: Accountability should sit with the human owner of the agent path, the application owner, and the identity governance process together. The agent cannot be the sole accountable subject because it is not a governance endpoint. Teams should tie approvals, logs, and access reviews to the person or team responsible for the agent’s use.
👉 Read our full editorial: AI access management exposes the gap between agents and human IAM
