An LLM security layer that keeps customer names, identifiers and business data from ever reaching the external model — and measures leakage on every release instead of assuming it away.
The Model Never Knows the Customer — Yet Still Answers the Question
The cost of adding AI to business software is usually invisible: the user's question, the table on screen, the record a tool returns — all of it leaves inside a prompt. Motice Shield narrows that path to a single gate. Everything bound for the model passes through it first, and in any undefined situation nothing is sent.
Inside the gate runs an in-memory pseudonym vault, scoped to each conversation turn and each business. Ayşe Yılmaz reaches the model as "Customer-1" and becomes Ayşe Yılmaz again on the user's screen as the answer streams back. The user's question, the screen context, the system instructions and tool outputs — all four outbound channels pass through the same rules. Tool output without a manifest declaring which fields may be shared never reaches the model at all.
Trust is tied to the provider contract too. Unless no-training, no-retention, data region and the legal basis under Turkish data-protection law (KVKK) are on record, not a single call is made with real data. The model may only use record IDs it actually saw in that turn — a rule we added after measuring that one invented branch ID could make 11 bookings show up as "0".
How It Works
Per-turn, per-business pseudonym vault, rehydrated in the response stream
Egress control on four channels: question, screen context, system prompt, tool output
Field manifests: undeclared data is withheld from the model by default
Fail-closed egress gate: no call without policy, purpose context and decision log
Provider contract evidence: training, retention, data region and KVKK checks
ID-provenance gate: the model may only use identifiers it has actually seen
We Measure the Leakage
We do not hide the residual risk. Every release runs the same role-based question set and reports leaked pseudonyms, output withheld from the model, latency and token cost. Security becomes a test result, not a claim.
Where We Use It
Ask Motice, the AI assistant inside Motice — our platform for pilates, yoga and studio businesses — runs behind this layer. Its core was designed as a package independent of Motice's business rules, so the same protection can move to other products.
Bring this technique into your product
Talk to our team about building the same approach into your own system.
The interface and the AI pass through the same door: the AI can never exceed the permissions of the person using it — it drafts, but never applies without approval.
The AI Gets No Permissions of Its Own — Only Yours
The most dangerous shortcut in AI-assisted products is opening a separate "super user" path for the model. We do the opposite: every operation has exactly one definition — one schema, one permission, one risk level, one handler. A button in the interface and a tool the AI calls go through the same registry.
Authorization does not care whether the caller is a human or the AI; the AI inherits exactly the permissions and branch scope of the person using it. A risk gate sits on top: reads are free, writes require human approval, critical operations never run autonomously. The approval card carries a hash of the preview it shows, expires, and can be confirmed only by the person who asked.
Identity never comes from the model either. User and business identity are resolved from the server-side session; tool schemas cannot contain identity fields, and a test breaks the build if that rule is ever violated. In the database, every business table is protected by PostgreSQL row-level security (RLS) — even a faulty AI query cannot reach another business's data.
How It Works
Single door: one operation definition for both UI and AI
AI as the user's mirror: same permissions, same data scope
Risk gate: reads free, writes approved, critical never autonomous
Identity from the session; identity fields banned from tool input
Business isolation in the database: forced RLS with a coverage test
Why It Matters
Two doors eventually produce two truths: the rules for the same operation quietly drift apart between the interface and the AI. A single door makes that architecturally impossible — change a rule, and it changes for humans and AI alike.
Where We Use It
Operations across Motice's 21 domain modules — bookings, packages, sales, payments — run through this single door, whether triggered from the panel or from Ask Motice.
Bring this technique into your product
Talk to our team about building the same approach into your own system.
A remote identity verification pipeline that relies on check digits rather than guesswork when reading ID cards — with face matching and liveness built without using real personal data.
On an ID Card, the Text You Read Is Not the Thing to Trust
Most remote identity verification systems read the front of the card and trust what they read. We measured it: on real cards, front-side OCR reads only ~77% of fields exactly right. So we anchored trust somewhere else — the machine-readable zone (MRZ) on the back of the card.
The MRZ carries its own proof through ICAO 9303 check digits. If a value fails its check digit, it is wrong — there is no room for guessing. Front-side reading is supporting evidence only: the Turkish national ID number is validated with its own algorithm, single-character OCR errors are recovered through that rule, and dates and names pass plausibility checks.
The card's owner must be proven too. The card photo and a live selfie are matched through face embeddings, with the threshold set by a calibration tool that measures false-accept and false-reject rates. The user is asked for randomized head movements, and passive anti-spoofing runs against a photo held up to the camera. Development ran on synthetic cards we generated, not on real ID cards — so there is no personal-data burden from the start.
How It Works
MRZ-canonical trust model: ICAO 9303 check digits
Front OCR as support only; error recovery via the national ID algorithm
Card detection, perspective correction, auto-rotation by OCR vote
Face matching with a calibrated threshold (ArcFace)
We dropped a field-detection model trained on synthetic cards because it missed fields on real ones, and stripped the pipeline of heavy deep-learning dependencies. Measuring accuracy on real cards rather than demo cards is what made that call.
Where We Use It
In UNITICID, our own remote identity verification pipeline. The same face-matching foundation also lets Hardiye recognise returning customers without storing their photos.
Bring this technique into your product
Talk to our team about building the same approach into your own system.
Agent memory that updates knowledge without deleting it, can answer "what did we know, and when", and gives every AI agent the same company memory.
An Agent Should Know Not Just What Is True, but When It Was True
Most AI memory either forgets everything or piles everything up. Both end the same way: the agent mistakes an old decision for today's truth. In APEX we built memory as bi-temporal. New knowledge does not delete the old, it supersedes it; the old record stays archived, knowing what replaced it. Even "what did we know in March?" has an answer.
Remembering is selective, too. Near-duplicates are never written twice. At retrieval, semantic similarity, importance and recency are scored together; recency decays exponentially, so an old but important decision is not lost. Knowledge with a retention period drops out on its own when it expires, and because embeddings are generated locally, the memory never leaves the company.
The memory belongs to no single agent. It is served over MCP; conversation, coding and content agents read from and write to the same brain. The same server also connects to Linear and Google Drive. Every call leaves an audit record and a trace with personal data masked.
How It Works
Bi-temporal records: supersede, version chain, never delete
Deduplication that never writes a near-duplicate twice
Re-ranking by meaning + importance + exponential recency
Retention-based forgetting for KVKK; local embeddings
MCP server: recall, remember, context; Linear and Drive tools
OAuth 2.1 access, an audit record and trace on every call
Hybrid Retrieval
We use the same thinking in product search. In Hardiye, precise requests such as price, flavour or weight go to a structured query in milliseconds; vague ones like "something for after training" go to semantic search. Both sit behind a single tool — the real-time model never has to decide which to use.
Where We Use It
In APEX, Unitic's own collective AI brain, and in Hardiye's product search.
Bring this technique into your product
Talk to our team about building the same approach into your own system.
A testing and telemetry setup where voice assistants are put in conversation with another AI playing the customer — and measured — before they ever meet a real user.
You Don't Test a Voice Assistant by Listening. You Test It by Talking to It.
A few trial conversations tell you almost nothing about a voice assistant's quality; the failures hide in the tail of the conversation, at the moment of interruption, in a misheard product name. For Hardiye we turned this into a testing problem: an AI playing the customer joins the real-time room and talks to the assistant, and the conversation's event timeline is verified automatically against written scenarios.
We don't treat latency as one number. A sentence's mouth-to-ear journey is marked step by step: the moment the user stops speaking, the model's first word, the moment audio starts playing. We see separately how much of the total is spent in the backend and how much in the avatar. A browser driven with a fake microphone replays interruption (barge-in) scenarios on every release.
Measurement drives decisions: the silence threshold is tuned by A/B test, tool outputs are compressed to the size the model handles well, a possibly misheard product name triggers a spoken confirmation, and non-Latin hallucinations in transcripts are counted separately. The same discipline runs through our other AI systems: cost- and latency-targeted scenario tests for the company brain, and leakage measurement on every Motice release.
How It Works
LLM-simulated customer: speech-to-speech tests in a real-time room
Event-timeline verification against YAML scenarios
Mouth-to-ear latency telemetry, with backend and avatar shares split
Latency and barge-in tests through a fake-microphone browser
End-to-end per-session traces in Langfuse
Scenario tests with cost and latency targets
Where We Use It
In Hardiye, Hardline Nutrition's voice assistant; and in the AI layers of APEX and Motice.
Bring this technique into your product
Talk to our team about building the same approach into your own system.
Content infrastructure where an AI agent can change the site only through typed tools, and every edit passes a governance flow from draft to approval.
We Give the Agent a Toolset, Not a Keyboard
"Let AI run our website" is a tempting idea, but opening the database or the HTML to an agent invites disaster. In Anvil, the agent touches the site only through defined, typed tools: edit a page, update SEO, check site health, search knowledge. Each of roughly twenty tools has a contract for its input and output, and the same tools are exposed both to external agents over MCP and to the assistant inside the panel.
Governance lives in the tool layer, not in the agent's good intentions. Every edit the agent makes lands as a draft; only publishing changes the live site, and publishing passes an approval queue. While a person is editing a page, the agent cannot touch it. Tenant context is injected on the server and never arrives as a model parameter. Every action is written to an audit log.
The agent doesn't invent. Before writing a fact, it searches the tenant's own knowledge base; if it finds nothing, it asks. The brand's voice is extracted from a URL and added to every instruction; alt text for images is generated in the background, and SEO metadata and structured data are updated through the same tools.
How It Works
Contracted, typed toolset; MCP and in-panel agent
Draft → approval queue → publish; page locks
Tenant context on the server, never from the model
Per-tenant knowledge base: search first, ask if nothing is found
Brand identity extraction, automatic alt text, SEO and structured data
An audit record for every action
Where We Use It
In Anvil, Unitic's own AI-first content management product.
Bring this technique into your product
Talk to our team about building the same approach into your own system.
