HOW IT WORKS
Security and governance, inside your data
Theom observes, classifies, and validates inside your own account, and nothing identifying is retained outside your environment.
One graph underneath, three modes on top
Theom joins your data with the objects, identities, policy, and activity around it into one queryable graph. You turn on protection in three modes, in order: observe first, then enforce at the data layer, then control AI inline. One policy drives all three.
Explore the platformTHE KNOWLEDGE GRAPH
Objects, identities, policy, and activity, joined
Each layer of your estate contributes to one graph rather than a set of disconnected scans. Because objects, identities, permissions, policy, and observed activity are joined, a question like which gold products carry PHI, who queried them last month, and which raw tables still feed them is a single traversal instead of a project. It is also the shape of the Theom mark: a triangle joining data, AI, and human identity.
TURN IT ON IN STAGES
Turn on protection in three stages
Most teams start with observe, add data-layer enforcement where the label is trusted, then control AI inline. Same deployment, same policy throughout.
Observe
Theom classifies, reconciles access against content, and watches activity. Tags are written and nothing changes in the query path, so you can run it across the whole estate from week one.
Enforce at the data layer
Those tags drive the platform’s own row, column, and masking controls. The platform does the enforcing on the labels Theom maintains, so Theom is never in the query path and cannot affect performance or availability.
Control AI inline
For model and agent requests, Theom evaluates the request against identity, data sensitivity, and policy, and can allow, block, shape, or redact the response. Here Theom is a dependency in the AI request path, and you choose whether it fails open or fails closed.
THE TWO ENFORCEMENT POINTS
Where enforcement happens
The two places the one policy is applied: the platform’s own controls at the data layer, and Theom’s inline decision at the AI layer.
Where Theom sits
Outside the query path.
Inline in the request and response cycle.
Who enforces
The platform’s own row, column, and masking policies, driven by tags Theom maintains.
Theom evaluates the request against identity, data sensitivity, and policy, and can block or shape the response.
The verbs
Surfaces, reconciles, labels, alerts, drives native controls.
Allows, blocks, shapes, redacts.
Performance
Nothing Theom does can affect query performance or availability.
Theom is a dependency in the AI request path.
If Theom is unavailable
Not applicable — the platform’s controls are unaffected.
The customer chooses. We support failing open and failing closed.
Resolved for display, never retained
Findings and object metadata cross at render time — names, classifications, grants, counts. What happens the rest of the time is the whole argument: nothing identifying is retained outside your environment.
In flight, for display. A name is resolved on demand, under your own authentication, by asking the deployment inside your environment.
At rest, everywhere else. What sits outside that environment is references — identifiers standing in for schema, table, and column names.
Inspect the Theom-controlled database and you would find no real object names and no mapping back to them. That mapping never leaves you.
Deployed inside your own account
Deployment is the same shape on Snowflake and on Databricks: a scoped read-only identity, dedicated compute so the cost is visible to you, results held in your account, and a scheduled job that keeps the picture current. Theom runs natively inside Snowflake, Databricks, and BigQuery.
No agent, no host to manage, and no copy of your data
Least privilege — USAGE and SELECT only on the approved scope; no write, delete, alter, ownership, or grant on your data
Customer record data is analyzed in place and never copied to a secondary Theom repository
CAPABILITIES
Go deeper
The architecture in practice, capability by capability.
Common questions
Does Theom store our metadata outside our environment?
No. Findings and object metadata are resolved for display and never retained. Real names cross at render time, under your own authentication, from the deployment inside your environment. What sits outside is references — identifiers that stand in for schema, table, and column names — with no mapping back to them.
Is Theom in our query path?
Not at the data layer. There, Theom labels and the platform applies its own row, column, and masking controls, so nothing Theom does can affect query performance or availability. At the AI layer, Theom evaluates the request inline and is a dependency in that path, and you choose whether it fails open or fails closed.
What is the knowledge graph?
One live graph that joins your data with the objects, identities, policy, and activity around it. Because those are joined, questions that would otherwise be a project become a single traversal, and the same graph feeds both detection and reporting so they cannot disagree.
How is Theom deployed?
Inside your own account, on your own compute, through a scoped read-only identity and dedicated compute, with results held in your account and a scheduled job that keeps the picture current. It is agentless: no host to manage and no copy of your data.
See Theom inside your own environment
We will walk you through the architecture on your own stores, with nothing moved out.
Book a Demo