Databricks' AI gateway policies can now read why a request was made. The caller writes that answer
Unity Gateway policies can now check caller-supplied request tags before a model or MCP tool call, in beta. Useful for attribution and routing. Databricks says a tag alone proves nothing.
Listen to this article · 5 min
AI-generated narration of the full article.
Enterprise AI governance keeps asking for context: not just who is calling a model or tool, but for which project, in which environment, for what purpose. On October 9, Databricks gave its gateway a way to read that context. The catch is in who supplies it.
The beta release note is short: “Custom service policies in Unity Gateway can now check caller-supplied request tags, such as requiring a tag before a model request or MCP tool call proceeds.” The caller sends the tags as a JSON object in a request header, and a policy can return ALLOW or DENY based on their values, evaluated on every request.
Databricks’ own documentation states the limit plainly: “Tags are supplied by the caller and are separate from service tags and authenticated actor context.” And: “A tag alone doesn’t establish identity or permission to use a project.”
Three kinds of input a gateway policy can read
Established by the platform
- Authenticated actor
- Service tags
Can carry authorization
Asserted by the caller
- Request tags: project, purpose, environment
Useful context; proves nothing alone
Judged by a model
- LLM-as-a-judge policies, now with OpenJev
Request tags are not passed to the judge
Useful for attribution, weak for authorization
Request tags are genuinely useful. A tag naming the project lets finance attribute model spend to the right budget. A tag naming the environment lets a policy route test traffic away from production endpoints. “Require a tag before the call proceeds” is good hygiene, because it forces every caller to declare a purpose that later shows up in the record.
What a tag cannot do on its own is authorize. If the policy says “allow calls tagged with project p-1042,” any caller able to send the header can claim p-1042. A DENY based on a tag stops honest callers who forgot it, not dishonest ones. The documentation says checks on identity or project permission need trusted identity and authorization data.
The useful pattern is to bind the two: the policy checks that the tagged project is one the authenticated actor actually belongs to, using data the platform trusts. Then the tag adds context to an identity, rather than replacing one. It is the same separation we found in Databricks’ identity-carrying agents, and in the three identities every agent has: a claim about purpose is not the same as a credential.
The approval gap
One detail in the documentation deserves attention from anyone designing human approvals. Policies that return ASK, pausing for a person to approve, do not distinguish tags. The documentation warns that an approval can be reused for a matching call with different tags, and that approval prompts do not show tags.
In practice: if a reviewer approves a tool call that was tagged “test,” the same approval can cover a matching call tagged “production.” Do not use tags to scope what a human approved. Scope approvals by the call itself, and keep tags for attribution.
Tags also reach both phases of a policy, the call and the result, and survive retries and model fallback, so a request keeps its declared context end to end. They are not sent to external policy providers or added to LLM-as-a-judge prompts, and the decoded tags are limited to 10 KiB by default.
A faster judge
The same release added a second beta. OpenJev, a Qwen3.5 4B model, can now be selected as the evaluator for custom LLM-as-a-judge service policies. Because it “classifies content without generating output tokens,” Databricks says it “typically responds faster than a chat evaluator.”
That matters because inline governance has a latency budget. A judge that checks every model response or tool result adds its delay to every call, and a slow judge eventually gets switched off. A classifier-style evaluator is the decision-model idea applied to policy enforcement. It still costs inference, and its verdicts need the same calibration testing as any judge.
Both features are beta, and the pairing is telling. Databricks is giving its gateway more context and faster judgment, the ingredients of a gateway that enforces policy rather than proxying traffic. The design work left to customers is deciding which of those inputs can be trusted to decide anything.