Kong AI Prompt Guard vs AI Semantic Prompt Guard: What Each Blocks and Where Evidence Stops

Two plugins, two matching mechanisms

Kong AI Gateway offers two plugins that filter prompts before they reach a model. They are often discussed as if one were a stronger version of the other. They are better understood as different mechanisms with different failure modes.

The AI Prompt Guard plugin applies allow and deny pattern rules. A prompt is evaluated against configured patterns, and the outcome depends on whether the text matches. This is lexical matching. It is predictable and easy to reason about: if a prompt contains a string that a deny pattern covers, the rule applies. The same property limits it. A pattern describes how text is written, not what it means, so its coverage is only as broad as the patterns someone thought to write.

The AI Semantic Prompt Guard plugin compares prompts against configured allow and deny topics using embeddings and a vector store. Instead of matching characters, it asks whether a prompt is close in meaning to a topic you have defined. That adds dependencies a pattern filter does not have: an embedding model, a vector store, and a similarity judgment that someone has to tune. Both plugins are described by Kong's documentation. The documentation describes configuration and matching behavior, which is different from showing how well either one performs against attackers.

Side-by-side comparison with an evidence boundary

The table separates what Kong describes from what has no public independent evidence. Where a row says not evidenced publicly, do not assume the answer in either direction.

• Matching method: AI Prompt Guard: allow and deny pattern rules. AI Semantic Prompt Guard: similarity to allow and deny topics using embeddings. Evidence: documented by Kong.
• Dependencies: AI Prompt Guard: the rule set itself. AI Semantic Prompt Guard: an embedding model and a vector store. Evidence: documented by Kong.
• What you maintain: AI Prompt Guard: patterns. AI Semantic Prompt Guard: topic definitions and the similarity settings that decide what counts as a match. Evidence: documented by Kong.
• Paraphrased or obfuscated attacks: Behavior of each plugin against these variants is not evidenced publicly.
• Detection accuracy, false positives, latency: No public independent testing identified for either plugin. Measure on your own traffic.
• Indirect injection, tool calls, model outputs: Coverage by either plugin is not evidenced publicly. Do not assume it.

Which prompts each plugin is documented to block

For direct, user-submitted prompts, the documented behavior follows from the mechanism. AI Prompt Guard blocks or allows prompts according to the patterns configured. AI Semantic Prompt Guard blocks or allows prompts according to how they relate to the configured topics. Kong's documentation does not, to our knowledge, extend either description into claims about attack categories.

That leaves several categories without public evidence. These include paraphrased or obfuscated attacks, off-topic requests that a topic list may or may not capture, and multi-turn context where intent builds across messages. Mechanism reasoning can suggest where each approach is likely to be stronger or weaker. A pattern rule is unlikely to match a rewording it does not list. A semantic comparison depends on how an embedding model represents a prompt and on where the similarity line is drawn. Those are hypotheses to test, not documented results.

NIST's guidance on generative AI offers a useful caution. It notes that many current systems restrict model outputs to limit certain content or in response to certain prompts, but that this approach may still produce harmful recommendations in response to other less-explicit, novel prompts. This is general context, not a finding about either Kong plugin. It does explain why a rule set built from known attacks should not be treated as complete.

Where prompt-level filtering ends

NIST's adversarial machine learning taxonomy states that defenses proposed for prompt injection provide a measure of protection but not full immunity to all attacker techniques. It also separates direct injection, where an attacker inputs a malicious prompt straight to the system, from indirect injection. NIST AI 600-1 ties prompt injection to downstream negative consequences for interconnected systems.

That framing matters when you decide what a prompt guard is for. Both plugins are described as acting on prompts. Whether either inspects system prompts, chat history, retrieved content, model responses, or tool calls is not something the public evidence establishes, so those stages should be treated as uncovered until you have tested them. In an agentic design, a model's tool call can have consequences that no prompt filter ever sees, and content retrieved from a document or web page can carry instructions the user never typed.

This is where a separate control point becomes relevant. Trussed takes a different approach: it enforces policy in the execution path across models, agents, tools, and MCP servers, with actions that include allow, redact, block, rate limit, and escalate for human approval. Its scope is individual interactions and tool calls, and enforcement produces audit-ready evidence for regulated enterprises. That is a complement to prompt-level filtering, not a replacement for evaluating it, and it makes no statement about the Kong plugins beyond what is described above.

Choosing between them, and recording the decision

The choice follows the threat you are addressing. If you need a deterministic rule for strings you already know you must stop, a pattern filter is a straightforward fit, and you can explain exactly why a prompt was blocked. If your concern is a topic boundary that cannot be expressed as a fixed string, a semantic approach is designed for that, at the cost of extra dependencies and tuning. Many teams will reasonably evaluate both, since they address different matching problems.

Whichever you choose, avoid describing it internally as a complete prompt-level control. NIST's position that defenses give partial protection supports treating each plugin as one layer among several. For governance, keep test cases, results, configuration versions, and dates, so a reviewer can see what was tested and what was not. Label each capability claim in your own documentation the way this page does: documented by the vendor, independently tested, or not publicly evidenced.