Databricks Adds External Guardrail Enforcement to Unity Gateway
The beta lets teams send model and MCP traffic to an existing security vendor for allow-or-deny decisions, with important egress and availability tradeoffs.
Edited by Tyronne Panaino
Databricks opened external service policies in beta on October 7, giving Unity Gateway customers a way to place an existing third-party guardrail in the path of model and MCP traffic. The policy sends selected request or response content to the vendor, receives an allow-or-deny verdict, and can block the governed call without requiring changes to the application making it.
The change matters to AI platform and security teams that already use a data-loss-prevention or AI-security service outside Databricks. It creates a native enforcement point at the gateway, but it also moves vendor availability, latency and data handling into the execution path of every protected call.
One policy path for models and MCP tools
The October Databricks release notes describe the beta as an external guardrail for Unity Gateway traffic. The more detailed external service policy documentation says a policy can attach to a Model Service, Model Provider Service or MCP Service. That gives administrators one control pattern across hosted models, provider connections and agent tools, even though each policy is attached to one service at a time.
A Unity Catalog HTTP connection stores the vendor endpoint and OAuth credentials. The policy then identifies that connection, its evaluation phase, its ordering rank and an optional configuration that is passed to the vendor. The vendor must implement Databricks' external policy interface and return either an allow or deny result. Databricks does not provide individual vendor adapters.
OAuth machine-to-machine authentication is the only supported authentication method in the beta. Connection creation and policy attachment also use separate Unity Catalog privileges, which allows credential administration and service-policy administration to be divided between different operators.
Input and output checks have different exposure
Administrators can evaluate inputs before a service runs, outputs after it responds, or both. Choosing both phases creates two vendor calls for a typical governed interaction, so it can increase external evaluation volume as well as add latency on both sides of the model or tool execution.
The content is not merely a category label. For a model service, the vendor receives the full request body at the input phase and the full response body with the originating request at the output phase. For an MCP service, the input contains the tool name and arguments, while the output contains the tool result and the originating tool call. Databricks says caller identity is not sent, although a trace identifier can accompany a traced request.
That makes the network boundary a central design question. A prompt, model response, tool argument or tool result may contain business data that was previously confined to the application and Databricks path. Teams need to approve the vendor's data-handling terms and verify the configured destination before treating the feature as a security improvement. Databricks also recommends restricting serverless egress to approved policy-service destinations.
Log mode is the safer starting point
The beta offers Log and Enforce modes. Log mode records the decision the vendor would have made without blocking the application call. Enforce mode applies a deny result and stops the call. Databricks recommends beginning with logging so teams can observe real traffic and unexpected decisions before making the external verdict blocking.
Logging is not free of operational effects. Every evaluation still calls the vendor and can consume vendor quota or per-call charges. Teams also need a unified trace table or inference table if they want the evaluation results available for review.
Policy rank controls evaluation order when external checks are combined with other gateway policies. A denial can prevent later checks from running, so the order determines both which controls see the content and which external calls still occur. This makes policy composition part of the deployment review, not just a naming or configuration detail.
Fail-closed behavior changes the reliability model
External service policies fail closed. If the vendor endpoint times out, returns an error, produces an unreadable response or sends a verdict other than allow or deny, Databricks denies the governed call. Its documentation says the platform waits about five seconds for the vendor response before treating a slower result as a denial.
In Enforce mode, the vendor therefore sits on the critical path for both availability and latency. A security service outage can become an application outage for the governed service. Log mode can expose that behavior before enforcement, but it does not conceal endpoint failures; failed evaluations still appear as denials in the logs.
The beta also has functional limits. It cannot pause a request for human approval, redact sensitive fields or rewrite content. Policies are attached through the Unity Gateway interface rather than REST or Terraform, and one policy cannot be applied across many services in a single action. Those constraints make the first release best suited to binary enforcement at a carefully selected boundary.
Status and evidence limits
Confirmed. Databricks' official release notes and product documentation establish the beta, supported service types, evaluation flow, data sent to vendors, failure behavior and current limitations. Internal confidence is medium because both sources come from Databricks; independent security testing, vendor interoperability, production latency and false-positive rates were not available in the fetched evidence.
Sources
- Databricks — October 2026 release notes
- Databricks — Enforce a partner guardrail with an external service policy
Update note: Last reviewed 2026-10-09. We will revise this post if Databricks changes the beta's enforcement, data-handling, automation or failure semantics.
Sources
- Databricks — October 2026 release notes — official
- Databricks — External service policy documentation — official
Drafted with AI assistance from source briefs; reviewed for citation completeness and label accuracy.