AI security risk is outpacing controls for LLMs and agents

At a glance

What this is: Akto's 2026 analysis says AI security controls are lagging behind LLM and agent adoption, leaving visibility, governance, and runtime enforcement gaps across models, tools, and actions.

Why it matters: This matters because AI systems now make and execute decisions across enterprise environments, so IAM, PAM, and NHI teams need controls that govern identity, privilege, and runtime behaviour rather than static application assumptions.

By the numbers:

• 69% of organisations have already deployed AI agents in real-world environments, rapidly expanding the enterprise attack surface.
• Only 21% of enterprises maintain a complete inventory of AI agents and MCP connections, creating major visibility gaps.
• 79% of organizations lack governance policies for AI agent permissions and monitoring, increasing the risk of unauthorized access and untracked AI behavior.
• AI now drives 83% of breaches, according to Gigamon's 2026 survey of 1,000+ global security leaders cited by Akto.

Context

AI security has moved beyond model protection into governance of systems that interpret instructions, call tools, and trigger downstream actions. Once an LLM can reach data, invoke APIs, or hand work to another agent, the security problem is no longer just input filtering. It becomes identity, authorisation, logging, and runtime control across the full execution path.

The article's central gap is that many organisations are still treating AI like a conventional application or REST API. That model breaks when behaviour is dynamic, context is assembled at runtime, and agents can request access on the fly. For IAM and NHI programmes, the real issue is whether the enterprise can inventory, govern, and revoke machine-driven access with enough precision to limit blast radius.

AI security posture management: The emerging control problem is not simply whether a model is secure, but whether the organisation can continuously discover every model, agent, integration, and tool path it has exposed. That makes AI-SPM a governance layer, not just a monitoring practice.

Key questions

Q: What breaks when AI agents are treated like standard human users?

A: You lose visibility into effective permissions, expected behaviour, and real blast radius. Human-centric controls can misclassify normal agent activity as compromise, or miss policy violations that happen entirely within legitimate access. The failure is not only technical, it is governance design that assumes a person is always behind the action.

Q: When should organisations prioritise inventory over broader AI governance controls?

A: Inventory should come first because every downstream control depends on knowing what exists. Risk classification, assessments, access review and lifecycle management all assume the asset is already identified. If the record is missing or stale, the organisation is governing a partial estate and cannot trust the rest of the programme.

Q: What do security teams get wrong about AI agent permissions?

A: Teams often assume that permissions are safe if the agent was approved at deployment. In practice, approval does not prevent privilege from becoming stale, unnecessary, or dangerous after integrations change. The mistake is treating authorisation as a one-time event instead of a living identity state that must be continuously re-evaluated.

Q: How should teams govern AI agent actions so a prompt injection cannot turn into a real-world incident?

A: Teams should place enforcement at the action layer, not only inside the model. Guardrails can shape text and refuse many bad prompts, but they remain probabilistic and advisory. Runtime governance should check authorization, policy, and audit at the exact moment a tool call is made, so a manipulated agent can be stopped before money moves, data is deleted, or records are changed.

Technical breakdown

Why LLMs and agents break API-style security models

LLMs do not behave like fixed-function APIs. They interpret natural language, assemble context from multiple sources, and may choose actions at runtime, which means the attack surface includes prompts, retrieved content, tool responses, and the decisions the model makes from them. Traditional request validation is necessary but insufficient because the model can still be manipulated through prompt injection, indirect prompt injection, or corrupted context. Once the system can call tools or trigger workflows, output becomes an execution path, not just a response.

Practical implication: govern AI systems as dynamic decision engines, not as static application endpoints.

How AI identity and privilege control change the risk model

AI identity is about what a model or agent can access, what it can act upon, and how those actions are attributed. If an agent shares broad credentials, inherits excess permissions, or can reach systems outside its task boundary, compromise becomes a blast-radius problem rather than a single-model problem. The article's emphasis on least privilege, distinct service identities, and role-based access reflects a core identity principle: access must be scoped to task, time, and tool, then revoked cleanly when the task ends.

Practical implication: issue separate identities for agents and enforce task-scoped authorisation.

Why runtime protection matters more than pre-deployment review

AI controls fail when they stop at launch. Models drift, prompts change, integrations expand, and new attack patterns emerge after deployment, so the control point has to move to inference time. Runtime protection inspects inputs before they reach the model, outputs before they reach users, and tool calls before they cause side effects. This is where prompt injection detection, content filtering, output validation, and behavioural monitoring work together as a continuous control layer.

Practical implication: extend monitoring to tool calls, agent actions, and prompt changes as live security events.

Threat narrative

Attacker objective: The attacker aims to turn trusted AI behaviour into unauthorized access, data exposure, or downstream action execution.

1. Entry begins when a malicious prompt, document, or tool response is introduced into the AI context and the model treats it as trusted input.
2. Credential access or privilege abuse follows when the agent is manipulated into using broader permissions, higher-privilege workflows, or connected systems it should not reach.
3. Impact occurs when the agent executes unsafe actions such as exposing data, sending messages, invoking APIs, or amplifying the attacker’s control across connected services.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
• Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.

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 now has an identity problem: the moment agents can call tools, reach data, or trigger workflows, privilege becomes part of the attack surface. That shifts the governing question from model accuracy to who or what is allowed to act, under which identity, and with what revocation path. Practitioners should treat AI access as a living identity estate, not a static application permission set.

Visibility is the prerequisite control for AI governance: you cannot enforce policy across models, integrations, and prompt flows that you have not inventoried. The article's 21% inventory figure is a signal that many organisations are still blind to their own AI footprint. The result is governance debt, where controls are designed after exposure instead of before deployment.

Runtime behaviour is the real control boundary for agentic systems: prompt review alone cannot contain systems that retrieve content, choose tools, and act in sequence. AI security has to move from pre-release assurance to continuous enforcement at inference time, where context poisoning, unsafe output handling, and excessive tool use actually occur. That makes continuous validation the practical dividing line between manageable automation and uncontrollable delegation.

AI security posture management is becoming the operational layer for agentic AI: the field needs a named concept for continuously discovering, classifying, and governing AI assets before they become unmanaged enterprise actors. AI-SPM is not a product category claim here, but a governance model for keeping AI activity auditable and reversible. Practitioners should align AI security programme ownership with identity, platform, and risk teams, not leave it siloed in experimentation or application security.

Traditional IAM is necessary but not sufficient for agentic AI: the article shows that authorisation logic, audit trails, and accountability must extend beyond human users to machine-driven decision paths. That means identity governance teams need to reason about agent identities, tool permissions, and logging quality in the same control language they already use for privileged access. The practical conclusion is simple: if an AI system can act, it needs governed identity and measured privilege.

From our research library:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Agentic AI governance debt: organisations are moving into agent deployment faster than they are building the controls that make those deployments explainable, revocable, and auditable. That gap is especially acute where AI touches enterprise tools, because identity and access decisions become runtime events rather than one-time approvals.

A mature programme will align AI oversight with existing identity governance, not treat AI as an exception. The practical test is whether you can inventory agents, scope their access, log their actions, and prove who owns each risk when behaviour changes.

The credential and context problem is already visible: AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026. That pattern suggests the weakest point is often not the model but the surrounding operational estate.

For practitioners

• Implement complete AI asset inventory Catalog every model, agent, plugin, integration, and MCP connection, then assign an owner and data access scope to each one.
• Issue task-scoped identities for agents Give each AI agent a distinct service identity with minimum permissions, separate from human or shared application credentials.
• Enforce runtime policy at inference time Inspect prompts, retrieved content, tool calls, and outputs before side effects occur, and block actions that exceed policy.
• Treat prompt and integration changes as security events Version-control system prompts, log model updates, and require security review for new tool integrations or permission expansions.
• Build an AI risk register with accountable owners Track each AI use case, its risk rating, its sensitive data exposure, and the team responsible for remediation and monitoring.

Key takeaways

• AI security risk is now driven by systems that interpret context and act, not just by models that generate output.
• The biggest governance gap is visibility, because organisations cannot control AI estates they have not fully inventoried.
• Runtime authorisation, task-scoped identity, and continuous monitoring are the controls that matter when agents can trigger real-world actions.

Key terms

• Agentic AI Security: Agentic AI security is the discipline of securing autonomous AI systems that can take actions, use tools, and chain decisions without direct human approval at each step. It covers identity and access management for AI agents, prompt injection defence, tool call governance, credential scoping, and runtime monitoring. As agentic systems acquire real-world authority, API access, file writes, workflow triggers, the security model must treat them as non-human identities with explicit lifecycle controls, not trusted processes.
• AI Security Posture Management: A governance approach for discovering and tracking AI assets such as models, agents, datasets, vector stores, and related infrastructure. It becomes useful only when inventory is connected to runtime exposure and the identity that can actually reach the data.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and workload identity. It helps practitioners translate identity controls into programmes that can govern AI agents, machine identities, and delegated access.