Isn't a prompt injection filter enough to secure an AI agent?

No. A filter inspects text for suspicious strings. Once an agent can retrieve documents, read memory, call tools, use MCP servers, browse, and execute code, benign-looking context can still drive a privileged action. The full context-to-action loop needs source-to-sink enforcement.

What failure modes live past the prompt?

Indirect injection via documents and tool output, RAG poisoning, memory poisoning, MCP tool drift and shadowing, tool-result hijacking, egress exfiltration, SSRF, consent spoofing, and cross-tenant bleed — each is a case of untrusted context crossing into a sink it should not control.

How does Ultra13 address the whole workflow?

Ultra13 labels every context span by source and trust class, then enforces source-to-sink policy at retrieval, memory writes, tool calls, egress, and approvals — blocking, redacting, quarantining, or gating before untrusted context becomes an unsafe action, and logging each decision for replay.

Research · Agent Attack Surface

Prompt injection is only the first failure mode.

Modern AI agents read context, call tools, update memory, use MCP servers, browse the web, write code, and trigger workflows. The missing layer is a Context Firewall between what they read and what they do.

By the Ultra13 teamPublished 23 Jun 2026Updated 8 Jul 2026

Get the Context Boundary Checklist Join Waitlist

TL;DR

Prompt injection is the entry point, not the whole agent threat model.
Once an agent retrieves context, reads memory, calls tools, uses MCP, and acts, every step reads untrusted content and can take a real action.
The attack surface is the whole workflow — retrieval, memory, tool calls, egress, and approvals — not just the prompt.
The control is a context firewall that enforces which sources may influence which actions.

Then vs now

The model you secured is not the model you shipped.

Context is now an attack surface. Every retrieved document, memory item, tool response, and MCP description can become instruction.

The old model

User prompt→LLM→response

One input, one output. Guardrails on the prompt could catch most of the obvious abuse.

The agentic model

Goal→plan→retrieve context→read memory→call tools→observe result→update state→act again

Every step in the loop reads untrusted content and can take a real action. The attack surface is the whole workflow, not the prompt.

Attack classes

The failure modes that live past the prompt.

Prompt injection is the entry point, not the whole threat model. These are the classes we replay against real agent workflows.

Attack class

Example

Indirect prompt injection

Malicious instructions hidden in docs, tickets, web pages, emails, or MCP responses.

Tool hijacking

The agent is manipulated into calling a tool with dangerous arguments.

Memory poisoning

Bad context persists and steers future sessions.

RAG poisoning

Retrieved content becomes instruction instead of evidence.

Confused deputy

The agent uses a privileged identity for an attacker-controlled goal.

Output handling abuse

Model output becomes shell, SQL, code, markdown, or workflow config.

OAST exfiltration

The agent sends sensitive data to an external callback.

Human approval spoofing

The agent misrepresents a dangerous action as safe.

Teams usually start by searching for prompt injection protection, LLM firewalling, MCP security, RAG poisoning, or agentic AI red teaming. Those are valid entry points, but the shared control problem is broader: untrusted context must not be allowed to drive privileged actions outside its authority.

FAQ

Frequently asked questions

Isn't a prompt injection filter enough to secure an AI agent?: No. A filter inspects text for suspicious strings. Once an agent can retrieve documents, read memory, call tools, use MCP servers, browse, and execute code, benign-looking context can still drive a privileged action. The full context-to-action loop needs source-to-sink enforcement.
What failure modes live past the prompt?: Indirect injection via documents and tool output, RAG poisoning, memory poisoning, MCP tool drift and shadowing, tool-result hijacking, egress exfiltration, SSRF, consent spoofing, and cross-tenant bleed — each is a case of untrusted context crossing into a sink it should not control.
How does Ultra13 address the whole workflow?: Ultra13 labels every context span by source and trust class, then enforces source-to-sink policy at retrieval, memory writes, tool calls, egress, and approvals — blocking, redacting, quarantining, or gating before untrusted context becomes an unsafe action, and logging each decision for replay.

Stop treating agent security as a prompt problem.

Guardrails catch the obvious. Ultra13 controls the context-to-action boundary.

Join Waitlist See a Sample Report