Reviewing Databricks Mosaic AI Agent Framework — the gap Databricks names in its own framework

A newer piece, Unity AI Gateway (extended from the earlier Mosaic AI Gateway), is positioned as the runtime control plane for model requests, agent activity, tool calling, guardrails, and inference logs — meaning Databricks explicitly separates “governs data at rest” (Unity Catalog's original job) from “governs runtime agent behavior” (the Gateway's newer one).

Unity AI Gateway reached general availability at Data + AI Summit 2026 (June 16), and its guardrails aren't rigid pre-built rules — each is backed by an editable prompt and a configurable model that evaluates requests, responses, or both, doing contextual reasoning to distinguish a real policy violation from a benign reference (news reporting, fiction, education) rather than relying on pure keyword or regex matching. On a violation, it can reject the request or mask the sensitive data. Every guardrail decision is logged to Inference Tables — a Unity Catalog Delta table — which is what makes audit, accuracy evaluation, and prompt tuning over time possible.

MLflow Tracing, the observability layer underneath, is fully OpenTelemetry-compatible and captures raw inputs, retrieved documents, tool-call parameters, and outputs at every step by design — which means the trace data itself becomes a sensitive-data surface (PII, proprietary business context) that needs the same governance as the underlying data. Databricks' stated mitigation is native Unity Catalog integration on Managed MLflow: role-based access control on trace data, data lineage, and audit logging extended to observability data, not just to training or inference data. A review should confirm that extension is actually configured, not assume trace data inherits governance automatically just because the rest of the pipeline does.

What replaces a CVE here is more useful for a review than a single bug would be: Databricks' own AI Security Framework (DASF) version 3.0, published in 2026, names the structural problem directly in its own documentation rather than leaving it for a third party to discover.

Databricks' own framing: “when an AI system can take action, read-only access controls aren't enough.” DASF v3.0 adds Agentic AI as a 13th system component, with 35 new risk categories — agent-core reasoning and memory poisoning, MCP server tool-poisoning, MCP client risks, and multi-agent communication threats among them — and six new controls: least-privilege tools, human-in-the-loop for high-stakes actions, sandboxing for agent-generated code, AI Gateway guardrails, reasoning observability, and tool-ecosystem mapping.

The core admission is a confused-deputy problem, stated in Databricks' own words: an agent performs discovery and traversal across data paths and tools a human user never explicitly reached, so in effect the human inherits the agent's permission surface rather than the other way around. Unity Catalog ACLs on data don't, by themselves, bound what an agent can be manipulated into doing with the tools it's allowed to call — the framework says this plainly, which is a stronger signal for a review than most vendors' marketing-adjacent security pages offer.

For any system built on Mosaic AI Agent Framework, a design-time review should be able to answer:

• Is Unity AI Gateway actually deployed as the runtime control plane for agent tool-calling, or is agent traffic bypassing it?
• Which of an agent's registered Unity Catalog Function tools would let it discover or traverse data paths beyond what its invoking user explicitly requested?
• Which high-stakes agent actions require human-in-the-loop approval, per DASF v3.0's own recommended control — and is that list documented, not assumed?
• Is agent-generated code actually sandboxed before execution, per DASF v3.0's control, or does it run with the same privileges as the rest of the pipeline?
• Are guardrail decisions reviewed via Inference Tables, or is the logging enabled but never actually examined?
• Does Managed MLflow's Unity Catalog integration extend role-based access control to trace data specifically, given traces capture the same sensitive inputs and outputs as the underlying pipeline?

See tool-use permission scoping for the general version of the confused-deputy pattern Databricks names above.