Unity Catalog vs Independent Agent Governance

Does Unity Catalog give you tamper-evident, independent evidence of what your agents did?

Databricks shipped real agent governance, and its "Governing AI agents at scale with Unity Catalog" post from May 20, 2026 is worth your time. The Unity AI Gateway writes the full payload of every model call to inference tables: the exact prompt, the exact response, token counts, latency. Unity Catalog audit logs capture which principal called what, from which agent, and when. MLflow tracing auto-instruments the common agent frameworks and model SDKs, landing traces as Unity Catalog tables. That is a genuinely strong observability story, and it is documented as production-ready.

The problem is what all of it shares. Every bit is telemetry the platform emits about itself and stores in tables the same platform governs. Databricks does market these inference tables as an audit-ready record for compliance review, which is the obvious counter to raise, so let me answer it head-on. Audit-ready observability, meaning queryable and complete by intent, is not the same as tamper-evident, meaning cryptographically provable that no record was altered, inserted, or deleted after the fact. Nowhere in those posts does Databricks claim any of it is hash-chained or cryptographically signed. So it answers what happened beautifully, and it says nothing about whether the record could have been changed afterward. Those are two different questions, and only one of them is a compliance question.

One caveat on sourcing: the mutable, non-cryptographic read is my own analysis of what the posts describe, meaning table-based storage under a single control plane, rather than a Databricks quote. They never claim integrity guarantees, and equally they never rule the possibility out.

Why native telemetry falls short as audit evidence

Observability tells you what your system did so your engineers can debug it. Audit evidence is a stronger claim: it lets a third party confirm what your system did even when someone has a motive to lie about it. The distinction sounds academic right up until an incident review, a regulator, or a customer's security team asks the uncomfortable version of the question, which is how you know a given log is complete and unedited.

With table-based logs, the honest answer is that the platform says so. The platform that ran the agent also wrote the log, stores the log, and holds the keys to the storage. That is the system under audit acting as its own only witness. In most other domains we would call that a control weakness. You do not let a trader reconcile his own book. Separation of duties exists precisely because self-attestation is not evidence, however detailed it happens to be.

This is not a criticism of Databricks specifically. It holds for any native telemetry, from any platform, that lives in mutable storage the platform controls. Such logs are rich, queryable, and well suited to engineering work. They are simply not the artifact you hand an auditor with the claim that it cannot have been tampered with.

Agent goal hijack is not theoretical, and that raises the stakes on logging

Why obsess over whether a log could be altered? Because the attacks that make logs matter are already working. In December 2025 the OWASP GenAI Security Project released its Top 10 for Agentic Applications, and the number one category, ASI01 Agent Goal Hijack, folds prompt-injection-style manipulation such as hidden instructions in documents, emails, or RAG results into the broader problem of an attacker rewriting an agent's objective. Simon Willison's lethal trifecta is the crisp version of why this bites: an agent becomes dangerous when it has access to private data at the same time as exposure to untrusted content and a channel to send data back out.

How well does the attack work? In January 2025 NIST, working with the UK AI Security Institute, used an enhanced version of the AgentDojo framework and found that when red-teamers tailored attacks to how LLM agents actually behave, task-hijacking success climbed from an 11% baseline to 81%. That is roughly a sevenfold increase against baseline defenses, and it is worth re-checking against the NIST source before you quote it. NIST's broader adversarial ML taxonomy, AI 100-2e2025 from March 2025 catalogs the same family of techniques, including indirect prompt injection, memory poisoning, and supply-chain attacks on agent tools.

The attack has also left the lab at least once. EchoLeak (CVE-2025-32711), disclosed by Aim Labs (Aim Security) in June 2025, was a zero-click indirect prompt injection in Microsoft 365 Copilot. A single crafted email made Copilot read internal files and attempt to exfiltrate them with no user interaction. The linked arXiv paper is a secondary write-up rather than the primary Aim Labs advisory or the CVE record, so treat its finer details accordingly. It was responsibly disclosed with no known exploitation in the wild, and Microsoft patched it server-side. The exact patch date is reported inconsistently across sources, so the fact to hold onto is the June 2025 disclosure. It was a proof of concept rather than an active breach, yet it is a clean demonstration of ASI01, and it is exactly the kind of event where your audit trail becomes the most important artifact you own.

How a tamper-evident audit chain actually works

The mechanism is deliberately simple, and that simplicity is much of why it holds up. Give every log record a SHA-256 digest that includes the previous record's digest. The sequence then becomes append-only in a verifiable sense. Change one record, drop one, insert one, or reorder two, and every downstream digest stops matching, so the break is detectable by anyone who recomputes the chain.

You then periodically sign the head of the chain, for example with an Ed25519 checkpoint. That signature lets a third party verify integrity without trusting the log's host at all. They do not need access to your storage or any assumption of good intent. They recompute the chain, check it against the signed checkpoint, and get a yes or a no. The AuditableLLM framework, published in MDPI's Electronics journal, demonstrates exactly this: a hash-chain-backed, compliance-aware audit trail for LLM systems. It supports the general mechanism rather than any particular vendor, and it establishes that the approach is feasible. If the specific venue matters to your assurance team, confirm its review status directly.

This is precisely the property that Unity Catalog's inference tables, audit logs, and MLflow traces do not provide out of the box. That is not a failing on Databricks' part. Ordinary lakehouse tables were never designed to be their own integrity proof.

Limit what a hijacked agent can reach

There is a second half to this that pure logging cannot cover, and it changes where you spend effort. Most agent-safety work tries to constrain how the model behaves. That is useful, but a hijacked agent is doing exactly what the attacker wants, so behavioral guardrails end up fighting on the attacker's terms. The more durable move is to limit what the agent is able to reach in the first place.

That is the data-plane angle, and it is where DataShield lives. Tokenize sensitive fields at ingest so that a hijacked agent reading a record finds tokens where the PII used to be rather than the raw data. Authorize per tool call instead of per session, with mid-session revocation, so a compromised agent's reach can be cut the instant something looks wrong. Then seal every one of those calls into a tamper-evident audit chain. For the full shape of it, the architecture and the ontology model lay out how reachability is scoped, and /security covers the field-level tokenization. None of this replaces behavioral defenses. It makes sure that when they fail, and NIST's numbers say they will, the blast radius is limited to tokens while the evidence stays intact.

Agent governance best practices worth adopting now

These are the practices the primary sources actually point to, in rough order of leverage.

• Strong identity for agents. The Model Context Protocol authorization spec, revision 2025-11-25, is the current bar. HTTP-based MCP servers act as OAuth 2.1 resource servers, clients must implement PKCE and use the S256 method when technically capable of it, and clients must send the RFC 8707 resource parameter so that tokens are audience-bound to a specific server. Servers must reject tokens not issued for them and must never pass tokens through to upstream APIs, which is how you avoid the confused-deputy problem. Watch the details, because authorization is optional in MCP, and STDIO-transport servers take credentials from the environment instead, so it is worth citing the specific 2025-11-25 revision rather than "the MCP spec" generically.
• Least privilege and human-in-the-loop. Scope tools tightly and require a human approval on high-impact calls. It is an unglamorous control that works.
• Input and output isolation with content provenance. This is your blunt instrument against indirect prompt injection, straight out of NIST AI 100-2e2025 and OWASP ASI01 and ASI06.
• Tamper-evident logging. The hash chain plus signed checkpoints from the section above. This is the one most teams skip and most later regret.

If you want the taxonomy of how these pieces differ from gateways and guardrails, I wrote that up separately in agent governance vs gateways vs guardrails.

Bring Unity Catalog, add an independent witness

None of this argues for ripping out Unity Catalog. It argues for not asking one system to serve as both the party that acts and the party that audits the action. Keep Unity Catalog for what it is genuinely great at, which includes policy, model governance, and deep observability across every agent framework you run. Then place an independent, cryptographically tamper-evident layer beneath it, held by a party that is not the platform under audit.

A fair question is why that layer is not just another flavor of self-attestation. The answer is mechanical: it runs as a separate control plane that holds its own signing keys, so the party able to prove a record is unaltered is not the platform that ran the agent. That independence is the whole product. DataShield's evidence layer chains each entry with SHA-256, anchors it with Ed25519 checkpoints, and returns named verdicts rather than a bare valid or invalid. It reports tampering, insertion, deletion, and truncation as separate, named outcomes. You can run that verification yourself against a sample chain at /verify, with no sales call required. To be clear about the claim, this is a technical property, namely independent hash-chained verification you can check for yourself, and not a compliance certification. DataShield does not hold a SOC 2 attestation yet, and it is better to say so than to let you assume otherwise.

If your regime cares about immutable, complete logging, EU AI Act Article 12 is the concrete example. It requires high-risk AI systems to technically allow for the automatic recording of events, the logs, over the lifetime of the system, and we go deeper on that in a separate breakdown. The gap between a platform storing a table and a separate party being able to prove the record is unaltered is the gap between telemetry and evidence. If you want to scope what that would look like against your own agent traffic, the quote worksheet is the fastest way in.

Watch: related explainers

Databricks governance for agentic AI, plus the injection risk that makes independent evidence matter.

▶

Databricks unified governance for agentic AI (Byte-Size AI)

▶

Prompt injection and the lethal trifecta (CharlieCowanAI)

▶

Breaking and securing AI agents (Hackerspace Mumbai)

Frequently asked questions