Notifications
Clear all
Topic starter
06/06/2026 1:43 am
TL;DR: AI Access Management is generally available for all C1 customers, letting organizations govern employee AI assistants and enterprise agents through self-service provisioning, inline policy enforcement, and full audit logging across MCP-based tool access, according to ConductorOne. The operational shift is that access governance now has to follow agentic sessions in real time, not legacy ticket and review cycles.
NHIMG editorial — what this means for NHI practitioners
By the numbers:
- 78% of employees who use AI tools bring their own.
- AI Access Management provisioned access in under 60 seconds through self-service provisioning.
Questions worth separating out
Q: How should security teams govern AI agents that request enterprise tool access?
A: Security teams should govern AI agents through the same entitlement, approval, and audit model used for other identities, but with policy attached to tool actions rather than just login events.
Q: Why do AI assistants create shadow access problems for IAM teams?
A: AI assistants often move faster than formal access workflows, so users bypass the governed path when it is too slow or too hard to use.
Q: What breaks when agent access is managed in a separate governance process?
A: A separate AI governance process breaks the identity record because reviewers no longer see human access, NHI access, and agent access together.
Practitioner guidance
- Map AI tool access to explicit entitlement classes Separate read, write, destructive, and sensitive tool actions before agents are allowed to invoke them.
- Treat enterprise agents as governed service principals Assign each agent an owner, approver, and review cadence, then place its entitlements into the same certification campaign as human and machine identities.
- Remove unmanaged AI access paths from daily work Make the governed path faster than the workaround by reducing request friction, preclassifying common access profiles, and publishing the approved route for tools and data.
What's in the full announcement
ConductorOne's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step setup for registering MCP servers and turning discovered tools into requestable access profiles
- Policy examples for auto-approval, self-approval, and destructive-action denial across different tool types
- Audit logging details showing how tool calls, grants, and data classification flow into SIEM or SOAR
- Administrative workflow guidance for managing enterprise agents as service principals with owners and reviewers
👉 Read ConductorOne's blog on AI access management for enterprise agents →
AI access management for enterprise agents: are your controls ready?
Explore further
06/06/2026 2:59 am
AI access governance is becoming the control plane for shadow AI. The article shows that employees are already bringing their own AI tools, which means the problem is not adoption but unmanaged access paths. When the governed route is slower than the shadow route, security teams lose both visibility and policy leverage. Practitioners should treat this as a governance channel problem, not a tooling preference.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Should enterprise agents be treated like service accounts or like users?
A: Enterprise agents need a service-principal model with user-like governance. They should have named owners, approvers, and review cycles, but their permissions should be limited and logged like any other non-human identity. That approach preserves accountability without pretending the agent is a person.
👉 Read our full editorial: AI access management changes how enterprises govern agent access
