AI security is identity security, and blind spots are growing

At a glance

What this is: Permiso Security maps eight AI security challenges to identity failures, arguing that AI usage, over-permissioned agents, and attribution gaps all stem from weak visibility into who or what is acting.

Why it matters: IAM, PAM, and NHI teams need to treat AI services and agents as identity-bearing actors because unmanaged access, shared credentials, and opaque runtime behaviour create blind spots that static tools miss.

By the numbers:

• 80% of actual AI activity is invisible to traditional tools that only track licensing and static configurations, according to Permiso Security.
• AI agents can operate with up to 90% unused permissions, according to Permiso Security.
• Fewer than 40% of organisations currently govern AI agents as they proliferate across teams and business units, according to Permiso Security.
• Permiso Security says 80% of organisations have encountered risky behaviours from AI agents, including improper data exposure.

Context

AI security is the governance problem that appears when AI systems start acting like identities rather than like simple software features. In this article, Permiso Security argues that organisations are scaling AI usage faster than they can see who is using it, what it touches, or which accounts and services it can reach.

That matters because AI access is increasingly granted through human credentials, federated logins, API keys, and service accounts. Once AI activity is treated as an identity event, the familiar IAM questions change from inventory to runtime control, attribution, and least privilege across human and non-human actors.

The article’s starting position is typical of many current AI rollouts: rapid adoption, weak visibility, and governance that lags behind operational use.

Key questions

Q: What breaks when AI access is managed like normal application access?

A: Normal application access assumes stable ownership, predictable usage, and clear review cycles. AI-connected identities can change behavior faster than those cycles can detect, especially when tool use and data access happen in the same session. If teams rely only on point-in-time approvals, they miss the runtime risk.

Q: Why do AI agents increase the risk of overpermissioning?

A: AI agents increase that risk because teams often expand scopes to unblock early use cases, then keep those permissions because the original need is hard to prove or remove. The access model becomes broader over time, and the agent inherits more privilege than anyone intended.

Q: How can security teams tell whether AI lifecycle controls are working?

A: They should look for evidence that access requests, policy enforcement, and usage visibility are centrally recorded and current. If those signals are fragmented across platforms, the programme may be documenting governance rather than enforcing it. Continuous traceability is the practical test.

Q: What should organisations do when AI-generated code touches credentials or service accounts?

A: Apply stricter review and approval rules whenever generated code creates, stores, rotates, or calls machine credentials. Those paths can expand NHI exposure quickly, so the code should be treated like privileged automation. Require explicit ownership, logging, and pre-merge checks for credential handling.

Technical breakdown

Why AI usage becomes an identity problem

AI access is not just another application control surface. When an employee uses a consumer AI account, a developer connects an LLM through OAuth, or an agent calls enterprise APIs, the security event is really about authenticated identity, delegated scope, and what that identity can do at runtime. The problem grows when access is shared through human accounts or standing service credentials, because attribution collapses and policy enforcement loses context. In identity terms, AI is extending the perimeter into a space where access is dynamic, multi-protocol, and hard to govern with static inventory alone.

Practical implication: classify AI interactions by identity type, not by tool name, and govern the account or token behind each interaction.

Why over-permissioned AI agents create broad blast radius

AI agents frequently need access across multiple systems at once, including model endpoints, internal APIs, cloud services, and data stores. That breadth makes over-permissioning easy: teams grant more than the task requires so development keeps moving, then leave the privilege in place. If an agent is compromised or misbehaves, the blast radius is defined by the combined reach of every connected identity and token it can use. This is why least privilege for AI agents is an access-scope question first, not a model-quality question.

Practical implication: right-size agent permissions against actual task scope and remove unused access before the agent is promoted into production.

Why attribution and runtime evidence matter more than static inventory

Static configuration data can tell you a license exists, but not whether the AI service is being used, which account initiated the session, or whether the actor behind it was human or autonomous. Runtime evidence fills that gap by showing live access paths, authentication flows, and behaviour changes over time. That distinction is crucial in incident response, because an agent that acts through shared credentials can hide behind the human operator unless the session is individually observable. Without runtime evidence, governance decisions are built on assumptions rather than behaviour.

Practical implication: pair inventory with session-level telemetry so investigations can tie each AI action back to a specific identity and access path.

Threat narrative

Attacker objective: The attacker aims to exploit AI identity blind spots to gain wider access, obscure activity, and reach sensitive data or privileged credentials.

1. Entry begins when a human user, developer, or agent authenticates to an AI service through personal accounts, federated access, API keys, or shared service credentials.
2. Escalation follows when the AI identity is granted excess scope across APIs, cloud services, or data stores, allowing it to reach more systems than the task requires.
3. Impact occurs when the AI actor exposes sensitive data, hides activity from static tools, or provides attackers with a path from compromised AI access into human credentials and broader enterprise systems.

Breaches seen in the wild

• Air Canada chatbot ruling 2024: A tribunal held Air Canada liable for its chatbot's wrong bereavement fare answer, rejecting the claim that the bot was a separate legal entity.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI security is now an identity governance discipline, not a tool category. The article is right to collapse AI monitoring, agent control, and user activity into one identity problem. That matters because security teams do not lose control only when AI is malicious, but when access is granted through the wrong account model and then becomes untraceable at runtime. Practitioners should treat AI adoption as an expansion of IAM scope, not a standalone exception.

Runtime visibility is the new control plane for AI access. Static inventories tell you what should exist, not what is actually happening across federated logins, shared credentials, and autonomous sessions. That is why the identity question changes from 'what AI do we have?' to 'what identity is acting, under what authority, and with what live scope?' The organisations that cannot answer that will keep discovering AI risk only after exposure.

Over-permissioning is the real AI blast-radius problem. The article’s most useful contribution is its framing of unused permissions as latent risk rather than administrative clutter. When AI systems are granted broad reach across LLMs, cloud APIs, and internal data stores, the attack surface is multiplied by every downstream connection. Practitioners need to see that as a privilege design failure, not merely an operational convenience.

Attribute-heavy forensic trails are becoming mandatory for AI accountability. The old assumption that one human operator maps cleanly to one action breaks as AI usage shifts through shared accounts, delegated tokens, and chained agent behaviour. That creates an attribution gap that undermines incident response, audit, and policy enforcement. Identity programmes should now assume that AI-related evidence must be session-based, not just account-based.

Identity perimeter extension is the right named concept for this category. AI provisioned through human credentials or service accounts extends the identity perimeter into runtime contexts that were never designed for delegated machine action. That is not a cosmetic governance issue. It means practitioners must rethink how identity boundaries are drawn when the actor can authenticate, call tools, and act without a human sitting in the loop.

From our research library:

• 8 of the top 10 fastest-growing types of leaked secrets year-over-year are tied directly to AI services, according to the State of Secrets Sprawl 2026.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Identity perimeter extension: AI adoption turns every delegated token, federated login, and shared account into part of the security boundary. That boundary now has to be governed by runtime evidence, because static inventories cannot explain what an AI actor actually did once it authenticated.

Organisations that grant AI systems broader access than human employees are not only increasing exposure, they are making privilege review less meaningful. The control point moves from later certification to issuance-time scope design, especially when an AI agent can authenticate, call tools, and share data in one session.

For practitioners

• Define AI actors by identity type Map employees, builders, AI agents, and service accounts separately so policy can follow the actual actor rather than the AI product name.
• Measure runtime AI activity Correlate federated logins, API calls, and session data to see which AI services are being used and what they are accessing in production.
• Rightsize agent permissions against task scope Review each AI agent’s connected systems and remove unused access that is not required for its current operating task.
• Separate shared credentials from attribution Eliminate human credential sharing for AI workflows and preserve per-session evidence so incident response can identify the true operator or agent.

Key takeaways

• AI security failures are increasingly identity failures, because access paths and runtime behaviour matter more than tool labels.
• Over-permissioned AI agents expand blast radius across APIs, cloud services, and data stores, making least privilege harder to ignore.
• Runtime evidence and session-level attribution are now essential if teams want to govern AI use, investigate incidents, and enforce accountability.

Key terms

• AI Identity Scope: The set of resources, tools, and credentials an AI system can access in order to complete a task. Proper scope is narrower than generic user access because autonomous systems can chain actions quickly, making overbroad permissions far more damaging than in human-only workflows.
• Runtime Visibility: The ability to observe what an AI client actually accessed, which tools it used, and how it behaved during a session. It is more useful than entitlement snapshots for agent governance because it captures executed reality, not just approved access.
• Identity Perimeter: The identity perimeter is the access boundary defined by who or what is requesting entry, not by where the request comes from. In zero trust, it is the point where authentication, authorization, and risk context decide whether a caller can proceed.
• Attribution gap: The attribution gap is the distance between what an AI agent did and what the enterprise can prove about who authorized it, what it was allowed to do, and who is accountable. It is an identity and governance problem that becomes visible during audits, incidents, and legal disputes.

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.