Architecture Overview

What is OGuardAI?

OGuardAI is a semantic data protection and transformation runtime for AI systems. It sits between your applications and language models, detecting sensitive entities in text, replacing them with deterministic semantic tokens, and restoring original values in model output, all governed by declarative policies. The result: your LLM produces grammatically correct, personalized output while working from tokens instead of detected raw PII.

Architecture Diagram

OGuardAI is organized into three planes:

+-----------------------------------------------------+
|                    Applications                       |
|  (Chatbots, RAG, Agents, CRM, Support, Docs)        |
+---------------------------+--------------------------+
                            |
+---------------------------v--------------------------+
|                 Integration Plane                     |
|  TS SDK | Python SDK | MCP | LangChain | Proxy       |
+---------------------------+--------------------------+
                            |
+---------------------------v--------------------------+
|                Runtime Plane (Rust)                    |
| +-----------+ +----------+ +-----------+             |
| | Detectors |>| Tokenizer|>|Transformer| --> LLM     |
| +-----------+ +----------+ +-----------+             |
|                                    |                  |
| +---------+ +----------+ +--------------+            |
| | Policy  | | Session  | | Rehydrator   | <-- LLM    |
| +---------+ +----------+ +--------------+            |
+------------------------------------------------------+

Runtime Plane (Rust)

The core engine, written in Rust for performance and safety:

Integration Plane

SDKs and framework adapters:

Platform Plane (Future)

SaaS/PaaS capabilities: tenant management, usage-based billing, managed sessions.

Pipeline Flow

This is the logical protect, generate, and restore round trip. Steps 1-6 and 9-12 run inside the OGuardAI runtime; steps 7-8 are the LLM call your application owns (or that the transparent proxy makes on its own client's behalf), not the core server. A direct detect, rehydrate, policy, or health request runs only its relevant stages and never calls a provider.

1. INPUT           Raw text with PII
2. DETECT          Regex + optional NER: find names, emails, IDs, phones, addresses
3. CLASSIFY        Entity type, confidence score, language, metadata
4. POLICY CHECK    Block? Tokenize? Allow? What restore mode per entity?
5. TOKENIZE        Assign deterministic `{{type:id:cap}}` tokens, build session mapping
6. TRANSFORM       Replace spans in text, generate safe metadata for LLM

   === TRUST BOUNDARY === (detected, non-whitelisted raw PII tokenized before crossing)

7. LLM PROCESSES   Model sees tokens + safe metadata (plus any whitelisted values)
8. LLM RESPONDS    Response contains tokens: "Sehr geehrte `{{person:p_001:ad4f97591c16aa11bb22cc33dd44ee55}}`..."

   === TRUST BOUNDARY ===

9. TOKEN REPAIR    3-stage: strict parse -> deterministic repair -> fuzzy resolve
10. REHYDRATE      Restore values per policy: full/partial/masked/formatted/abstract/none
11. OUTPUT GUARD   Re-scan for NEW PII the model hallucinated (not from input)
12. FINAL OUTPUT   Business-ready, personalized, compliant

Trust Boundary Model

The trust boundary is the legal and technical foundation of OGuardAI. By design, detected raw PII is tokenized before it crosses it; an explicit policy whitelist is the one deliberate exception.

What crosses the boundary

Outbound (to LLM):

• Tokenized text: "Contact `{{person:p_001:ad4f97591c16aa11bb22cc33dd44ee55}}` at `{{email:e_001:1bcaef1a4affaa11bb22cc33dd44ee55}}`"
• Entity context (safe metadata only): [{token: "`{{person:p_001:ad4f97591c16aa11bb22cc33dd44ee55}}`", type: "person", gender: "female"}]

Inbound (from LLM):

• LLM output with tokens: "Dear `{{person:p_001:ad4f97591c16aa11bb22cc33dd44ee55}}`, thank you for..."

Never crosses (unless explicitly whitelisted):

• Raw values: "Erika Mustermann", "erika.mustermann@example.com"
• Token-to-value mappings
• Encryption keys

Crate Dependency Graph

Apps (binaries)
  oguardai-server   depends on guardai-runtime plus the server-only crates
  oguardai-proxy    depends on guardai-runtime plus a subset
  oguardai-cli      depends only on guardai-core + guardai-api-types (thin HTTP client)

guardai-runtime   the protection kernel; aggregates the pipeline crates:
  guardai-tokenizer, guardai-transformer, guardai-rehydrate, guardai-policy,
  guardai-token-robustness, guardai-output-guard, guardai-session,
  guardai-provider-strategy, guardai-detector-builtins

guardai-core      shared types; guardai-api-types depends on core

Self-contained crates (no internal dependencies):
  guardai-auth, guardai-prompt-security, guardai-streaming,
  guardai-large-text, guardai-sandbox, guardai-licensing

# See the Crate Graph page for the full, exact dependency edges.

Session Model

Sessions bind token-to-value mappings for the duration of a transform-rehydrate cycle.

Default: Sealed sessions. AES-256-GCM encrypted blobs returned to the client. No server-side state required. The client is the sole custodian of the encrypted session blob.

Other backends: in-memory (dev/test) and Redis (encrypted at rest, shared cross-replica for HA). A Redis session backend also requires a Redis replay backend, and any Redis or multi-replica HA deployment requires revocation_backend=redis (with high_availability=true) so a value revoked on one replica cannot be restored through another; server startup rejects the unpaired configurations. Managed/persistent SaaS backends remain planned.

Performance

No latency, throughput, or memory figures are published here. None have been produced by a reproducible, named run against a dataset we can point to, and a number without a run behind it is a guess. See Benchmarks for the harnesses that produce real, hardware-specific numbers on your own machine.

What the architecture does establish is the shape of the cost. Which detection path you configure is the dominant factor: the built-in detectors are pure in-process regex and string work whose cost scales with payload length and entity count, while an NER-enabled request additionally makes a synchronous round trip to the Python sidecar and waits for a model forward pass. Tokenize, transform, seal, repair, and rehydrate are in-process compute. Shared backends cross the process boundary when you configure them: a detector webhook, Redis-backed sessions, replay protection, revocation, and outbound telemetry each add network I/O regardless of the detection path.