- In-house AI applications and services
- The AI gateway you already run
- Analytics and batch workloads
- Agents and automated pipelines
- SDK and API traffic
- Browser AI services (ChatGPT, Claude, Gemini…)
- Desktop AI applications
- Specialist and vertical AI products
- Documents, images, and screenshots
- Human review before anything sends
The test is control, not ownership#
Every protected AI interaction takes one of two shapes. Either there is a cooperating component in the request path — your application, your service, your AI gateway — that can deliberately hand the request to Salus, or there is not, and Salus must be inserted around the usage without the application's cooperation.
Ownership only predicts the answer; it doesn't decide it. You may own an application and still choose the interposed path because changing it is expensive — or not own the application but control a gateway in front of it that can call Salus. The question to ask per surface is simply: is there something in this request path that we control and can point at Salus?
Integrated deployment — Salus in your stack#
When the answer is yes, integrate Salus into your stack — through the Salus SDK, a local API, or a thin adapter for the gateway you already run. Salus is deployed inside your environment, not a hosted service: your code or your gateway calls it locally to tokenize detected sensitive values before the provider call and restore approved values from the answer, with identity kept consistent across a whole workload so analytics and multi-step jobs work over tokens. Integration is explicit, which is its strength: protection lives exactly where the request is formed, and fail-closed behavior is part of the contract.
Endpoint deployment — Salus on managed devices#
When the answer is no — browser AI, desktop AI clients, vertical tools whose vendors will not add an integration — deploy Salus on managed endpoints. Governed AI traffic is captured on the device, detected values cross the boundary as tokens, and responses are restored on your side, with a review window where policy requires a person to sign off.
Side by side#
| Integrated deployment | Endpoint deployment | |
|---|---|---|
| The situation | A component you control is in the request path | The application can't be changed |
| Who does the work | Your application or gateway calls Salus | Salus captures governed traffic on the device |
| Typical surfaces | In-house apps, services, analytics, agents, your gateway | Browser AI, desktop AI apps, specialist tools |
| Who adopts it | Engineering and AI platform teams | Security, IT, and endpoint teams |
| Main risk to manage | An integration omitted or wrong | Coverage gaps on ungoverned surfaces |
| Contract — tokens, Context, fail-closed | Shared | Shared |
One contract, one engine#
The paths are ways of reaching Salus, not different protection models. Tokens follow the same grammar, the Context semantics are identical, and the failure defaults are the same wherever traffic enters — an API call from a batch job and a prompt captured from a browser are protected under the same rules. Owning both paths makes the architecture complete in kind: every interaction is either handed to Salus by a cooperating component or captured without one. Practical coverage still has to be earned surface by surface — which is what First Deployment is for.