ADLC compliance: Mapping agentic development to NIST SSDF, the OWASP LLM Top 10, and the EU AI Act

TL;DR

• ADLC compliance governs two surfaces: the code agents produce and the actions they take, including shell commands, file access, MCP tool calls, and package installs.
• No official crosswalk exists between NIST SSDF, OWASP GenAI lists, and the EU AI Act. This map is Endor Labs' interpretation, not legal advice.
• Existing SDLC controls like SAST, SCA, secrets detection, and signing still apply. New work centers on agent inventory, permission scoping, real-time action policy, and audit logs.
• Treat models, MCP servers, skills, and plugins as supply chain components with provenance and inventory records, satisfying SSDF PW.4 alongside OWASP LLM03 and ASI04.
• Using coding agents internally mainly triggers EU AI Act Article 4 AI literacy duties. Annex III high-risk obligations now apply from 2 December 2027.
• A system prompt rule isn't a control, and an agent reporting passed tests isn't evidence. Deterministic policy and independent CI, scanner, and log output hold up in audits.

What is ADLC compliance?

ADLC compliance means applying secure development practices, AI risk controls, and AI regulatory requirements to software built with AI coding agents. It covers two things: the code the agent produces and the actions the agent takes while producing it.

If you need the lifecycle stages first, start with our explainer on the secure agentic development lifecycle. 

This post assumes you already have Cursor, Claude Code, or a similar agent in your repos. Now an auditor, a customer security review, or your legal team wants to know how that work is governed.

Three frameworks come up in those conversations. They do different jobs:

• NIST SSDF (SP 800-218) is a practice framework. It tells you what a secure development program does.
• The OWASP GenAI lists are risk taxonomies. They tell you what goes wrong when LLMs and agents are in the loop.
• The EU AI Act is binding law. It assigns obligations based on your role and on the risk level of the AI system in question.

Mapping them together is useful. One control can satisfy a practice, mitigate a named risk, and support a legal obligation at the same time. You build it once and produce evidence once.

A caveat: NIST, OWASP, and the European Commission don't publish an official crosswalk between these frameworks. 

The map in this post is Endor Labs' practical interpretation. It supports compliance work. It doesn't establish legal compliance, and it isn't legal advice.

Why does agentic development need its own compliance map?

Agentic development needs its own map because agents add a second surface that classic SDLC controls never had to govern: the actions the agent takes on a developer's machine and in your infrastructure.

Split every requirement across two surfaces:

1. The code surface. This covers the source code, dependencies, configs, and containers the agent writes or pulls in. Your existing SDLC controls already cover most of it.
2. The action surface. This covers what the agent does while it works: shell commands, file reads and writes, MCP tool calls, and package installs. A human developer did these things too, but at human speed, with human judgment, and usually without someone else's text steering them.

Most crosswalks only map the first surface. That's where they fall short. A coding agent can read a poisoned README, run curl | sh, open ~/.aws/credentials, and call an MCP server nobody approved, all before a single line reaches a pull request. No PR-stage scanner sees any of that.

Plenty carries over unchanged. Code review, SAST, SCA, secrets detection, container scanning, and release signing all still apply to agent-written code. Agents produce more code, faster, so those controls need to run continuously and with less noise. They don't need to be reinvented. Our guide to securing the code your agents write covers that side in depth.

New work concentrates on the action surface. Expect to add inventory of agents and tools, permission scoping, real-time policy on agent actions, and logs that record what the agent did.

How does NIST SSDF apply to agentic development?

NIST SSDF applies to agentic development the same way it applies to any development: its four practice groups still define a secure program, but each one now has agent-specific tasks. This map uses NIST SP 800-218, SSDF Version 1.1, the current final version. NIST released SP 800-218 Rev. 1 (SSDF Version 1.2) as a draft in December 2025, so check its status on the CSRC site before you cite practice IDs in an audit.

Here's what each group looks like when an agent does part of the work:

• Prepare the Organization (PO). PO.1 asks you to define security requirements, and that now includes rules for agents, such as which commands they can run and which MCP servers they can call. PO.3 (supporting toolchains) and PO.5 (secure development environments) cover the agent itself as part of your toolchain. Agent example: a written, versioned policy that blocks destructive shell commands and unapproved MCP servers for every agent in use.
• Protect the Software (PS). PS.1 asks you to protect all forms of code from unauthorized access and tampering. An agent with broad file access is a new principal that can touch that code. PS.2 and PS.3 cover release integrity and archiving. Agent example: agent sessions can't read signing keys or modify CI configuration without a policy exception.
• Produce Well-Secured Software (PW). PW.4 (reuse existing, well-secured software) is where agents cause the most new risk, because they install packages on their own. PW.5, PW.7, and PW.8 cover secure coding, code review, and testing. Agent example: every package an agent proposes passes the same SCA and policy checks a human's would, at install time.
• Respond to Vulnerabilities (RV). RV.1, RV.2, and RV.3 cover finding, prioritizing, remediating, and root-causing vulnerabilities. Agents increase volume, so prioritization matters more. Agent example: findings in agent-written code are prioritized by whether the vulnerable path is reachable from your application.

Treat models, MCP servers, and agent tools as supply chain components

SSDF already expects you to know what third-party software you use and where it came from. Apply that to AI components too. That means models, MCP servers, agent skills, and plugins, each with provenance, an inventory record, and integrity verification.

This matters because the OWASP lists name the same risk: supply chain (LLM03 in the LLM Top 10, ASI04 in the Agentic Top 10). One inventory can satisfy both. Teams that already run SCA for packages can extend that process instead of starting a separate AI spreadsheet that drifts the moment someone pulls a new model.

Use reachability as RV evidence

For RV.2, assessors want to see why you prioritized what you did. Full-stack reachability across first-party code, open source dependencies, and container images gives you that record. Endor Labs builds a code context graph of how your application behaves, then shows the data flow and call paths that make a finding reachable, or the proof that it isn't. When a fix is needed and an upgrade would break things, Endor Patches applies backported patches to the vulnerable open source version. That gives you a remediation record without a forced major-version bump.

Where SP 800-218A fits

NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile, adds AI-specific practices and tasks to the SSDF. It focuses on model development: training, fine-tuning, and alignment data, plus model weights and the AI systems built around them.

Check its scope against your situation. Most teams using coding agents don't train or fine-tune the model behind the agent. For those teams, SP 800-218A works mainly as a checklist for evaluating model and agent vendors. If you do fine-tune models or ship AI features, more of it applies directly to you.

Which OWASP risks apply to coding agents?

The OWASP risks most relevant to coding agents are prompt injection, excessive agency, supply chain, and sensitive information disclosure. In the 2025 LLM Top 10 those are LLM01, LLM06, LLM03, and LLM02. Their agentic counterparts include agent goal hijack, tool misuse, identity and privilege abuse, and agentic supply chain vulnerabilities.

Two lists, two scopes

The OWASP GenAI Security Project maintains two related lists:

• OWASP Top 10 for LLM Applications, 2025 edition. This covers risks in applications built on LLMs: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM07 System Prompt Leakage, LLM08 Vector and Embedding Weaknesses, LLM09 Misinformation, and LLM10 Unbounded Consumption.

• OWASP Top 10 for Agentic Applications, released December 2025 and labeled for 2026. This covers risks specific to systems that plan, use tools, and act with autonomy, with IDs ASI01 through ASI10.

That "2026" label is likely where search confusion comes from. When we pinned this map, the current LLM Top 10 on genai.owasp.org was the 2025 edition. We found no 2026 edition of the LLM list. The 2026 label belongs to the Agentic Top 10.

Use the LLM Top 10 for model input and output risks. Use the Agentic Top 10 for tool use, permissions, and autonomous action. Coding agents need both.

Read the lists from two angles

Most explainers present OWASP as risks in apps you build. For ADLC compliance, read each list twice.

Angle 1: your coding agent is the LLM application at risk.

• Prompt injection (LLM01, ASI01) arrives through issue text, repo files, code comments, and dependency documentation the agent reads as context.
• Excessive agency (LLM06) and tool misuse (ASI02) show up when an agent has broad shell, file, and network permissions it doesn't need for the task.
• Sensitive information disclosure (LLM02) happens when an agent reads .env files or credentials and pastes them into a prompt, a log, or a commit.
• Supply chain (LLM03, ASI04) covers unvetted MCP servers, skills, and packages the agent installs.

Angle 2: the LLM features your team ships to customers. If your product includes a chatbot, a copilot, or an agent, the same lists apply to that product. That work belongs in your threat model and design review (SSDF PW.1 and PW.2).

Least agency

The Agentic Top 10 introduces a principle of least agency: give an agent only the autonomy and tool access a task needs. A Cloud Security Alliance research note on the NIST AI Agent Standards Initiative connects that principle to NIST's emerging expectation of task-scoped, time-limited agent permissions. Scoped agent permissions are becoming a standards expectation as well as good hygiene.

What does the EU AI Act require for agentic development?

Using coding agents alone doesn't make your software, or your team, subject to high-risk obligations under the EU AI Act. Obligations depend on the intended purpose of the AI system and on whether you're its provider or its deployer.

The Act, Regulation (EU) 2024/1689, sorts AI systems into risk tiers: prohibited practices, high-risk systems, systems with transparency obligations, and minimal-risk systems. General-purpose AI models carry separate obligations. The European Commission's AI Act overview summarizes the tiers.

A four-step scoping path

1. Are we only using coding agents internally to build software? You're a deployer of the agent. The software you build isn't an AI system just because an agent helped write it. The main obligation here is AI literacy (Article 4): promote a sufficient level of AI literacy among staff who use AI systems, matched to their roles. Keep training records.

2. Are we shipping an AI system or a general-purpose AI model? If your product contains AI features, continue. If you only build conventional software with agent help, you can stop here.

3. Are we the provider or the deployer? You're a provider if you develop an AI system and place it on the market under your name (Article 3). Providers carry most obligations. Deployers have narrower duties (Article 26 for high-risk systems). Substantially modifying a high-risk system, or putting your name on one, can make you its provider (Article 25).

4. Does the intended purpose fall into a high-risk category? Check Article 6, Annex I (AI used as a safety component of regulated products), and Annex III (areas such as employment, credit scoring, critical infrastructure, and education). If yes, provider obligations apply. These include risk management (Article 9), technical documentation (Article 11), record-keeping through automatic logging (Article 12), human oversight (Article 14), and accuracy, robustness, and cybersecurity (Article 15). If no, check Article 50 for transparency duties, such as telling users they're interacting with an AI system.

Readers who ship AI features should pair this path with a structured AI model risk assessment before mapping controls.

Application dates

The Act entered into force on 1 August 2024. Prohibitions and AI literacy have applied since 2 February 2025, and general-purpose AI model obligations since 2 August 2025. Most Article 50 transparency obligations have applied since 2 August 2026.

The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and pushed back the high-risk deadlines. Annex III high-risk obligations now apply from 2 December 2027 instead of 2 August 2026. Annex I obligations now apply from 2 August 2028 instead of 2 August 2027. Check the consolidated text on EUR-Lex for any later changes before you commit to a date.

The ADLC control map, stage by stage

Version note. This map is pinned to NIST SP 800-218 (SSDF v1.1; the v1.2 revision was still a draft), NIST SP 800-218A (July 2024), the OWASP Top 10 for LLM Applications 2025, the OWASP Top 10 for Agentic Applications (December 2025, labeled 2026), and the EU AI Act as amended by Regulation (EU) 2026/1744. When NIST or OWASP revises a list, recheck every ID in the affected column. Then confirm that the evidence artifact still demonstrates the renamed or merged item.

The stages follow our ADLC explainer. Rename them to match your own lifecycle. SSDF IDs are indicative practice-level anchors, so check them at the task level against your control library. "N/A" means no EU AI Act provision maps naturally for teams that only use coding agents internally.

The ADLC control map

For dependency, model, and tool selection, the evidence is an inventory that stays current. Endor Labs keeps a continuously updated inventory of AI models and components with version and provenance attached. It scores each one for vulnerability, deprecation, and license risk, and includes AI components in your SBOMs so the inventory is exportable on demand.

For merge, build, and release, Endor Labs Artifact Signing cryptographically signs container images, binaries, and build artifacts and verifies them at deployment. The verification record is the evidence. It shows that what ran in production is what your pipeline built.

One control, traced: blocking unapproved MCP servers

• SSDF: PO.3 and PO.5 (approved toolchain, secure environment), plus PW.4 (vetted third-party components).

• OWASP: LLM03 and ASI04 (supply chain), ASI02 (tool misuse).

• EU AI Act: none directly for internal use. It does support a cybersecurity posture under Article 15 if your product is a high-risk system.

• Evidence: the allowlist, the policy definition, and log entries showing blocked connection attempts with agent, user, and timestamp.

How do you produce ADLC compliance evidence that holds up?

ADLC compliance evidence holds up when it comes from controls that run independently of the model and when your systems generate it continuously rather than assembling it before an audit.

The test: does the control hold regardless of what the model decides?

Apply this test to every row in the map. A rule in a system prompt saying "never run rm -rf" isn't a control. The model can ignore it, misread it, or get talked out of it by injected text. If your governance depends on the model choosing to behave, you don't have a control. You have a request.

The same logic applies to evidence. An agent reporting "all tests passed" isn't evidence. It's a claim from the system you're trying to govern, and agents do confidently misreport (OWASP files that under LLM09). Evidence an assessor can inspect comes from a system outside the agent: CI test results, scanner output, policy engine logs, and signed artifacts.

Deterministic policy at the action layer passes the test. Coding Agent Governance from Endor Labs records a complete, searchable audit log of agent actions: shell commands, file access, MCP tool calls, and package installs. It enforces policy in real time, blocking destructive commands, sensitive file access, and unapproved MCP servers no matter what the model decides. It does this across Cursor, Claude Code, and other agents from one control plane, so you don't maintain separate controls per tool. See how coding agent governance works for the discovery and enforcement details, and why hooks act as the ADLC control plane for the mechanism underneath. Our guides on governing the agents that write the code and how policies meet agent behavior in practice go further into the design choices.

For the code surface, AURI by Endor Labs works as a security harness for agentic software development. It gives coding agents and developers deterministic program analysis results while they write code. A tool that returns the same answer every time is easier to defend in an audit than a model's best guess.

Continuous evidence beats pre-audit assembly

Manual evidence collection before each audit is a recurring fire drill. Scan results, remediation records, and agent activity logs live in separate tools. Stitching them together by hand creates gaps, and assessors notice gaps.

The alternative is to generate evidence as a by-product of normal work. Every build emits scan results and an SBOM. Every agent session emits an activity log. Every remediation leaves a record. Cover AI-generated code, open source dependencies, secrets, and containers in one evidence stream, and export it when a certification body or customer review asks. Security then runs alongside development continuously instead of acting as a checkpoint that stops it.

Where should teams start?

Teams should start by inventorying what agents and AI components they already have, because every other control in the map depends on knowing what's in use.

1. Inventory agents, models, and MCP servers. Find which coding agents developers run, which models they call, and which MCP servers and skills they connect. Add AI components to your SBOM process instead of keeping a side spreadsheet. Our guide to AI model governance covers what to track.

2. Define deterministic agent policies. Start with three rules: block destructive commands, block access to credential files, and allowlist MCP servers. Scope agent permissions to the task, in line with least agency.

3. Wire evidence collection into builds and agent sessions. Make sure each row in the control map produces its artifact automatically. If an artifact depends on someone remembering to export it, fix that first.

4. Run the EU AI Act scoping path. Most teams land on AI literacy plus whatever obligations attach to AI features they ship. Document the reasoning either way, because "we checked and it doesn't apply" is also evidence.

If your organization needs a formal AI management system, ISO 42001 is the adjacent standard. It covers the policies and management processes around AI, while this map covers the development practices underneath. In Endor Labs' view, regulators and frameworks such as the EU AI Act and NIST AI RMF are moving toward the same management-system expectations ISO 42001 describes. For details, see our page on ISO 42001 compliance.

FAQs

Is there an official crosswalk between NIST SSDF and the OWASP Top 10 for LLM Applications?

No. NIST and OWASP haven't published an official crosswalk between the SSDF and either OWASP GenAI list. Any mapping, including this one, is an interpretation. Pin it to specific editions and recheck it when either body publishes a revision.

Does following NIST SSDF make us compliant with the EU AI Act?

No. The SSDF is a voluntary practice framework, and the EU AI Act is law with its own obligations, definitions, and conformity requirements. SSDF practices can support some Act obligations, such as cybersecurity under Article 15, but meeting the SSDF doesn't establish compliance with the Act. Work with legal counsel on your obligations.

Do we need NIST SP 800-218A if we don't train our own models?

Probably not as a primary framework. SP 800-218A targets producers of AI models and of the systems built on them, with a focus on training data and model development. If you only use coding agents, use it to evaluate model and agent vendors. If you fine-tune models or ship AI features, review the practices that cover your work directly.