LLM security risks in 2026: prompt injection, MCP and agent abuse

At a glance

What this is: This article maps the main security risks facing large language models and agentic AI, with prompt injection, data leakage, poisoning, excessive agency and MCP-related abuse treated as the core failure modes.

Why it matters: It matters to IAM and security teams because LLMs and AI agents are becoming decisioning systems with real access paths, so identity, authorisation and monitoring controls now have to cover tools, outputs and delegated actions.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Akto's analysis of LLM security risks in agentic systems

Context

LLM security risk is no longer a narrow model problem. Once a model is placed inside a workflow, connected to retrieval, or allowed to call tools, it becomes part of the enterprise trust boundary and inherits the same access and governance failures that affect APIs, service accounts and other non-human identities. That is why the primary issue is not whether the model can generate fluent text, but whether the surrounding controls can stop it from turning untrusted input into unsafe action.

The article is strongest when it treats prompt injection, excessive agency and data leakage as governance failures, not just technical bugs. That framing matters for IAM and PAM teams because AI systems increasingly sit on top of credentials, delegated access and workflow automation. Where LLMs can read, retrieve or act, identity controls need to define scope, boundaries and auditability with the same discipline used for NHI programmes.

Key questions

Q: How should security teams govern LLMs that can call tools or run code?

A: Security teams should govern them as privileged workloads, not as chat interfaces. Every tool call needs server-side authorization, schema validation, and a dedicated identity with minimal scope. If a model can influence code execution, treat that path like a production admin channel and apply least privilege, logging, and runtime isolation.

Q: Why do conversational AI systems create new identity and access risks?

A: Because they can combine data retrieval, decision-making, and execution in a single interaction. That collapses the gap between information access and business action, which traditional IAM and security tools were not built to manage. The result is higher exposure when the system can modify records or disclose sensitive guest data.

Q: What do organisations get wrong about prompt injection?

A: They often treat it as a purely content-filtering problem. In practice, prompt injection is an instruction-trust problem that becomes serious when the chatbot can act on behalf of the organisation. The fix is not just blocking bad text. It is constraining what the model can access, what it can call, and what it can change.

Q: How can teams tell whether LLM governance is actually working?

A: Look for evidence that model access is scoped, tool use is logged, sensitive outputs are blocked or reviewed, and poisoned context fails closed. If teams cannot trace prompts, retrieval sources and actions end to end, governance exists on paper but not in practice.

Technical breakdown

How prompt injection works in retrieval-augmented LLM systems

Prompt injection happens when malicious instructions are embedded in content the model later retrieves, such as email text, web pages or documents. In retrieval-augmented generation, the model does not separate trusted system intent from untrusted retrieved content unless the application enforces that boundary. That makes the retrieval layer a security control point, not just a search function. The real failure is contextual trust leakage: the model treats adversary-controlled text as if it were operational guidance, which can steer answers, expose hidden instructions or trigger downstream actions in connected systems.

Practical implication: isolate retrieved content from system instructions and require policy checks before any model output can influence an action.

Why excessive agency turns an LLM into an access risk

Excessive agency is the point at which a model is allowed to perform business actions without enough constraints, such as issuing refunds, changing accounts or invoking tools. In practice, the risk is less about the model generating a bad answer and more about it completing a workflow with real authority. If the model can call tools through MCP or similar integrations, then the security question becomes whether each action is scoped, authenticated and reversible. Without those controls, the model becomes an execution path for abuse rather than a decision-support layer.

Practical implication: bind every tool call to a least-privilege policy and separate model suggestion from privileged execution.

Data leakage, poisoning and model theft as an AI supply chain problem

LLMs can leak sensitive data through responses, embeddings, training corpora or poorly controlled logs, and poisoned data can corrupt outputs long after ingestion. The article also notes supply chain model attacks, which is the right lens because model integrity depends on upstream datasets, third-party components, plugins and deployment paths. Once those dependencies are compromised, the harm is not confined to one prompt. It can persist across sessions, propagate into downstream applications and undermine confidence in the model's behaviour at scale.

Practical implication: inventory model inputs, outputs and dependencies, then apply controls that treat training and retrieval data as governed assets.

Threat narrative

Attacker objective: The attacker aims to turn an LLM or AI agent into a trusted execution path for data theft, workflow abuse, or policy evasion.

1. Entry occurs when attackers hide instructions inside retrieved content, poisoned data, or untrusted prompts that the model is designed to process.
2. Escalation follows when the model is allowed to reveal secrets, call tools, or act through delegated workflows with more privilege than the user intended.
3. Impact arrives when the model leaks sensitive data, executes unsafe actions, or corrupts downstream business processes at scale.

NHI Mgmt Group analysis

LLM security is becoming an identity governance problem, not just a model safety problem. Once an LLM can read enterprise data, call tools or act inside workflows, it behaves like a governed access principal. That means the relevant question is not only whether the model is accurate, but whether its inputs, outputs and delegated actions are constrained like any other privileged system. For IAM and PAM teams, the operational boundary is now the model itself, its retrieval sources and the service identities behind its tools.

MCP expands the trust boundary for every agent that uses it. Model Context Protocol standardises how AI agents connect to tools and data sources, which is useful for interoperability but also broadens the blast radius of a compromised model or poisoned prompt. If tool permissions are not separated from model intent, attackers can turn one unsafe instruction into multiple unsafe actions. Practitioners should treat MCP-connected systems as a governed delegation layer, not a neutral integration pattern.

Prompt injection creates a verification trust gap that traditional application security does not close. The article correctly shows that harmful instructions can arrive through ordinary content paths, which means the attack surface includes documents, pages, messages and retrieved context. This is where the intersection with NHI governance becomes explicit: systems acting on behalf of users or services need stronger scoping, audit and approval logic than a normal UI workflow. Security teams should assume that content can be adversarial and that runtime trust must be re-established before any action is taken.

AI governance debt: unchecked model deployment creates a backlog of access, data and accountability failures that accumulate faster than teams can remediate them. The article's mix of leakage, poisoning and excessive agency shows that AI risk compounds across the full lifecycle, from data ingestion to runtime execution. That makes governance ownership as important as technical hardening. The practitioner conclusion is simple: if no one owns model access scope and action boundaries, the organisation is already accumulating governance debt.

OWASP NHI Top 10 and agentic AI risk work are increasingly converging around the same failure pattern: trusted systems acting on untrusted context. That convergence matters because the control design question is now shared across AI, IAM and NHI programmes. Organisations that segment identities, narrow delegated scope and monitor tool use will be better positioned than those treating LLMs as just another application feature.

What this signals

The operational signal for practitioners is that model governance now needs the same lifecycle discipline as other privileged systems. The most useful next step is not another policy memo, but a control map that ties each model, tool and retrieval source to an owner, a scope and an audit trail. The OWASP NHI Top 10 is a practical reference point for organising that work.

Delegated action risk: the important shift is from monitoring model output quality to governing what the model is allowed to do after it generates output. That means separating recommendation from execution, especially where service identities, API keys or MCP-connected tools are involved. Teams that already manage privileged access can extend those patterns to AI workflows without waiting for a bespoke AI control framework.

If your programme already tracks secrets, service accounts and workload identities, use that foundation to instrument AI systems as first-class identity actors. Where the article intersects with agentic AI, the useful comparison is not between vendors but between unmanaged autonomy and governed delegation. The more your environment can trace prompts, retrieval sources and tool calls, the faster you can contain abuse and satisfy audit requirements.

For practitioners

• Map every LLM and agentic integration to an access owner Inventory each model, assistant and MCP connection, then assign a business owner for the credentials, data sources and actions it can reach. Include shadow agents, embedded APIs and any workflow that can trigger external side effects.
• Separate retrieval trust from execution trust Treat retrieved content as untrusted until it passes policy checks, and block any path where model output can trigger privileged actions without a second control. This is especially important where the model can reach service accounts or delegated NHI.
• Constrain tool use with least privilege and step-up approval Limit each agent to the narrowest tool set and data scope it actually needs, then require human approval for account changes, refunds, deletions or any action that alters security state. Apply the same discipline to AI workflows that IAM teams use for elevated access.
• Monitor for sensitive output and abnormal action chains Log prompts, retrieved context, tool calls and final actions so you can detect when the model starts revealing credentials, touching prohibited systems or chaining actions outside its intended role. Use those logs for both containment and audit evidence.
• Red-team prompt injection and data leakage paths continuously Test the full path from hostile content to model interpretation to tool execution, including email, documents, web content and embedded instructions. Validate that the system fails closed when it encounters poisoned context or attempts to access secrets.

Key takeaways

• LLM risk is now a governance and identity problem because models can ingest untrusted context and act through real privileges.
• The biggest control gap is not model intelligence, but the absence of scoped access, traceable actions and constrained tool use.
• Teams that map model identities, restrict delegation and test prompt injection paths will reduce both data leakage and workflow abuse.

Key terms

• 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.
• Excessive agency: A condition where an AI system is given more operational authority than its task requires. The risk is not just poor output. It is that mistakes, manipulation, or compromise can produce destructive actions at machine speed across the systems the agent can reach.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Retrieval-augmented Generation: Retrieval-augmented generation is a pattern where an AI model pulls external information before generating output. The security challenge is that access rules can weaken when data is chunked, embedded, cached, or reused, so source permissions may not automatically follow the content into the model's context.

What's in the full article

Akto's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step breakdowns of the OWASP LLM risk categories as Akto applies them in testing and monitoring.
• Examples of the article's mitigation patterns for prompt injection, output handling and model poisoning.
• Descriptions of the AI agent, MCP and chatbot coverage that underpin Akto's testing workflow.
• The platform-specific feature list for discovery, detection and CI/CD integration that implementation teams would need.

👉 Akto's full post covers the OWASP risk mapping, mitigation patterns and AI agent testing examples.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security and secrets management. It helps security practitioners translate access control principles into programmes that can govern both human and non-human identities.