The prompt is the leak.

Layer 1 — exact data

Things no prompt has a legitimate reason to contain.

Card numbers, SSNs, bank routing numbers, IBANs and live API keys are self-identifying: recognisable by checksum and format, with no model involved. Nothing is scanned until you turn a category on; when you do, block is the action the console suggests, and the choice stays yours.

• Checked by format and checksum, not inference, with a confidence floor you control
• Runs inline in the gateway itself; it is not a second hop
• Block refuses the request with a 403 governance envelope carrying a decision ID and no leaked value
• No always-on floor: every category, live secrets included, is on or off by your decision

Layer 2 — you opt in

The categories your regime actually cares about.

Names, addresses, emails, phone numbers, medical terms, and your own keyword dictionaries. These are off by default, because whether a name is sensitive depends on your regime and not on our opinion. One team turns on names and medical terms; a support tool handling contact details may deliberately leave them off.

• Detected by local named-entity recognition and pattern matching
• NER runs on our own CPU inference — prompts are not shipped to a third-party classifier to be scanned
• Off by default, enabled per category, so you are never silently opted into someone else's compliance posture
• Custom keyword dictionaries for the terms only your business would recognise

Layer 3 — you declare it

Your source code, contracts, roadmap and customer lists.

No model can infer what is proprietary to your business, so this layer protects exactly what you register and nothing more. We index the sources you connect and match prompts against them at the gate — by fingerprint for literal leakage, and by embedding for paraphrase.

• Fingerprint matching for verbatim leakage — someone pasting a real contract clause into a chat
• Embedding matching for paraphrase, where the words changed but the substance did not
• We store derived artifacts only: the index is one-way, not a readable copy of your documents
• Coverage equals what you connect — we say plainly that we cannot protect data you never declared

What happens on a hit

Five actions, because blocking is not always the right answer.

A detection is not automatically a refusal. Most teams start in log-only to measure what their traffic actually contains, then tighten per category once they can see it.

• log_only — record the event and pass through; the place to start while you measure
• tokenize — swap the value for a deterministic token, then rehydrate the real value in the response, so the workflow still works and the provider never sees it
• mask — irreversible redaction, for data the model genuinely does not need
• route_restrict — for your declared sources and policy rules: the request may only be served by platforms you approve, such as your own cloud account
• block — a 403 governance envelope with a decision ID, and no leaked value in the error

Limits, stated up front

What this does not do.

DLP vendors tend to describe a ceiling and let you find the floor in production. The accuracy of each layer differs in kind, so size your expectations per layer rather than trusting one number.

• Layer 1 is format and checksum math, the most precise layer; its confidence floor is yours to set
• Layer 2 is model-dependent; roll it out in log-only first and tune against your own traffic
• Layer 3 embeddings have real recall on paraphrase but are the most false-positive-prone surface we ship
• Nothing here protects a source you never connected, and no setting changes that
• In replies, only exact-data values are masked, and only in non-streamed replies; tokenized values are restored in both
• Tessarac signs no Business Associate Agreements today, so do not send protected health information through it (see the Trust Center)