Skip to main content
← Learning Center
Technical Deep Dive

Why Your WAF Can't See Inside LLM Requests

Web application firewalls inspect HTTP traffic at the network layer. AI prompts, secrets, and injection attacks travel inside the request body — invisible to signature-based detection. Here's the architectural gap, explained.

The Architectural Blind Spot

Web Application Firewalls (WAFs) sit at the network perimeter — they inspect HTTP requests as they enter or leave your infrastructure. They look at URLs, headers, cookies, and request body byte patterns. This approach works brilliantly for traditional web threats: SQL injection in query parameters, XSS in form fields, path traversal in URLs.

But LLM API calls don't look like traditional web traffic. The sensitive content — an API key pasted into a prompt, a patient's medical history used as context, proprietary source code sent for code review — is buried inside a JSON string in the request body. To the WAF, it's just bytes. There's no signature for "an AWS secret key accidentally typed into a ChatGPT prompt."

This isn't a WAF deficiency — it's a layer mismatch. WAFs operate at OSI Layer 7 (application) but only at the HTTP protocol level. Shield operates inside the application, at the content layer — it reads the actual prompt text and makes semantic decisions about what should and shouldn't leave your machine.

The Layer Problem — Visualized

Your MachineAI App / IDEShield (Local Proxy)Tokenizes secrets hereRaw promptTokenizedInternet / TLSSecrets never reach hereWAFSees onlyencrypted bytesLLM ProviderReceives tokenized promptNo secrets exposedShield protection boundaryWAF visibility boundaryWAF blind spot

Shield tokenizes secrets on your machine before they reach the network. The WAF — positioned at the network perimeter — only sees encrypted TLS traffic. By design, it cannot inspect what it cannot decrypt.

Close the gap between your WAF and your AI traffic

PurfectShield runs locally on your machine — one binary, one config file. Tokenize secrets before they reach the network. Works alongside your existing WAF with zero conflict.

See Shield Pricing Book a Demo

Frequently Asked Questions

You can block the API endpoints, but that's an all-or-nothing approach — either your team can use AI tools or they can't. WAF rules operate on HTTP-level patterns (URLs, headers, request methods), not on the content inside the request body. A WAF can see that a POST went to api.openai.com, but it cannot inspect the prompt to determine whether it contains secrets. Shield lets you keep the API access while removing the sensitive content — redaction, not blocking.
Shield and WAFs solve different layers of the security stack. Your WAF handles network-layer threats — DDoS, SQL injection, XSS, bot mitigation. Shield handles application-layer AI threats that are invisible at the network level — prompt injection, secret leakage, PII exfiltration. They're complementary: WAF protects your infrastructure, Shield protects your data. Deploy both. Shield runs on the developer's machine as a local desktop app, so it doesn't conflict with your existing network security stack.
Shield uses a multi-layered detection approach: (1) Entropy-based scanning catches high-randomness strings that match the statistical profile of API keys and tokens — WAF regex rules miss these entirely because they don't match known attack signatures. (2) Regex pattern packs for 40+ credential types (AWS, GitHub, OpenAI, Stripe, etc.). (3) Domain-specific filter packs for PII, PHI, and PCI data. (4) Custom organization-specific patterns you define. Because Shield runs locally on your machine, it sees the raw prompt before encryption and before it hits the network — the WAF only sees encrypted TLS traffic.
ML-based WAFs improve detection of novel HTTP attack patterns, but they still operate on network-layer signals — request velocity, header anomalies, payload size distributions. They're trained on web attack traffic (SQLi, XSS, path traversal), not on the semantic content of AI prompts. An ML WAF might flag an unusually large JSON payload to an LLM endpoint, but it cannot distinguish between a legitimate 10KB code review prompt and one that accidentally includes your production database credentials. Shield operates at the right layer — inside the application, inspecting the actual text content.
API gateways validate request structure — correct JSON schema, valid authentication headers, rate limits. They don't inspect the semantic content of the request body for secrets or PII. An API gateway will happily forward a well-formed JSON request that contains your AWS root credentials in the prompt field. Shield fills this gap by operating as a local proxy that tokenizes sensitive content before it ever reaches the gateway. The gateway sees only tokenized placeholders; the original secrets never leave your machine.
Modern LLM APIs support function calling (tool use), structured JSON outputs, and MCP protocol tool invocations. These add new data exfiltration surfaces: a function call argument might contain customer data, a structured output schema might leak internal system design. WAFs have zero visibility into these — they see opaque JSON. Shield inspects every outbound payload regardless of format: function call arguments, tool parameters, structured output schemas, and standard prompt text all go through the same filter packs. If it leaves your machine, Shield has scanned it.