A WAF That Reads the Prompt: OWASP CRS for LLM and MCP

Originally published at webofmike.com on 2026-09-20. The demo repo and every command in it were run before publishing.

A conventional web application firewall reads a URL, some headers, and maybe a form body. For agent traffic that is the wrong layer. The interesting content is in the request body: the prompt for an LLM call, and the method, tool name, and arguments for an MCP call.

Solo Enterprise for agentgateway runs Coraza, the OWASP-maintained rules engine, as a shared extension. With body inspection turned on, the OWASP Core Rule Set that a security team already knows how to reason about applies to prompts and tool calls, and the SOC can add its own signatures in SecLang without touching an agent, a model, or an MCP server.

The policies are in themsquared/agentic-demo under manifests/governance/. Every status code below came from a live cluster on v2026.8.2.

The config that makes body inspection actually happen

Two settings do the work, and skipping either one produces a WAF that passes every payload while looking healthy.

apiVersion: waf.solo.io/v1alpha1
kind: WAFPolicy
metadata:
  name: governed-llm-waf
  namespace: agentgateway-system
spec:
  processingConfig:
    request:
      mode: HeadersAndBody          # 1. buffer the body at all
  coreRuleSet:
    settings:
      inline: |
        SecDefaultAction "phase:1,log,auditlog,deny,status:403"
        SecDefaultAction "phase:2,log,auditlog,deny,status:403"
        SecAction "id:900990,phase:1,pass,t:none,nolog,tag:'OWASP_CRS',ver:'OWASP_CRS/4.23.0',setvar:tx.crs_setup_version=4230"
  ruleEngineSettings:
    inline: |
      SecRuleEngine On
      SecAuditEngine RelevantOnly
      SecAuditLog /dev/stdout
      SecAuditLogFormat JSON
      SecAuditLogParts AKHZ
      # 2. parse the JSON body into ARGS so rules can see prompt fields
      SecRule REQUEST_HEADERS:Content-Type "^application/json" \
        "id:200001,phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON"

mode: HeadersAndBody makes the body available. Rule 200001 makes it structured: without the JSON body processor the body is one opaque blob, and rules matching on ARGS have nothing to match against. With it, a chat completions request becomes addressable fields, and ARGS covers json.model, json.messages.0.content, and everything else in the document.

Custom signatures go alongside CRS. These three are the AI-specific ones, in a rule ID range reserved for them:

  customDirectives:
  - inline: |
      SecRule ARGS "@rx (?i)ignore\s+(all\s+)?(previous|prior|above)\s+instructions" \
        "id:9001,phase:2,deny,status:403,log,msg:'LLM prompt injection: instruction override'"
      SecRule ARGS "@rx (?i)\b(DAN|developer)\s+mode\b|\bjailbreak\b" \
        "id:9002,phase:2,deny,status:403,log,msg:'LLM jailbreak framing'"
      SecRule ARGS "@rx (?i)(print|reveal|show|repeat)\s+(your|the)\s+(system\s+prompt|hidden\s+instructions)" \
        "id:9003,phase:2,deny,status:403,log,msg:'LLM system-prompt exfiltration attempt'"

Attaching it to a route is a separate resource, which means one WAFPolicy can be reused across many routes:

apiVersion: enterpriseagentgateway.solo.io/v1alpha1
kind: EnterpriseAgentgatewayPolicy
metadata:
  name: governed-llm-waf
  namespace: agentgateway-system
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: governed-llm
  traffic:
    entWAF:
      wafPolicyRef:
        name: governed-llm-waf

What gets blocked on an LLM route

Same authenticated user for every row, so the only variable is the payload:

The last three are stock CRS with no AI-specific configuration at all. A gateway carrying LLM traffic is still an HTTP endpoint, and it gets scanned like one.

The caller sees whatever you configure, and terse is better than descriptive:

{"error":{"type":"policy_violation","message":"Request blocked by the enterprise AI WAF policy."}}

The detail belongs in the audit log, not in a response body that an attacker is reading to tune their next attempt.

The false-positive question, answered before it is asked

The first thing anyone with WAF operating experience asks is what this does to legitimate traffic. Prompt text is long, unpredictable, and full of strings that look hostile out of context. So the test suite includes a deliberately awkward but entirely real engineering prompt: a SQL keyword, a URL with query parameters, diagnostic codes, and a firmware version.

curl -s -o /dev/null -w '%{http_code}\n' localhost:8081/governed-llm/v1/chat/completions \
  -H "Authorization: Bearer $TOKEN" -H 'content-type: application/json' \
  -d '{"model":"acme-standard","max_tokens":30,"messages":[
       {"role":"system","content":"You are a helpful assistant for platform engineers."},
       {"role":"user","content":"Summarize in two sentences: our device logs show intermittent bus errors (code 639, severity 9) on the v2 platform after firmware 2.4.1; the SELECT statement in our telemetry pipeline returns duplicates; and the admin portal at https://example.com/portal?id=42&view=full times out under load."}]}'

Returns 200. That single case is worth keeping in CI, because the moment someone raises the CRS paranoia level or adds a broad custom rule, this is the request that tells them what it cost.

The same firewall in front of MCP

This is the part I had not seen done. MCP is JSON-RPC over HTTP, so once the body is parsed, the WAF can address the protocol's own structure: json.method, json.params.name, and every entry under json.params.arguments.

Two custom rules cover the MCP-specific cases:

  customDirectives:
  - inline: |
      # 9101 - JSON-RPC method allowlist
      SecRule ARGS:json.method "!@rx ^(initialize|notifications/initialized|ping|tools/list|tools/call)$" \
        "id:9101,phase:2,deny,status:403,log,msg:'MCP method not allowlisted'"
      # 9102 - prompt injection inside any tool argument
      SecRule ARGS:/^json\.params\.arguments\./ "@rx (?i)ignore\s+(all\s+)?(previous|prior|above)\s+instructions" \
        "id:9102,phase:2,deny,status:403,log,msg:'MCP tool argument carries prompt injection'"

Open a real MCP session against the governed route, then send it a mix of honest and hostile calls:

The honest call returns what it should:

{"jsonrpc":"2.0","id":8,"result":{"content":[{"type":"text",
 "text":"Weather in Portland: Temperature: 77 F, Humidity: 87%, Wind: 14.2 mph"}],"isError":false}}

and a blocked one gets a JSON-RPC shaped error rather than raw HTML, which matters because the caller is an MCP client that has to parse it:

{"jsonrpc":"2.0","error":{"code":-32000,"message":"Request blocked by the enterprise MCP WAF policy."}}

Rows three and four are the ones I find most useful to point at. Nobody wrote an MCP-specific rule for either. ../../etc/passwd in a city parameter is path traversal, and a script tag is XSS, whoever sends them and whatever field they arrive in. Twenty years of CRS signatures apply the moment the arguments are parseable.

A method allowlist is protocol-level least privilege

Rule 9101 is the one I would put on every MCP route first, ahead of any content signature.

An MCP server exposes more than tools. There are resources, prompts, sampling, and completion methods in the protocol, and a given client usually needs a small subset. A client that only needs to call tools needs exactly five methods. Everything else is surface that exists because the protocol defines it, not because anyone needs it.

resources/list returning 403 in the table above is that rule working. The MCP server behind the gateway still implements the method. The client just cannot reach it, and the decision is made before the server is contacted.

This is the same reasoning a network team already applies when they allow four ports instead of the whole range. It transfers cleanly to a tool protocol, and unlike an authorization policy it needs no identity model to be useful.

What the WAF recorded

Blocks are only worth as much as their audit trail. With SecAuditLogFormat JSON and SecAuditLog /dev/stdout, every intervention lands in the WAF server's log, and the messages name the rule that fired:

kubectl logs deploy/waf-server-enterprise-agentgateway -n agentgateway-system \
  --since=3m | grep -oE '"msg":"[^"]*"' | sort | uniq -c | sort -rn

   2 "msg":"MCP method not allowlisted"
   1 "msg":"XSS Attack Detected via libinjection"
   1 "msg":"SQL Injection Attack Detected via libinjection"
   1 "msg":"Path Traversal Attack (/../) or (/.../)"
   1 "msg":"MCP tool argument carries prompt injection"
   1 "msg":"LLM prompt injection: instruction override"
   1 "msg":"LLM jailbreak framing"
   1 "msg":"Found User-Agent associated with security scanner"

Custom rules and CRS rules appear in the same stream with the same shape, which is what makes this usable by a team that already has ModSecurity or CRS dashboards. There are Prometheus counters on the same server:

waf_server_requests_total{action="allow",reason=""} 64
waf_server_requests_total{action="deny",reason="waf_blocked"} 77
waf_server_policy_status{name="governed-llm-waf",status="active"} 1

Ordering, and one failure mode worth knowing

The WAF is not the first thing a request meets. On this route the order is JWT authentication, then CEL authorization, then WAF. An anonymous caller gets 401 and a caller denied by policy gets 403 without the firewall ever running. Everything the WAF blocks is therefore an authenticated, authorized user sending a hostile payload, which is a much more interesting signal than raw block counts from the open internet.

I wrote about the authorization layer that sits in front of this in two agentgateway CEL gotchas, including one where the policy silently permits requests it looks like it should deny. Worth reading before you rely on that layer to filter what reaches the WAF.

The failure mode to know: an invalid WAFPolicy fails closed. A rule that does not compile takes the route to HTTP 500 rather than passing traffic through unfiltered. That is the right default, and it means a 500 after a WAF change is almost always a compilation error rather than runtime blocking:

kubectl describe wafpolicy governed-llm-waf -n agentgateway-system
# check status.conditions[type=Ready]

Running it

./setup.sh              # k3d cluster, mesh, gateway, agents (~15 min)
./port-forward.sh
./governance-demo.sh --act 3

Act 3 applies both policies and runs every request in the two tables above, printing the status code next to what was expected. --check runs the whole governance walkthrough non-interactively and asserts 24 outcomes.

It needs a Solo Enterprise license, since WAFPolicy and EnterpriseAgentgatewayPolicy are enterprise CRDs. The rules themselves are plain SecLang and OWASP CRS, so the signatures port to any Coraza or ModSecurity deployment. What the gateway supplies is the position: one place where every LLM and MCP request is already passing through, with the body already parsed.

Next: what happens to the record when you stop an agent that has already done something you did not like.

Frequently asked questions

Can a web application firewall inspect LLM prompts?

Yes, if request body inspection is enabled and the body is parsed as JSON. Setting processingConfig.request.mode to HeadersAndBody and adding a Coraza rule with ctl:requestBodyProcessor=JSON turns a chat completions body into inspectable ARGS, so both OWASP Core Rule Set rules and custom SecLang signatures evaluate against the prompt text rather than only the URL and headers.

How do you apply OWASP CRS to MCP tool calls?

MCP is JSON-RPC over HTTP, so the same body-aware WAF sees the method, the tool name, and every tool argument as JSON fields. CRS rules then evaluate against argument values, which is how a city parameter containing ../../etc/passwd is caught as path traversal and one containing a script tag is caught as XSS, with no change to the MCP server.

How do I restrict which MCP methods a client can call?

Write a Coraza rule that negates a regex against the JSON-RPC method field, for example SecRule ARGS:json.method with !@rx matching only initialize, notifications/initialized, ping, tools/list and tools/call. Anything outside the list, such as resources/list or prompts/get, is refused with 403 at the gateway. It is protocol-level least privilege, enforced before the MCP server is contacted.

Canonical version, with machine-readable markdown at https://webofmike.com/waf-for-llm-and-mcp-traffic/index.md: https://webofmike.com/waf-for-llm-and-mcp-traffic/