AI agent identity governance is lagging behind enterprise control

At a glance

What this is: This is an Onyx analysis arguing that AI security evaluations are asking the wrong questions while agent identity sprawl, invisible provisioning, and weak runtime controls create a larger governance gap.

Why it matters: It matters because IAM, PAM, IGA, and NHI teams need to evaluate AI agents as identities with attribution, control, and lifecycle requirements, not as another software surface.

By the numbers:

• As of 2024, for every 1,000 human identities in most enterprise environments, there were over 20,000 non-human identities: service accounts, API tokens, OAuth grants, webhooks, machine credentials of every description.
• Onyx data puts the median number of AI agents per enterprise at over 1,000, and between 80 and 90 percent of those agents were invisible to security teams before they were discovered.
• 68% of organisations do not know how to fully address NHI risks.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Onyx's analysis of the five evaluation questions for AI security vendors

Context

AI agent identity governance is the discipline of controlling which autonomous or semi-autonomous software identities can act, what they can reach, and how those actions are attributed back to owners and sessions. The article argues that many teams are still evaluating these systems with the wrong lens, which leaves the core governance gap untouched.

The operational problem starts well before agent deployment. Enterprises already have a large non-human identity base, weak offboarding, and limited visibility into service accounts, then add AI agents through fast, low-friction provisioning paths that bypass normal review. That combination turns AI agent identity into a scale problem, not just a tooling problem.

For IAM and NHI programmes, the relevant question is whether the organisation can trace action to actor, constrain action at runtime, and preserve accountability across tool use, session boundaries, and handoffs. The starting position described in the article is typical, not exceptional.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents create new risk in non-human identity management?

A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts. They can connect quickly, persist across teams, and accumulate permissions that are hard to review. That combination increases the chance of unnoticed access drift and credential exposure.

Q: What do security teams get wrong about AI agent and NHI monitoring?

A: They often treat monitoring as a logging problem instead of an identity governance problem. More telemetry does not help if the programme cannot tell which behaviour is expected, who owns the identity, or what an anomaly means in context. Monitoring must be tied to identity semantics, not raw event count.

Q: How do security teams decide whether an AI workload is ready for production?

A: Use a governance test, not a marketing test. The workload is ready only if its models, dependencies, data sources, runtime controls, and resource limits are known, approved, and continuously monitored. If any of those elements are opaque, the deployment is still experimental from a security perspective.

Technical breakdown

Identity attribution at runtime across AI agent sessions

Runtime attribution means being able to identify which agent, in which session, took which action and which human, workload, or workflow initiated it. In AI agent environments, a single session can span reads, writes, tool calls, and API requests across multiple systems. If the control plane only records that a session occurred, it does not provide usable identity evidence. The useful model is session-bound attribution that preserves action lineage, tool boundary events, and the initiating identity. That is the difference between a log and an accountability chain.

Practical implication: require session-level evidence that ties every tool call and downstream action to an initiating identity before approving production use.

Runtime control versus detection-only enforcement

Detection tells you a policy boundary was crossed after the fact. Runtime control blocks, masks, or redirects the action at the moment the agent is about to execute it. That distinction matters more for AI agents because decisions are made and executed inside a single session window, often before a human can intervene. A useful control architecture therefore needs enforcement at the action boundary, not just telemetry after the event. In practice, that means policy evaluation must sit close to the tool invocation point or the action cannot be meaningfully governed.

Practical implication: test whether policy violations can be stopped mid-session, not merely alerted after the data has moved.

Autonomous action boundaries and human review gates

When an agent operates without human oversight, governance depends on knowing where human review is mandatory and what happens while that review is pending. The technical issue is not whether a review policy exists, but whether the system can pause execution, preserve state, and route the action to a reviewer before the agent continues. Without a clear escalation mechanism, autonomous behaviour collapses the old assumption that a person can always approve the next step before it occurs. That assumption is valid for many IAM workflows, but not for independent agent execution.

Practical implication: define which action classes require pre-execution review and verify that the agent cannot proceed until the review decision is resolved.

Threat narrative

Attacker objective: The objective is to abuse agent credentials and runtime access to move through connected systems while preserving plausible administrative normality.

1. Entry occurs when engineering teams provision AI agents through informal channels and connect them to production systems with credentials and tool access.
2. Escalation happens when the agent is granted broad access across systems, allowing chained actions that extend far beyond the original user intent.
3. Impact follows when a compromised or misused agent can read, write, and exfiltrate data across multiple surfaces without a stable human review point.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent security is an identity governance problem before it is a threat detection problem. The article correctly shifts the evaluation lens away from alert quality and toward attribution, control, and accountability. That is the right move because agents are being provisioned into production like ordinary software, while their behaviour has identity consequences that conventional app security does not model well. Practitioners should treat agent evaluation as a governance exercise, not a feature comparison.

Session-bound attribution is the named gap that most AI security teams still miss. If a team cannot prove which agent, which session, and which initiating identity produced a given action, it cannot govern that action after the fact. This is more than logging completeness. It is the difference between reconstructing behaviour and merely recording activity. The practical conclusion is that attribution chains belong in the control model, not the audit wishlist.

Autonomous action boundaries collapse the old assumption that access persists long enough to be reviewed. That assumption was designed for human-paced IAM and many NHI workflows. It fails when an agent can acquire, combine, and use privileges inside a single runtime span before any access review cycle begins. The implication is not simply stronger review. It is that review cadence no longer describes the risk window for autonomous systems.

Identity sprawl is now the AI agent control problem as much as the NHI control problem. The article’s 20,000-to-1,000 identity ratio shows that most enterprises are already operating with a large non-human base before agent adoption accelerates it further. Once the agent population grows into the thousands, unmanaged onboarding and invisible discovery become structural governance defects. Practitioners should re-evaluate whether their identity programme can absorb another identity class without a unified lifecycle model.

Agent evaluation criteria should be aligned to OWASP-NHI and zero-trust principles, not generic software procurement checklists. The relevant questions are whether access is bounded, whether tool use is attributable, and whether enforcement happens at runtime. That maps cleanly to how identity and privilege should be governed across machine and autonomous actors. Security teams should use identity controls to decide deployment readiness, not just integration convenience.

From our research:

• 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.
• For lifecycle context, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding controls that reduce hidden access.

What this signals

Session-bound attribution is becoming the control line for AI agent governance. As agent populations grow, teams will need a single view of human, workload, and agent-initiated actions across tool boundaries. The practical shift is from asking whether an alert fired to asking whether the organisation can prove what the agent did, who authorised it, and where the session ended.

Identity sprawl is now a programme design problem, not a tooling gap. With over 20,000 non-human identities per 1,000 human identities in the source article’s benchmark, AI agents are joining an already crowded machine-identity estate. That means discovery, ownership, and offboarding need to be treated as core governance workflows, not ancillary hygiene.

The teams that adapt fastest will align AI agent controls with established NHI lifecycle discipline and zero-trust enforcement, then extend those controls to runtime decision-making. That is the path from partial observability to defensible accountability.

For practitioners

• Map every agent to an owning identity and session model Require each AI agent to be bound to an initiating user, workload, or workflow identity, with session-level records for all tool calls and downstream actions. If you cannot attribute an agent action back to a specific initiator, the agent is not ready for production use. Use the Ultimate Guide to NHIs and the NHI Lifecycle Management Guide to align ownership, provisioning, and offboarding.
• Test for enforcement at the action boundary Run a live policy-violation scenario and verify that the system can block or mask the action before data leaves the approved boundary. An alert after the fact is evidence of monitoring, not control. Tie the test to tool invocation points and confirm the control follows the agent across surfaces.
• Define pre-execution review gates for high-risk actions List the action classes that require human approval, then confirm the agent session pauses until the reviewer responds. If the session continues while the review is pending, the review gate is cosmetic. Document which actions are subject to mandatory escalation and who can override them.
• Consolidate agent and NHI discovery into one governance view Inventory AI agents, service accounts, API keys, OAuth grants, and other machine identities in the same programme so that hidden access is not treated as a separate problem. Use the 52 NHI Breaches Analysis to pressure-test the discovery and offboarding assumptions that usually fail first.

Key takeaways

• AI agents should be governed as identities with runtime consequences, not as ordinary software integrations.
• The biggest gap is not alerting quality but the ability to attribute, constrain, and review agent actions across sessions.
• Enterprises that already struggle with NHI visibility and lifecycle control will need a unified model before agent sprawl gets worse.

Key terms

• Session-bound attribution: Session-bound attribution is the ability to link every agent action to the specific session and initiating identity that caused it. For autonomous and semi-autonomous systems, this is the minimum evidence needed to investigate misuse, reconstruct behaviour, and assign accountability across tool calls and downstream systems.
• Action boundary enforcement: Action boundary enforcement means blocking, masking, or redirecting a harmful action at the moment it is about to occur. For AI agents, this control matters because post-event alerts do not prevent damage and do not meaningfully constrain an agent that can move through systems in a single session.
• Autonomous action boundary: An autonomous action boundary is the point at which an AI agent may act without a human approval step. In governance terms, this boundary determines whether oversight is preventive or merely observational, and whether a policy can interrupt execution before the agent completes the next step.
• Identity Sprawl: Identity sprawl is the uncontrolled growth of identities, entitlements, and credentials across an environment. For NHIs, it usually appears when automation creates accounts faster than governance teams can inventory, review, and remove them. The result is hidden access, weak accountability, and a wider attack surface.

What's in the full article

Onyx's full article covers the operational detail this post intentionally leaves for the source:

• How Onyx frames runtime attribution across human, workload, and agent-initiated actions.
• The vendor's five evaluation questions in their original wording, including demonstration prompts.
• Operational examples for action-boundary enforcement and human-review escalation paths.
• Onyx's discussion of cross-platform coverage across SaaS, cloud, coding, and MCP-related surfaces.

👉 Onyx's full post covers runtime attribution, control boundaries, and cross-platform coverage in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 or identity security programme, it is worth exploring.