Request anonymisation
See exactly what leaves your side.
Your request is answered inside the Caesar® engine: a large orchestrator model at the centre, and smaller models around it, each with one job. No outside provider ever sees your whole request, only small anonymised questions.
Three levels of anonymisation
- Fact-based
- Context-based
- Intent-based
Follow one request through the engine.
Nine steps, from your question to one checked answer. Play, or move the slider, to go one step at a time.You ask in your application. Your request goes to the orchestrator model, at the centre of the Caesar® engine.The context model, which holds all the context, adds what your request needs. None of it goes out.Fact-based: the PII model takes out names and identifying facts, and puts stand-ins in their place.Context-based: the decomposition model breaks the request into many small questions. None of them carries the whole story.Intent-based: the routing model spreads the questions out. Each provider gets different ones; the sensitive one stays inside.Each model answers only the questions it got, and the answers come back to the orchestrator.The orchestrator joins the answers into one, and the PII model puts the real names and facts back.The auditor model checks the answer for reliability before you see it.Your application shows you one answer, with the real facts. No outside provider saw your whole request.
Application layer
Caesar® engine
Trust boundary
Outside providers
Caesar® engine
- Context model holds all the context
- PII model takes out names, then puts them backFact-based
- Decomposition model breaks it into small questionsContext-based
- Routing model spreads the questions outIntent-based
- Local answer model answers the sensitive one
- Auditor model checks the answer
Trust boundary and outside providers
| Step | What moves | Crosses the trust boundary | Who sees it |
|---|---|---|---|
| 01Ask | Your request, in full | No | The orchestrator model |
| 02Context | The context your request needs | No | The context model |
| 03Names out | Names and identifying facts, swapped for stand-ins | No | The PII model |
| 04Break down | Many small questions, none of them the whole request | No | The decomposition model |
| 05Spread out | Different questions to each provider; the sensitive one stays | Yes, small anonymised questions | Anthropic, OpenAI and Google each get their own; the local answer model keeps the sensitive one |
| 06Answers | Each question's answer | Yes, the answers come back | The orchestrator model |
| 07Names back | The answers joined into one, with the real names and facts | No | The orchestrator and PII models |
| 08Check | The joined answer, checked for reliability | No | The auditor model |
| 09Answer | One answer, with the real facts | No | You, in your application |
Read the diagram.
- The orchestrator model sits at the centre and directs the models around it. Each of them does one job.
- The Caesar® engine's boundary holds the orchestrator and its six models. Only small anonymised questions cross the trust boundary, to the outside providers.
- A tag rides a line whenever something moves, and says what it is: a request, a question or an answer. Each padlock on it is one level of anonymisation already applied.
- Outside providers are shown by their mark. Caesar® uses different models from each.
- At rest every step is shown. Play, or move the slider, to go one step at a time.
Keep these on your side.
- Your whole request, and all of its context.
- The real names and identifying facts.
- The sensitive questions, and their answers.
- The final answer, checked before you see it.
Get answers on what crosses the boundary.
How does Caesar® handle a request, step by step?
Seven steps. 1. The request arrives on your infrastructure. 2. Caesar® reads the material locally. 3. It extracts what matters. 4. It anonymizes on three levels: personal data, context and intent. 5. It asks approved frontier models, in parallel, only what they need. 6. It compares and verifies the answers and records every call for audit. 7. It puts the answer back in your context, and your team makes the call.
What does “anonymize on three levels” mean?
Personal data, context and intent are each anonymized before anything leaves. Personal data: names, numbers and other identifiers are replaced. Context: the request is broken into smaller questions that carry no context on their own. Intent: those questions go to different models, so the purpose of the request stays behind.
What is the first level (fact-based, personal data)?
Caesar® finds personal and sensitive facts, such as names, identification and account numbers, contact details and the terms you define, and replaces them with stand-ins before a request leaves. The real values are put back in the answer you receive.
What is the second level (context-based)?
A local model breaks the request into smaller questions that make sense only together. Each question goes out without the surrounding context, the way the site’s example sends only “16 × 9”.
What is the third level (intent-based)?
The smaller questions are spread across different models and providers, which makes it hard for any one provider to piece together what was asked or why. Caesar® then verifies the answers and merges them back into your context.
Does our data reach the frontier models?
Your records stay inside the boundary you set. A frontier model receives only the anonymized part of a task it needs, and only if you have approved that model; in the site’s example, only “What’s 16 × 9?” leaves. In a fully local set-up, nothing reaches an external model at all.
Which kinds of personal data does Caesar® detect?
Names, identification and passport numbers, account and card numbers, contact details, dates and the sensitive terms your institution adds, in Arabic, French and English.
What happens if something sensitive is missed?
Caesar® is designed to fail closed: if a check cannot complete, the request does not leave. Every call is recorded, so your reviewers can inspect what was sent.
What does the audit record contain?
Your deployment defines what is captured. It can include, for each request, the user, the question and the answer, the sources used, the anonymized version at each level, the models called and when, the tool activity and the approvals, so your reviewers can show who asked what, what left and what came back.
Bring one real request. We’ll walk it through with you.
We’ll take a request your team sends every day and show you, step by step, what Caesar® keeps on your side and what it asks a provider.
Bring the problem. We’ll shape the use case with you.
You don’t need a defined AI use case to start. We work through it with your team, then the architecture, infrastructure, security review and deployment path your environment requires.
Prefer email? Write to our team