What breaks when prompt injection controls rely on keyword filters alone?

Why keyword filters break on semantic prompt injection

Keyword filtering fails because the attack is about meaning, not exact wording. A malicious instruction can be paraphrased, split across lines, disguised as ordinary content, or embedded in data the model is likely to treat as trustworthy. In practice, a filter that only blocks known phrases gives a false sense of coverage while leaving most real attack variants untouched.

That is why guidance for prompt injection has moved toward layered defences, not single-point text screening. A useful control stack looks at content before it is installed into prompts or memory, watches what the agent does at runtime, and constrains the agent’s reachable actions so a successful injection does not automatically become a high-impact event. Prompt Injection Guide

In other words, the broken assumption is that dangerous instructions will announce themselves in a stable form. Real attackers adapt to the filter, while benign content can also contain patterns that look suspicious out of context. The control therefore misses both malicious paraphrases and legitimate edge cases, which makes it brittle as a primary safeguard.

What kinds of attacks keyword-only controls miss

Semantic attacks can arrive through direct prompts, indirect prompts hidden in documents or web content, poisoned retrieval sources, and tool-related instructions that only become dangerous after the agent reads or executes them. The common thread is that the model or agent interprets the content as instruction-bearing even when the exact banned keyword never appears. That is why the same weakness shows up across chat assistants, coding agents, retrieval systems, and browser-driven agents.

Attackers also benefit from fragmentation and indirection. They can spread an instruction across multiple sentences, use synonyms, insert benign filler, or rely on formatting that the filter does not parse well. A keyword rule might catch obvious jailbreak phrases, yet still allow the underlying intent to pass through in a form the system will obey. OWASP Agentic AI Top 10

The practical failure mode is not just missed detection, but misplaced trust. If the system treats every filtered prompt as safe, it may allow unsafe retrieval, unsafe tool calls, or unsafe action execution when the same instruction is repackaged in a different form. That makes the control easy to bypass and hard to validate by simple test cases alone.

How to harden prompt injection defence beyond filters

A stronger design separates content handling, model interpretation, and action execution. Content should be screened and normalised before it is allowed into the agent’s working context, but runtime behaviour still needs policy checks because the harmful outcome often happens at the tool or action layer rather than the text layer. That means you need visibility into what the agent attempted to do, not only what words it saw.

Access limits matter just as much as detection. If an injected instruction succeeds, the blast radius should still be small because the agent can only reach approved tools, scoped data, and narrow permissions. For browser or desktop agents, isolation and session boundaries are especially important because the attack often tries to turn trusted user sessions into a channel for exfiltration or misuse. Browser and Computer-Use Agent Security Guide

Testing should also reflect adversarial variation, not just keyword hits. Teams need examples that include paraphrase, hidden instructions, indirect injection, and poisoned content sources, then verify whether the system still blocks unsafe tool calls or data exposure when the wording changes. That is a better measure of control strength than counting how many obvious phrases the filter catches.

Risk and Threat Considerations

Keyword-only defences create a predictable bypass path: the attacker only needs to change the phrasing, not the objective. That matters because prompt injection is often used to steer retrieval, trigger unauthorized tool use, or cause data leakage from the agent’s context or connected systems.

Failure mechanism: The filter keys on surface strings instead of intent, so paraphrased, fragmented, or embedded instructions pass through and are then acted on by the model or agent.

Impact: A successful injection can lead to context exfiltration, unsafe tool execution, workflow corruption, or broader compromise of whatever the agent is allowed to reach.

Practitioner Guidance

What to verify: Check whether your controls stop the same malicious instruction when it is rewritten, split across multiple lines, or hidden inside benign-looking content. If they only work on a small library of known phrases, treat them as a detection aid, not a security boundary.

Decision rule: If a prompt can influence tool use, retrieval, or action execution, the control must be validated at those layers, not only at text ingestion. If the system cannot safely limit what the agent may do after manipulation, reduce its privileges before expanding its prompt handling logic.

Practitioner takeaway: The real boundary is not the keyword list, it is whether the system can absorb a manipulated prompt without converting it into a harmful action or data exposure.

Related resources from NHI Mgmt Group

• Guide: Agentic AI Security Guide
• Why do generative AI abuse controls fail when they rely on generic keyword filters alone?
• What breaks when organisations rely on traditional input validation alone to stop prompt injection?
• What breaks when LLM prompt filters rely on keywords alone?
• What is the difference between prompt injection risk and identity abuse in agents?