In Part 1, I talked about how Unity Catalog governs Databricks well but can’t anchor an enterprise that also runs Snowflake, Lake Formation, and Iceberg. This next part explores why Unity AI Gateway can’t govern every agent and why enterprises need a vendor-neutral control plane. The fix was to define policy once and enforce it natively in each engine. That was the data half.
This second half is about agents. Most enterprises now have AI agents in production, and no central view of what those agents can see or do. They reach across Snowflake, Databricks, SaaS apps, and internal APIs faster than any human ever did. Few teams can account for all of them.
Agents break the old model in a specific way.
Why the old tools don’t govern agents
Observability tells you what happened, after the fact. Authorization tells you what is statically allowed. Neither governs the live decision: this agent, this declared purpose, this data, right now.
That is the missing layer. The same principle from Part 1, define once and enforce everywhere, applies cleanly in three actions.
Discover, observe, secure
Discover is the act of finding the agents you didn’t sanction. Agent information is inferred from runtime traffic, framework registries, and gateway logs. The real count is almost always higher than the org chart says.
Observe is the act of capturing every prompt, retrieval, and tool call as it happens.
Secure is the act of authorizing each action at the moment it fires. A single tool call looks like this. The agent’s identity is resolved to the workload that invoked it. Its declared purpose is checked against the purposes allowed for that data, not a self-asserted label it can spoof. A just-in-time, purpose-scoped grant is issued. The action is allowed, masked, or blocked. An immutable audit entry is written.
Done right, the decision sits inline only for the authorization itself, with policy cached so it doesn’t become a per-call tax. The latency budget is the thing to pin down in any evaluation.
Time-to-access is the metric of the agentic era
An agent can’t wait days for a ticket, and it shouldn’t hold access after the work is done. Its access has to be bound to the agent’s own identity and scoped to the life of the agent: granted for the task, withdrawn when the task is done, never left as a standing entitlement that outlives the work.
An agent’s access should live and die with the task. Access that outlives its task is how the next breach happens.
The regulatory clock is ticking
This is where “we’ll govern agents later” gets expensive. EU AI Act obligations for high-risk systems take effect in 2027, and they map almost one-to-one onto discover, observe, secure: know your AI systems, log what they do, keep a human able to intervene. The evidence and logging have to exist before the deadline, not start at it.
Why not let the platform govern its own agents?
Every agent platform ships with native governance, and the fair question is whether that’s enough. Take Databricks: Agent Bricks builds and runs agents on your data, and Unity AI Gateway governs their model and tool access. Both are strong. Both are also anchored to the Databricks ecosystem, exactly like Unity Catalog on the data side.
That’s the limit. A vendor-neutral control plane governs the agents Databricks builds and the ones built in Bedrock, Copilot Studio, CrewAI, or in-house, reaching Snowflake, Lake Formation, and SaaS as readily as Databricks data, under one set of policies and one audit.
It’s the portfolio problem again, moved up a layer to agents.
What you’re signing up for
The same honesty from Part 1. A control plane is another product to run, and the security lead’s question stands: what happens when it’s unreachable?
For agents the answer is the same shape, with a sharper edge. Compiled policy lives at the enforcement points, so an outage stops new policy from propagating but doesn’t open access. Fail-static, not fail-open. For agents specifically, that makes a fast revocation path non-negotiable, because an agent acts continuously and you may need to kill its access mid-task.
Questions leaders should be asking
If you’re evaluating where agent governance sits in your stack, these are the questions that expose whether you actually have it or just think you do.
How many agents are actually running, and who can name them?
Can you block a single non-compliant tool call in real time, across frameworks, not just inside one platform?
Does an agent’s grant carry a declared purpose and an expiry tied to its task, or does it persist after the work is done?
Two governance jobs, one control plane
Databricks governs Databricks well. What it can’t govern are the agents built in Bedrock, Copilot Studio, or CrewAI, or the data sitting in Snowflake, BigQuery, and Iceberg. A vendor-neutral layer fills that gap, and it’s what Trust3 AI was built for.
The Trust3 AI Unified Trust Layer discovers every agent, observes every decision, and secures every action, across any framework and any cloud. Intent is defined once and enforced natively in each engine, with identity, declared purpose, and lineage traveling with every request, every hop. One control plane to secure any data, any agent.
Across both blogs the same argument is applied twice. The enterprise is a portfolio, not a single platform, and a portfolio needs a coordinator that isn’t one of the holdings. Part 1 showed us that the coordinator kept data policy consistent across engines. Here it keeps agent governance consistent across frameworks. Same principle, harder problem, and a regulatory clock that’s already running.
Let’s chat further here: https://trust3.ai/demo/