The enforcement layer for AI traffic

Redact supported PII. Record the decision.

Interdict sits between your applications and every supported model. It blocks unsafe requests, controls where sensitive data can go, enforces provider, model, and budget rules, and inspects responses before they return to your application.

One-month free trial · no credit card · 10,000 requests included. Your model provider bills its own usage separately.

The problem

AI creates a new exit point for sensitive data.

Your databases can be encrypted, permissioned, and compliant while the application still sends too much context to a third-party model. The AI call needs its own enforcement boundary.

Protected systemsSource dataRBAC · encryption · access policy
Application layerContext assemblyPrompts · RAG · tools · records
External boundaryAI providerWhat is actually allowed to leave?
The enforcement gap
01Sensitive data

What is your application allowed to send?

SSNs, dates of birth, emails, phone numbers, payment data, and other sensitive values can travel inside prompts, tool arguments, and model responses. Direct provider calls give security teams no single place to decide where each data type is allowed to go.

02Policy drift

Who decides which provider, model, and spend are acceptable?

AI applications can change providers, models, output limits, streaming behavior, and usage patterns quickly. Without a shared enforcement point, those controls become scattered across application code and provider-specific settings.

03Request + response risk

What happens before and after generation?

Prompt-injection attempts arrive before the provider call. Sensitive data can appear again in model output. If the only security boundary is the model itself, important checks happen too late or in different places.

The AI handoff

What reaches the model, and what comes back, runs through Interdict first.

Context assembled by your app is evaluated at the handoff to the provider, and the response is inspected on the way back — so the runtime moment data leaves for a model is governed, not assumed.

Context assembled by your app
User inputForms, chat, uploads
Retrieved contextRAG, records, search
Tool dataAPIs, functions, workflows
Interdictruntime policy
Decide what crosses the boundary
BlockRedactAllowVerify
PII classificationPrompt-injection policyProvider + model policyBudget + token guards
Approved destinationAI providerOnly the context policy permits
Response returns through InterdictPII inspection · audit · alerts
Scope

Interdict protects the runtime request and response boundary. It complements upstream data cataloging, access control, and retrieval governance rather than replacing them.

01

Protect delivery, not just storage

Database permissions can be correct while an application still assembles more sensitive context than a model should receive. Interdict evaluates the request at the handoff to the provider.

02

Route sensitive data by purpose

A value may need to be blocked from the model, redacted before forwarding, or sent to an approved verifier while the LLM receives only the permitted result.

03

Record the enforcement decision

Interdict records policy and detection metadata for the request without putting the raw prompt or response into the audit record.

The solution

Put one checkpoint in the path of every model call.

Interdict evaluates the request before provider credentials are retrieved, then inspects the response on the way back. Policy lives at the boundary instead of being scattered across every application and provider.

Your applicationRequestPrompt · tools · model · limits
InterdictEnforcement checkpoint
  1. 01Authenticate the application
  2. 02Inspect prompt injection + request PII
  3. 03Route sensitive data by policy
  4. 04Enforce provider, model, token + budget rules
  5. 05Retrieve provider credentials only after checks pass
Sensitive-data decision
BlockStop the request
RedactMask before model
VerifyApproved verifier → result only
Approved providerModel callOpenAI · Anthropic · Gemini · Grok · Ollama
Return pathResponse PII inspectionProtected streamingUsage + cost metadataAudit + alerts
See what reaches the model

Make the policy decision visible.

Run safe local simulations of sensitive-data routing, PII redaction, prompt-injection blocking, model policy, and budget enforcement. Nothing you enter here is sent or stored.

Run a free leak audit Read the 3-minute Quick Start
interdict · local policy simulatorlocal only
Product surface

See the controls security teams can actually inspect.

Interdict is not a black-box risk score. Policies, request decisions, and audit metadata are visible as concrete runtime controls your team can configure and review.

application · clinical-assistantpolicy v7 · active
Policy

Sensitive-data routing

runtime
TypeModelExternal
SSNRedactVerify → identity-primary
Date of birthRedactVerify → identity-primary
EmailRedactNone
PhoneRedactNone
Request inspector

req_8F219

allowed
PII detected
ssn, date_of_birth
Policy action
verify + redact
Provider
openai
Model payload
protected context removed
Audit event

Enforcement metadata

no raw prompt
policy_version: 7
pii_types: [ssn, date_of_birth]
action: verification + redaction
provider: openai
raw_prompt: not stored
Security review

Built for the questions security teams actually ask.

Current product safeguards, stated plainly. No badge wall, no invented certification language, and no requirement to trust a black-box score.

Review the security architecture
Request inspectionYes
Response inspectionYes
Raw prompt in ordinary audit logNo
Destination-aware verificationYes
Provider and model policyYes
Protected streamingYes
Current safeguards · not a certification or compliance guarantee

Find out what your AI pipeline is prepared to expose.

Try Interdict free for one month with 10,000 requests and no credit card. The trial ends automatically; you choose whether to upgrade. Model provider charges are separate.