product / deployment
Deployment
A security layer that requires a rewrite does not get deployed. Divelai is built to go in front of code you have already shipped.
Four modes
Proxy
Change the base URL. Divelai speaks the provider’s protocol, including streaming, so requests and responses keep their shape. The fastest path to coverage, and the one that catches code you forgot about.
SDK
Call sanitize() and rehydrate() directly when you want sanitization to be explicit in the code review rather than invisible in the network path.
Gateway sidecar
Runs beside your existing egress gateway or service mesh and applies policy to any outbound destination, not only AI providers. Covers vendor APIs and data exports.
Self-hosted
The whole engine and vault inside your own VPC or data centre. No payload, token, or mapping ever reaches infrastructure Divelai operates.
Supported providers, SDK languages, and orchestration targets at launch [CONFIRM]
What it costs you in latency
Sanitization is inline and synchronous — batch scanning after the fact does not prevent a disclosure that already happened. So the number that matters is what Divelai adds to a request, and that number should be published with the harness that produced it.
We will not put a figure on this page until it comes from a benchmark you can re-run yourself, on stated hardware, with a stated payload distribution.
Benchmark and methodology [CONFIRM]
Failure behaviour
You choose what happens when Divelai cannot complete a pass. fail_closed rejects the request — the default, because the alternative silently leaks. fail_open forwards raw and writes a high-severity audit event. There is no mode that leaks quietly.
# Self-hosted: nothing leaves your boundary. services: divelai: image: divelai/gateway:"[CONFIRM tag]" environment: DIVELAI_MODE: selfhosted DIVELAI_VAULT: postgres://vault.internal/dv DIVELAI_POLICY: /etc/divelai/policy.yaml DIVELAI_ON_ERROR: fail_closed ports: ["8080:8080"] volumes: - ./policy.yaml:/etc/divelai/policy.yaml:ro