First deployment

Phase 1: install and validate

The engine installs as a Helm chart on OpenShift or as a Docker Compose stack, on CPU servers you run. The deployment overview lists what it needs: PostgreSQL, Redis, a pull secret for the image registry and a handful of keys you generate.

Once it is up, the first administrator is created with a one-time bootstrap call, a tenant is created for the pilot team, and an API key is issued for the pilot application. The management console’s detection playground lets the team paste real samples from the workflow and see exactly which spans are found, by which layer, with what confidence, before anything is enforced.

What you get out of this phase is evidence: detection quality measured on your own documents and records, not quoted from a datasheet.

Phase 2: protect

With the baseline agreed, the workflow is integrated. For an application you build, that is two calls: protect before the provider call, restore after it. For traffic that already flows through LiteLLM, it is a guardrail entry in the gateway configuration and no application change at all.

Users keep the same tools and the same workflow. The difference is that the provider now receives typed tokens for detected values, and answers are restored inside your perimeter.

Before protection goes in path, agree what the application does when Salus returns an error. The engine fails closed: if detection cannot complete, the request fails and no text comes back. Your application should treat that as “do not send”, which is the safe default.

Phase 3: review and tune

The console’s detection reviews screen captures real detection runs so a reviewer can mark each span correct or a false positive and record anything that was missed. Reviewed precision is shown over the last 24 hours and 7 days. Custom regex rules, per tenant or global, cover identifiers that are specific to your organisation such as case numbers or policy numbers; they take effect at the next request, without a restart.

Feedback never changes rules or models on its own. It is evidence for you and for the Salus team.

Expand

• More callers. Each new application is a key with its own route permissions and, if you want, its own source-IP allow-list.
• More teams. Tenants isolate tokens, rate limits and keys from each other.
• More documents. The same file endpoint handles PDF, DOCX, XLSX and PPTX in place. Scanned pages and images are read when the optional OCR service is enabled.
• Endpoints. Where employee AI use is in scope, the endpoint deployment extends the same engine to managed devices.

There is no fixed pilot duration. The trigger for each step is that the previous scope is measured and stable.