AI agent control planes fail when identity visibility is missing

At a glance

What this is: This case study argues that AI agent control planes fail when teams cannot see the API keys, OAuth tokens, and service accounts behind those agents.

Why it matters: IAM, IGA, and PAM teams need identity-layer visibility for AI agents because policy and monitoring do not enforce access when the underlying non-human identities are unknown.

By the numbers:

• Within 1.5 months, the enterprise built approximately 400 GPTs, 240 of them published and the rest in draft.
• The organisation gave enterprise licenses to 200 developers within a broader engineering organisation of thousands.
• Within the first week, Astrix uncovered 250+ GPTs active in the environment.
• About 10% of the GPTs had direct API access to external systems such as BigQuery and Atlassian.

Context

AI agent access visibility is the practical control problem behind many control-plane discussions. In this case, the issue was not whether the organisation had policies or orchestration, but whether it could see the identities and permissions actually powering its agents.

The article centres on non-human identities such as API keys, OAuth tokens, and service accounts because those are the access paths AI agents use to reach data and systems. When those identities are opaque, ownership and enforcement break down even if governance language exists.

For IAM teams, the point is straightforward: agent governance starts where access is granted, not where activity is observed. A control plane without identity visibility is only a monitoring layer with limited enforcement value.

Key questions

Q: What breaks when AI agents are given access without identity governance?

A: What breaks is accountability. The organisation may see actions, logs, and alerts, but it cannot reliably tie them to a governed identity with clear scope and revocation. That creates uncontrolled blast radius, especially when agents can reach sensitive systems through shared tokens, delegated service accounts, or broad API access.

Q: When does AI agent access create more risk than it reduces?

A: AI agent access creates more risk when the business benefit depends on broad permissions, weak ownership, or uncontrolled tool invocation. At that point, productivity gains are offset by a larger identity blast radius, harder audits, and a higher chance of unintended data movement. If the agent touches sensitive systems, runtime policy and strong revocation become mandatory, not optional.

Q: How do security teams know if agent governance is actually working?

A: It is working only if the team can answer three questions quickly for any agent: what it can reach, what it did recently, and whether that behaviour matches intent. If any of those answers require manual reconstruction, governance exists on paper but not in operations.

Q: Should organisations treat AI SOC agents like governed identities?

A: Yes, because the practical risk is delegated access, not just model output. If an AI agent can read evidence, prepare actions, or trigger connected tools, it needs scoped permissions, defined task boundaries, and revocation when the workflow ends. That is the identity control model SOC teams already use for other non-human actors.

Technical breakdown

Why control planes fail at the identity layer

An AI agent control plane can inventory agents, monitor activity, and apply policy, but those functions do not by themselves define or constrain access. In this pattern, the real security boundary is the non-human identity behind the agent, such as an API key, OAuth token, or service account. If that identity is hidden, privilege accumulates outside effective governance and the control plane becomes descriptive rather than authoritative. The article shows that the organisation could not answer a basic question: what do the GPTs have access to? That is an identity visibility failure, not a workflow problem.

Practical implication: map every agent to the NHI it uses before treating the control plane as enforceable.

How agent permissions become opaque

AI agents often inherit access through integrations, shared data sources, and credentials assigned during development. Because the access path is indirect, teams may know the agent exists but still not know which systems it can reach, what scopes were granted, or who owns the underlying identity. That opacity is why policy checks alone miss risk. The article’s examples, including admin-level scopes and direct API access to external systems, show how agent access can expand quickly once credentials are attached to a published or even draft GPT. Visibility has to cover both the agent and the credentialed path it uses.

Practical implication: inventory agent-to-identity-to-system relationships, not just agent counts.

Why monitoring is not the same as control

Monitoring tells you what an agent did, but control depends on whether the agent should have had the access in the first place. In identity terms, that means enforcing ownership, scope, and revocation at the credential layer. The article’s central lesson is that risk remained hidden until the organisation could inspect identities, permissions, and connected systems together. For AI agents, the governance question is not only whether activity is logged, but whether access is governed at issuance and continuously attributable after deployment.

Practical implication: tie AI agent governance to access issuance and revocation, not just runtime observation.

NHI Mgmt Group analysis

Identity visibility is the control plane, not a supporting feature. A governance model for AI agents fails if it starts with orchestration and monitoring but cannot enumerate the non-human identities that actually grant access. The article shows that access control was already breaking before any malicious activity was needed. Practitioners should treat identity inventory as the control plane's foundation, not its sidecar.

Control-plane language often masks a trust gap in delegated access. AI agents do not consume permissions abstractly; they inherit them through credentials, tokens, and service accounts. When those objects are unknown or poorly owned, the programme cannot assign accountability or bound access. The implication is that agent governance must be anchored in identity ownership and scope, not in dashboards alone.

Agent control without NHI visibility creates hidden privilege drift. Once developers can connect agents to production systems and shared data sources, permissions can expand faster than review cycles can catch up. That is the same structural problem seen in other non-human identity programmes, except the agent layer adds more rapid creation and more dynamic reuse. Practitioners need a model that tracks who can act, through which identity, and against which system.

AI agent governance is converging with NHI governance. The article makes clear that AI agents are not a separate control class once they operate through API keys, OAuth tokens, and service accounts. That means NHI governance patterns now apply directly to agent fleets, including ownership, discovery, and access scoping. Security teams should stop treating agent governance as an adjacent AI problem and manage it as identity governance with a different runtime subject.

Identity visibility gap: the missing named concept for agent governance. This is the failure mode that matters here. Teams may believe they have control because they can see the agent, but the real risk sits in the underlying access path and its unresolved ownership. Practitioners should frame agent programmes around identity visibility gap, because that is where governance either becomes enforceable or stays performative.

From our research library:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Agentic AI Identity Guide

What this signals

Identity visibility gap: AI agent programmes now fail or succeed on the same control question that governs every NHI estate, namely whether access can be mapped back to an owner, a scope, and a revocation path. If that mapping is incomplete, the control plane is only descriptive.

The practical shift for security teams is to move governance left, before agent deployment, and insist on credentialed access inventory for every GPT, assistant, or agentic workflow. That approach aligns AI agent oversight with established NHI governance rather than creating a separate policy universe.

For practitioners

• Build an agent-to-identity inventory Catalogue every AI agent alongside the API keys, OAuth tokens, service accounts, and integrations it uses. Include draft agents and developer-built prototypes, because hidden access often appears before formal rollout.
• Reconcile agent access with system ownership Assign a business and technical owner to each credentialed access path, then remove any agent connections that cannot be attributed to a responsible team.
• Scope agent privileges to least access Review whether agents have admin-level or broad read access to production data stores, collaboration tools, and analytics platforms, and reduce scopes that exceed the task.
• Separate sensitive data from training inputs Prevent publicly accessible GPTs and internal agent workspaces from consuming sensitive files or production data unless the data path is explicitly approved and monitored.
• Require revocation paths for every agent credential Treat agent credentials like other NHIs by defining how they are disabled when the agent is retired, changed, or no longer needed.

Key takeaways

• AI agent control planes fail when organisations can see activity but not the non-human identities that authorize access.
• The case study showed how quickly agent sprawl can outpace governance, with hundreds of GPTs and direct links to sensitive systems appearing in a short window.
• Enforceable control starts with inventory, ownership, and revocation of the credentials behind each agent, not with monitoring alone.

Key terms

• AI Agent Identity Control Plane: The AI Agent Identity Control Plane is the governance layer that creates, manages, monitors, and revokes identities used by autonomous AI agents. It coordinates authentication, authorization, policy enforcement, credential lifecycle, and auditability across tools, data, and services, so agent actions remain attributable, constrained, and continuously governed.
• Identity Visibility: Identity visibility is the ability to see which identities exist, what they can access, and how those access paths relate across systems. In NHI programmes, it means correlating service accounts, tokens, certificates, and agents into one operational view so governance decisions are based on evidence, not assumptions.
• Delegated access path: A delegated access path is the chain of identities, tokens, connectors, and approvals that lets one system act through another. It becomes a governance concern when the path outlives the original approval or can be reused for actions beyond the intended business purpose.
• Agent-to-Identity Mapping: Agent-to-identity mapping is the process of linking each AI agent to the specific NHI that authenticates it and the systems it can reach. For governance, this is the core inventory problem, because every later control depends on knowing which access path belongs to which agent.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.