At Data + AI Summit 2026, Databricks closed the largest remaining open question in enterprise agent deployment: who governs what an agent does at runtime. The answer is Unity AI Gateway - now a substantially more complete control surface than the platform offered six months ago. For healthcare teams building agents over clinical and claims data, it eliminates many of the reasons to wait. It does not eliminate all of them.
The remaining gap is not in detection; it is in what happens after detection. This post covers both: what the platform now provides natively, and the specific layer healthcare deployments still need to build.
What Databricks announced
The headline change is architectural. AI Gateway is now part of Unity Catalog as Unity AI Gateway, extending Unity Catalog’s governance model (the same permissions, auditing, and policy controls organizations already use for tables) to the runtime interactions between models, agents, MCP services, and tools. That is a meaningful reframe. Governance stops being a property of data at rest and becomes a property of what happens during an agent’s execution.
Four capabilities matter most for regulated deployments.
MCP governance with on-behalf-of execution. Unity AI Gateway supports on-behalf-of user execution for MCP calls, meaning the MCP executes with the requesting user’s exact permissions rather than a shared service account. If a user cannot access a record, neither can the agent acting for them, even when the agent itself holds elevated privileges. For anyone who has watched a service-principal-backed agent quietly flatten row-level security across an entire user population, this is the single most important control in the release. Databricks now also provides managed MCP services for common enterprise applications, and custom MCP services can be registered, creating a governed inventory of approved tools with per-tool enable/disable and usage auditing.
Contextual Service Policies (Beta). Traditional access control decides who can reach a model or tool. Contextual Service Policies decide what a system may do during a specific interaction: allowing, denying, or requiring approval for actions, with policies applied based on the user, agent, model, MCP service, tool being invoked, or the contents of the request and response. Content-aware policy is the operative phrase. A policy can block a response because of what is in it, not merely because of who asked.
LLM-judge guardrails. The guardrail set now includes PII detection and redaction, content safety, prompt injection detection, data exfiltration prevention, and hallucination checks, configurable to run on requests, responses, or both. Critically, each guardrail is backed by an editable prompt and a configurable model rather than fixed logic, so a healthcare team can tune detection toward clinical identifier formats instead of accepting generic PII recognizers. When a guardrail fires, the gateway can reject the request or mask the sensitive data, and the action is logged.
Unified tracing. Unity AI Gateway captures model interactions and MCP tool activity in a single governed telemetry layer, with inference tables capturing complete request/response payloads. Every request logs the requesting identity and, for MCP calls, the connection name and whether the call was on-behalf-of user. Those traces can be analyzed in Lakewatch to detect suspicious activity and investigate policy violations.
Taken together, this is a real answer to the runtime governance problem. Six months ago, an architect building a clinical agent had to hand-roll tool-level authorization, egress control, and audit. Most of that is now platform.
The gap: redaction destroys what agents need
Here is where healthcare diverges from the general case.
The guardrail model is fundamentally detect and remove. Find the identifier, mask it, pass the sanitized payload along. For a customer support agent or a coding assistant, that is exactly right: the identifier was incidental to the task, and removing it costs nothing.
Clinical and actuarial agents do not work that way. Consider a realistic multi-step workflow: retrieve a patient’s recent clinical notes from vector search, look up diagnosis codes against a terminology service, score the patient against a risk stratification model, then check whether that score crosses a palliative care identification threshold. Four tool calls, four payloads, and the entire workflow depends on the agent knowing that all four results describe the same person.
Redaction breaks this. If the member identifier is masked to [REDACTED] in call one and [REDACTED] in call three, the agent has lost the join key. It cannot correlate. The workflow either fails or, worse, the agent hallucinates a correlation that isn’t there, and now you have a risk score attached to the wrong patient in a care management queue.
The fix is not less protection. It is a different protection primitive: deterministic tokenization. Replace the identifier with a stable surrogate (the same member always maps to the same token within a session), held in a vault that lives inside your governed perimeter. The model reasons over MBR_a1b2c3 exactly as it would over the real value, correlates correctly across all four tool calls, and never sees an actual identifier. On approved return paths, where a real value is genuinely required, the token resolves.
Detection and protection are separable concerns. Unity AI Gateway’s guardrails are a strong detection engine, and the fact that they are prompt-and-model-backed rather than regex-fixed makes them tunable for healthcare identifier formats. What a regulated deployment adds is a protection layer that preserves referential integrity instead of discarding it.
Why this matters more under HIPAA
There is a second reason the tokenization distinction carries weight in healthcare, and it is a compliance argument rather than a functional one.
HIPAA’s Safe Harbor de-identification standard enumerates eighteen identifier categories. If every one of them is tokenized before a payload reaches a model, the argument you make to a compliance officer changes shape entirely. You are no longer arguing that your BAA adequately covers a model provider’s handling of PHI. You are arguing that the model never processed PHI at all. That is a materially easier position to defend, and it holds regardless of which model vendor you are using this quarter.
Generic PII guardrails are calibrated for the common categories: emails, phone numbers, national ID numbers. Healthcare identifiers are messier: medical record numbers with payer-specific formats, member IDs that vary by plan, provider NPIs, encounter identifiers. A tunable guardrail can be taught these. But teaching it is work a healthcare team has to do deliberately, and the default configuration will not do it for you.
Tokenization does not achieve de-identification on its own. Quasi-identifiers survive it. An agent that sees ZIP code, age, admission date, and a rare diagnosis can re-identify a patient with no direct identifier present anywhere in the payload. That is a genuine residual risk, and the correct response is to document it and constrain what combinations reach the model, not to claim the tokenization layer eliminated it.
Where the trace surface still bites
One more thing that catches teams by surprise, and it is not a Databricks flaw so much as a consequence of how completely the platform now instruments agents.
Inference tables and traces capture full request and response payloads. That is precisely what you want for debugging and for audit. It also means that if PHI flows through an agent unprotected, it is now durably stored in a telemetry surface whose access control is configured independently from the Gold tables the data came from.
The tables are masked; the traces are not, unless someone configured them to match. A user restricted from seeing member identifiers by a column mask may be able to read those same identifiers in an MLflow trace or an inference table, because trace permissions were set by a platform team optimizing for debuggability and table permissions were set by a governance team optimizing for minimum necessary access. Nobody made a bad decision. The two decisions were just never reconciled.
Tokenizing upstream of the model resolves this structurally. If the payload was tokenized before the agent saw it, the trace contains tokens, and the permission mismatch stops mattering. The vault becomes the single governed location where real values live, and it can be secured once, properly.
Filling the gap: a DLP proxy at the MCP layer
The question is where the tokenization runs. There are three plausible placements, and only one of them holds up.
Inside the agent’s own code is the obvious first instinct and the worst option. Every agent reimplements it, every team gets it subtly wrong, and the control depends on the good behavior of the thing being controlled. A developer who adds a fifth tool to the agent has to remember to route it through the tokenizer. Eventually one doesn’t.
Inside the data layer, as UC column masks, is where PHI protection already lives, and it is the right place for authorization. But masks are all-or-nothing per principal. The agent either gets the real value or a masked one, and if it gets the masked one, correlation breaks for exactly the reason described above. Masking cannot express “substitute a stable surrogate.”
Between the agent and its tools is the placement that works. A DLP proxy speaking the Model Context Protocol sits in front of the MCP servers an agent calls: Genie spaces, Unity Catalog functions, vector search endpoints, external terminology or trial-matching services. It registers upstream as an MCP client and re-exposes their tools to the agent. Every tool call and every tool result passes through it.
The flow is straightforward:
Agent Runtime
│ MCP
▼
┌──────────────────────────────────────────┐
│ DLP MCP Proxy │
│ intercept → inspect → tokenize → audit │
│ ↕ │
│ Token Vault (UC) │
└──────────────────────────────────────────┘
│ │ │
▼ ▼ ▼
Genie UC Functions Vector Search … external MCPsFour properties make this placement the right one for healthcare.
It is the last point where structure is still intact. At the MCP layer, a Genie response is still a result set with typed columns, and a UC function response is still a named return value. The proxy knows that member_id is an identifier because the schema says so; no inference required. One turn later, that same data is unstructured text inside a prompt, and detection becomes a probabilistic NER problem with a false-negative rate. Inspecting where the schema still exists converts most of the detection problem into a lookup.
It covers tool results, not just prompts. The higher-volume PHI exposure in a clinical agent is not what the user typed; it is what the tools returned. A vector search over clinical notes returns free text dense with identifiers. A Genie query returns rows of patients. Prompt-level controls see this only after it has been assembled into a model request; a tool-layer control sees it as it emerges, per tool, with the source known.
It is agent-agnostic. The proxy does not care whether the caller is a Mosaic AI agent, a LangGraph workflow, a Databricks App, or an external MCP client. Anything speaking MCP inherits the control. This matters because agent frameworks turn over fast and the compliance posture should not.
It produces the audit artifact directly. Every intercepted call appends to a Delta table: timestamp, calling identity, tool invoked, entity types detected, tokens issued. That table is the evidence a compliance review asks for, and it is queryable in the same catalog as everything else.
Practically, the inspection engine is pluggable: an in-cluster open-source recognizer like Presidio when PHI must not leave the tenancy, or a commercial DLP service where a BAA covers it. What matters architecturally is the interception point, not the vendor behind it.
How this sits alongside Unity AI Gateway
This is additive, not competitive, and the distinction is worth being precise about.
Unity AI Gateway answers who may invoke this tool, as whom, and should this action be permitted. On-behalf-of execution enforces the user’s real permissions. Contextual Service Policies decide whether an action proceeds. Guardrails catch policy violations and unsafe content. Those are authorization and policy questions, and the platform now answers them well.
The proxy answers a different question: given that this call is authorized and proceeding, what form should the data take when it crosses into the model’s context? That is a data-transformation question, and it is the one place the native controls stop short, because their protection primitive is removal and healthcare needs substitution.
In deployment they compose cleanly. Unity AI Gateway governs the perimeter and logs the decisions. The proxy shapes the payloads inside it. An agent call passes both: the gateway confirms the user may run this tool, the proxy ensures what comes back is tokenized before it reaches the prompt, and both write to Delta tables in the same catalog.
When not to build this
The proxy is real engineering and a real latency cost: expect 50-200ms per intercepted call, plus a vault to operate and secure. It is not free, and it is not always warranted.
Skip it when the agent is single-tool, or when its workflows don’t chain calls about the same individual, or when everything runs on Databricks-native models and the telemetry permissions have been reconciled with the underlying table permissions. In those cases, tuned guardrails plus a governance audit gets you there for a fraction of the effort, and building the proxy anyway is over-engineering dressed as diligence.
Build it when agents chain multiple tool calls about the same patient and need to correlate across them, when any external model or external MCP service is in the path, or when the compliance argument you need to make is that the model never processed PHI, not that its handling of PHI was adequately covered.
What to actually do
For a healthcare team standing up agents on Databricks today, the sequence is:
Use what exists. Unity AI Gateway with on-behalf-of MCP execution, guardrails tuned toward your identifier formats, unified tracing. This is most of the control surface and it requires configuration rather than engineering.
Audit the telemetry permissions. Compare access on inference tables and MLflow experiments against access on the underlying governed tables. If the former is broader, you have an exposure that no amount of gateway configuration addresses.
Insert a DLP proxy where correlation matters. Not on every path; that is over-engineering. Specifically on the workflows where an agent chains multiple tool calls about the same individual, or where any call leaves your tenancy. In practice that means clinical and actuarial agents rather than general analytics ones.
Document the residual. Quasi-identifier re-identification risk survives all of the above. Say so in writing before an auditor says it for you.
The platform has moved a long way. Most of what a healthcare team needed to build a year ago is now configuration. What remains is narrow and specific: a transformation layer at the tool boundary that substitutes rather than removes, because clinical agents must correlate across calls and redaction takes that capability away. That is a substantially better problem than the one we faced twelve months ago.