Trust

Most data-protection pitches lead with a promise they cannot keep. We lead with the boundary instead. This page states plainly what OGuardAI does, what it does not do, and where the responsibility stays with you. The detailed, binding version lives in Security Guarantees; this is the short, honest read.

What OGuardAI does

OGuardAI is a semantic data-protection runtime that sits between your application and the model. It does three things, in order.

• Detect. A built-in floor of regular-expression and format detectors (email, phone, IBAN, SSN, card with Luhn, IP, URL, and more) runs on every request. Optional NER (the GLiNER sidecar) adds person, company, and location. A policy can add its own custom_patterns for any domain identifier.
• Tokenize. Each detected value is replaced with a semantic token, for example {{email:e_001:1bcaef1a4aff}}, that carries enough context (type, and optionally language, gender, formality) for the model to write correct, personalized output without seeing the real value.
• Restore. After the model responds, OGuardAI deterministically restores only what the policy and the output channel allow, with six restore modes from full to none, gated per audience.

Two properties hold across all of it.

• The Line. The built-in detection and restore behavior is a fail-closed floor. Configuration adds detectors or tightens what is restored; it cannot silently weaken a built-in or disable detection. Invalid configuration does not degrade quietly: it aborts startup.
• The trust boundary. Values that OGuardAI tokenizes exist in raw form only inside the runtime. The model, your logs, your vector store, and any external tool see tokens and safe metadata, not the original value. One exception is deliberate: a value your policy explicitly whitelists is passed through unchanged, because you chose to allow it.

Where a deployment needs a hard assurance for an NER-backed entity such as a person, company, or location, it sets detection.required_for. If the NER sidecar that type depends on did not run, the request fails closed rather than under-detecting in silence. Built-in regex detectors are always present, so a required regex type is found by the floor. Any vertical, healthcare, finance, government, legal, HR, ecommerce, is expressed in policy and configuration, not in a fork of the code.

What OGuardAI does not do

We do not use the words "eliminates," "100 percent compliant," or "guaranteed safe." They are not true of any detection system, and we will not print them.

• It protects detected entities, not arbitrary text. Detection is the regular-expression floor plus optional NER plus your policy patterns. Text that no detector matches is not masked. This is why required_for and the output guard exist, and why policy tuning matters.
• Person, company, and location need the NER sidecar. In built-in-only mode those types are not detected. This is a deployment choice, and the capability matrix in Security Guarantees states it exactly.
• It does not reach into your other systems. OGuardAI cannot delete a value from your vector store, your database, or your log sink. It gives you the signals and the revocation primitives; the external cleanup is yours.
• It does not validate or scan provider credentials. When the proxy forwards your Authorization or api-key header to the upstream model, that is a routing credential, not request data. It is passed through unchanged so the call can authenticate, and it is never scanned or logged.
• It is not a model, a DPA, or a certification. OGuardAI is a control you operate. It strengthens a Schrems II or section 203 posture; it does not replace a data-processing agreement, a legal review, or an audit.

The honest posture

The accurate way to describe OGuardAI is "fail-closed when required, extensible per policy." Not an absolute, a contract. When you require an NER-backed entity and its sidecar did not run, the request stops. When you need a new entity, a new channel, or a new role, you declare it in YAML and the runtime enforces it. When configuration is wrong, the server refuses to start rather than run with a false sense of safety.

If a vendor tells you their tool removes all risk, ask them what happens when the NER detector they depend on is down. With required_for, ours stops the request rather than guessing. That is the difference we are willing to put in writing.

For the binding, testable version of every claim here, including the revocation contract, the NER capability matrix, and the customer-responsibility list, read Security Guarantees.