MODE 01
Leakage
Sensitive fields reaching external models in identifiable form. SyniSense refuses the call before it leaves the perimeter.
DATA GOVERNANCE
SyniSense — safety at the boundary.
The layer that lets sensitive data work with frontier external models without leaving the perimeter in identifiable form. Anonymises on the way out. Re-identifies inside the perimeter on the way back. Produces an audit receipt for every call.
Our compliance officer signed off. The model never saw a real name.
SECTION 01 — HOW IT WORKS
Out, across, back.
- 01 — OUTAnonymises on the way out.Sensitive identifiers — names, account numbers, medical record IDs, any field marked as a boundary token — are replaced with reversible pseudonyms before any request leaves the perimeter.
- 02 — ACROSSModel never sees the real data.The external model receives the pseudonymised payload only. SyniSense holds the mapping inside the perimeter, where the model cannot reach it.
- 03 — BACKRe-identifies on return.The response is matched back against the perimeter-held mapping. The user sees the real data. The model never did.
SECTION 02 — AUDIT
An audit receipt for every call.
WHAT WAS REDACTED
Every field replaced, every token used.
Every field replaced, every token used, every mapping reference — recorded against the request.
WHAT WAS SENT
The exact pseudonymised payload.
The exact payload the external model received, in pseudonymised form. Re-derivable for audit, never re-derived in production.
WHAT CAME BACK
Before and after re-identification.
The model response before and after re-identification, with the diff. Inspectable by compliance, security, and data protection teams.
SECTION 03 — FAILURE MODES
What it catches.
MODE 02
Re-identification by inference
Model output that infers identity from quasi-identifiers — postcodes, dates, rare combinations. SyniSense flags reconstructable patterns.
MODE 03
Audit gap
Requests that cannot be replayed under audit. SyniSense refuses calls that cannot produce a complete receipt.
MODE 04
Policy drift
Boundary policy that has slipped out of alignment with regulation or internal control. SyniSense re-validates policy on every call, not on every deploy.
SECTION 04 — STACK POSITION
Inside Akki, or standalone.
INSIDE AKKI
Integrated by default
When the Akki platform is deployed, SyniSense is the data boundary layer. Every external model call is mediated through it. Audit receipts are written to the platform's own observability stack.
STANDALONE
As a framework
For organisations using Copilot, Claude, or GPT through existing infrastructure, SyniSense deploys as a perimeter SDK. The mapping store stays inside the customer's environment; nothing about the perimeter leaves the perimeter.
SECTION 05 — DEPLOY
Deploy SyniSense.
Deployment begins with a conversation about the perimeter, the data classes inside it, and the regulators who will read the receipts.