Databricks AI Security Framework: Turn DASF Risks Into Control Tests
The Databricks AI Security Framework gives security teams a component-based risk catalog for AI systems. A useful implementation turns each applicable DASF risk into an owned control and a test on the real request path, with evidence that shows the result. This article explains that workflow and identifies the narrow HTTP enforcement slice that DeepInspect can cover.
The Databricks AI Security Framework organizes risks around the parts of an AI system. Its current agentic extension gives a security team a way to decompose one use case, identify applicable risks and assign controls, then retain evidence from the systems that own those controls. The useful output is a control test plan tied to the actual architecture.
TL;DR
- DASF v3.0 covers 13 AI system components, 97 risks, and 73 controls, including an agentic component. That component covers reasoning and memory as well as MCP connections and tool use.
- Start with one deployed use case and mark the components it actually uses. Assign each applicable risk to the system that can prevent or detect it. If the risk materializes, assign the system that can contain it.
- Write a test and an evidence requirement for every selected control. A framework mapping without an observed result remains a risk register entry.
- DeepInspect covers the narrow slice of authenticated HTTP traffic routed through its AI request boundary. Training pipelines and local execution remain with their respective control owners. Memory stores and tool-side authorization do as well.
Applying the Databricks AI security framework
Databricks describes DASF as a framework for assessing risks across the components of a modern AI or ML system. The DASF v3.0 announcement adds agentic AI as the 13th component and brings the catalog to 97 risks and 73 controls. The update separates risks in the agent core from those in MCP servers and clients, while also covering communication between agents.
That decomposition is the reason to use DASF. Begin with one named deployment, such as a claims agent that retrieves policy documents and calls a payment-review tool. Draw its real components and data flows. Mark which DASF components appear in that design, then select risks that match those components and the authority granted to the agent. A whiteboard with the user identity and agent service is more useful than a framework spreadsheet copied wholesale. Add the model endpoint and retrieval store, then mark the tool boundary.
The Databricks DASF architecture page presents the framework as a way to assess potential risks and apply security practices across an AI system. Treat that architecture as a scoping model. The control implementation still belongs to the identity platform and data store. Other controls belong to the model-serving layer, agent runtime, network path, or tool that has authority over the event.
Each selected risk needs an owner and a test
A DASF mapping should end with a testable record. Give every applicable risk four fields. Record the owning system and the control action, followed by the test procedure and retained evidence. The owner is the component with enough authority to change the outcome. The test sends a representative allowed event and a representative denied event through the production-like path. Evidence records the configuration version and observed result, with a reviewer and test time.
Consider an agent that can read a customer record and invoke a refund tool. Tool permission belongs at the tool or its authorization service. Prompt and response inspection can sit on a routed model call. Memory poisoning needs controls where memory is written and retrieved. Generated code needs isolation in the execution environment. The framework connects those risks in one assessment, while the controls stay distributed.
I would reject a DASF worksheet that lists "gateway enabled" as its evidence. That phrase says nothing about the identity presented, the route tested, the policy applied, or the denied action. A stronger record shows the attempt and its result. User u-1842 attempted a refund above the approved threshold at 14:07 UTC. The policy decision point denied the request under policy version 31, and the tool received no invocation.
Agentic risk crosses several enforcement boundaries
Databricks added 35 agentic risks and six mitigation controls in the March 20, 2026 extension. Its examples cover memory poisoning and goal manipulation. They also cover tool poisoning and malicious MCP servers. Client-side code execution is included. The same agent workflow can therefore cross several security boundaries during one task.
Follow one task turn by turn. After the application receives an authenticated instruction, the model plans a step over HTTP. A retrieval service then supplies context. The agent may then select a tool that changes state. Agent memory can store a summary for another session after the action completes. Each transition has a different control owner and failure mode.
This separation prevents a common architecture error: assigning every DASF risk to the AI gateway. An HTTP gateway can inspect traffic that traverses it and apply policy before forwarding that traffic. Vector index sanitation belongs at the data store. Execution environments own code isolation. Tool servers and databases enforce their respective authorization policies.
Confused deputy controls should preserve the requesting identity and delegated authority at the tool call. The AI agent post-authentication gap appears when a valid login turns into a broad service credential downstream. An agent kill switch supplies containment when prevention fails and work must stop across active queues and credentials.
The HTTP request slice has a precise evidence shape
The request boundary owns decisions on deliberately routed HTTP calls between an authenticated user or agent and an LLM endpoint. For that slice, the control test should establish the originating identity and acting service principal. It should also establish the destination route and content classification. Record the policy version and decision with the timestamp. A response record should join back to the allowed request that produced it.
NIST SP 800-207 states that zero trust grants no implicit trust based solely on network location or asset ownership, and that authentication and authorization occur before a session to an enterprise resource is established. Applied to an AI route, a valid network position or shared service credential supplies insufficient decision context. The policy point needs the identity and requested action for that resource.
Test the slice with two calls that differ in one meaningful attribute. The first might permit a claims reviewer to summarize a record with approved data classes. The second might deny the same person from sending payment-card data to an unapproved endpoint. Retain the two decision records and confirm that the denied payload never reached the model. AI policy enforcement at the HTTP layer explains this control point in more detail.
Framework coverage and platform coverage stay separate
DASF can be used for AI systems running on Databricks or elsewhere, including a mixed estate. The framework defines a security assessment structure. Databricks platform services supply controls for parts of that structure, while other systems supply the rest. Keep those two maps separate so a framework label never becomes an unsupported claim of product coverage.
A practical review packet contains the use-case diagram and selected DASF risks. It names the control owners and includes the test results. Open exceptions belong in the same packet. It also records the traffic and execution paths excluded from each control. The existing Databricks Mosaic AI security review covers Unity Catalog permissions and the request-boundary decision for a Mosaic deployment. This DASF mapping has a different purpose: it coordinates risk ownership across the complete AI system and records where each control is tested.
The NIST AI Risk Management Framework is voluntary guidance for incorporating trustworthiness considerations into the design and development of AI systems. It also covers their use and evaluation. Use NIST AI RMF as the wider risk-management process and DASF as a technical decomposition for the AI architecture.
DeepInspect
DeepInspect can own the HTTP request slice in a DASF control plan. It sits between authenticated users or agents and LLM endpoints as a stateless enforcement layer. For traffic routed through that boundary, it can evaluate identity-bound policy and prompt classification before forwarding the request. It can then write a per-decision audit record with the route and policy version. The same record contains the outcome and event time.
Its boundary stays narrow. DeepInspect does not govern model training or vector-store writes. It does not govern local or STDIO execution. Workspace configuration and authorization enforced inside a downstream tool also remain outside its boundary. Assign those DASF risks to controls with authority at those components. The resulting plan gives DeepInspect a defined set of request-path tests instead of treating one gateway as coverage for the whole framework. Book a technical deep dive at deepinspect.ai.