AI security is identity security, and blind spots are growing

At a glance

What this is: Permiso Security argues that AI security failures are really identity failures, driven by poor visibility, over-permissioning, and weak attribution across human and AI-driven access.

Why it matters: IAM, NHI, and autonomous-identity programmes all need the same shift from static entitlement review to runtime governance, because AI systems can expand the identity perimeter faster than conventional controls can observe.

By the numbers:

• Organizations lack visibility into 80% of actual AI activity because traditional tools only track licensing and static configurations.
• AI agents operate with 90% unused permissions, creating unnecessary access risk across APIs, cloud services, and data stores.
• Fewer than 40% of organizations currently govern AI agents even as they multiply across development teams and business units.
• 80% of organizations have encountered risky behaviors from AI agents including improper data exposure.

👉 Read Permiso Security's analysis of AI security challenges through an identity lens

Context

AI security is an identity problem when the system in question can authenticate, request access, and act on data or infrastructure. Once AI agents and AI-enabled workflows are allowed to use enterprise accounts, the governance question shifts from model safety to who or what is actually holding access at runtime. That is why AI security now sits squarely inside identity security, not beside it.

The article's core point is that static inventory and licence tracking are not enough for AI systems that change behaviour in session. Traditional IAM and NHI controls were built to describe access state, then review it later. AI agents and human users working through AI services need continuous visibility into authentication paths, privilege scope, and data movement, which is where lifecycle and runtime governance start to converge.

Key questions

Q: How should security teams govern AI systems that use enterprise identities?

A: Security teams should treat AI access as an identity governance problem, not a separate AI monitoring problem. The practical approach is to bind each AI action to a known identity, record the session evidence, and review granted access against observed usage. That gives you a defensible control model for both human-triggered and agent-driven activity.

Q: Why do AI agents create more risk than ordinary automation?

A: AI agents create more risk because they can select actions at runtime, use multiple tools, and move across systems with access that was granted for a broad task rather than a fixed workflow. That makes over-permissioning and poor attribution much more damaging than in scripted automation, where the path is usually known in advance.

Q: What do security teams get wrong about AI visibility?

A: They often assume licence data or static configuration data is enough to understand AI risk. In practice, the important question is what identities actually do at runtime, which services they reach, and what data they share. If you cannot observe that behaviour, you cannot govern it reliably.

Q: How can organisations reduce the blast radius of AI access?

A: They should rightsize permissions from observed behaviour, not from fear of blocking a future use case. Dedicate distinct identities for AI workloads, eliminate shared credentials, and review whether any agent truly needs broad access across APIs, cloud services, and sensitive data stores.

Technical breakdown

Why static AI inventory misses the real identity problem

Static inventory tells you an AI account exists, but not whether it is active, over-privileged, or using a personal account to reach external services. In identity terms, the problem is the difference between entitlement records and observed behaviour. If AI usage occurs through federated sign-in, personal subscriptions, or shared service credentials, the security team sees only fragments unless it correlates runtime activity, authentication events, and data access. That is why AI visibility has to be evidence-led rather than licence-led.

Practical implication: build runtime discovery that ties AI usage to authenticated identities and actual service calls, not just named licences.

Over-permissioned AI agents and the problem of unused access

The article highlights a familiar machine-identity pattern: broad access granted for convenience, then left in place because no one can prove which permissions are actually needed. For AI agents, this is more dangerous because one agent may need multiple services at once, which tempts teams to over-scope access at provisioning time. The technical failure is not simply excess privilege, but the absence of evidence-based rightsizing across APIs, cloud services, and data stores. That turns every agent into a larger blast-radius object than the task requires.

Practical implication: measure used versus granted permissions for AI agents and reduce standing access wherever the task does not prove the need.

Attribution and accountability across human and AI identities

When AI runs through human credentials or shared accounts, the audit trail becomes a delegation problem. The system may know which API was called, but not which person initiated it, which agent executed it, or which downstream service inherited the trust chain. That breaks forensic attribution because identity proof is scattered across the user, the agent, and the session. The stronger model is a unified identity graph that joins human, NHI, and AI activity into one traceable chain of custody.

Practical implication: require session-level attribution that can reconstruct who initiated an AI action, what identity was used, and what data or system it touched.

Threat narrative

Attacker objective: The attacker seeks to turn AI-enabled access into a hidden path for data exposure, privilege abuse, or infrastructure manipulation without immediate attribution.

1. Entry begins when employees use personal AI accounts or AI systems authenticate through enterprise and federated identities that security teams cannot fully see.
2. Escalation occurs when AI agents hold broad, unused permissions and can reach multiple APIs, cloud services, and data stores from a single compromised identity path.
3. Impact follows when sensitive documents, credentials, or infrastructure actions are exposed through opaque agent activity and the organisation cannot reliably attribute or contain the event.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 security has collapsed into identity governance because the runtime actor, not the model, now determines risk. The article is right to treat AI security as an identity problem, because the security outcome depends on who or what is authenticated, how much access it receives, and whether activity is visible at the moment of use. That means IAM, NHI, and AI governance can no longer be managed as separate disciplines. Practitioners should read this as a call to unify identity evidence across human and non-human actors.

Runtime visibility is the real control gap, not inventory completeness. The article's strongest practical point is that static licensing and configuration data miss the majority of AI activity. That is a control failure in the discovery layer, and it matters because access review cannot correct what monitoring never captured. The implication is that governance programmes must treat observed behaviour as the source of truth for AI identities.

Identity blast radius is now the best way to describe AI over-permissioning. AI agents often need multi-system reach, but many are granted far more access than the task can justify. That creates a blast-radius problem across APIs, cloud services, and data stores, and it is the same structural issue security teams already know from service-account sprawl. Practitioners should use that shared lens to align NHI and AI agent controls.

Attribution across human and machine identities is becoming a board-level accountability issue. When agents run through human accounts or shared service credentials, forensic certainty drops and incident response slows. This is not just a logging problem, because the organisation loses confidence in who acted, under what authority, and with what downstream effect. Security leaders should treat attribution as a governance requirement, not a technical convenience.

From our research:

• Organizations lack visibility into 80% of actual AI activity because traditional tools only track licensing and static configurations, according to the 2026 Infrastructure Identity Survey.
• Another finding in the same survey shows that only 44% of organisations have implemented any policies to manage their AI agents, even though 92% agree governance is critical to enterprise security.
• For a broader forward view, see Ultimate Guide to NHIs , 2025 Outlook and Predictions for how AI identity governance is reshaping programme priorities.

What this signals

Invisible AI activity will push identity teams toward runtime governance models. When 7% of security leaders say they do not know how often their AI systems are making autonomous changes to infrastructure, the operating assumption behind access review already looks outdated. The practical shift is toward continuous evidence, not periodic certification, because the behaviour is happening faster than review cycles can close. See also NHI Lifecycle Management Guide.

Agentic AI and NHI governance are converging around the same control plane. The next programme decision is no longer whether to manage AI separately, but how to extend identity evidence, privilege scoping, and lifecycle ownership across users, builders, agents, and service accounts. That is the governance boundary teams will have to document for audit, risk, and incident response. For a standards lens, compare with the NIST AI Risk Management Framework.

Identity blast radius is the concept that will matter most in AI rollouts. With 19% of organisations giving AI systems dramatically more access than human employees, the issue is not whether AI is adopted, but how far privilege is allowed to spread before controls catch up. Teams should prioritise evidence-led rightsizing and attribution before adoption scales further. The same pattern is discussed in OWASP Agentic Applications Top 10.

For practitioners

• Correlate AI activity to authenticated identities Tie AI service access to session evidence, federated sign-in records, and application logs so you can answer who used the system, what it touched, and whether the action was expected. Use the same identity graph approach across human and non-human identities.
• Rightsize agent permissions from observed usage Compare granted permissions with actual AI service calls, data access, and API usage to identify unused access. Shrink standing privilege where the task never proves a need for broad access across cloud services and data stores.
• Separate human credentials from AI execution paths Stop allowing AI agents to operate through personal accounts or shared credentials when a dedicated machine or agent identity can be traced and governed. The goal is a clean chain of custody for every AI action.
• Build lifecycle controls for AI identities Inventory AI users, builders, and agents from creation through decommissioning, then review which identities are stale, unused, or unowned. Lifecycle management should cover AI identities with the same discipline used for service accounts and other NHIs.

Key takeaways

• AI security failures are identity failures when agents, users, and shared accounts all sit on the same trust path.
• Static inventory is not enough for AI governance when most activity is invisible to conventional tools.
• The most effective response is to bind runtime evidence, rightsized access, and lifecycle ownership to every AI identity.

Key terms

• AI identity: An AI identity is the set of credentials, accounts, claims, and permissions used by an AI system to access services and data. In practice, it behaves like a non-human identity, but it may also inherit human trust if organisations let it run through user accounts or shared credentials.
• Runtime visibility: Runtime visibility is the ability to observe what an identity actually does while it is active, including authentication, tool use, and data access. For AI and NHI governance, this matters more than static inventory because privilege and behaviour often diverge once the session starts.
• Identity blast radius: Identity blast radius is the amount of damage an identity can cause if it is compromised, over-scoped, or misused. For AI agents and other NHIs, it grows quickly when one identity can reach multiple APIs, cloud services, and sensitive data sets at the same time.
• Lifecycle management: Lifecycle management is the governance process that tracks an identity from creation through change, review, and decommissioning. For AI identities and other NHIs, the key challenge is keeping ownership, access scope, and offboarding current as systems proliferate and behaviour changes.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Permiso Security: 8 Critical AI Security Challenges and How Permiso Solves Them. Read the original.