Databricks Mosaic AI Audit Logs at the Request Boundary
Databricks Mosaic AI audit logs need to do more than retain prompts and responses. A reviewable record connects an HTTP model request to the originating identity, route, evaluated policy, response outcome, and timestamp. This article separates Databricks-native usage records from independent request-boundary evidence for mixed model deployments.
TL;DR
- Databricks Mosaic AI audit logs become useful evidence when one record binds the originating principal, model route, evaluated policy, decision, and event time.
- Unity AI Gateway supplies Databricks-native governance and usage visibility for registered AI services, while a request-boundary record preserves the policy decision for HTTP traffic an application routes to an LLM.
- Review one permitted request and one denied request with the same fields. That test reveals missing identity context and disconnected response evidence faster than a console walkthrough.
The event that an audit needs to reconstruct
A Databricks notebook sends a prompt to a registered model endpoint at 14:07 UTC. The line that matters in a later review is not simply that an endpoint ran. The reviewer needs to join the person or agent who initiated the work, the service principal that executed it, the selected model route, the policy in force, and the result returned on the HTTP response path.
Databricks describes Unity AI Gateway as a Unity Catalog-based control plane for runtime interactions among models, agents, MCP servers, and tools. That is valuable operating context. The NIST AI Risk Management Framework also puts documented governance and measurement at the center of AI risk work. For a security review, the useful unit is the individual request, not a monthly usage chart.
I want a reviewer to find an event by request ID or timestamp and reconstruct it without opening five notebook runs. A laptop displaying an inference table in a glass meeting room looks reassuring. It still leaves work if the event cannot tie content, identity, policy, and response together.
Databricks-native records and request-boundary evidence
Unity AI Gateway can govern access to registered AI assets and observe traffic inside the Databricks control plane. Its documentation says registered AI assets become Unity Catalog securable objects, with grants and revocations handled through the same privilege system used for tables and volumes. Those records establish who had access to an AI service and how the Databricks route behaved.
A request-boundary record answers a narrower, operational question: what policy decision applied to this specific HTTP request before it reached the selected LLM, and what happened to the matching response? That record should include an originating identity supplied by the application, the Databricks service principal when one executes work, the endpoint, a policy version, classifications, decision, timestamps, and a stable request identifier.
The distinction matters in a mixed deployment. A team may call a Databricks-hosted endpoint for retrieval and send another route directly to an external LLM API. The AI gateway architecture explains why a control point must see the traffic it is asked to govern. A request record can be compared with provider and application records, yet each record keeps its own purpose.
A review exercise that exposes gaps
Run a two-event exercise during the Databricks security review. First, submit an allowed request through the production route. Retrieve the corresponding event by its request identifier. Confirm that the record holds the originating principal, acting service principal, route, policy version, decision time, and response status in one place.
Then submit a request that policy denies before model invocation. The denied event should retain the same identity-and-route context, plus the rule that caused the decision. A blocked request is useful evidence because it shows the policy evaluated the real route rather than existing as an unused configuration. I would rather see this controlled test than a 40-slide governance deck with no event retrieval demonstration.
Databricks documentation for legacy endpoint governance advises restricting endpoint creation and CAN MANAGE privileges to prevent bypass of guardrails or throughput limits. That administrative control belongs in the review. The audit exercise asks a different question: can the team account for the exact HTTP request and response that traversed the approved route?
The scope of the record
This evidence covers HTTP AI request and response traffic that the control point receives between authenticated users or agents and LLM endpoints. It can record an inbound prompt, evaluate identity-aware policy before forwarding, and associate the returned response with that decision.
The record has clear edges. Local code execution and credentials, along with Databricks workspace configuration, require their own endpoint, identity, and platform controls. An event that never crosses the inspected HTTP route produces no request-boundary evidence. Keeping that scope explicit prevents an audit design from claiming evidence it never collected.
Databricks teams should document the route diagram beside the audit fields. Mark the authenticated caller, application, gateway or proxy, model endpoint, and response path. The AI audit-trail requirements provide a useful basis for evaluating the resulting evidence package.
DeepInspect
DeepInspect sits as a stateless proxy on the HTTP path between authenticated users or agents and the LLM endpoints their applications call. It evaluates identity-bound policy and prompt-level classification before forwarding an approved request, then produces a per-decision audit record outside the application write path.
For Databricks Mosaic AI deployments, that record can preserve the originating identity alongside the service principal and model route supplied by the application. It covers only requests and responses that pass through the proxy. Book a technical deep dive at deepinspect.ai.