Databricks adds request-tag checks and OpenJev evaluation to Unity Gateway beta

Databricks’ October 2026 release notes list two Unity Gateway beta additions dated October 9, 2026. One lets custom service policies check caller-supplied request tags, including before model requests or MCP tool calls proceed. The other lets OpenJev (Qwen3.5 4B) serve as the evaluator model for custom LLM-as-a-judge policies. Databricks says OpenJev classifies content without generating output tokens and typically responds faster than a chat evaluator.

Account admins can control access to the beta features from the account console’s Previews page. A custom SQL service policy is a user-defined function registered in Unity Catalog and evaluated during interactions with the service it governs. The function accepts an event value and returns a decision value. It runs at two points: before the service is called and after it responds. Policies can inspect request tags in the event context for model services, model provider services, and MCP tool calls. The tags come from an HTTP header and remain the same through request transformations, retries, and model fallback.

A request without that header has an empty tag object, and the default limit for decoded tag keys and values combined is 10 KiB of UTF-8 data. Model services reject malformed or oversized tag headers; for MCP tool calls with applicable service policies, the gateway rejects them before policy evaluation, including in Log mode. Databricks’ examples distinguish deterministic SQL policies, which make exact rule-based decisions, from LLM-as-a-judge policies for semantic checks. The examples include a rule that accepts only specified project tags and denies requests with missing, empty, or unlisted project values. A required-tag rule can therefore prevent a model request or MCP tool call from proceeding when its tag is absent or does not meet the policy.

The project-tag example also cautions that a tag supplied by the caller does not establish permission to charge that project; it says to check permission against trusted identity and authorization data. The documentation says service policies fail closed, so a missing field, unsupported function, or evaluation error results in DENY. For builders, the two policy types offer distinct approaches in the documented examples: exact checks such as project-tag eligibility, or evaluator-based checks for meaning that a fixed rule does not capture. Request-tagging guidance includes SDK and REST examples for sending tags.