AI agent governance is failing where teams lack ownership

At a glance

What this is: This is a governance analysis of AI agent and unapproved tool risk, showing that organisations are treating autonomous access and sanctioned use as separate issues when they are operationally linked.

Why it matters: It matters because IAM, security, and legal teams now have to govern AI agents, shadow AI, and human access patterns as one control plane rather than as isolated policy problems.

By the numbers:

• 61% of organizations report encountering unsanctioned or unmonitored use of AI tools by employees.
• 97% of these breaches involve a complete lack of basic access controls.

👉 Read JumpCloud's analysis of AI governance roles, risk, and shadow AI

Context

AI agent governance is the discipline of deciding who or what may use tools, data, and credentials, under what approval model, and with what accountability. The primary problem here is not AI capability itself, but the fact that organisations are adopting autonomous and semi-autonomous tools faster than they can define ownership, sanctioned use, and control boundaries.

That gap is now visible in everyday work patterns. Employees bypass approved channels, security teams adopt the same tools they are meant to govern, and legal teams are asked to create policy after the fact. For practitioners, the issue is no longer whether AI will be used, but whether AI agent identity, access, and usage can be governed before exposure becomes normalised.

Key questions

Q: How should security teams govern AI agents that can access company tools and data?

A: Security teams should treat AI agents as governed identities, not as informal automation. That means assigning ownership, constraining permissions to task scope, logging tool use, and reviewing access on a defined cadence. If the agent can act without visibility or accountability, the organisation has created a shadow identity problem rather than an AI productivity gain.

Q: Why do unsanctioned AI tools create so much identity risk?

A: Unsanctioned AI tools bypass the directory, policy, and audit paths that make identity governance work. Once users move outside approved access routes, security teams lose visibility into who used what, which credentials were involved, and whether data handling stayed within policy. That turns routine adoption into unmanaged entitlement expansion.

Q: What do teams get wrong about least privilege in AI workflows?

A: Teams often apply least privilege only at account creation, then forget that AI workflows can call multiple tools and inherit broader access through tokens or delegated permissions. Least privilege has to be enforced at runtime as well as provisioning time, otherwise the effective blast radius can be much wider than the stated role.

Q: Who is accountable when an AI agent or unapproved tool causes a breach?

A: Accountability should sit with the business owner of the workflow, the technical custodian of the identity path, and the legal or compliance function that approved usage boundaries. If those roles are not defined up front, incident response becomes a debate about ownership instead of a containment exercise.

Technical breakdown

Shadow AI and unsanctioned access paths

Shadow AI appears when employees use unapproved tools or services outside governed procurement, identity, and logging paths. The technical problem is not just discovery. It is that the organisation loses the identity signal that tells it who accessed what, through which account, and under which policy. Once a tool sits outside directory-backed control, normal recertification, monitoring, and audit trails stop seeing it. That makes risk assessment reactive and incomplete. Practical implication: build sanctioned routes for AI tool usage so identity, logging, and policy enforcement stay attached to the activity.

Practical implication: require all AI tools to pass through approved identity and logging controls before users can adopt them.

AI agent identity and least privilege

The article treats each automated agent as an identity with permissions, not as a feature inside an application. That matters because AI agents can invoke tools, move data, and trigger actions on behalf of a user or team. Least privilege in this context means constraining the agent to the smallest usable scope, with explicit ownership and reviewable entitlements. If the agent can reach production systems, customer data, or admin APIs, the access model has already become a governance problem. Practical implication: define agent identities separately from human users and bind them to task-scoped permissions.

Practical implication: assign each AI agent a distinct identity with task-scoped permissions and named ownership.

Token management, logging, and blast-radius control

The Drift example in the source article shows why token handling and access controls matter as much as model behaviour. When tokens are stolen or misused, an attacker does not need to defeat the AI itself. They inherit the permissions attached to the token and can operate inside trusted workflows. Logging helps after the fact, but blast-radius control determines how much damage those credentials can do during the window of abuse. Practical implication: reduce token scope, tie it to monitored sessions, and treat access as a bounded runtime condition rather than a standing entitlement.

Practical implication: minimise token scope and session duration so a stolen credential cannot operate broadly across workflows.

Threat narrative

Attacker objective: The objective is to turn uncontrolled AI usage into a durable access path that reaches sensitive data, privileged workflows, or regulated systems without timely detection.

1. Entry begins when employees or attackers use unsanctioned AI tools or compromise token-managed workflows that sit outside normal control paths.
2. Credential access or abuse occurs when those tools inherit permissions through tokens, app grants, or weak access control rather than through explicit governance.
3. Impact follows as unmanaged applications expand breach cost, expose data, and create compliance failures that are difficult to trace or contain.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Shadow AI is not a usage problem, it is an identity problem. When employees adopt unmonitored tools, the organisation loses the ability to tie access, ownership, and auditability to a governed identity path. That is why the issue sits across IAM, security, and legal at the same time. Practitioners should treat unsanctioned AI use as a control-plane failure, not a training gap.

AI agents must be governed as identities before they are governed as tools. The article is right to frame automated programs as entities with permissions, owners, and audit obligations. That position aligns with OWASP-NHI and NIST CSF thinking, because the core failure mode is unmanaged entitlement, not model sophistication. For practitioners, the decisive question is whether each agent has a distinct identity and accountable lifecycle.

Credential-based trust is too brittle for AI workflows that move faster than human review. The source article’s examples show that token management failures and weak access controls let automated or semi-automated systems act inside trusted boundaries. That exposes a broader governance gap: access models built for stable human sessions do not automatically contain runtime AI behaviour. The implication is that current identity governance assumptions need re-scoping around runtime use, not just provisioning.

Cross-functional governance is now a control requirement, not a committee preference. IT can discover and integrate, security can constrain and monitor, and legal can define usage boundaries, but none of those functions works alone. The organisations that separate policy from identity and accountability will keep producing blind spots. Practitioners should align ownership, access review, and acceptable use as one operating model.

AI agent governance is creating a new identity blast radius. This named concept describes how a single unmanaged tool, token, or approval path can expand impact across data, systems, and policy domains at once. The practical conclusion is that teams need to think in terms of where identity-driven damage can spread, not just whether a tool is approved.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks.
• For a broader control baseline, see Ultimate Guide to NHIs for the lifecycle and governance patterns that reduce unmanaged identity exposure.

What this signals

Identity blast radius is the right way to think about uncontrolled AI usage. When a tool is adopted outside governed identity paths, the risk is not limited to the application itself, because access, data movement, and compliance obligations travel with the identity that touches it.

The operating model needs to shift from approving tools to governing usage paths. That means procurement, directory integration, logging, and acceptable use all have to line up before adoption becomes normalised, especially where AI is connected to production data or regulated workflows.

NIST Cybersecurity Framework 2.0 remains a useful anchor for this work because the governing and protecting functions map cleanly to ownership, identity enforcement, and monitoring. Teams that can link policy to identity signals will be better placed to detect shadow AI before it becomes an incident.

For practitioners

• Define a sanctioned AI access path Require employees to use approved AI tools that inherit directory-backed identity, logging, and policy enforcement before they can touch company data.
• Assign every AI agent a named owner Register each automated agent with a business owner, technical custodian, and review cadence so accountability survives turnover and reuse.
• Restrict token scope and lifetime Limit app tokens and delegated credentials to the narrowest task scope possible, and remove standing access wherever sessions can be made shorter.
• Unify IT, security, and legal governance Create one approval and review model for acceptable use, data handling, and identity controls so policy does not drift away from actual usage.

Key takeaways

• Unapproved AI use is now an identity governance problem because it breaks ownership, visibility, and auditability at the point of access.
• The evidence points to scale, not edge cases: 61% encounter unsanctioned AI use, and unmanaged applications add $670,000 on average to breach cost.
• The practical response is to govern AI agents, tokens, and acceptable use as one control model across IT, security, and legal.

Key terms

• Shadow AI: AI tools or agents used outside approved governance, identity, and logging controls. Shadow AI becomes an identity risk when users or systems can access data and actions without a sanctioned account path, leaving security teams unable to prove ownership, review access, or trace impact after the fact.
• Identity blast radius: The amount of damage an identity can cause if its access is misused, overextended, or stolen. For AI workflows, the blast radius is shaped by token scope, tool permissions, data access, and how quickly the organisation can detect and revoke that access.
• Agent ownership: The assignment of accountable business and technical responsibility for an AI agent or automated workflow. Ownership should include approval authority, review cadence, and a clear connection to the identity that the agent uses, so that access and liability do not disappear when the workflow scales.

Deepen your knowledge

AI agent governance and shadow AI controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is trying to govern automated access alongside human and service identities, this is a practical next step.

This post draws on content published by JumpCloud: The AI Mandate, securing autonomous agents before they secure you. Read the original.