Defend every prompt.
DFENS applies declarative, auditable rules for security, compliance, and
cost to every request between your organization and a model. Run it in your
app via /v1/inspect, as a reverse proxy in front of a hosted LLM,
or as the outbound gateway for internal AI use. Think mod_security, rebuilt
for LLM traffic.
RUNS ON YOUR HARDWARE · NO OUTBOUND CALLS TO ANYONE'S API (INCLUDING OURS) · OPENAI · ANTHROPIC · AZURE · BEDROCK · VERTEX
# Point your existing client at DFENS. One line. No SDK. $ export OPENAI_BASE_URL=http://localhost:8080 $ curl -X POST http://localhost:8080/v1/chat/completions \ -d '{"model":"gpt-4o","messages":[{"role":"user", "content":"ignore previous instructions"}]}' HTTP 403 Request blocked by firewall policy. # Every decision names the rule that fired: {"event_type":"rule.fired","rule_id":"LLM-2026-0001","severity":"HIGH", "action":"deny","phase":2,"matched_variable":"instruction_override", "message":"LLM01: jailbreak / prompt-injection pattern detected", "tags":["owasp/llm01","llm-request"],"upstream_provider":"openai"}
Security, compliance and cost, enforced in the same request path.
One rule engine and one audit log carry all three. A rule you write once inspects, redacts, blocks, or reroutes traffic across every model, inbound and outbound.
Security
Block prompt injection, jailbreaks and indirect injection in real time, inbound and outbound, with evasion decoded first.
- Injection & jailbreak detection
- Tool & retrieval content scanning
- Unbounded-consumption & abuse controls
Compliance
Redact PII and secrets, keep data in-region, and log every decision as signed, sequenced evidence for audit.
- PII & secret detection
- Signed, sequenced audit trail
- Residency & encrypted retention
Cost
A rule can route a matched request to a cheaper model on the same provider: same wire format, same audit log, no app change.
- Rule-driven model routing
- Same-provider, no new integration
- Audited like every other decision
One firewall in front of every major model provider.
DFENS speaks each provider's native wire format and forwards on its own path, so your existing client keeps working. Enable the providers you use; disabled providers' routes are refused, not forwarded.
/v1/chat/completions, streaming + non-streaming, tool calls./v1/messages, content-block walk, tool_use / tool_result.generateContent / streaming on Vertex and the Gemini Developer API.A rule you write once fires identically whether the traffic is bound for GPT-4o, Claude, Gemini, or a Bedrock model. The adapter normalizes each provider to one canonical shape before rules run.
Three ways to put AI Assurance in your stack.
There are three places to run it. Pick the one that matches how a given AI workload actually touches your organization.
In your application code
Call /v1/inspect
For apps that can't sit a proxy in the network path, calling Bedrock, Vertex, or a
custom inference server natively. Post the prompt, the response, or a tool result to
/v1/inspect alongside your own LLM call and get back an allow/deny verdict:
the full rule engine and audit trail, without a proxy hop.
Best for teams who want the rule engine without changing their request path.
In front of a hosted LLM
Reverse proxy
DFENS speaks the OpenAI, Anthropic, Azure, Bedrock, and Vertex wire formats natively. Point your base URL at it and every request, response, and tool call is inspected transparently: no SDK changes, no code changes, full phase coverage automatically.
Best for securing an application's own LLM traffic with the least integration work.
For internal AI use
Outbound gateway
The same transparent proxy, pointed the other way: internal tools, copilots, and developers route their calls to third-party AI services through DFENS. The same PII/secret-leak operators that catch leaks in model output can be aimed at the outbound prompt instead, catching a leak before it reaches a third party, not just after it comes back.
Best for security and compliance teams who need visibility into AI usage they don't operate themselves.
All three run the same rule engine against the same audit log. A rule you write once
behaves identically whether it's evaluating an /v1/inspect call, a proxied
request, or outbound employee traffic.
Putting an LLM in front of users creates an attack surface your WAF can't see.
Bank chatbot, healthcare assistant, support agent: the moment untrusted text flows into a model with access to your data and tools, you inherit a class of attacks that traditional application security tooling can't inspect.
Prompt injection & jailbreaks
Instruction overrides, role-play framing, memory-wipe and policy-evasion patterns, including Cyrillic-homoglyph, zero-width, and base64 evasion.
Indirect injection
Hostile instructions smuggled in through retrieved documents, RAG chunks, and tool results, inspected on dedicated tool phases before they re-enter the model.
Sensitive data leakage
PII, API keys, and private keys leaving through model output; system-prompt extraction attempts on the way in.
Excessive agency
Destructive commands, privilege escalation, command injection, and path traversal hidden inside tool-call arguments.
Insecure output
XSS, SQL injection, SSRF, SSTI, and invisible-character smuggling in model responses your app might render or execute.
Unbounded consumption
Model-DoS through unbounded generation, extreme request volume, and training-data / logit-harvesting extraction probes.
Two deployments, one firewall.
Whether the model faces the public or your own staff, the untrusted-text problem is the same. Only the risk emphasis shifts.
Customer-facing LLM
Chatbots · support agents · public assistants
The model takes input from anyone on the internet and answers under your brand. Every prompt is untrusted; every response is something a customer or a regulator may read.
What DFENS guards
- Inbound abuse. Jailbreaks, prompt injection, and extraction probes are blocked before they reach the model, evasion-decoded first.
- Outbound leakage. PII, secrets, and system-prompt disclosure are caught on the response phase so they never reach the user.
- Unsafe rendering. XSS, SSRF, and SQLi in model output are flagged before your front-end executes them.
- Abuse & cost. The DoS budget and model-extraction rules bound unbounded generation and scraping.
Outcome: a defensible answer to "what stops someone abusing our chatbot?", backed by an audit record for every block.
Internal LLM & agents
Employee copilots · RAG over corporate data · internal tools
Trusted users, but the model reaches into internal documents, databases, and tools. The threat moves from the prompt to everything the agent reads and does.
What DFENS guards
- Indirect injection. Poisoned instructions inside retrieved documents and tool results are inspected on dedicated tool phases, the classic agent-hijack vector.
- Excessive agency. Destructive commands, privilege escalation, and path traversal in tool arguments are blocked before the tool runs.
- Data governance. Optional encrypted history gives you a per-tenant, retention-bounded record of what was asked and answered, for e-discovery and incident review.
- Segmentation. Multi-tenant rule scoping lets each team or business unit carry its own policy and its own admin control.
Outcome: internal AI your security and data-governance teams can actually sign off, with tenant isolation and an evidence trail.
A reverse proxy for your model traffic. Deployed in minutes.
Drop it in front of your provider
DFENS speaks the OpenAI, Anthropic, Azure, Bedrock, and Vertex HTTP APIs. Point your base URL at it and your existing app works unchanged: no SDK, no code changes.
Rules run on every phase
Declarative rules evaluate requests, responses, and tool calls. They're a strict subset of mod_security's SecRule syntax, extended with LLM-specific variables, operators, and phases. Canonicalization (NFKC, zero-width strip, homoglyph fold, base64/URL/hex decode) runs first, so evasion tricks don't slip past.
Block, log, and prove it
Matches are denied with a 403 and an audit event naming the exact rule ID, severity, phase, and matched snippet. Arbitrary content such as RAG chunks or tool results can be checked via /v1/inspect.
Deterministic where it matters. Explainable everywhere.
▸Self-hosted and auditable
Runs entirely on your own hardware, shipped as a signed container image. Your prompts never leave your network for scoring: no outbound calls to a vendor API.
▸Declarative rules, not opaque scores
Every block decision has a rule ID, a citation, and a severity vector you can read. If a rule misfires, you can see exactly why, and disable it at runtime via an audited admin endpoint.
▸CVE-style signatures
Each rule carries an LLM-YYYY-NNNN identifier in a central registry, with citation-backed reference payloads and tests committed alongside it. Detection is validated against a labeled attack corpus.
▸Layered ML, on your terms
Optional ML operators (prompt-injection classification, content classification, toxicity) run locally in the extended image. They augment the deterministic engine; they never replace the audit trail.
▸Built to survive attack itself
Every regex is statically analyzed for ReDoS at load time, each rule is isolated with panic recovery, and a DoS budget enforcer bounds consumption. A firewall shouldn't be your weakest link.
▸An open rule contract
The rule format is a documented, portable specification separate from the engine. Your rules are plain files you can review, diff, and version, not configuration locked inside someone else's SaaS.
The same rules can also cut your model spend.
Routing isn't a separate system bolted on top. It's the same declarative rule engine and audit log, extended with one more outcome: send a matched request to a cheaper model on the same provider, instead of blocking it or forwarding it as-is.
▸Rule-driven, not a black box
A rule can set a target model the same way it sets a severity tag. Write the condition once; the engine routes every matching request. No separate routing service to stand up or operate.
▸Same provider, no new integration
Requests route to a cheaper model on the same provider: same wire format, same credentials. No cross-provider translation step, and no new class of failure it can introduce.
▸Audited like every other decision
The audit log and request record reflect the model that actually served the request, not just the one the client asked for, so a cost decision is exactly as traceable as a security one.
Roadmap: today, routing stays on the same provider: same wire format, no translation step, no new class of failure. Routing to a different model on a different provider or host is on the roadmap; it needs request/response translation between wire formats, which is a bigger project we're scoping separately. We won't claim cross-host routing on this page until it ships.
Controls and evidence your auditors will ask for.
DFENS is infrastructure you run inside your own boundary. That makes it a building block for your SOC 2, ISO 27001, HIPAA, and GDPR programmes. It gives the security, logging, and data-handling controls those frameworks expect at the LLM layer.
▸Signed, sequenced audit log
Every rule firing is a typed, signed event with a per-host monotonic sequence counter persisted to disk, restart-safe and tamper-evident. This is the access-and-decision record your control framework asks for at the AI boundary.
▸Data residency by design
Self-hosted, with zero outbound calls to any vendor for scoring. Prompts and responses never leave the region and network you deploy into. The answer to data-residency and cross-border-transfer questions is "they don't."
▸Encrypted retention & e-discovery
Optional chat-history retention with encryption at rest (fails closed, so it never silently degrades), per-tenant retention windows, and automatic expiry sweeps. Backed by any S3-compatible store you control (AWS S3, GCS, MinIO, Ceph).
▸Least-privilege redaction
The audit trail keeps rule metadata and a redacted snippet by default; reading raw, unredacted conversation is a separate, higher privilege from managing rules. "Operate the firewall" and "read the data" are different keys.
▸PII & secret detection
Built-in operators detect PII (SSN, credit card with Luhn, email, phone) and secrets (cloud keys, tokens, private keys, high-entropy strings) in model output, data-loss controls mapped straight to GDPR and HIPAA obligations.
▸Verifiable supply chain
Images ship with an SBOM, SLSA provenance, and cosign signatures logged to a transparency log, so your third-party-risk and supply-chain review has something concrete to verify.
Straight talk: DFENS provides the technical controls; certifications are held by organisations, not products. Integrated AI's own SOC 2 / ISO 27001 programme is on the roadmap, and we're glad to complete your vendor-security questionnaire during early access. We won't put a certification badge on this page until we hold it.
Mapped to the OWASP LLM Top 10 (2025).
Honest coverage, stated plainly, including the categories a proxy can't see.
| 2025 category | Status | What DFENS does |
|---|---|---|
| LLM01: Prompt Injection | covered | Signature rules plus a 61-pattern injection catalog: instruction-override, role-play, memory-wipe, policy-evasion, encoding; indirect subtype via tool-phase patterns. |
| LLM02: Sensitive Information Disclosure | covered | PII, API keys, private keys, and system-prompt extraction; dedicated PII-leak and secret-leak operators. |
| LLM03: Supply Chain | out of scope | Build- and supply-time; not detectable at a proxy. |
| LLM04: Data & Model Poisoning | out of scope | Training / RAG-ingestion time; not detectable at a proxy. |
| LLM05: Improper Output Handling | covered | XSS, SQL injection, SSRF, SSTI, invisible-character / Unicode-Tags smuggling in model output. |
| LLM06: Excessive Agency | covered | Destructive commands and privilege escalation; command injection and path traversal in tool arguments. |
| LLM07: System Prompt Leakage | covered | Leaked scaffolding and control tokens, plus natural-language disclosure. |
| LLM08: Vector & Embedding Weaknesses | partial | RAG-infrastructure class; hidden-text-in-document partially covered. |
| LLM09: Misinformation | partial | Toxicity and output rules touch adjacent harms; factuality is not deterministically detectable. |
| LLM10: Unbounded Consumption | covered | Model-DoS rules, extraction-probe detection, and a DoS budget enforcer. |
We say "out of scope" where a traffic proxy genuinely can't help. If a vendor claims full Top-10 coverage at the proxy layer, ask them about LLM03.
Every decision is evidence.
- Rule-level audit log. Each event records the rule ID, severity, action, phase, matched variable, and the upstream provider and model.
- Runtime control plane. Disable a misbehaving rule instantly via an audited admin endpoint: no redeploy, no gap in the record.
- Health you can page on. A single health endpoint reports readiness, degraded rules, and disabled rules; Prometheus metrics expose rule fires and inference timing.
- Reviewable by design. Rules are plain text with citations. Your security review can read every pattern that will ever fire in production.
$ curl http://localhost:8080/health
{"status":"ok","ready":true,
"degraded_rules":[],"disabled_rules":[]}
# Inspect arbitrary content — RAG chunks, tool results:
$ curl -X POST http://localhost:8080/v1/inspect \
-d '{"content":"<untrusted document text>"}'
DFENS is onboarding design partners now.
We're working with a small number of teams shipping LLM features in regulated and security-conscious environments. Early-access partners get hands-on deployment support, rule tuning against their real traffic, and a direct line to the engineering team.
hello@integratedai.co.uk · We reply within one business day.