The Policy Layer series established the enforcement lifecycle axis — the structural distinction between compile-time, runtime, and protocol-layer enforcement. The CABP dispatch documented what enforcement at the MCP layer actually requires. On April 17, 2026, Databricks published a clear and well-argued illustration of exactly where enterprise MCP security currently stands. This dispatch maps the gap between what the article delivers and what it leaves open.
Databricks published “Governing Coding Agent Sprawl with Unity AI Gateway” on April 17, 2026 — a coherent, practitioner-grade case for centralizing MCP governance across coding agent deployments. The operational problem it addresses is real: engineering teams are running Cursor, Codex, Claude Code, and other tools simultaneously, with no unified visibility into cost, access, or audit trails. The Unity AI Gateway response is genuinely useful. This dispatch is not a critique of that response. It is a map of what the response does not cover — and why the distinction between governance and security matters at protocol depth.
The article names the core risk with precision: “MCP tools are most useful when they have access to critical data within your organization, so it’s easy to accidentally make them the most privileged developer in your organization.” That is an accurate description of the threat. The prescription that follows — centralized logging, unified identity, cost observability — addresses a different problem. The article conflates the two without signaling the gap. For enterprise security teams reading it as a security solution, that conflation is the issue this dispatch examines.
Three Pillars, One Tier
The Unity AI Gateway is organized around three pillars. Pillar One: centralized security and audit, which captures all agent data access in Unity Catalog with MCP servers managed in Databricks and centralized tracing via MLflow. Pillar Two: single billing and cost limits across all coding tools. Pillar Three: full observability in the Data Lakehouse — lines of code written per user, cost per month per user, and all coding activity automatically ingested into Delta tables.
Mapped against the enforcement lifecycle axis, all three pillars occupy the same tier. Cost limits are operational controls. Observability metrics are reporting controls. Audit-ready logging and centralized tracing are detection controls. These are the mechanisms that document what happened after execution. They operate at the API and observability layer — not the semantic instruction layer where agent behavior is actually shaped. Authorization checks and policy controls do act at the call boundary; what they cannot reliably do is inspect semantic intent, validate the reasoning chain, or sanitize the prompt context that preceded the call.
Observability & Detection Tier
Documents agent behavior after execution begins. Essential for compliance, forensics, and cost management. Necessary but not sufficient for structural security.
- Audit logs of all tool calls and data access events
- Centralized tracing via MLflow across coding agents
- Unified identity — one Databricks credential across all tools
- Cost limits and usage budgets per developer
- OpenTelemetry ingestion to Delta tables for analytics
Structural Enforcement Tier
Operates upstream of execution. Validates the instruction surface before the agent acts — and constrains what the agent can be told to do before any log entry is written.
- Schema validation and inspection of tool description fields at registration
- Runtime call graph constraints that bind tool chaining to declared intent
- Tool behavior attestation against a registered baseline
- Context isolation preventing injected instructions from crossing session boundaries
- Pre-execution validation of retrieved context for adversarial payloads
Where the Protocol-Layer Threats Live
The article is correct that MCP tools present a security risk when they have access to sensitive organizational data. What it does not address is the mechanism by which that risk materializes — and the mechanism matters because it determines whether the controls being deployed can intercept it.
Two specific threat vectors sit upstream of everything the Unity AI Gateway monitors.
The Tool Description as Attack Surface
The MCP tool description field is processed by the agent before any tool call is initiated. An adversary — or a compromised MCP server — can embed instructions in the description field that the agent treats as authoritative. The gateway sees a legitimate call from an authenticated principal. It cannot log what the description told the agent to do before the call was made, because that instruction arrived in the field that shaped the reasoning that produced the call.
This is the first protocol-layer threat: the attack surface is the description, not the call. Centralized logging addresses the call. It has no reach over the description that preceded it.
The second threat is direct from the article’s own premise. The piece identifies the data sources that make MCP tools valuable: “engineering tickets, design documents, and customer issues.” These are precisely the injection surfaces that the Invisible Attack series covers in depth. Adversarial content embedded in a Jira ticket, a GitHub issue, or a design document can redirect an agent’s subsequent tool call sequence — laterally, silently, and within the same authenticated, fully-logged session. The gateway observes a legitimate call chain. It has no mechanism to distinguish a call chain shaped by legitimate instructions from one shaped by a payload embedded in retrieved context.
The Unity AI Gateway logs that a legitimate call was made by an authenticated principal. It cannot log what the tool description told the agent to do before the call was initiated — or what adversarial content in a Jira ticket told the agent to do next.
A third vector completes the picture: trust propagation across chained tool calls. The article frames MCP security as an identity problem — who is allowed to call which tool, with what credentials. The actual risk in multi-step agentic workflows is that the agent, having been granted permission to call Tool A, uses Tool A’s output to construct a rationale for calling Tool B with expanded scope. Neither call is individually unauthorized. The gateway logs both. The lateral expansion remains invisible at the governance tier.
What Structural Enforcement Would Require
The controls that would close these gaps are not readily present in current MCP gateways — and the gap is worth naming precisely. Guardrail frameworks, orchestration layers, and policy engines address parts of this: call-boundary authorization, coarse-grained content filtering, some tool allow/deny policies. What none of them reliably address is the semantic instruction layer — inspecting the intent embedded in retrieved context, validating the reasoning chain that connects tool calls, or sanitizing the prompt surface before it shapes agent behavior. That gap is not a Databricks failure. It is an industry-wide immaturity at the semantic enforcement layer. What closing it requires is not just protocol changes — it is a control plane that operates at the same layer as reasoning and context formation. Today’s gateways, including Unity AI Gateway, operate below that layer.
What Structural Enforcement at the MCP Layer Requires
Schema validation at tool registration that inspects the description field for adversarial instruction patterns. Tool behavior attestation that validates current tool state against a registered baseline — preventing post-authorization state drift (the rug pull vector). Runtime call graph constraints that bind the agent’s tool-chaining behavior to the declared intent of the workflow. Pre-execution context validation that scans retrieved documents for injection payloads before they enter agent reasoning. The MCP governance frameworks at aaif.io and the OWASP MCP Practical Guide are where this specification work is active.
These controls cannot be consistently enforced across heterogeneous agents when implemented purely as gateway observability features, because the threat manifests before any observable event is generated. The distinction is not implementation depth — it is layer. A logging layer built on top of an unvalidated tool description surface is logging activity on an attack surface it cannot reliably inspect.
The Honest Accounting
The Unity AI Gateway gives enterprise teams something they genuinely need and currently lack: unified visibility into how coding agents are being used, what they cost, and which teams are driving adoption. That operational intelligence is a real contribution. The identity unification is a meaningful security improvement over per-tool authentication. The cost controls prevent runaway spend. These are not trivial problems, and Databricks solves them with genuine engineering precision.
The limitation is one of category, not execution. The three Unity AI Gateway security pillars are observability-tier controls positioned as a security solution for a threat that operates at the protocol layer. For enterprise security architects reading the article, the practical implication is this: deploying Unity AI Gateway does not close the MCP tool description attack surface, does not prevent indirect prompt injection via retrieved context, and does not constrain lateral tool chaining. It documents all three after the fact.
Centralized governance is a necessary precondition for what comes next — you cannot enforce what you cannot observe. The gap is not that Databricks got it wrong. The gap is that the industry is at governance-layer maturity and has not yet reached structural enforcement maturity. What closing that gap requires is not just protocol changes — it is a control plane that operates at the same layer as reasoning and context formation. Today’s gateways operate below that layer. Enterprise security teams deploying MCP-connected agents today should treat current gateway controls as detection capability, not prevention capability — and architect for the control plane that layer will eventually require.
