Governance belongs in the control plane. Tokenization execution belongs near the data.
TokenMesh separates governance from execution. The control plane decides and signs the rules. The application enforces those rules locally.
Comparison
Central tokenization API model versus TokenMesh SDK model
| Capability | Central Tokenization API Model | TokenMesh SDK Model |
|---|---|---|
| Runtime path | External API call per tokenization | In-process SDK tokenization |
| Raw data movement | Raw values may travel to service | Raw values can stay in application boundary |
| Control plane outage | May affect new tokenization if service is hot path | Valid cached bundle can continue |
| Regional drift | Service replicas must stay aligned | Signed bundle version/hash can be compared |
| Key ownership | Often vendor/service-managed | Designed for customer KMS/HSM/Vault references |
| Latency | Network call dependent | Local execution avoids per-event network hop |
| Audit | Service-side audit | Redacted SDK/control-plane evidence |
| Developer integration | API dependency | SDK embedded in app |
Philosophy
Control the policy. Keep the data. Move only tokens.
Control plane
Decides policy, signs bundles, records evidence, and detects drift.
SDK execution
Verifies the rulebook and tokenizes locally inside authorized workloads.
Customer keys
Uses KMS/HSM/Vault references instead of handing raw key material to the control plane.
Data movement
The architectural wedge is simple.
Raw values stay close to the producer. Signed policies move to applications. Tokens move downstream. Redacted evidence moves back to governance workflows.