Prompt Injection: The SQL Injection of the AI Era

Two decades ago, SQL injection was the most dangerous bug in web applications. The industry eventually fixed it with parameterized queries. AI systems now face a strikingly similar threat — prompt injection — and there is no parameterized query to reach for.

What prompt injection is

Prompt injection happens when crafted input makes a model deviate from its intended behavior. Because large language models process natural language — where instructions and data live in the same channel — there is no clean line between “what the model should do” and “what the model is reading.” That one property is what makes the whole class so hard to defend against.

Three shapes it takes

• Direct. The attacker talks to the model and tries to override its system prompt — jailbreaks, role-play, “ignore all previous instructions.”
• Indirect. The more insidious variant: the attacker plants instructions in content the agent will later read — a web page, an email, a document, a database row, or a tool's response. The agent follows them, believing they're legitimate.
• Multi-step. The attacker shifts the model's context gradually across several innocuous-looking turns until it does something a single prompt would have been refused.

Why the result leg is the real battleground

Notice where indirect injection arrives: in content the agent fetches. A tool returns a document; the document carries hidden instructions; the agent acts on them. The same leg that leaks sensitive data — the response coming back from a tool, a model, or another agent — is the leg that carries the attack in. Inspecting the prompt the user typed does nothing about either. You have to screen what comes back.

A concrete leak: an attacker hides an instruction in a page telling the agent to encode an API key into a URL and render it as a markdown image. When the image loads, the data is gone — and the request leg looked perfectly ordinary. The defensible place to intervene is the response: inspect it, strip or redact the sensitive value, and keep the reply valid so the agent keeps working.

You can't make the model trustworthy, so the control belongs outside it — inline, on the wire, at the moment of the call. Screen the request, screen the result, and on the paths that guard data, fail closed: a call that can't be judged doesn't reach the data.

A layered, runtime defense

• Screen inputs for known patterns. Fast, inline checks catch recognized injection and jailbreak syntax before a request goes out. Useful, never sufficient — the creative space is vast.
• Inspect every response. Screen what tools, models, and other agents return — the result leg — for injected instructions and for sensitive data, and redact in place rather than passing the raw value on.
• Isolate reading from acting. Separate an agent's ability to read data from its ability to take action. Route egress — agent-to-tool, A2A, model calls — through a control with an allowlist.
• Keep an audit trail. Every block or redaction carries the rule that fired and why — the record a reviewer can actually read.

How BlueAspen fits

BlueAspen is data security for AI: one policy engine and one detection stack across the agents you run and the employees using AI. For the agents you run, the MCP Gateway and Agent Proxy screen both legs of every call — request and result — and redact sensitive values in place, so a poisoned or leaky response can't carry data out. Fast inline detection catches known techniques; local ML analyzers catch novel ones. On ingress and agent-to-tool paths it fails closed by design.

Prompt injection is the defining security challenge of this era, and unlike SQL injection there's no silver bullet — no construct that eliminates the class outright. What works is a layered defense that runs at runtime and treats the response as untrusted. The question isn't whether your agents will meet an injection attempt. It's whether there's a control on the data when they do.