DASF shows why AI security must move from theory to operations

At a glance

What this is: Noma Security argues that DASF turns AI security into an operational discipline by organizing 62 risks across the AI lifecycle and mapping them to controls, standards, and workflows.

Why it matters: This matters because AI systems change after deployment, so IAM, security, and governance teams need controls that follow models, data, tools, and agents as they evolve.

Context

AI security fails when teams treat models and agents like fixed applications. The article’s core point is that AI systems ingest, transform, and expose data in ways that can shift after launch, which makes one-time review insufficient for governance or operational assurance.

That creates a direct governance problem for security teams: discovery, control selection, monitoring, and review must happen across the full AI lifecycle, including training data, RAG pipelines, deployments, updates, and retirement. Where AI systems can be prompted, tuned, or connected to tools, the boundary between application security and identity governance becomes much thinner.

Key questions

Q: What breaks when AI security is handled only at launch time?

A: Controls go stale as the system changes. New data sources, fine-tuning, prompt updates, and tool integrations can all expand the attack surface after go-live, which means the original approval no longer reflects the current risk. Continuous review is required because AI systems are operationally dynamic, not static software artifacts.

Q: Why do RAG pipelines increase AI governance risk?

A: RAG creates a live retrieval path into enterprise content, so the model can surface information that was never intended for broad disclosure. If source repositories are not classified and access-controlled, users can obtain sensitive material through prompts even when the original storage layer looked secure.

Q: How can teams tell whether AI oversharing controls are actually working?

A: They should measure whether realistic prompts produce restricted answers, redactions, or blocks when policy should apply. If the assistant still returns sensitive context under common follow-up questions, the control is not effective. Effective governance changes the response the user sees, not just the log entries security teams review.

Q: Which frameworks should organisations align AI compliance to?

A: For most programmes, NIST AI RMF, NIST Cybersecurity Framework, and zero trust principles provide the broadest control alignment. Organisations in regulated sectors should add the relevant sector rules, then map AI governance, runtime controls, and data protection to the specific risks each framework covers.

Technical breakdown

Why the AI attack surface is not static

AI systems differ from conventional software because the same input can produce different outputs as models drift, are fine-tuned, or are retrained. That means risk is not confined to the initial build. Retrieval-augmented generation, embedded documents, tool integrations, and promptable agents all create mutable attack surfaces that can expose sensitive information or change behavior after deployment. Traditional perimeter controls do not see these internal shifts because the failure often happens inside the model or its context layer, not in the network boundary.

Practical implication: Treat the model, its context, and its integrations as continuously changing assets, not one-time approvals.

How operational control differs from paper compliance in AI governance

A framework only changes security outcomes when risks, controls, and ownership are embedded into operational workflows. In AI environments, that means discovery, prioritisation, validation, and monitoring must sit alongside development and deployment rather than in a separate review document. Shared responsibility is essential because data science, MLOps, security, and governance teams each see only part of the risk. Without a workflow that links those views, the framework becomes a checklist rather than a control system.

Practical implication: Place AI risk review inside delivery pipelines and assign explicit ownership across data, platform, and security teams.

Why standards mapping matters for AI security programmes

AI security governance becomes actionable when risks can be mapped to existing frameworks such as NIST AI RMF, MITRE ATLAS, OWASP guidance, ISO 42001, and the EU AI Act. That mapping gives security teams a shared language for board reporting, audit evidence, and control selection. It also helps distinguish technical risk from compliance obligation, which is important when the same AI system may affect privacy, model integrity, and operational resilience at once.

Practical implication: Use standards mapping to connect AI controls to audit, risk, and regulatory processes already used by the organisation.

Threat narrative

Attacker objective: The attacker aims to extract sensitive information or manipulate AI output without needing traditional infrastructure compromise.

1. Entry occurs when a user or researcher interacts with a promptable AI system and coaxes it to surface information embedded in indexed documents or model context.
2. Credential access is replaced here by information extraction, because the attacker abuses the AI’s retrieval and generation behavior rather than breaching a server directly.
3. Impact follows when confidential business knowledge, sensitive guidance, or training data is disclosed through normal-looking responses that users may trust.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI security has moved from model design to operational governance. The article’s central lesson is that a static risk review cannot protect a system that learns, drifts, and changes integrations after launch. Security teams need lifecycle controls that cover discovery, deployment, monitoring, and retirement, or the control model will lag the system it is meant to govern.

RAG and agentic integrations turn knowledge exposure into a security control problem. Once an AI system can retrieve internal documents or call tools, the issue is no longer only model quality. It becomes a governance question about what the system can access, what it can reveal, and how privilege is scoped across data, prompts, and connected services.

DASF is most useful when it is treated as a control mapping method, not a framework poster. The article is strongest when it shows how risks move into real workflows, where prioritisation, monitoring, and standards alignment become measurable. That is the difference between a framework that informs policy and a framework that changes behaviour.

AI governance debt is now a material security liability. The longer an organisation waits to inventory AI systems, map exposures, and assign owners, the more remediation becomes expensive retrofitting rather than operational design. Practitioners should treat unmanaged AI growth as a governance debt problem that compounds with every new model, prompt path, or tool integration.

From our research library:

• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.

What this signals

AI governance debt: AI programmes accumulate exposure when discovery, ownership, and monitoring lag deployment. The practical signal is clear: if a team cannot inventory models, retrieval layers, and tool integrations on demand, it does not yet have operational control of the AI estate.

The reader takeaway is not to treat DASF as a document to file away. The right operating model links model risk, data governance, and security review into one lifecycle, because that is the only way to keep pace with drift, redeployment, and new agent connections.

For practitioners

• Map the full AI deployment surface Inventory models, datasets, retrieval layers, APIs, tool connections, and agent pathways before approval so hidden data flows do not escape governance.
• Embed AI controls into delivery workflows Put review gates, validation checks, and exception handling directly into CI/CD and model-serving pipelines so security does not rely on a separate manual process.
• Prioritise controls by AI lifecycle risk Rank exposure by likelihood and impact across training, deployment, inference, and update stages, then address the highest-risk failure modes first.
• Map AI controls to governance frameworks Connect model and agent controls to NIST AI RMF, ISO 42001, MITRE ATLAS, and EU AI Act obligations so audit evidence and remediation plans use the same control language.
• Continuously monitor drift and new integrations Reassess systems after fine-tuning, new data ingestion, or added tool integrations because each change can reintroduce exposure that was absent at launch.

Key takeaways

• AI security breaks down when organisations assume a model is safe after the first review and do not govern what changes later.
• The operational risk is not just model output quality. It is also what the system can retrieve, infer, and disclose once data and tools are connected.
• Practitioners need lifecycle controls, standards mapping, and continuous monitoring so AI governance keeps pace with drift, fine-tuning, and new integrations.

Key terms

• Retrieval-augmented Generation: Retrieval-augmented generation is a pattern where an AI model pulls external information before generating output. The security challenge is that access rules can weaken when data is chunked, embedded, cached, or reused, so source permissions may not automatically follow the content into the model's context.
• API Governance Debt: API governance debt is the accumulation of weak, inconsistent, or missing controls around how APIs are designed, approved, documented, secured, and retired. It creates hidden risk over time. Technically, it includes gaps in authentication, authorization, versioning, inventory, ownership, logging, and policy enforcement that make APIs harder to trust and govern.
• Model Drift: Model drift is the gradual change in a model’s behaviour or performance after deployment. It happens when the operating environment, user patterns, or inputs no longer match the conditions used to validate the system. Drift matters because a model can appear functional while no longer meeting approved standards.
• Agentic connectivity: Agentic connectivity is the set of links that lets an AI agent reach tools, APIs, events, and memory during execution. The governance challenge is not just creating those links, but ensuring every one of them is policy-bound, observable, and attributable across the full workflow.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps practitioners build the governance skills needed to secure autonomous systems and connected credentials.