Custosa vs data governance platforms (Immuta, Privacera)

The short version: data governance platforms such as Immuta and Privacera govern structured data in the warehouse, classifying and tagging sensitive columns and enforcing access policy on queries, largely at build time and in batch. Custosa governs the model boundary at runtime, inspecting the exact records retrieved into a prompt, issuing a per-field PASS or REDACT verdict for the actor's role, and signing content-free evidence of each decision. The catalog owns the warehouse; Custosa owns the inference path. They are complementary far more often than they are alternatives.

If you are evaluating an Immuta alternative for AI, or weighing data catalog AI governance more broadly, the more useful framing is not "which tool wins" but "which layer owns which problem." A catalog owns data classification and access policy in the data platform. A runtime control plane owns per-field access decisions at the moment a model reads data, plus tamper-evident evidence. The table below maps the two categories against the capabilities buyers tend to conflate.

01What data governance platforms do well

A data governance platform, or catalog, is the control layer for your data warehouse and analytics engines. Tools such as Immuta and Privacera connect to platforms like Snowflake, Databricks, BigQuery, and Starburst, discover and classify sensitive data, and let you author access policy once and enforce it consistently across those systems. For teams that need to make one dataset safely serve many audiences, this is essential infrastructure.

• Cataloging and classification. Automated scanning detects and tags sensitive columns across multiple data sources, building a classified inventory and the metadata that policies attach to.
• Column and row-level policy. Row filters limit which records a user sees, and column or cell masking limits which values are visible, so a regional analyst sees only their rows and sensitive columns are masked by role.
• Attribute, tag, and purpose-based access. Policies combine role-based, attribute-based, and tag-based controls, and can gate access by declared purpose, authored in a central, often plain-language interface.
• Centralized enforcement. One policy deploys to many supported data services, which removes the need to manage permissions separately in each platform.
• Audit and compliance reporting. The platform tracks who accessed which data in the warehouse and whether access was compliant, which supports governance and regulatory reporting.

These are real and valuable capabilities. For governing structured data in the warehouse, a catalog is the right tool. The question is what happens after data leaves the warehouse for an AI pipeline.

02What catalogs do not cover for runtime AI

A catalog governs data in the data platform. Its policies evaluate when an analyst or pipeline queries a catalogued table. But an LLM rarely reads the warehouse directly. Content is exported, embedded into a vector index, cached, or retrieved into a prompt, and at that point the query the catalog policed is over. The decision that matters for AI happens later, at the model boundary, and that is where the gap opens.

• It does not inspect the records retrieved into a prompt. The catalog governs the query against the warehouse, not the rows or documents a retrieval step later assembles for a model. Once content is in an embedding store or a prompt, the warehouse policy is no longer in the path.
• It does not give field-level verdicts at inference. Column and row policies are enforced when the query runs. They do not re-evaluate, at the moment a model reads data, whether a particular field of a particular record should be exposed to the particular actor making the AI request.
• It is largely build-time and batch. Governance is applied where data is prepared and queried, often offline or on a schedule. The live, per-request inference path, where the actor, the fields, and the moment all matter, sits outside that scope.
• It does not produce signed, content-free evidence of each AI access. Warehouse audit logs record query access. 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 that boundary. 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 a catalog and Custosa enforce who may see which data, and both can mask or withhold sensitive fields based on identity. A catalog masks columns and filters rows for warehouse users; Custosa withholds fields before they reach a model. A buyer comparing them on a feature checklist will see "field-level access control" and "role-based policy" appear in both columns, which is accurate.

The distinction is the surface and the timing. The catalog governs the warehouse and enforces at query time, largely build-time and batch; Custosa governs the model boundary and enforces at inference, in the live request path, recording signed evidence of each decision. One controls who reads the warehouse; the other controls what reaches the model. They are the same idea applied at two different points in the data flow.

04When to use each, and why they are complementary

These tools govern different surfaces in the same pipeline, so the practical answer is usually "both," with each owning what it is built for.

• Use a data governance platform to govern the warehouse: catalog and classify data, enforce column and row policy on queries across your data services, gate by attribute and purpose, and report on warehouse access. This is control over structured data in the data platform.
• 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 treats the catalog as the source of truth for warehouse access while Custosa governs the inference path. The catalog ensures data is classified and queried under policy; Custosa then 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 catalog governs the warehouse; Custosa governs the model boundary the catalog does not reach. 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 catalog and is not trying to be; it is the runtime data-control layer that governs what reaches the model after a governed warehouse has done its work.