AI security reviews often stall because nobody can say which risks apply to a given deployment, which team owns each one and which concrete control closes it. The Databricks AI Security Framework (DASF) answers that by breaking an AI system into numbered components, attaching technical risks to each and mapping every risk to numbered controls and to common standards. Its latest version, DASF v3.0, adds agentic AI and the Model Context Protocol (MCP) as a thirteenth component. This guide explains how DASF is structured, how to use its compendium to build a risk profile, which identity controls matter most, and how it maps to other frameworks. It is written for security architects, data and ML platform owners and risk teams, whether or not they run the Databricks platform; product configuration is covered in the linked platform guides.
This is an independent guide from NHI Mgmt Group, based on Databricks' public documentation as of November 2026. It is not sponsored or reviewed by Databricks. Product features change, so confirm settings against Databricks' current documentation.
Key takeaways
- Components first, then risks, then controls. DASF models an AI system as 13 components in v3.0, attaches 97 technical risks to them and maps those risks to 73 numbered controls.
- Agents are now a component in their own right. Component 13, Agentic AI, adds 35 risks across agent core behaviour, MCP servers and MCP clients, plus new controls DASF 68 to DASF 73.
- The compendium does the filtering. The companion spreadsheet lets you filter risks by deployment model and see which controls apply, so you work on your use case rather than the whole catalogue.
- Identity controls come first. DASF 1 (SSO with an identity provider and MFA) and DASF 2 (sync users and groups) open the control list, and the agentic risks add privilege compromise, identity spoofing, confused deputy and credential exposure.
- It is platform-agnostic in method. Databricks describes the four-step risk profile approach as usable regardless of platform, with each control also mapped to Databricks features for customers who run it.
What it is and who it applies to
DASF was created by the Databricks Security team to address vulnerabilities in AI systems with what it calls a holistic approach to mitigating risks beyond model security. It is intended for collaboration between business, IT, data, AI and security teams across the AI and ML lifecycle. Databricks publishes it as a free whitepaper with a companion compendium in Google Sheets and Excel formats.
| Version | Published | What it contains |
|---|---|---|
| DASF 2.0 | 12 February 2025 (announcement blog) | 62 technical security risks across 12 AI system components, mapped to controls and to standards including MITRE ATLAS, OWASP LLM and ML Top 10s, NIST SP 800-53, NIST CSF, HITRUST, ENISA Securing ML Algorithms, ISO/IEC 42001, ISO/IEC 27001:2022 and the EU AI Act. Added the compendium and a DASF AI assistant |
| DASF v3.0 (Agentic AI Security Extension, whitepaper version 1.0) | 20 March 2026 (announcement blog) | Adds component 13 Agentic AI with 35 new risks and new controls DASF 68 to 73, bringing totals to 97 risks and 73 controls; compendium maps them to MITRE ATLAS, OWASP, NIST and Cloud Security Alliance material |
DASF covers several deployment models: predictive ML models, foundation model APIs, retrieval-augmented generation (RAG), fine-tuned and pre-trained LLMs, external third-party models, and AI agents built on LLMs. It is relevant to model creators, teams that consume models through APIs and platform teams operating agents. Because control numbers and totals change between versions, always cite the version you assessed against and confirm current values in the Databricks documentation.
Structure and key requirements
The 13 components and four stages
DASF 2.0 groups its 12 original components into four stages. v3.0 adds the agentic component.
| Stage | Components | Risks (DASF 2.0) |
|---|---|---|
| Data operations | 1 Raw data, 2 Data preparation, 3 Datasets, 4 Catalog and governance | 20 |
| Model operations | 5 ML algorithm, 6 Evaluation, 7 Model build, 8 Model management | 15 |
| Model deployment and serving | 9 Model serving: inference requests, 10 Model serving: inference responses | 19 |
| Operations and platform | 11 ML operations, 12 ML platform | 8 |
| Agentic AI (v3.0) | 13 Agentic AI: 13A agents core, 13B tools MCP server, 13C tools MCP client | 35 |
Risks carry the component number as a prefix: for example 1.1 Insufficient access controls, 1.2 Missing data classification, 1.10 Lack of data access logs, 8.2 Model theft, 9.1 Prompt inject, 12.1 Lack of vulnerability management and 12.4 Unauthorized privileged access.
The agentic risks
- 13A Agents core (13.1 to 13.15): memory poisoning, tool misuse, privilege compromise, resource overload, cascading hallucination attacks, intent breaking and goal manipulation, misaligned and deceptive behaviours, repudiation and untraceability, identity spoofing and impersonation, overwhelming human in the loop, unexpected remote code execution and code attacks, agent communication poisoning, rogue agents in multi-agent systems, human attacks on multi-agent systems, and human manipulation.
- 13B Tools, MCP server (13.16 to 13.25): prompt injection (including in tool descriptions), confused deputy, tool poisoning, credential and token exposure, insecure server configuration, supply chain attacks, excessive permissions and scope creep, data exfiltration, context spoofing and manipulation, and insecure communication.
- 13C Tools, MCP client (13.26 to 13.35): malicious server connection, insecure credential storage, UI and UX deception, insufficient server validation, client-side data leakage, excessive permission granting, client-side code execution, insecure communication handling, session and state management failures, and update and patch management.
The controls
Databricks groups its controls into three kinds: cybersecurity best practices, data and AI governance controls, and AI-specific controls. Examples from the published material:
| Control | What it requires | Typical risks addressed |
|---|---|---|
| DASF 1 | SSO with an identity provider and MFA to limit who can access the data and AI platform | 1.1, 12.4 |
| DASF 2 | Sync users and groups so access inherits organisational roles | 1.1 |
| DASF 3 and 4 | Restrict access using IP access lists and private link | Platform exposure |
| DASF 5 | Control access to data and other objects through one permissions model across all data assets | 1.1, agent tool scope |
| DASF 24 | Control access to models and model assets | 8.2 |
| DASF 33 | Manage credentials securely | 13.19, 13.27 |
| DASF 5, 57, 64 | Least privilege for agent tools | 13.2, 13.22, 13.31 |
| DASF 34, 62 | Sandboxing and isolation | 13.11, 13.32 |
| DASF 54 | AI gateway and guardrails | 9.1, 13.16 |
| DASF 65 | Observability of agent reasoning ("observability of thought") | 13.8 |
| DASF 66 | Human-in-the-loop oversight | 13.10, 13.15 |
| DASF 68 to 70 | Use securely hosted managed MCP servers; securely host custom MCP servers; securely connect to external MCP servers | 13B and 13C |
| DASF 71 to 73 | Log and register AI agents; securely store and reuse agent state; register prompts | 13.1, 13.8, 13.13 |
The risk column is NHI Mgmt Group's reading of where each control applies, to help orientation. Use the compendium's control applicability tab for the authoritative mapping.
Identity and NHI requirements
A large share of DASF's agentic risks are identity risks in another form. Privilege compromise (13.3), identity spoofing and impersonation (13.9), confused deputy (13.17), credential and token exposure (13.19), excessive permissions and scope creep (13.22), insecure credential storage (13.27) and excessive permission granting (13.31) all concern how agents and tools authenticate and what they are allowed to do. The v3.0 announcement warns that without controls the user effectively inherits the agent's permissions rather than their own, and recommends tool permissions scoped to the agent's immediate task, comparable to RBAC and ABAC.
- Human access: DASF 1 and 2 put the platform behind the organisation's identity provider with MFA and group-driven access.
- Workload and agent identities: give each agent, job and MCP server its own non-human identity, scoped through one permissions model (DASF 5), with credentials held in a secrets service (DASF 33) rather than in code or agent state.
- Registration: DASF 71 (log and register AI agents) gives you the inventory that identity governance needs: owner, purpose, tools and credentials per agent.
- Delegation: where an agent acts for a user, design the flow so the agent's effective access is the intersection of its own scope and the user's, which is the condition behind the confused deputy risk.
On Databricks, these map to service principals, Unity Catalog permissions and the platform's authentication options. See the Databricks Service Principal Security Guide and the Databricks Mosaic AI and Agent Bricks Security guide, and for platform-neutral practice the Agent Identity and Access Guide and the Confused Deputy in AI Agents Guide.
Implementation steps
Databricks sets out a sequence for using the framework: define the use case, stakeholders and deployment model; review the components and risks and assign owners; review the controls; use the compendium to identify relevant risks, control applicability and impacts; and implement prioritised controls, starting with perimeter and data security. NHI Mgmt Group suggests expanding that into the following rollout:
- Pick one use case and deployment model. For example "RAG assistant over HR policies using a foundation model API" or "agent with MCP tools updating tickets". Download the current compendium.
- Filter risks. Use the DASF Risk Applicability tab to keep only risks that apply to that deployment model. Add component 13 risks if the system uses agents or MCP.
- Assign owners per component. Data operations to data engineering, model operations to ML, serving to platform, agentic to the agent product team, with security as reviewer.
- Select controls. Use the DASF Control Applicability tab, then record each control's status: in place, planned or risk accepted.
- Start with identity and perimeter. DASF 1 to 5 and DASF 33 give the broadest reduction. For agents, add least privilege for tools, the AI gateway and agent registration next.
- Test before widening. Run prompt injection and tool misuse tests against the agent in a non-production workspace, with human-in-the-loop (DASF 66) on for all write actions. Remove approvals only for actions you have tested.
- Repeat per use case and track versions. Each new deployment model gets its own filtered profile. When Databricks publishes a new DASF version, diff the compendium and re-review changed rows.
Small and large organisations
A small team with one or two AI use cases can complete steps 1 to 5 in a workshop; Databricks also offers DASF workshops through its published contact address. Large organisations should load the compendium into their governance, risk and compliance tooling, link controls to evidence and use component owners as control owners.
Evidence and assessment
DASF is a framework, not a certification, so evidence is your own record that the selected controls operate. Keep:
- Filtered risk profile: per use case, with the DASF version, deployment model and owner per risk.
- Control status: for each applicable control, the implementation, evidence location and residual risk decision.
- Identity evidence: SSO and MFA configuration, group sync, the agent registry (DASF 71), credential storage and rotation records, and tool permission scopes.
- Agent logs: tool calls, approvals and reasoning traces that support DASF 65 and repudiation risk 13.8.
- Standards mapping: the compendium's mapping columns for whichever frameworks your auditors use.
Metrics (our suggestions):
- Percentage of AI use cases with a current DASF risk profile and named owners.
- Percentage of applicable controls in place, by stage.
- Percentage of agents registered with owner, tools and credentials recorded.
- Number of agent identities with standing write access to production data, trending down.
- Share of MCP servers in use that are managed or registered, against all MCP connections observed.
Mapping to other frameworks
The compendium maps every risk and control to standards. The table shows where DASF elements sit in commonly used frameworks; check the compendium for the authoritative rows. See the AI Security Frameworks Crosswalk Guide for the wider picture.
| DASF element | MITRE ATLAS | NIST SP 800-53 Rev. 5 and CSF 2.0 | Other |
|---|---|---|---|
| Risk 9.1 Prompt inject, 13.16 | AML.T0051 LLM Prompt Injection | SI-4 System Monitoring | OWASP LLM01 |
| Data operations poisoning risks | AML.T0020 Training Data Poisoning | SR-3; CSF GV.SC-01 | OWASP LLM04 |
| Risk 8.2 Model theft, DASF 24 | AML.T0024 Exfiltration via AI Inference API; AML.M0019 | AC-6 Least Privilege | ISO/IEC 27001:2022 access control |
| 13.2 Tool misuse, 13.22 scope creep | AML.T0053 AI Agent Tool Invocation | AC-6; CSF PR.AA-05 | OWASP Agentic Top 10 ASI02 |
| 13.21 Supply chain attacks | AML.T0010 AI Supply Chain Compromise | SR-3, PM-30 | OWASP LLM03 |
| DASF 71 agent registration | Not a technique | CM-8 System Component Inventory | ISO/IEC 42001 AI system inventory |
| 13.8 Repudiation and untraceability, DASF 65 | Not a technique | AU-12 Audit Record Generation; CSF DE.CM-09 | EU AI Act Art. 12 record-keeping (high-risk) |
For the frameworks themselves see the MITRE ATLAS Guide, the NIST AI RMF Guide and the MCP Security Guide.
Common pitfalls
- Working the whole catalogue. 97 risks is too many to treat equally. Filter by deployment model first or the review never finishes.
- Assessing against an old version. Teams that profiled against DASF 2.0 miss the 35 agentic risks. Record the version and re-review when agents are added.
- Treating MCP as a feature, not an attack surface. v3.0 gives MCP servers and clients 20 risks between them. Register every MCP connection and apply DASF 68 to 70.
- Shared credentials for agents and jobs. One token for several agents makes 13.8 untraceability and 13.22 scope creep almost certain. Use a non-human identity per agent.
- Removing human approval too early. DASF 66 protects against cascading and manipulation risks while behaviour is still being learned. Relax it only per tested action.
- Reading the mapping as compliance. A mapped standard row shows relevance, not conformance. Keep separate evidence for audits.
Practitioner checklist
- Download the current DASF compendium and record the version you assess against.
- Build one filtered risk profile per AI use case and deployment model.
- Add component 13 risks for any system using agents or MCP.
- Assign an owner to each component and each applicable control.
- Put the platform behind SSO with MFA and group sync (DASF 1 and 2).
- Give each agent, job and MCP server its own identity, with credentials in a secrets service (DASF 33).
- Register every agent with owner, tools and credentials (DASF 71) and scope tool permissions to the task.
- Keep human approval on agent write actions until tested, and log tool calls and reasoning.
- Re-review profiles whenever a new DASF version or a new deployment model arrives.
Standards and references
- Databricks: Databricks AI Security Framework (DASF) whitepaper
- Databricks: Agentic AI Security, New Risks and Controls in DASF v3.0
- Databricks: Agentic AI Security Extension to the Databricks AI Security Framework
- Databricks: Announcing the Databricks AI Security Framework 2.0
- Databricks: DASF 2.0 ebook
- Databricks: AI Security (Trust Center)
Related NHI Mgmt Group resources: AI Security Frameworks Crosswalk Guide · Databricks Mosaic AI and Agent Bricks Security · Databricks Service Principal Security Guide · MCP Security Guide