Notifications
Clear all
Topic starter
24/07/2026 4:08 pm
TL;DR: AI initiatives often stall when agents move from demo to production because they need access to real systems, data, and tools, according to ConductorOne. The governance problem is not model quality but whether access can be granted, observed, and revoked fast enough without creating standing privilege.
NHIMG editorial — based on content published by ConductorOne: Why AI transformation stalls
Questions worth separating out
Q: How should security teams limit the risk from AI agents that have access to production systems?
A: Security teams should scope every agent to the smallest set of actions and resources needed for its task, then remove standing privilege wherever possible.
Q: Why do AI agents create access problems that human approval processes do not solve well?
A: AI agents can inherit credentials, chain actions, and execute at machine speed, while human approval models assume slower, request-based behaviour.
Q: What breaks when AI agents are given broad standing access?
A: Broad standing access breaks governance because the agent can move from one task to another without a fresh authorization check.
Practitioner guidance
- Define agent identity before deployment Assign each production AI agent an explicit identity, owner, and access boundary before it can interact with internal systems or customer data.
- Replace tickets with policy gates Use policy-based approval for routine agent actions so low-risk requests flow automatically while sensitive actions still trigger human review.
- Time-bound every agent permission Issue access for a specific workflow window and revoke it automatically when the task completes, rather than leaving credentials attached to the agent.
What's in the full article
ConductorOne's full blog covers the operational detail this post intentionally leaves for the source:
- How policy-based approval is applied to agent requests in real workflows.
- How time-bound permissions are structured for AI agents that need production access.
- How visibility is maintained over what agents touched, changed, or queried.
- How teams reduce approval bottlenecks without creating unmanaged shadow AI access.
👉 Read ConductorOne's blog on governed AI agent access and stalled transformation →
AI agent access governance: why transformation stalls at the gate?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
24/07/2026 4:14 pm
AI agent access is now the control point that determines whether transformation proceeds. The article describes a common failure mode where model capability is available but governed access is not, and the programme stalls at production readiness. That is not a tooling problem alone. It is a sign that identity governance has not been extended to autonomous or semi-autonomous actors in a way the business can use safely.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Who should own governance when AI agents cross identity, access, and application teams?
A: Ownership should sit with identity governance and security architecture, with application and platform teams accountable for implementation detail. Cross-functional ownership is necessary because agent identity touches federation, authorization, lifecycle, and audit evidence at the same time. If no single team owns the model, control gaps usually appear between systems rather than inside them.
👉 Read our full editorial: AI transformation stalls at the access layer for AI agents
