Can DeepInspect run LLM Guard's scanners?

The scanner concepts overlap with DeepInspect's classification step. DeepInspect classifies prompt content for PII, PHI, prompt-injection signatures, and policy-defined data classes at the proxy layer. The classification result feeds the policy decision. DeepInspect supports plugging classifier stages into the policy chain when a customer wants to reuse an existing scanner. Most deployments find the DeepInspect-native classification covers the same ground LLM Guard scanners do, without the in-process integration overhead.

What if our application teams already use LLM Guard?

LLM Guard remains in place. The DeepInspect proxy sits one layer further out, between the application and the LLM provider. The application's scanner stack continues to run on the prompt before it leaves the process. The proxy runs identity and policy checks on the outbound HTTP call. The two layers do not interfere with each other. Some enterprise customers run both for defense in depth: the in-process scanner catches application-specific risks early, and the proxy enforces the enterprise-wide policy with the audit record regulators accept.

How does this comparison hold for vendor SaaS AI usage?

LLM Guard requires application code changes. Vendor SaaS apps that embed models do not expose their LLM calls to the customer's application code, so LLM Guard cannot run on those calls. The customer remains the deployer under EU AI Act Article 12 and inherits the disclosure obligation. DeepInspect, when placed in the customer's egress path, sees the SaaS-to-LLM traffic and produces the audit record the customer needs. The architectural reach is wider.

DeepInspect vs LLM Guard: Two Different Layers of the AI Stack

Q: Does LLM Guard satisfy EU AI Act Article 12 by itself?

Article 12 requires automatic recording of AI events over the system lifetime with identification of the natural persons involved and enough detail to reconstruct the decision. LLM Guard records its scan verdicts inside the application's log stream. The verdict log is generated and stored by the same application that handles the LLM request. Self-attestation by the system under audit fails the independence test. The records can be modified, suppressed by code paths the security team never sees, or lost when the application crashes after the response but before the log commit. LLM Guard alone fails Article 12 in regulated deployments.

Protect AI shipped LLM Guard as an open-source Python toolkit in late 2023. It scans LLM inputs and outputs for prompt injection patterns, PII, toxic content, and policy violations. The scan runs inside the application process and returns a verdict the application code acts on. DeepInspect operates at a different layer of the stack: an HTTP proxy that intercepts AI traffic before it reaches the model and produces a signed, identity-bound audit record for every decision.

I want to walk through how the two tools differ architecturally, what each one covers, and how the buying decision changes when EU AI Act Article 12 or NIST AI RMF identity-and-authorization framing enters the requirement set.

TL;DR

LLM Guard is an in-process scanner that returns verdicts to the application. DeepInspect is an external enforcement layer that intercepts AI traffic at the HTTP boundary, enforces identity-aware policy, and writes per-decision audit records the application cannot reach.

LLM Guard: where it sits

LLM Guard is a Python library distributed under the MIT license by Protect AI. The library exposes a collection of "scanners" for input and output side of an LLM call. Input scanners include detectors for prompt injection, PII, prompt-template tampering, and token limits. Output scanners include toxicity, factual consistency, and refusal-pattern checks.

The execution model is a function call inside the application. A developer imports the library, instantiates the scanners, and passes the prompt through them before the LLM call. The scanners return a sanitized prompt or a hard refusal. After the LLM responds, the output scanners run a second pass.

What LLM Guard handles well

Single-application prompt sanitization. PII detection at the prompt level via the same scanner libraries the broader Protect AI suite uses. Prompt-injection regex matches against the Lakera, Rebuff, and Garak adversarial datasets. Lightweight integration when the application is greenfield and the team owns the LLM call site.

Where LLM Guard ends

The scanner sees the prompt text. The scanner does not see the identity of the user behind the prompt. The verdict is logged inside the application. The application can ignore the verdict in code branches the security team never reviews. If the application crashes mid-call, the verdict is lost. The same application that handles the LLM request also writes the audit log, which fails the self-attestation test the EU AI Act applies.

Where DeepInspect sits

DeepInspect intercepts the HTTP request as it leaves the application en route to the LLM provider. The proxy reads identity headers the application supplies, evaluates policy against per-route and per-role rules, classifies the prompt content, decides permit or redact or deny, and commits a per-decision audit record to a tamper-evident log before the model response returns. The record contains identity, role, policy version, classification, decision outcome, and a cryptographic signature.

The execution model is out-of-process. The application makes its HTTP call to the DeepInspect endpoint instead of directly to the LLM provider. The proxy is the policy decision point. The audit record lives independent of the application.

What DeepInspect handles

Identity-bound enforcement across every LLM endpoint the enterprise uses, including vendor SaaS that embeds models. Per-decision audit records signed and committed before the application receives the response. EU AI Act Article 12 logging that satisfies the natural-person identification requirement. NIST AI RMF Pillar 1 identity, Pillar 2 authorization, and Pillar 3 action lineage. Sub-50ms enforcement overhead from internal testing.

Feature comparison

| Property | LLM Guard | DeepInspect | |---|---|---| | Execution model | In-process Python | Out-of-process HTTP proxy | | Scope | One application | All AI traffic, enterprise-wide | | Identity context | Not captured | Required, per request | | Audit independence | Application-controlled | External, tamper-evident | | EU AI Act Article 12 fit | Partial | Structural | | NIST AI RMF Pillars 1-3 | No | Yes | | Prompt-injection detection | Yes, regex + ML | Yes, plus identity-bound block | | PII / PHI detection | Yes | Yes | | Per-route policy | Manual application code | Native | | Per-role policy | Manual application code | Native | | Fail-closed default | Configurable | Yes | | Coverage of vendor SaaS AI | No | Yes | | Open source | Yes (MIT) | No (commercial) | | Performance overhead | ~10-30ms per scanner | Sub-50ms total p95 from internal testing |

Pick LLM Guard if

You are building a single LLM application and you control the call site. You want prompt-injection regex and PII scanners that ship with sensible defaults. You are comfortable maintaining the scanner stack in your application's deployment pipeline. The regulatory exposure is light and identity-aware logging is handled by a separate audit system the application code writes into. You want an MIT-licensed toolkit you can read and modify.

Pick DeepInspect if

You are running AI in a regulated environment subject to the EU AI Act, HIPAA, GDPR, or NIST AI RMF. You need audit records that survive an auditor's questions about identity and policy state. You have multiple AI endpoints and the policy must apply consistently across them, including vendor SaaS embedding models. You face the August 2, 2026 EU AI Act high-risk-system deadline.

Pricing approach

LLM Guard is free under the MIT license. The operational cost is engineering integration time and infrastructure for the application that hosts the scanners. Updates require redeploying the application. DeepInspect is commercial and priced per-deployment based on traffic volume. Pricing is communicated through sales conversations.

DeepInspect

DeepInspect was built for regulated environments where the audit record matters more than the prompt-level verdict. LLM Guard inspects content. DeepInspect enforces identity-aware policy and produces the evidence regulators ask for.

In deployments that run both, LLM Guard handles application-level prompt sanitization inside a specific chatbot. DeepInspect captures the identity context, applies the same policy across every AI endpoint the enterprise touches, and writes the audit record the chatbot's application cannot tamper with. The two layers complement each other when the customer's compliance exposure crosses a regulatory threshold.

If you are facing the August 2 EU AI Act deadline and your current AI architecture relies on in-process scanners alone, the audit-record gap surfaces the first time a regulator asks who initiated a specific request. Book a demo today.