AI Security in 2026: Prompt Injection, Tool Poisoning, and the New Agentic Risk Stack

The threat model changed between March 2025 and June 2026

On March 12, 2025, the OWASP GenAI Security Project published the 2025 LLM Top 10 and made the shift explicit. The list still starts with prompt injection, but it also highlights sensitive information disclosure, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, and unbounded consumption. That is a broader runtime security surface than the early "just moderate the answer" framing.

The next signal came on February 17, 2025, when OWASP published Agentic AI - Threats and Mitigations. The framing changed from single-model misuse to autonomous-system risk: repeated tool calls, broader capabilities, and a larger blast radius when instructions are manipulated.

By March 23, 2026, MCP-specific research had pushed the model further. Papers such as Are AI-assisted Development Tools Immune to Prompt Injection? and Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning argued that tool metadata and client behavior can become their own attack surfaces. Then on June 1, 2026, OWASP's State of Agentic AI Security and Governance 2.01 and, on May 25, 2026, the AIUC-1 crosswalk added even more emphasis on agent identity, runtime containment, architectural monitoring, and privilege abuse.

The practical change is simple: AI infra security is now a layered control-plane problem, not a prompt-formatting problem.

The runtime risks that matter most now

Prompt injection and jailbreaks remain first-order risks. OWASP still lists prompt injection as LLM01:2025, and it explicitly notes that RAG and fine-tuning do not remove the vulnerability. If the gateway cannot inspect untrusted input before the provider call, the rest of the stack inherits the risk.

Excessive agency turns weak model behavior into real actions. OWASP's LLM06:2025 Excessive Agency points directly at too much functionality, too many permissions, and too much autonomy. In practice, that means the security question is not only "what did the model say?" but also "what was it allowed to do next?"

Tool poisoning is now part of the agentic attack surface. The latest MCP papers focus on poisoned tool metadata, hidden parameters, cross-tool poisoning, and unauthorized invocation. That matters because many teams still treat tool integration as a product feature instead of a governed capability boundary.

Unbounded consumption is both a resilience and a security issue. OWASP's LLM10:2025 Unbounded Consumption explicitly ties uncontrolled inference to denial of service, denial of wallet, service degradation, and model extraction pressure. In AI systems, cost abuse and availability abuse are often the same operational event.

Sensitive disclosure is not only a provider problem. The 2025 OWASP list separates sensitive information disclosure and improper output handling because the model can leak data even if the original prompt looked acceptable. Response-side enforcement matters as much as request-side filtering.

How Odock handles these risks in the security engine

At Odock, we make a deliberate separation: policy guardrails handle traffic shape, access, payload, tokens, budgets, and quotas, while our Security Engine, SafetySec, handles prompt and response content.

That separation maps cleanly to the newer AI security guidance:

• Prompt injection and jailbreaks:

We run request-side content checks before upstream execution with SafetySec prompt-injection and jailbreak-pattern modules.

• Sensitive data entering or leaving the provider boundary:

We support redaction before upstream calls and leakage checks after upstream responses through sensitive-redaction and data-leakage modules.

• Repeated low-signal attacks:

We use repeated-risk awareness so suspicious patterns can escalate based on behavior rather than one isolated score.

• Excessive agency and tool misuse:

We enforce explicit capability boundaries on tool access with MCP grants, team or API-key scope, and allowed or blocked tools.

• MCP tool poisoning or risky payloads:

We inspect tool calls at runtime and apply narrow content rules with semantic filters on MCP payloads.

• Denial of wallet and runaway usage:

We enforce token-aware and cost-aware lifecycle gates through token limits, budgets, quotas, and final usage reconciliation.

The key architectural point is timing. At Odock, our runtime enforces staged gates: request-aware checks, identity and access checks, resource-aware context, token and cost gates, request-side safety, plugin gates, upstream execution, response-side safety, and then usage evidence. That matches the reality that different risks become visible at different moments.

SafetySec itself is also lifecycle-aware. In our runtime, request-side modules can catch prompt manipulation and redact sensitive input before the provider call. Response-side modules can then catch data leakage or sensitive output before the caller receives it. That is much closer to what OWASP 2025 is asking for than a single preflight regex layer.

Where Odock is especially strong in the comparison

Gateway-level prompt and response controls. The Security Engine is not described as a one-time admission check. It can act both before and after upstream work, which is important for prompt injection on the way in and leakage on the way out.

Capability governance for MCP. At Odock, we treat tool access as runtime capability access. A server must be granted to a virtual API key, can be narrowed by team or key scope, and can have allowed tools, blocked tools, and semantic filters. That is the right mental model for agent security.

Cost and abuse protection in the same path. Budgets, quotas, token gates, concurrency, and usage reconciliation are separate from SafetySec but still part of the enforcement pipeline. That matters because OWASP's unbounded-consumption category is not just FinOps; it is also security and availability control.

Evidence and auditability. SafetySec produces safety evidence, and the runtime model records usage, status, tokens, cost, latency, and lifecycle outcomes. For platform teams, that is the difference between a blocked request and an explainable blocked request.

What Odock does not claim to solve by itself

We are deliberate about this boundary. Our gateway provides strong runtime controls, but we do not claim that the gateway alone solves every AI security problem.

Areas that still need adjacent controls include:

• model and dataset supply-chain attestation
• training-data and embedding-data poisoning defense upstream of inference
• secure SDLC and patch management for MCP servers themselves
• deep schema validation inside business-specific tool handlers
• model evaluation, red-team workflows, and release-governance policy outside the request path

That is the honest comparative position. Odock covers a large part of the runtime AI infra layer. It should not be described as replacing the rest of the security program.

The production standard for AI infra security

If your stack includes LLMs, MCP servers, or agent loops, your platform should be able to answer a few hard questions:

• Which prompts were blocked before reaching the provider?
• Which sensitive values were redacted on the way in or out?
• Which tools can each API key actually call?
• Which repeated suspicious events escalated from observe to block?
• Which workloads are closest to a cost, token, or concurrency limit?
• Which requests were denied by content policy, by capability policy, or by budget policy?

That is where the latest guidance is pointing. The winning design is not "better prompt templates." It is lifecycle-aware runtime enforcement with explicit capability boundaries and evidence.

Sources

• OWASP Top 10 Risk & Mitigations for LLMs and Gen AI Apps, 2025
• OWASP LLM01:2025 Prompt Injection
• OWASP LLM06:2025 Excessive Agency
• OWASP LLM10:2025 Unbounded Consumption
• OWASP Agentic AI - Threats and Mitigations, February 17, 2025
• OWASP State of Agentic AI Security and Governance 2.01, June 1, 2026
• OWASP AIUC-1 Crosswalks for Agentic Applications, May 25, 2026
• Are AI-assisted Development Tools Immune to Prompt Injection?, March 23, 2026
• Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning, March 23, 2026
• Odock Security Engine
• Odock MCP Security