The short version: Skyflow is a data privacy vault that protects sensitive data where it is stored, by isolating it, tokenizing it, and governing detokenization. Custosa is a runtime data-control plane that decides, at the moment of AI access, which fields a given actor may see and signs evidence of that decision. A vault asks where sensitive data lives and who can resolve a token; Custosa asks who reaches which field at inference and proves the answer. They are complementary far more often than they are alternatives.
If you are evaluating a Skyflow alternative for inference-time control, the more useful framing is not "which tool wins" but "which layer owns which problem." A vault owns isolation, tokenization, and governed detokenization across your stack. A runtime control plane owns per-field access decisions at the point a model reads data, plus tamper-evident evidence. The table below maps the two categories against the capabilities buyers tend to conflate.
| Capability | Skyflow (data privacy vault) | Custosa |
|---|---|---|
| Isolate sensitive data outside the main stack | ✓ | Not its job |
| Tokenize and de-identify data at rest | ✓ | Not its job |
| Governed detokenization via API | ✓ | No |
| Reduce sensitive-data exposure overall | ✓ | ✓ |
| Inspect records retrieved into a prompt at runtime | No; storage-centric | ✓ |
| Per-field PASS or REDACT by actor role at inference | No | ✓ five-level clearance lattice |
| Deterministic formal policy engine | No | ✓ Cedar, fail-closed |
| Signed, hash-chained, content-free evidence of each access | Audit logs, not a signed ledger | ✓ |
| Data plane runs inside your environment; records never leave | Vault-hosted; varies by deployment | ✓ data plane in your boundary |
01What Skyflow does well
Skyflow is a data privacy vault. Instead of letting sensitive personal data spread across application databases, warehouses, logs, and analytics systems, it centralizes that data in a dedicated, isolated store and hands the rest of your stack tokens in its place. Sensitive values are protected with strong techniques, and access to the real data is mediated through the vault. It is a clean answer to a real problem: too many systems holding plaintext.
- Data isolation. Sensitive PII, PHI, and payment data live in the vault, outside your existing infrastructure, so the blast radius of a breach in any downstream system is reduced to tokens.
- Tokenization and de-identification. Downstream services store non-sensitive tokens with no exploitable mathematical link to the original values, while preserving format and structure so existing schemas keep working.
- Governed detokenization. Resolving a token back to its value is mediated by fine-grained, zero-trust access control, so only authorized callers can retrieve plaintext.
- Developer APIs. Applications interact with the vault through APIs, letting teams use sensitive data without copying it across the stack.
- Compliance posture for data at rest. Centralizing and tokenizing sensitive data supports privacy and residency requirements by shrinking where regulated data physically lives.
These are real and valuable capabilities. For organizations trying to contain where sensitive data exists, a vault is a strong architectural choice. The question is what it governs at the moment a model reads data.
02What a vault does not cover for inference-time access
A vault is storage-centric. It governs where sensitive data lives and who can detokenize it. That is a different question from which specific fields a particular actor should see in a particular AI request. By the time a record is retrieved into a prompt, the relevant decision is contextual: this role, this field, this moment. A vault is not built to make that decision per request.
- It does not make per-actor, per-field decisions at inference. A vault governs detokenization rights, not whether a specific field of a retrieved record should be exposed to a specific role inside a given prompt. Once data is detokenized for an authorized path, the vault has done its job; what happens at the model boundary is outside its scope.
- It does not inspect the records assembled for a prompt. Tokenization protects data at storage time. It does not evaluate the rows or documents a retrieval step pulled together for a model and decide, field by field, what may pass.
- It does not run deterministic, role-based policy at the model boundary. A vault's access control governs the vault. It is not a formal policy engine sitting in the inference path issuing a verdict for each field against the actor's clearance.
- It does not produce signed, content-free evidence of each AI access. Vault audit logs record access to the vault. They are not designed to be a tamper-evident, offline-verifiable record of which field was passed or redacted, for which role, at the moment a model read it.
Custosa is built for exactly that moment. Its data plane runs inside your environment and inspects every record and field at runtime, before the model. A deterministic formal policy engine (Cedar) evaluates each field against the actor's role using a five-level clearance lattice, issues a per-field PASS or REDACT verdict, and withholds sensitive fields before the prompt is built. The control plane receives only content-free verdict evidence; the records themselves never leave your boundary. Because the engine is deterministic and fail-closed, the same inputs always produce the same decision, and an unresolved decision blocks rather than leaks.
03Where they overlap
The overlap is real and worth stating plainly. Both Skyflow and Custosa reduce sensitive-data exposure, and both can keep raw values from spreading where they should not. A vault does this by relocating and tokenizing data so most systems never hold plaintext; Custosa does it by withholding prohibited fields before they reach a model. A buyer comparing them on a feature checklist will see "reduces exposure of sensitive data" appear in both columns, which is accurate.
The distinction is when and how the protection applies. The vault acts at storage and pipeline time, substituting tokens across the stack; Custosa acts at access time, evaluating the actual fields and the actor's role with a formal policy engine and recording signed evidence of each decision. One narrows where sensitive data exists; the other decides, in the moment, what reaches the model and proves it.
04When to use each, and why they are complementary
These tools live at different layers of the same data lifecycle, so the practical answer is often "both," with each owning what it is built for.
- Use Skyflow to contain where sensitive data lives: isolate PII, PHI, and payment data in a vault, tokenize it across your stack, and govern detokenization. This is protection for data at rest and in pipelines.
- Use Custosa to govern what data reaches the model: per-record, per-field, per-role inspection at runtime, with deterministic policy and signed, tamper-evident evidence. This is control over AI access at the moment of use, inside your environment.
A natural deployment uses a vault to keep plaintext out of most systems, so the broader environment holds tokens rather than raw values, while Custosa governs the model boundary. At query time, Custosa inspects the records retrieved into a prompt, applies role-based policy, withholds fields the actor may not see, and writes a content-free evidence entry for each decision. The vault narrows the surface where sensitive data exists; Custosa controls and proves field-level AI access. Added latency from Custosa inspection is typically a p99 of 50 to 110ms, which fits inside an interactive AI request.
Custosa is early-stage and in production with design partners. It is not a vault and is not trying to be; it is the runtime data-control layer that governs what reaches the model after a vault has done its work at rest.
See field-level control in front of your model
Custosa inspects every record and field at runtime, redacts by role, and signs content-free evidence of each decision, all inside your environment. It runs alongside the data vault you already have.
05Frequently asked questions
What is Skyflow?
Skyflow is a data privacy vault. It isolates sensitive personal data, such as PII, PHI, and payment data, in a dedicated store outside your main infrastructure, then tokenizes and de-identifies it so downstream systems hold tokens instead of the real values. It provides governed detokenization, fine-grained access control over the vault, and APIs that let applications use the data without spreading it across the stack. The goal is to reduce where sensitive data lives and to shrink the systems that ever touch plaintext.
Is Custosa an alternative to Skyflow?
Not exactly. The two address different points in the data lifecycle and are often complementary rather than substitutes. Skyflow protects sensitive data at storage and in pipelines through isolation and tokenization. Custosa is a runtime data-control plane that inspects records field by field at the moment of AI access, applies role-based PASS or REDACT decisions before the prompt is built, and signs content-free evidence of each decision. If your question is who reaches which field at inference time and how you prove it, that is Custosa. If your question is how to isolate and tokenize sensitive data at rest, that is a vault.
What is the difference between a data privacy vault and a runtime control plane?
A data privacy vault is a storage-centric pattern: it centralizes sensitive data, replaces it with tokens downstream, and governs detokenization. It is concerned with where data lives and who can resolve a token back to a value. A runtime control plane is an access-decision layer: it sits in the path of a specific request, evaluates the exact records and fields being retrieved against the actor's role, and decides per field whether each value may be exposed at that moment. A vault reduces exposure by relocating data; a control plane reduces exposure by deciding access at the point of use and recording evidence of the decision.
Do tokenization and runtime redaction overlap?
They overlap in intent because both reduce how much sensitive data is exposed, but they work differently. Tokenization substitutes a sensitive value with a non-sensitive token at storage time, so systems holding the token never see plaintext unless they detokenize through governed access. Runtime redaction evaluates the actual fields requested for a given actor and withholds the prohibited ones before they reach the model, with a per-field verdict and signed evidence. One protects data by replacing it across the stack; the other makes a contextual, role-aware decision at the moment of access.
Can you use Skyflow and Custosa together?
Yes, and they fit together cleanly. A vault can protect sensitive data at rest and across pipelines, so the broader environment holds tokens rather than raw values. Custosa then governs what reaches the model at query time: it inspects the records retrieved into a prompt, applies deterministic role-based policy, withholds fields the actor may not see, and writes a content-free, tamper-evident evidence entry. The vault narrows where plaintext exists; Custosa controls and proves field-level AI access at runtime. The two cover adjacent layers of the same problem.