Two Different Governance Problems
As enterprises adopt both large-scale data platforms and autonomous AI agents, two distinct categories of governance have emerged. Data governance controls who and what may access tables, files, functions, and models. Agent runtime governance controls what an autonomous agent actually does with that access once it is running. These are related problems, but they are not the same problem, and a platform designed to solve one does not automatically solve the other.
Databricks Unity Catalog and Snowflake Horizon are built to solve the first problem. Trussed is built to solve the second. Understanding where each layer starts and stops is the first step in designing a governance model that actually covers how agents behave in production.
Governance Scope by Platform
Each platform below governs a different part of the stack. The table summarizes what each one is responsible for and how it enforces that responsibility.
| Platform | Governs | Primary mechanism |
|---|---|---|
| Databricks Unity Catalog | Tables, files, functions, and ML models across Databricks workspaces | Centralized grants, lineage, and cross-workspace access controls |
| Snowflake Horizon | Data and AI assets stored within Snowflake | Unified compliance, security, discovery, and access controls |
| Trussed | AI agent behavior at execution time | Runtime enforcement of agent identity, least-privilege permissions, and tool-call authorization |
Why Catalog Grants Do Not Cover Tool Calls
Catalog grants operate on stored assets. They determine whether a query, job, or model invocation is permitted before it runs, based on the identity of the service principal making the request. This model works well for tables, files, and models because those objects are accessed in discrete, well-defined events.
Autonomous agents behave differently. A single agent task can trigger a sequence of tool calls: reading data, calling external APIs, invoking functions, and taking actions that a catalog grant was never designed to authorize individually. A catalog permission that allows an agent to read a table does not indicate whether a specific action the agent took at runtime was appropriately scoped, correctly attributed to that agent, or consistent with the task it was assigned. Catalog governance answers "can this identity reach this asset." It does not answer "was this specific tool call, at this moment, the right thing for this agent to do."
What Runtime Governance Adds
Trussed operates at the point where an agent actually acts, not at the point where a data asset is stored. This closes the gap left by catalog-level controls in a few specific ways:
- Authorizing individual tool calls rather than only broad access to a dataset or model
- Verifying agent identity separately from the service principal used for catalog access
- Enforcing least-privilege permissions as an agent's tool set changes after deployment
- Logging execution as it happens, so a full audit trail of tool-invocation sequences exists alongside data lineage
When Enterprises Need Both Layers
Catalog governance and runtime governance are complementary, not competing. Unity Catalog and Snowflake Horizon establish what data and AI assets an agent is permitted to reach. Trussed governs what the agent actually does with that access once it is operating autonomously. Enterprises running agents against governed data generally need both layers: catalog controls to secure the assets, and runtime controls to secure the actions taken against them.