How Praetor governs every AI request

Overview

Calling an AI API is not the same as controlling it. A provider gives you a capable model behind an endpoint, but no visibility into what your applications send, no enforcement of your own rules, and no audit trail you own. Praetor is the control plane that supplies all three, without changing how your applications call the model.

Every request that transits Praetor is, in a fixed order:

• screened for prompt injection by an ML classifier;
• pseudonymized — 30+ classes of personal data replaced with reversible tokens;
• classified into one of 17 regulated use-case categories;
• evaluated against your active policies — allowed, blocked, or held for a human;
• recorded in an immutable audit entry, with a SHA-256 request hash, before it leaves your boundary.

Architecture

Praetor intercepts AI traffic before it reaches the provider. Your application keeps calling the same endpoints; the governance pipeline runs transparently in between. There are two ingress modes — an API proxy for server-side traffic and a Desktop Client for end-user tools — and both run the identical pipeline and write to the same audit store.

The gateway is a reverse proxy (YARP) that forwards allowed traffic to the upstream provider in its native wire format. ML inference — injection scoring, use-case classification, and PII detection — runs in dedicated services the gateway calls over an internal network; the verdict is assembled at the gateway before any byte leaves your infrastructure.

Deployment: API proxy

The fastest integration. Point your client at the Praetor gateway instead of the provider and add your Praetor API key header. Every request now runs the full pipeline with no other code changes; typical setup is about 30 minutes including testing.

In proxy mode, pseudonymization runs on the gateway with the Microsoft Presidio stack; the reversal map is held in Redis and re-applied to the response before it returns to your application. Provider credentials are stored encrypted and injected server-side (see Security), so your upstream keys are never handled by application code.

Deployment: Desktop Client

A Windows application that governs AI traffic at the network level — no application code changes at all. It natively governs ChatGPT (browser and desktop), the OpenAI API, VS Code Copilot, Claude.ai, and the Claude Code CLI.

• A system PAC file routes only AI hostnames to a local proxy; all other traffic goes direct.
• Installs a local Root CA for HTTPS interception — local-only, removed cleanly on exit.
• Sensitive data is detected and tokenized on the device, before anything leaves it.
• Trusts Node-based CLIs via NODE_EXTRA_CA_CERTS (Claude Code, Copilot CLI).
• The connection is held open while a human-review decision is pending.
• For browser apps behind Cloudflare (ChatGPT web, Claude web), the gateway renders the governance verdict and the request is sent direct from the device.

The 7-step pipeline

Every request passes through these steps, in this order, every time — before it leaves your infrastructure.

Performance

Governance runs inline, so latency matters. Most pipeline steps complete in single-digit milliseconds; the ML models dominate the budget. The figures below are the governance overhead Praetor adds, on top of whatever the model itself takes to respond.

Deterministic steps

Under 5 ms each (audit write, policy evaluation, token substitution)

Injection detection

≈ 100–500 ms (ML classifier)

Use-case classification

≈ 5–15 ms (ML classifier)

Worst-case total overhead

Under 600 ms

Blocked requests short-circuit the pipeline and return immediately, so a policy violation never pays the cost of a round trip to the provider.

Policy engine

You author policies in the dashboard. A policy is a set of rules; each rule pairs a use-case code from the 17-category catalog with an action — Allow, High Risk (hold for human review), or Block. Policies can inherit from base policies and override at any level, and multiple policies can be active at once.

On each request the gateway evaluates every active policy against the detected use case and applies the highest-severity matching rule. A block returns HTTP 451 before the request is forwarded; a high-risk match opens the review flow; everything else passes through and is logged.

The 17 categories map to regulated AI domains — see how they line up with the EU AI Act risk tiers in the AI Governance Guide.

PII anonymization

Praetor detects 30+ classes of personal data and replaces each with a reversible structured token before the request leaves the device or gateway. Detection combines pattern matching with ML-based named-entity recognition, so names, places, and organizations are recognized in context, not just where they fit a fixed format.

A dedicated XLM-RoBERTa classifier additionally flags quasi-identifiers — sentences that single someone out with no explicit identifier, the case almost every other PII tool misses (GDPR Recital 26). "The only dentist in a small town near Niš" carries no email or ID, yet can re-identify a person.

In Desktop Client mode the originals live in memory only — never written to disk, never sent to our servers, never seen by the provider — and are restored locally on the response. In proxy mode the reversal map is held in Redis and applied at the gateway. Detection runs in English, German, and Serbian.

Human review & oversight

When a policy flags a request, Praetor neither passes it nor drops it — the connection is held open (up to 30 minutes) while a reviewer is notified in real time over SignalR. The reviewer sees the anonymized prompt, the detected use case, the violation codes, and the AI system involved, then approves, edits, or rejects. Approve forwards the request; reject returns HTTP 451.

The same mechanism applies to responses. For systems with response oversight enabled, the model's output is intercepted after generation so a reviewer can read it, edit it, and approve before it reaches the end user — appropriate for medical, legal, or other high-stakes use. Every decision is logged with the reviewer's identity, their note, and a timestamp.

Audit & integrity

Every request produces an immutable audit entry — the anonymized prompt, the model response, a SHA-256 request hash, the detected use case, the PII classes seen, the matched policies, the outcome, and any reviewer decision — written before the response is delivered.

For each reviewed decision Praetor issues a signed compliance certificate whose chain hash links it to the previous certificate, so the record cannot be altered after the fact without breaking the chain. Audit records and the AI-system inventory export to PDF and Excel with date-range filtering.

Security

Praetor sits on the most sensitive path in your stack, so the security model is conservative:

• Provider credentials are encrypted with AES-256 at rest. The gateway decrypts at request time, injects the key in each provider's required format, and strips all internal headers before forwarding — your upstream keys are never exposed in transit or at rest in plaintext.
• On-device protection. In Desktop Client mode, PII never leaves the machine; original values exist only in memory.
• Local-only CA. The Desktop Client's Root CA is installed locally for HTTPS interception and removed cleanly on exit; the PAC sends all non-AI traffic direct.
• Deployment control. The entire stack can run on-premise or air-gapped — gateway, ML models, audit store, and dashboard all inside your network, nothing leaving it.

Technical stack

Gateway / API

ASP.NET Core, YARP reverse proxy, Entity Framework Core, Redis, PostgreSQL

ML services

Python, FastAPI, ONNX Runtime, Hugging Face Transformers, Microsoft Presidio

Dashboard

Angular, Angular Material, Signals, SignalR (real-time review)

Desktop Client

WPF, system-tray app, local certificate management, DNS interception, PAC proxy

Getting started

1. Request access — Praetor is in private beta.
2. Register your AI systems in the inventory: provider, declared use case, owner, oversight settings.
3. Define policies, or start from a base policy and override per use case.
4. Choose ingress: point your app at the gateway (API proxy) or install the Desktop Client.
5. Watch the dashboard — allowed, blocked, and pending requests in real time, with the full audit trail.