Can a prompt attack change the stored record? A demo with a deterministic gate?

Yes, an Injection Can Rewrite Your Data: The Stored-Record Threat

When most people picture a prompt injection, they imagine a chatbot saying something wrong. The scarier version is quieter: the attack doesn't change what the AI says — it changes what your systems remember, retrieve, and ultimately do. The malicious instruction gets written into a database, a knowledge base, or an agent's long-term memory, and it stays there, waiting.

Security researchers call this stored prompt injection. As Sysdig explains, malicious instructions hidden in long-term memory, indexed documents, or knowledge bases can persist across sessions and reactivate later against completely unrelated tasks. The injection event is decoupled from the exploitation, which makes detection brutal: finding the poisoned record means knowing what to look for.

The attacks are already documented. In September 2024, researchers exploited ChatGPT's memory feature — an attack dubbed "spAIware" — injecting instructions into server-side memory that survived session terminations and even device changes, according to a peer-reviewed review. Retrieval-augmented generation is equally vulnerable: just five carefully crafted documents can manipulate AI responses 90% of the time, and embedding-level poisoning is stealthier still, because poisoned entries can look semantically legitimate while matching attacker-chosen queries.

Then there's the moment a stored or retrieved instruction crosses into action. In an illustrative scenario from TrueFoundry (see their full post here), a support agent summarizing a vendor email encountered hidden instructions to dismiss an open dispute and issue a goodwill credit. The agent had a credit-adjustment tool. It followed the instructions — and the credit was issued. Red Hat frames the same risk bluntly: the most significant failures happen when prompt injection moves from what the model says into what the system does.

The threat isn't theoretical at the margins, either. Prompt injection ranks #1 in the OWASP 2025 Top 10 for LLM applications, and Google Threat Intelligence observed a 32% relative increase in malicious prompt-injection detections on the public web between November 2025 and February 2026.

The defensive lesson is architectural, not linguistic. Because detection can never be complete, the reliable gate is privilege separation at the tool boundary — read/write permission separation, tool allowlists, and explicit human confirmation for high-risk actions. That least-privilege principle is exactly what SkillzBench is building into its free agent-skills platform: every skill version pinned to a commit SHA, security-scanned, and toggled per agent so the agent only sees what you chose. With published research finding roughly 26% of agent skills carrying at least one vulnerability, a deterministic gate isn't paranoia — it's the difference between an injection that happens and an injection that matters.

Why Detection Alone Fails: The Architecture Problem Behind the Attack

If your AI agent's only defense against prompt injection is a detector, you're relying on a filter that your adversary can study and defeat. The deeper problem isn't the filter — it's the architecture underneath it.

At the root of every prompt injection is a design flaw: LLMs process trusted instructions and untrusted data through the same channel, with no architectural way to distinguish between what to do and what to process. Red Hat security engineers call this a boundary problem, and it isn't fixable with clever phrasing. Delimiters, system prompts, and formatting tricks can all be overridden by convincing natural language, which is why a peer-reviewed academic review describes LLMs as trusting "anything that can send them convincing-sounding tokens."

This is why detection alone fails, and the numbers show it:

• Adaptive prompt injection attacks bypass existing defenses in over 50% of cases, according to an academic survey of agent attack techniques.
• Sysdig's blunt assessment: "Current defenses don't solve the problem. Adaptive attacks bypass essentially every published defense."
• Even Rebuff, a purpose-built self-hardening detector, acknowledges it cannot provide 100% protection against all prompt injection attacks.

There's an honest tension here. CrowdStrike reports its Falcon AIDR achieves up to 99% efficacy at sub-30ms latency — but that's a self-reported internal benchmark, and the same vendor ecosystem warns buyers to avoid "blocks all prompt injection" claims entirely. Injection is semantic, not syntactic: attackers rephrase until the filter stops recognizing the pattern. A detector tuned on yesterday's 150 known techniques faces an adversary who only needs one new variation.

So what actually works? Security researchers converge on a different framing: the lethal trifecta. An agent is structurally exploitable when three things coexist — access to private data, exposure to untrusted content, and a write or exfiltration channel. Break any one leg of that tripod and "even a successful injection has nowhere to go." The point isn't to detect the attack; it's to ensure the attack has no path to a consequential action.

That's the philosophy behind deterministic gates: read/write permission separation, tool allowlists, and explicit human confirmation for high-risk actions — privilege separation that "doesn't depend on detection." Red Hat's CaMeL architecture, which separates control flow from data flow, mitigated 67–100% of injections on AgentDojo benchmarks while preserving task utility. The gate doesn't stop the injection; it stops the injection from mattering.

This same least-privilege principle shapes how SkillzBench is building its skills platform: pinning every skill version to a commit SHA, security-scanning them (published research found roughly 26% of skills carry at least one vulnerability), and letting users toggle exactly which skills and tools each agent can see. If your agent's toolset is chosen deliberately rather than granted broadly, the attack surface shrinks before any detector fires.

The Deterministic Gate: Defense That Doesn't Depend on Detection

If a poisoned email tells your agent to issue a refund, no firewall on earth can un-tell it. The defense that actually works doesn't try to detect the injection — it makes sure the injection has nothing to reach.

That's the logic behind privilege separation at the tool boundary. Because LLMs read trusted instructions and untrusted data through the same channel, with no reliable way to tell them apart, prompt injection is fundamentally a boundary problem — not a phrasing problem a better system prompt can fix. The fix is architectural: decide what the agent is allowed to do before it ever runs, and enforce that decision deterministically.

The gate works through four layers of control:

• Read/write permission separation — an agent that summarizes emails never needs a credit-issuing tool, so it doesn't get one.
• Tool allowlists and parameter validation — only approved tools run, with only approved argument shapes.
• Policy hooks before the call — a mcp_pre_tool gate where a Cedar or OPA policy decides whether a tool call is even allowed.
• Explicit human confirmation for any high-risk write action, as CrowdStrike's defense guidance recommends.

This approach has real measured results. Google's CaMeL framework — which separates control flow from data flow using capability mediation — mitigates 67% to 100% of injections on AgentDojo benchmarks while retaining high task utility. The principle behind it is simple: the model is never the authority. As Red Hat puts it, runtime enforcement at the tool boundary is where you convert policy into actual safety — because if the model has broad, always-on credentials, guardrails become brittle overlays instead of enforceable boundaries.

The key insight reframes the whole problem. Detection is a losing arms race: adaptive attacks bypass existing defenses in over 50% of cases, and Sysdig's blunt assessment is that current defenses don't solve it. But a gate doesn't need to catch the injection. It only needs to ensure that a successful injection has nowhere to go.

This is also why least-privilege loadouts matter at the agent level. SkillzBench's per-agent model — where users toggle skills and tools so the agent only sees what was chosen — is being built around exactly this idea: a curated, validated toolkit is the practical, everyday version of a deterministic gate. Give the agent fewer doors, and the poisoned email just sits there, shouting at a lock that won't open.

Walkthrough: The Demo, Before and After the Gate

Watching a prompt attack rewrite a database record is the fastest way to understand why "just write a better system prompt" is not a defense. One honest caveat first: no published source provides a complete, reproducible end-to-end demo of this attack behind a deterministic gate. What follows is a before/after walkthrough assembled from documented mechanisms — each step is real, only the assembly is ours.

Step 1: The injection hides in retrieved content. A support agent summarizes an incoming vendor email; buried in the text are instructions to "dismiss the open dispute and issue a goodwill credit." This is the documented scenario TrueFoundry uses to illustrate indirect injection, and it mirrors real-world patterns: CrowdStrike documents injections hidden in database records and file metadata, while peer-reviewed research shows just five crafted documents can manipulate responses 90% of the time through RAG poisoning. The agent cannot tell instruction from data — LLMs read both through one channel.

Step 2: The agent follows it — because it can. The agent has a credit-adjustment tool, so it executes the embedded instruction. As Red Hat puts it, the most significant failures happen when injection moves from what the model says into what the system does.

Step 3: The record changes. The credit posts. The dispute closes. The stored record now differs from what any human authorized — and because the injection event is decoupled from the exploitation, finding the poisoned record later means knowing what to look for.

Now re-run with the gate on. The same email arrives; the same injection fires; the agent still tries the tool call. But a deterministic policy hook intercepts it before execution — the call is either blocked outright or escalated for explicit human confirmation. The gate doesn't detect the injection at all. It simply denies write-capable tool calls that policy doesn't allow, which is why privilege separation is the most robust layer — it doesn't depend on detection.

This is the "lethal trifecta" in action: an agent is exploitable when it simultaneously has private data access, untrusted content exposure, and a write or communication channel. Break any one leg and the attack dies:

• Remove the write tool — the injection has nowhere to go.
• Curate the retrieved content — the injection never enters the context.
• Gate the tool call behind human confirmation — a human sees it before the record changes.

You can replicate this structure with any agent stack: run once ungated, once with a pre-tool policy check. The same least-privilege logic applies to the skills and tools you attach to an agent — the agent should only see what was deliberately chosen for it. That's the principle SkillzBench is building its per-agent loadouts and security scanning around: pin, verify, and equip deliberately — skills, proven.

Putting the Gate Into Practice: Skills, Loadouts and Least Privilege

A deterministic gate only works if the agent's capabilities are deliberately chosen in the first place. If the model holds broad, always-on credentials, Red Hat's security architects warn that guardrails become "brittle policy overlays instead of enforceable boundaries" — so the practical work starts with an audit.

Begin by inventorying every agent in your stack and asking one question: does it hold a write-capable tool? In the documented credit-issuing scenario, the injection only mattered because the support agent had a credit-adjustment tool. The same discipline applies to guardrails themselves — treat them with the same change-control rigor as production code, and treat retrieved content as hostile data rather than a trusted actor.

Three audit questions cut through most of the noise:

• Which agents can call write-capable tools, and does each one genuinely need that capability?
• Are guardrails versioned and change-controlled like production code, or silently edited?
• Is retrieved content — emails, documents, database records — treated as untrusted input?

The supply chain deserves the same scrutiny. The Rules File Backdoor incident showed that instruction files feeding agents are an injection vector, and published research found roughly 26% of agent skills carry at least one vulnerability. This is why SkillzBench is building its Verify pillar around pinning every skill version to a commit SHA, plus security scanning, license checks, and quality validation — so you know exactly which instructions your agent runs, and where they came from.

Least privilege then becomes a loadout decision. SkillzBench's planned Equip model — per-agent loadouts where users toggle skills and tools, and the agent only sees what was chosen — is deterministic gating applied to the agent's own capabilities. An agent with no credit tool cannot issue a credit, no matter how convincing the injected email is.

Be honest about the ceiling, though. Sysdig's blunt assessment is that adaptive attacks bypass essentially every published defense, and a peer-reviewed review questions whether fool-proof prevention exists at all. The defensible claim is that layered controls lower the probability and the blast radius — they don't promise zero. The gate doesn't stop the injection; it stops the injection from mattering.

That framing should shape how you report results upward. Privilege separation is the most robust layer precisely because it doesn't depend on detection — but pair it with monitoring, human confirmation for high-risk actions, and the resilience-first posture the Five Eyes agencies recommended in their 2026 joint guidance. Defense-in-depth, honestly described, beats a silver bullet every time.