Why OGuardAI?

One-Sentence Answer

OGuardAI runs anywhere, works with any LLM, and keeps detected sensitive values inside your trust zone: on the protected path, what reaches the model is tokenized text plus the safe metadata policy permits, not the raw values.

The Problem

Existing PII tools (Presidio, AWS Comprehend, Azure AI Language) center on detection. They find sensitive data and redact or anonymize it. Their common output is redacted text with no path back to the original after an LLM responds. Presidio can encrypt and later decrypt a value at the library level, but none of these tools provide a policy-driven, per-channel restore built around an LLM round-trip.

OGuardAI solves a different problem: round-trip data protection for AI pipelines. It replaces sensitive values with semantic tokens that LLMs can reason about, then deterministically restores the originals in the output. Detection is one step in the pipeline, not the entire product.

Comparison Table

The OGuardAI column states what this codebase implements (each row is backed by the crate noted in the "Where it lives" section below). The competitor columns are qualitative summaries drawn from each vendor's public documentation, with sources and a retrieval date in the evidence ledger that follows the table. They describe scope and design intent, not head-to-head benchmarks. We have not independently benchmarked the competitors, and their capabilities change, so verify against the linked docs before relying on any competitor cell.

Evidence ledger

Competitor rows above are summarized from these public sources. Retrieved 2026-07-16. Capabilities and pricing change; treat this as a pointer to verify, not a guarantee.

We do not publish head-to-head latency numbers for the competitors because we have not run controlled benchmarks against them. We also do not quote latency figures for OGuardAI itself: no reproducible, named end-to-end run exists yet, so the benchmarks page carries no numbers on purpose. Architecturally, the built-in regex detectors are pure CPU work whose cost scales with payload length and entity count, while the NER path is dominated by the model backend. To get real, hardware-specific numbers, run the harness on your own machine; see the performance and benchmarks docs.

Where it lives (OGuardAI column)

Each OGuardAI cell maps to code in this repository:

Architecture Difference

The difference is detection/anonymization tools versus a round-trip protection runtime built around an LLM call.

Presidio / AWS Comprehend / Azure AI Language

Input -> Detect -> Redact / Anonymize -> output

These are primarily detection and anonymization tools. Their common path produces redacted or anonymized text that is not meant to be restored from LLM output. Presidio is a partial exception: its Anonymizer supports an encrypt operator that a Deanonymizer can decrypt, so a value can be recovered, but that is a library-level encrypt/decrypt, not a policy-driven, per-channel restore tied to an LLM round-trip. None of the three sit between your app and an LLM as a gateway or carry semantic token metadata for the model to reason about.

OGuardAI

Input -> Detect -> Tokenize -> Transform -> [LLM] -> Restore

Sensitive values are replaced with typed semantic tokens ({{email:e_001:44aa750af63b}}, {{person:p_001:53c283cc21d6}}). The token carries a type, an id, and a capability cap (the third segment). Production tokenization always emits the cap: a random 12-hex value on the transform path, or a per-corpus derived cap on the RAG corpus path. The id itself is a predictable sequential value like p_001; the cap is what is unguessable, and it is compared exactly at resolution, so a guessed id alone is insufficient to resolve a token. Capless tokens exist only in tests and fixtures and do not resolve against a capped production token. Safe metadata such as gender, formality, and language is tracked separately in the session and is exposed to the model only when policy explicitly permits it. This gives the model a semantic type signal to preserve context around. After the LLM responds, OGuardAI deterministically restores the original values based on policy. On the protected path, detected non-whitelisted values are tokenized: their raw form stays inside the configured trust zone, and what leaves to reach the LLM is tokenized text plus the metadata policy permits. Three boundary conditions are worth naming. A value explicitly listed in a policy whitelist is passed through raw by design (that is the only sanctioned raw path, and every other broad allow is clamped down to tokenize). Protection only covers what detection finds, so a detector miss can leave a value in the text. On the proxy, a remote (non-data:) image URL cannot be OCR-scanned and is rejected fail-closed unless an operator explicitly opts in to forwarding it. Policy governs restore: actions like redact purge the selected values from the session and intentionally make them non-restorable.

Six restore modes control what happens on output:

Different output channels (agent, customer, log, audit) can use different restore modes for the same entity, controlled by policy.

When to Use What

Use OGuardAI when:

• You need reversible protection: LLM output must contain real data (customer names, emails, account numbers) for the end user, while the model itself sees only the tokenized form of every detected, non-whitelisted value.
• You run RAG pipelines and need protection at ingest, query, context assembly, and answer generation.
• You need streaming (SSE) with real-time tokenization and restoration.
• You require self-hosted or air-gapped deployment with zero external calls.
• You work with any LLM provider (OpenAI, Anthropic, Mistral, Bedrock, local models) and do not want vendor lock-in.
• You need structured JSON protection that understands JSON paths and preserves structure.
• You need GDPR entity revocation: make a specific entity value (one type plus value pair) non-restorable across applicable sessions in one operation. Revoking a person cascades within a session: at rehydrate time, any email, phone, or address token that belongs_to that revoked person in the same session's token map is treated as revoked too. That cascade does not cross the session boundary and does not reach values that were never linked to the person, so to fully retire a person you still revoke each of their known values (name, email, phone, address) explicitly.
• You need policy-driven control over what gets masked, passed through, or blocked, with different rules per output channel.

Use Presidio when:

• You need a self-hostable PII SDK for detection and anonymization, and you are comfortable assembling the pipeline yourself.
• You are building compliance scanning or log sanitization, where redaction (or Presidio's encrypt/decrypt) covers your needs without an LLM round-trip.
• You do not need a gateway that sits between your app and an LLM, semantic token metadata, streaming, RAG protection, or per-channel restore.

Use AWS Comprehend or Azure AI Language when:

• You are already committed to that cloud provider and only need entity detection as a service.
• You do not need restoration, streaming, or self-hosted deployment.
• A managed cloud API call per request is acceptable for your use case.

Key Differentiators

Semantic tokens, not masks. OGuardAI tokens like {{person:p_001:53c283cc21d6}} carry a type, an id, and a capability cap in the third segment, which production tokenization always emits. The id is a predictable sequential value; the cap is unguessable and is compared exactly at resolution, so the id alone is insufficient to resolve a token. The type signal lets the model recognize that a token refers to a person and write coherent text around it. Optional per-entity metadata (gender, formality, language) is tracked separately in the session and is supplied to the model only when policy permits, which can further improve gender-aware and formality-appropriate output; results depend on the model. A bare [REDACTED] or **** gives the LLM no such signal.

Token repair. LLMs sometimes modify tokens in their output (extra spaces, changed brackets, partial tokens). OGuardAI's 3-stage repair pipeline (strict match, pattern repair, fuzzy resolution) recovers damaged tokens before restoration. Detection-only tools do not face this problem because they never restore.

Output guard. After the LLM responds, OGuardAI optionally re-scans the output for any new PII the model may have hallucinated or leaked. This second-pass protection catches data that was never in the input.

Stateless by design. Session state travels as an encrypted blob (AES-GCM) alongside the request. There is no server-side session store required, though an in-memory backend is available for dev/test, and a Redis session backend stores sessions encrypted at rest for cross-replica HA, which requires the Redis replay backend (replay_backend=redis) alongside it and revocation_backend=redis so a value revoked on one replica cannot be restored through another; server startup rejects a redis session backend configured without redis replay. Because each API instance is stateless on the sealed-session path, the core data path is designed to scale horizontally without server-side session affinity, and any multi-replica deployment requires revocation_backend=redis, with sealed-session HA advertised via high_availability=true, and air-gapped deployment stays straightforward. This is an architectural expectation, not a measured result: real capacity still depends on NER sidecar throughput, revocation and Redis session backends, audit I/O, and load-balancer behavior, and we publish multi-instance numbers only from a real load run.

Provider-neutral. OGuardAI sits between your application and any LLM. It does not depend on OpenAI, Anthropic, AWS, or Azure. Swap providers without changing your protection layer.

Summary

Presidio, AWS Comprehend, and Azure AI Language are detection and anonymization tools. They answer the question: "Where is the sensitive data, and how do I redact it?"

OGuardAI is a protection runtime. It answers a different question: "How do I use AI safely with sensitive data and still get useful results?"

If you only need to find and redact PII, the existing tools work well. If you need to protect data through an entire AI pipeline and restore it on the other side, that is what OGuardAI is built for.