Where does Nakato sit inside your existing stack? Who operates it? How do you know sensitive data is handled correctly? This page outlines Nakato's architecture and where it sits alongside what you already run.
Integration
Nakato intercepts traffic inside your infrastructure. On Kubernetes it runs as an Envoy sidecar next to your application pod. Outside Kubernetes it runs as a standalone gateway.
Requests from your application pass through the sidecar, where a filter in the sidecar inspects outbound traffic, detects identifying information and hands it to the twinning engine. When the response comes back, the filter swaps the original values back in place of the twins.
The round trip
Your service sends a request exactly as it does today. The sidecar in the same pod finds the identifying details, swaps each one for its semantic twin and sends the twin on. When the answer comes back, the originals are restored before your service reads it.
Diagram. Your service sends real data to the Nakato sidecar; both are inside your environment. Real data never crosses the boundary.
Your service sends the request as it is, and the real value travels only as far as the sidecar.
The sidecar swaps the value for its semantic twin, and only the twin crosses your boundary.
The model answers about the twin, the only version of the value it ever meets.
The sidecar reverses the swap, and your service receives the answer with the original restored.
The sidecar sits in the network layer of each pod, so it needs no change to your code and nobody has to remember to use it.
No changes to application code.
On Kubernetes the sidecar attaches to your services automatically, and on AWS ECS the same engine runs alongside each task. Applications send requests exactly as they do now.
Enforcement doesn't depend on developers.
The filter sits in the network layer, so there is no wrapper to remember and no library to import. Only substitutions that pass a high-confidence gate are applied automatically.
Observability comes with deployment.
The sidecar scales and fails with your pods, on the same lifecycle, so there is no separate service to keep alive.
Inbound and outbound are both covered. Webhooks coming in get the same treatment as API calls going out.
Deployment
Detection, twinning and restoration all happen inside your domain, and you don't have to operate the system by hand. The model provider only ever receives the twinned data.
For central management, the engine connects to a cloud-hosted control plane. That is where you manage configuration and policy updates and view aggregated audit logs.
Only operational telemetry goes to the control plane:
The control plane also ships agent updates, model improvements and new policy configurations. Nakato does not train its models on your data. You decide whether updates deploy automatically or wait for change approval. A fully customer-managed deployment, with no cloud control plane, is also available.
Modularity
Nakato has three separable layers: the Reversible Semantic Pseudonymisation (RSP) pipeline, the mechanism that connects it to your traffic, and the deployment topology. The sidecar is the main enforcement path; the SDK covers patterns the sidecar can't reach, such as batch export pipelines.
Each layer absorbs the differences between customers. The sidecar doesn't care which language your services are written in, so a Python team and a Go team integrate the same way. The same container image ships to every customer, whichever cloud they run on, and new AI providers are added through a plugin registry. Supporting a new model means adding a plugin, not changing the engine.
For how the pipeline twins each value, see How It Works.
A control in the network layer applies to everything that crosses it. Nobody has to remember to call it.
Enforcement sits where the traffic is, not where the developer is.
Procurement
A privacy control that relies on developers calling it is only as reliable as the people using it. A layer at the network boundary applies to everything that crosses it, automatically. That is the property security and architecture teams will want to check first, along with where the originals and the substitution maps are kept.
No. On Kubernetes and ECS the sidecar attaches to what you already run. Only batch export pipelines use the SDK.
The agent runs inside your environment and you don't operate it by hand. Updates come from the control plane, and you choose whether they deploy automatically or wait for change approval. A fully customer-managed deployment is also available.
Always inside your environment. Neither the model provider nor the control plane ever sees them.
The twin, sent to the model provider, and operational telemetry sent to the control plane: health metrics, detection statistics and pseudonymised performance data.
No. Nakato does not train its models on your data.
For data providers, Nakato twins the whole dataset before it moves. Every record arrives complete and coherent, pseudonymised to the correct de-identification requirements. Twins are kept consistent across tables so relationships between records still hold.