One line of code. Full split-knowledge privacy.

The 1-Line Integration

If you’re already using the Anthropic SDK, integration is a config change — not a code change.

# Before — direct to Anthropic
import anthropic
client = anthropic.Anthropic(api_key="sk-ant-...")

# After — through The Veil
import anthropic
client = anthropic.Anthropic(
    api_key="dsa_...",              # Your Veil API key
    base_url="https://gateway.your-veil.com"  # Your Veil Gateway
)

# Everything else stays the same
response = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Classify this ticket: ..."}]
)

// Before
const client = new Anthropic({ apiKey: "sk-ant-..." });

// After
const client = new Anthropic({
  apiKey: "dsa_...",
  baseURL: "https://gateway.your-veil.com"
});

// Everything else stays the same

Standard Anthropic Messages API. Your existing code, your existing prompts, your existing error handling — unchanged. The Veil intercepts, sanitises, isolates, signs, and returns.

Using OpenAI, Gemini, Mistral, or local models? The DSA Proxy API (Path 2 below) supports all providers with the same privacy guarantees. OpenAI SDK-compatible proxy is on the roadmap.

What Happens Under the Hood

Every API call passes through a five-stage pipeline before reaching the AI model:

1. 1Your code calls client.messages.create() — the request hits the Gateway.
2. 2PII Firewall detects and strips identity fields. Three layers: named entity recognition (11+ custom recognizers), quasi-identifier risk scoring (k-anonymity, l-diversity), and an optional LLM PII Shield.
3. 3ID Bridge generates an opaque pseudonymous token and stores the mapping in an encrypted vault. The AI will never see the real identity.
4. 4Sandbox B runs inference on pseudonymised data in a network-isolated environment. The AI model processes the request without any path back to identity data.
5. 5Response flows back through the Gateway. Tokens are re-linked to real identities in-memory (never persisted together), and a signed Veil Certificate is attached as proof.

Average overhead: single-digit milliseconds for PII detection. LLM inference time is unchanged.

Integration Paths

Find the path that fits your team:

DSA Proxy API Format

For teams who want explicit control over field routing, the DSA proxy format separates what the AI should read (prompt_template) from the data that needs sanitisation (context):

{
  "prompt_template": "Classify this incident: {{description}}",
  "context": {
    "description": "User John Smith ([email protected]) reports VPN issue from Berlin office"
  },
  "model": "claude-sonnet-4-20250514",
  "max_tokens": 1024
}

Supported models

Same request format, same privacy pipeline, same Veil Certificate — regardless of which model you choose.

The prompt_template is validated for PII (rejected if any is found). Context fields pass through the full 3-layer sanitisation pipeline. The AI receives the template with pseudonymised context — never the original identity data.

Deployment Options

cp config.env.template config.env
# Fill in your values
./setup.sh

helm install dsa ./deploy/helm \
  --namespace dsa-system \
  --create-namespace \
  --values deploy/helm/values-prod.yaml

Standard Kubernetes. Standard PostgreSQL. Standard Redis. No special hardware, no confidential computing enclaves, no vendor-specific silicon.

What You Get Back

Every response includes a link to its Veil Certificate — signed, timestamped, independently verifiable proof that identity data and AI processing were isolated throughout the pipeline.

{
  "status": "JOB_STATUS_COMPLETED",
  "result": { "text": "Category: Network, Priority: P2..." },
  "model_used": "claude-sonnet-4-20250514",
  "request_id": "req_4f3a1b2c8d9e",
  "veil": {
    "status": "available",
    "certificate_url": "/api/v1/veil/certificate/req_4f3a1b2c8d9e",
    "summary_url": "/api/v1/veil/certificate/req_4f3a1b2c8d9e/summary"
  }
}

Three certificate views: DPO summary for compliance officers, technical proof for security engineers, regulatory mapping (GDPR Art. 25/32, EU AI Act Art. 10/15) for auditors.