Where a data-protection layer sits next to DLP and an AI gateway

Three controls that sound alike, do different jobs, and work best together. What each one decides, and what Salus deliberately does not do.

Security teams evaluating AI protection meet three kinds of product that all claim to “protect data in AI traffic”. They are not substitutes. Each decides a different question, and a sound architecture has all three.

Three questions

DLP decides what may leave. It classifies content and enforces policy at the egress points it can see: e-mail, endpoints, cloud storage, the corporate proxy. Its unit of decision is a document or a session, and its verbs are allow, block, quarantine.

An AI gateway decides where it goes. It sits in front of the model providers an organisation uses, routes requests, enforces quotas and keys, and increasingly inspects prompts and responses for injection, jailbreaks and policy violations. Its unit of decision is a request, and its verbs are allow, deny, rewrite.

A data-protection layer changes the form of what leaves. It finds the identifiers in the text, replaces them with tokens before the request crosses the boundary, and restores them in the answer. Its unit of decision is a span of characters, and its verb is transform. This is what Salus is.

Why the three are complementary

A DLP policy that blocks every prompt containing a customer name stops the work; one that allows them leaks. The tool is not wrong, it is answering the wrong question for this traffic. What it needs is a layer that makes the prompt safe to allow.

An AI gateway can mask a name, but a stateless proxy cannot restore it, because restoration needs a case-scoped mapping held inside the perimeter and an authorisation model for who may read the original. A gateway’s job is routing and policy. The transformation is best done by a component the gateway calls, so that the gateway keeps its contract and keys and the mapping never leaves the customer.

So the shape that works is: DLP decides whether this traffic may leave at all; the data-protection layer makes it safe to leave; the gateway decides where it goes and watches for attacks. Each tool keeps the decision it is good at.

Where Salus connects

In the applications you build. Your code, your gateway or your batch job calls protect before the provider call and restore after it. If protection cannot complete, the request stops and nothing is sent.

Inside the gateway you already run. Salus is a streaming stage in the gateway’s pipeline. Routing, quota and cost stay with the gateway.

Around the applications you do not control. For the AI tools employees use directly in a browser or on the desktop, Salus runs on managed endpoints and protects what is typed or attached, with an optional review step before anything is sent.

In every case the detection, the tokens and the audit are the same. A security reviewer learns one dictionary and one event format.

What Salus deliberately does not do

It does not classify prompt injection or jailbreaks. It does not control agents, tools or retrieval. It does not filter toxicity or protect a brand. Those are gateway jobs, and a good gateway does them well. Salus is the data-transformation layer underneath, and it is built to be called by them rather than to replace them.

Saying this plainly matters, because the alternative is a product that claims every box on a comparison grid and does the data part as an afterthought. The data part is the one a regulator will ask about.

All resources