Databricks Mosaic AI Security at the HTTP Request Boundary

TL;DR

• Databricks Mosaic AI security starts with Unity Catalog access controls, then requires a per-request decision for the HTTP traffic an application sends to a model endpoint.
• A valid Databricks identity and an endpoint permission establish access to a service. The request boundary adds the policy question for the prompt and route, plus the originating user or agent.
• Security evidence should retain both a permitted and a denied event, including identity context, the selected endpoint and policy version, plus the response outcome.

The security decision after endpoint access

A data application can have permission to invoke a Databricks model endpoint and still need a separate decision for the prompt it is about to send. The call may carry customer notes, a financial forecast, or retrieved document chunks assembled after Unity Catalog has allowed the earlier table read. At that moment, the model route receives an HTTP payload, and the security question becomes specific: is this caller permitted to send this content to this endpoint under the active policy?

Databricks says Unity AI Gateway governs AI assets and traffic, along with service behavior through Unity Catalog. Its access model gives teams a sound baseline for registered models, agents, MCP services, functions, plus connections. The NIST Cybersecurity Framework 2.0 similarly centers governance and protection, plus detection and response, followed by recovery as distinct functions. I treat the HTTP request decision as a security control that deserves its own evidence, rather than a footnote under platform permissions.

That distinction becomes visible on a real route. A user opens a browser-based analyst tool, the application calls a Databricks endpoint using a service principal, and the endpoint invokes an LLM. The service principal may be necessary to run the workload. The human identity and the intended action still need to travel with the request if policy is meant to reflect who asked.

Identity context on the Mosaic route

Databricks can govern registered AI assets with Unity Catalog privileges. The access grant governs use of the asset. An application often has more context than the serving route alone: the originating employee, tenant, role, case identifier and data classification, plus business action. Attach the relevant context to the call before it reaches the policy point.

The security review should distinguish the originating identity from the acting principal. In a Lakehouse workflow, sanjay.rao@example.com might request an analysis while sp-claims-agent-prod performs a function call. Keeping both fields makes an investigation more precise and stops the service principal from becoming the only identity visible in the event stream.

This is the post-authentication gap: authentication identifies a caller, while request-layer authorization evaluates the content and action under the current policy. A policy can then apply different rules to a claims-review route and a document-summary route, even when both use the same Databricks endpoint.

Request and response controls

A security design at the request boundary has two moments. Before the request reaches the model, the control point receives the HTTP payload, evaluates supplied identity context, classifies relevant content, applies the route policy, and forwards or denies the request. The decision must be recorded at that point.

After the model returns, the same boundary can associate the response with the request identifier and apply response policy before the application receives it. That association matters when an investigator needs to establish which prompt produced a particular completion. It also supports a useful operational check: a response record should reference a request that the policy previously allowed.

Databricks documents model API governance and traffic routing through its central control plane. Teams should validate the route they actually operate, including external provider routes configured through Databricks. A route diagram on a whiteboard with five labeled boxes, caller and application, policy point and endpoint, plus response, often reveals a missing identity handoff in under ten minutes.

Security review boundaries

Review the traffic that reaches the control point. Confirm the HTTP endpoint, originating identity fields, service principal, policy bundle and request identifier, plus the response event. Test one allowed prompt and one denied prompt against the same production-like route. The evidence should show why each result occurred and whether the model received the request.

The boundary is deliberately narrow. DeepInspect can inspect and enforce policy on HTTP AI requests and responses that pass through it between authenticated users or agents and LLM endpoints. Local execution and credential handling, plus Databricks workspace configuration, need separate controls. A security review should assess those layers, but an HTTP proxy has no basis to claim coverage for events it never sees.

Use AI data classification to define the prompt categories that matter to the application, then bind those categories to the route policy. A policy without context becomes a generic filter. A policy tied to identity and content class, route and decision time becomes reviewable security evidence.

DeepInspect

DeepInspect is a stateless proxy at the HTTP AI request boundary. It evaluates identity-bound policy and prompt-level classification before an approved request reaches an LLM endpoint, and it can associate the response with the decision record produced for that request.

In a Databricks Mosaic AI deployment, DeepInspect complements Unity Catalog and Unity AI Gateway by covering the application HTTP routes sent through the proxy. It does not administer workspace settings or manage credentials, and it does not control local execution. Book a technical deep dive at deepinspect.ai.