An in-house AI feature, an analytics pipeline, an agent runtime, or the gateway your traffic already flows through — reaching Salus via the SDK, a local API, or a gateway adapter.
Tokenize and restore run against the engine in your environment: detect → tokenize → policy → restore. One implementation behind every integration method.
Receive tokenized requests from your application, exactly as they would any other call — the provider integration is unchanged.
What integration is for#
Salus is not a hosted service you call across the internet — it runs inside your environment, and your stack calls it locally; Salus never becomes your gateway and never becomes a cloud hop. Integration is the path for AI usage where a component you control sits in the request path: the AI features you build into your own products, internal services that call provider APIs, analytics and batch workloads over customer data, agents and automated pipelines — and the AI gateway you already operate, which can call Salus at the boundary without your applications changing at all.
Your code tokenizes the sensitive parts of a request before the provider call and restores approved values from the answer afterwards. Detection, restoration state, and protection logic all run in your environment; the provider receives tokens.
Ways to integrate#
Already have an AI gateway? Keep it — Salus plugs into it. Building directly against an AI SDK? Add Salus with a thin SDK. Want the fastest validation? Point an OpenAI-compatible client at a locally deployed Salus endpoint.
- Salus SDK — the easiest developer experience: protect and restore calls in your application's own language. SDKs are deliberately thin clients over the local Salus service — they contain no protection logic of their own, so behavior is identical from every language.
- Local API — the canonical, language-neutral technical contract the SDKs and adapters are built on. Anything that can make a local call can integrate.
- Gateway adapter — a thin plugin for the AI gateway you already run, calling the same local Salus service at the boundary. Your gateway keeps authentication, provider routing, credentials, quotas, and model selection.
- OpenAI-compatible endpoint — a quick-start wrapper for validation and proofs of concept: point an OpenAI-compatible client's base URL at a locally deployed Salus endpoint and requests are protected before egress, with no code changes. A convenience mode around Salus — not a gateway product.
One contract. One implementation. Many wrappers. Every method reaches the same engine, the same Context semantics, and the same fail-closed defaults — integration methods reduce adoption cost; they never create new protection logic.
Consistent identity across a workload#
Tokenize and restore are not isolated string operations — they run inside a Context: the boundary within which identity remains consistent. A Context spans a whole workload — a batch job, an analytics run, a case, a conversation, an agent's task. Within it, the same person is the same token in every call, however many requests the workload takes. That referential consistency is what keeps aggregation, joins, and multi-step reasoning working over tokenized data — the model can still connect "the customer in row 4,012" to "the customer who called twice in March" without ever seeing who that is.
Consistency is deliberately scoped: tokens are stable within a Context and differ across unrelated ones, which is a privacy property, not a limitation. When identity evidence is ambiguous, the engine protects the mention under a provisional identity rather than guessing — protection never waits on certainty.
Fail-closed by design#
A protection layer that can be accidentally skipped is not a protection layer. The integration contract is built so the safe behavior is the unmistakable default: requests in governed data classes that cannot be processed are held or rejected per policy rather than passed through raw, and the integration patterns Salus documents never leave a code path where an exception quietly sends the original values.
Restoration is governed#
Restoring a token back to its original value is a separate, policy-checked operation. The credential that identifies your tenant does not by itself authorize seeing restored values — restoration is evaluated against the identity your integration asserts for the requesting user or service, from a component you configure and trust. Restore happens at exactly one boundary, into the response a person or system is entitled to see — not into logs, traces, or intermediate storage.
Where the reference is#
This page describes the concepts and the integration model. The full technical reference — request and response shapes, the SDKs, and integration recipes for common gateways — is published alongside general availability. If you are evaluating Salus now, First Deployment describes how a pilot runs, and Where Salus Sits explains when integration is the right path versus deploying on endpoints.