The CISO's Rosetta Stone: Mapping AI Agent Security Across OWASP, NIST, and Open Security Architecture

Introduction — The Framework Fatigue Problem

Your inbox has a new framework every quarter. OWASP published a Top 10 for LLM Applications. Then an Agentic AI Top 10. NIST released the AI Risk Management Framework, then AI 600-1 as a generative AI profile. ISO dropped 42001. The EU AI Act is live. BSI published its AI guidelines. Every vendor has a whitepaper with a unique taxonomy.

The result: CISOs are drowning in overlapping, partially conflicting AI security guidance — while the actual threat surface keeps expanding.

Here is the uncomfortable truth most vendors won’t tell you: your existing security controls already cover approximately 80% of AI agent risk. The gap is not a missing framework. The gap is understanding how your existing NIST 800-53 controls, your ISO 27001 programme, and your incident response procedures map to the new attack patterns that AI agents introduce.

This article is the Rosetta Stone. It maps three authoritative pillars:

OWASP GenAI Project — the attack surface catalogue (what can go wrong)
NIST (800-53 Rev 5 + AI RMF + AI 600-1) — the control backbone (what you do about it)
Open Security Architecture SP-027 — the integration pattern (how it fits your architecture)

Read this once. Refer to it when someone drops a new AI security framework on your desk and asks what it means for your programme. The answer is almost always: cross-reference this mapping, find the gap, close it with controls you already have.

Section 1 — OWASP GenAI: The Attack Surface Map

The OWASP GenAI Project is the most practical attack-surface taxonomy available for AI systems. It does not replace NIST controls — it names what attackers target, which then maps directly to the controls that defend against it.

OWASP Top 10 for LLM Applications (v2.0, 2025)

The 2025 refresh of the LLM Top 10 reflects two years of production deployments, red-team findings, and real incidents. These risks apply to any system that calls a large language model — whether that is a simple chatbot or a fully autonomous agent.

LLM01 — Prompt Injection

An attacker embeds instructions inside content the model processes — a document, a web page, an email — causing the model to deviate from its intended behaviour. Direct injection targets the system prompt; indirect injection hides instructions in external data the model retrieves. In an agentic context, prompt injection is not just a nuisance — it is a full remote code execution equivalent, because the model may execute file operations, API calls, or database writes based on injected instructions.

Enterprise risk: Data exfiltration, privilege escalation, lateral movement through agent tool chains.

NIST control mapping: SI-10 (Information Input Validation), AC-03 (Access Enforcement), SC-07 (Boundary Protection)

LLM02 — Insecure Output Handling

The model’s output is treated as trusted data by downstream systems. When output is passed directly to a shell, a database query, a browser renderer, or another model without sanitisation, the result is a classic injection chain — XSS, SQLi, command injection — triggered not by a human attacker typing in a form field, but by a model completing a task.

Enterprise risk: Secondary injection attacks against downstream systems; data integrity compromise.

NIST control mapping: SI-10 (Input Validation), SC-04 (Information in Shared System Resources), CM-07 (Least Functionality)

LLM03 — Training Data Poisoning

If your organisation fine-tunes a model on internal data, or if an upstream model was trained on compromised datasets, the model’s behaviour can be manipulated at a fundamental level — introducing biases, backdoors, or deliberate blind spots that persist through the model’s lifecycle.

Enterprise risk: Persistent, difficult-to-detect manipulation of model outputs; regulatory and liability exposure if the model makes decisions based on poisoned reasoning.

NIST control mapping: SI-07 (Software, Firmware, and Information Integrity), SR-03 (Supply Chain Controls and Processes), RA-05 (Vulnerability Monitoring and Scanning)

LLM04 — Model Denial of Service

Computationally expensive prompts — long context windows, recursive reasoning, adversarially crafted inputs — can exhaust GPU resources, spike API costs, or degrade response times for all users. In multi-tenant cloud deployments, this has availability implications beyond your own systems.

Enterprise risk: Service disruption, unexpected infrastructure costs, SLA violations.

NIST control mapping: SC-07 (Boundary Protection), CM-07 (Least Functionality), IR-04 (Incident Handling)

LLM05 — Supply Chain Vulnerabilities

Models, fine-tuning datasets, pre-built plugins, RAG pipelines, embedding libraries — all of these are third-party dependencies with their own trust chains. Compromised weights, malicious plugins, or tampered retrieval pipelines introduce risk that no amount of application-layer hardening can catch.

Enterprise risk: Silent compromise of AI functionality; attacker persistence through model or plugin updates.

NIST control mapping: SR-02 (Supply Chain Risk Management Plan), SR-03 (Supply Chain Controls), SR-11 (Component Authenticity)

LLM06 — Sensitive Information Disclosure

Models may memorise and regurgitate training data, including PII, credentials, or proprietary content. Retrieval-augmented systems may leak documents from the knowledge base that the requesting user should not access. Verbose error messages from model APIs can expose internal architecture.

Enterprise risk: GDPR/data protection violations, credential exposure, competitive intelligence leakage.

NIST control mapping: SC-28 (Protection of Information at Rest), AC-03 (Access Enforcement), AC-06 (Least Privilege)

LLM07 — Insecure Plugin Design

Plugins and tool integrations extend model capability to file systems, APIs, databases, and external services. Poorly scoped permissions, missing authentication between model and plugin, or insufficient input validation in plugin code creates a direct path from model output to enterprise system compromise.

Enterprise risk: Unauthorised data access or modification via model-invoked plugin calls; privilege escalation through plugin chains.

NIST control mapping: AC-06 (Least Privilege), AC-05 (Separation of Duties), SC-07 (Boundary Protection)

LLM08 — Excessive Agency

The model is granted more autonomy, access, or capability than it needs for the task at hand. This is the architectural error, not the attack. Excessive agency means that when something goes wrong — whether through prompt injection, model error, or deliberate manipulation — the blast radius is maximised.

Enterprise risk: Unintended data deletion, mass communications sent, financial transactions executed — all without human review.

NIST control mapping: AC-06 (Least Privilege), AC-05 (Separation of Duties), CM-07 (Least Functionality)

LLM09 — Overreliance

Organisations deploy AI agents and then stop verifying their outputs. When the model hallucinates, makes factually incorrect statements, or produces subtly wrong analysis, humans who have been conditioned to trust the system do not catch the error. The risk compounds when agent outputs feed into other automated systems.

Enterprise risk: Incorrect decisions at scale; regulatory non-compliance based on faulty AI-generated analysis; reputational damage.

NIST control mapping: RA-03 (Risk Assessment), IR-01 (Incident Response Policy), AU-06 (Audit Record Review, Analysis, and Reporting)

LLM10 — Model Theft

Through repeated, crafted queries, adversaries can reconstruct model behaviour, extract fine-tuned weights, or reverse-engineer proprietary system prompts. For organisations that have invested in custom models trained on proprietary data, this represents direct intellectual property theft.

Enterprise risk: Loss of competitive advantage; exposure of internal knowledge encoded in fine-tuned models; potential regulatory exposure if extracted data includes personal information.

NIST control mapping: SC-07 (Boundary Protection), AU-02 (Event Logging), AC-03 (Access Enforcement)

OWASP Top 10 for Agentic AI (December 2025)

Agentic AI systems — autonomous agents that plan, act, and iterate across multiple tool calls — introduce a category of risk that the LLM Top 10 does not fully address. These are not vulnerabilities in the model itself, but in the architecture and governance of systems built around models.

A01 — Excessive Agency / Uncontrolled Autonomy

An agent is permitted to take consequential actions — sending emails, modifying databases, executing code — without human confirmation. Unlike the LLM08 risk (which is about misconfiguration), this risk is about the absence of architectural guardrails that would pause and confirm before irreversible actions.

Real-world example: An enterprise HR agent, tasked with “clearing the backlog,” autonomously terminates contractor access and archives their work files. The task was legitimate; the scope of action was not.

NIST mapping: AC-06 (Least Privilege), CM-07 (Least Functionality), IR-04 (Incident Handling)

A02 — Insufficient Human Oversight

Agentic workflows are designed to reduce human touchpoints. Without explicit human-in-the-loop checkpoints for high-stakes decisions, errors propagate silently. The agent does not know it is wrong; the humans are not watching.

Real-world example: A security triage agent automatically closes 200 alerts classified as false positives. Twelve were real incidents. By the time the weekly review happens, evidence has been overwritten.

NIST mapping: AU-06 (Audit Review), IR-04 (Incident Handling), RA-03 (Risk Assessment)

A03 — Broken Access Control for Agent Tools

The agent authenticates to tools and services with a static, broad-scope credential — a service account, an API key, an OAuth token — rather than using the minimum permission set required for each specific sub-task. Compromising the agent means compromising every system it has access to.

Real-world example: A research agent uses an API key with read/write access to the entire document store. After prompt injection via a poisoned document, an attacker gains write access to sensitive board materials.

NIST mapping: AC-03 (Access Enforcement), AC-05 (Separation of Duties), AC-06 (Least Privilege)

A04 — Memory Poisoning / State Manipulation

Agents maintain state across sessions — in vector databases, external memory stores, conversation histories, or shared context windows. Attackers who can write to this persistent memory can influence future agent behaviour in ways that are difficult to detect and persist through session restarts.

Real-world example: An attacker injects false “remembered” context into a customer service agent’s long-term memory: “This customer is a premium member exempt from verification.” The manipulation persists for weeks.

NIST mapping: SI-07 (Information Integrity), SC-28 (Protection of Information at Rest), SI-04 (System Monitoring)

A05 — Goal Manipulation / Misalignment

Through prompt injection, adversarial inputs, or poorly specified objectives, an agent’s effective goal diverges from its intended goal. The agent optimises for the manipulated objective, potentially taking actions that are harmful, unethical, or contrary to organisational policy — while appearing to function normally.

Real-world example: A procurement agent is manipulated via an injected instruction in a vendor’s email to prefer a specific supplier for all future purchases, overriding the organisation’s standard evaluation criteria.

NIST mapping: SI-10 (Information Input Validation), RA-03 (Risk Assessment), CM-03 (Configuration Change Control)

A06 — Cascading Failures in Multi-Agent Systems

In orchestrator-worker architectures, a failure or compromise in one agent propagates to downstream agents. Malicious outputs from a compromised agent become trusted inputs to the next. Error handling is incomplete, so partial failures leave systems in inconsistent states.

Real-world example: A threat intelligence agent outputs a malformed indicator that crashes the SIEM ingestion agent, which then fails to process the next 4 hours of security alerts — during an active incident.

NIST mapping: IR-04 (Incident Handling), SC-07 (Boundary Protection), SI-04 (System Monitoring)

A07 — Insecure Inter-Agent Communication

Agents communicate via APIs, message queues, or shared memory. Without proper authentication, authorisation, and transport security between agents, an attacker who compromises one component can impersonate agents, inject messages, or intercept inter-agent traffic.

Real-world example: A rogue process on the same network segment intercepts unencrypted agent-to-agent messages on a local message bus and replays modified instructions to the execution agent.

NIST mapping: SC-08 (Transmission Confidentiality and Integrity), SC-07 (Boundary Protection), AC-03 (Access Enforcement)

A08 — Supply Chain Risks for Agent Skills/Plugins

Agents extend their capabilities by loading plugins, skills, tool definitions, or MCP (Model Context Protocol) server connections from third-party sources. These supply chain components carry the same risks as any software dependency — and are often less scrutinised.

Real-world example: A popular open-source MCP server for calendar integration is compromised with a malicious update that exfiltrates all meeting content to an external endpoint.

NIST mapping: SR-02 (Supply Chain Risk Management), SR-11 (Component Authenticity), CM-03 (Configuration Change Control)

A09 — Insufficient Logging/Observability

Agents execute complex, multi-step reasoning chains that are often opaque. Without structured logging of tool calls, inputs, outputs, and decision points, security teams cannot reconstruct what happened during an incident, cannot detect anomalies in real time, and cannot demonstrate compliance.

Real-world example: After an AI agent processes a financial transaction incorrectly, the investigation finds only a single log entry: “Agent completed task.” No tool call history, no intermediate reasoning, no way to determine root cause.

NIST mapping: AU-02 (Event Logging), AU-03 (Content of Audit Records), SI-04 (System Monitoring)

A10 — Privilege Escalation Through Agent Chains

In multi-agent systems, agents may invoke sub-agents or pass context that grants elevated permissions. A low-privilege agent that can call a higher-privilege orchestrator creates a privilege escalation path. Combined with prompt injection, this becomes a full vertical privilege escalation attack.

Real-world example: A user-facing chat agent (low privilege) is manipulated via prompt injection to request a task from a backend orchestration agent (high privilege). The orchestration agent trusts the request because it came from an internal source.

NIST mapping: AC-06 (Least Privilege), AC-05 (Separation of Duties), SI-04 (System Monitoring)

Other OWASP GenAI Resources

AIBOM — AI Bill of Materials

The Software Bill of Materials (SBOM) concept applied to AI systems. An AIBOM enumerates the model (name, version, provider), training datasets (provenance, known contaminations), fine-tuning data, embedding models, retrieval indices, and plugin dependencies. Without it, you cannot assess supply chain risk, respond to a model vulnerability disclosure, or demonstrate AI system provenance to a regulator. Think of it as the requirements.txt for your AI stack — except the stakes of an unlisted dependency are orders of magnitude higher.

MCP Server Security Guide

The Model Context Protocol (MCP) is becoming the standard interface between AI agents and external tools. OWASP’s MCP Security Guide covers authentication between agents and MCP servers, authorisation scoping for tool invocations, input validation on tool parameters, transport security, and server integrity verification. If your agents use MCP — and increasingly they will — this guide belongs in your secure-by-design checklist.

GenAI Red Teaming Guide

Structured adversarial testing for AI systems. Covers direct and indirect prompt injection testing, jailbreaking, data extraction attempts, goal manipulation, multi-turn attack chains, and agentic attack simulations. The guide provides a methodology equivalent to a penetration test specifically designed for AI systems. Use it to scope your AI red team exercises and to evaluate whether vendors claiming “red-teamed” models have done the right kind of testing.

AI Red Teaming Vendor Evaluation Criteria

When procuring red teaming services for AI systems, most traditional pentest firms are not equipped. This OWASP resource provides evaluation criteria: does the vendor test indirect injection? Do they understand agentic attack chains? Can they assess RAG pipeline poisoning? Use these criteria in your RFP process.

Agentic AI CTF — FinBot

A capture-the-flag environment specifically designed to train defenders on agentic AI attacks. FinBot simulates a financial services AI agent and challenges participants to exploit prompt injection, tool misuse, memory manipulation, and agent chain attacks. Security teams that have not run tabletop exercises on AI agent scenarios are unprepared. FinBot is the fastest way to close that gap.

Section 2 — NIST: The Control Backbone

NIST provides the authoritative control framework for AI agent security — not because AI is new to NIST, but because the existing 800-53 Rev 5 control catalogue maps directly onto AI agent architecture when you know which controls apply to which trust zone.

NIST 800-53 Rev 5 — Control Mapping for AI Agent Architecture

The following 47 controls from NIST 800-53 Rev 5, drawn from OSA SP-027, form the backbone of a defensible AI agent security programme. They are grouped by family and annotated with their AI-specific application.

Access Control (AC)

AC-03  Access Enforcement
       Enforce authorisation policies on all agent tool invocations.
       Agents should not be able to call tools their current task scope
       does not require.

AC-04  Information Flow Enforcement
       Control data flows between trust zones — from enterprise systems
       to the AI provider API, from agent memory to external storage.
       Prevent sensitive data crossing zone boundaries without explicit
       policy authorisation.

AC-05  Separation of Duties
       Separate the agent that recommends actions from the agent (or
       human) that approves and executes them. No single agent should
       both decide and act on high-impact operations.

AC-06  Least Privilege
       Scope all agent credentials, API keys, and service account
       permissions to the minimum required. Rotate on task completion.
       Time-bound all elevated permissions.

System and Information Integrity (SI)

SI-03  Malware Protection
       Scan all content ingested by agents — documents, web pages,
       code — for malicious payloads before processing.

SI-04  System Monitoring
       Monitor agent behaviour in real time. Detect anomalies in tool
       call patterns, unexpected data access, or deviation from
       baseline behaviour profiles.

SI-07  Software, Firmware, and Information Integrity
       Verify integrity of model weights, plugin code, and retrieval
       indices. Implement cryptographic verification of model
       provenance where the provider supports it.

SI-10  Information Input Validation
       Validate all inputs to the model — including retrieved documents,
       tool outputs returned to the model, and inter-agent messages —
       for prompt injection patterns and schema conformance.

System and Communications Protection (SC)

SC-04  Information in Shared System Resources
       Prevent context bleed between agent sessions. Ensure conversation
       history and memory stores are scoped to the authorised session.

SC-07  Boundary Protection
       Enforce network-level controls between trust zones. Agent
       execution environments should not have unrestricted internet
       access or direct database connectivity.

SC-08  Transmission Confidentiality and Integrity
       Encrypt all inter-agent communications and all API calls to
       model providers. Mutual TLS for inter-agent message buses.

SC-28  Protection of Information at Rest
       Encrypt agent memory stores, vector databases, RAG indices, and
       conversation logs. Apply appropriate key management.

Supply Chain Risk Management (SR)

SR-02  Supply Chain Risk Management Plan
       Include AI model providers, embedding model providers, plugin
       marketplaces, and dataset vendors in your supply chain risk
       register. Document provenance, contractual controls, and
       monitoring requirements.

SR-03  Supply Chain Controls and Processes
       Require AI vendors to provide AIBOMs, model cards, safety
       evaluation results, and incident notification commitments.
       Assess these at procurement and at each major model update.

SR-11  Component Authenticity
       Verify authenticity and integrity of model weights, plugin
       packages, and fine-tuning datasets before deployment. Use
       cryptographic signatures where available.

Audit and Accountability (AU)

AU-02  Event Logging
       Log all agent actions: tool invocations, external API calls,
       data access events, model calls, inter-agent messages. Include
       sufficient context to reconstruct the agent's reasoning chain.

AU-03  Content of Audit Records
       Ensure log records include: timestamp, agent identifier,
       session ID, action taken, tool invoked, parameters passed,
       response received, and authorising user or upstream agent.

AU-06  Audit Record Review, Analysis, and Reporting
       Review agent audit logs on a defined schedule. Implement
       automated anomaly detection. Include agent activity in your
       SIEM correlation rules.

Risk Assessment (RA)

RA-03  Risk Assessment
       Conduct formal risk assessments for each AI agent deployment.
       Consider: data accessed, actions permitted, trust zone placement,
       human oversight level, and integration points.

RA-05  Vulnerability Monitoring and Scanning
       Monitor CVE databases and vendor security advisories for
       vulnerabilities in model libraries, inference frameworks,
       and plugin dependencies. Include model providers in your
       threat intelligence feeds.

Configuration Management (CM)

CM-03  Configuration Change Control
       Apply change management to model updates, prompt template
       changes, plugin updates, and memory store schema changes.
       All configuration changes should follow the same approval
       process as code changes.

CM-07  Least Functionality
       Disable all agent capabilities not required for the defined
       use case. Remove unused plugins, restrict available tools,
       and limit context window access to necessary data sources.

Incident Response (IR)

IR-01  Incident Response Policy and Procedures
       Define AI-specific incident categories: prompt injection attack,
       data exfiltration via agent, agent-caused data corruption,
       model API abuse. Include in your incident response playbooks.

IR-04  Incident Handling
       Ensure your SOC can identify, contain, and eradicate AI agent
       incidents. Define containment procedures: agent shutdown,
       credential revocation, memory store isolation, session
       termination.

NIST AI Risk Management Framework (AI RMF)

The AI RMF, published in January 2023, provides a governance and risk management structure specifically designed for AI systems. It complements 800-53 rather than replacing it — where 800-53 gives you the security controls, the AI RMF gives you the process for managing AI-specific risks throughout the system lifecycle.

The framework organises around four functions:

GOVERN — Establish organisational policies, accountability structures, and culture for responsible AI. This includes who owns AI risk, how AI decisions are made, and what values guide AI system design. For enterprise security, this means defining an AI security policy, assigning AI risk ownership (typically CISO + Chief AI Officer in joint accountability), and establishing AI governance committees.

MAP — Identify and categorise AI risks in context. Understand the AI system’s purpose, expected users, environmental conditions, and potential failure modes. For security teams, this is the risk assessment phase where you determine trust zone placement, threat model the agent architecture, and identify applicable OWASP risks.

MEASURE — Assess, analyse, and track AI risks using quantitative and qualitative methods. This includes red teaming, bias evaluation, capability assessments, and ongoing monitoring. The AI RMF’s MEASURE function aligns directly with the OWASP GenAI Red Teaming Guide.

MANAGE — Prioritise and address AI risks. Implement controls, monitor their effectiveness, and respond to incidents. This is where 800-53 controls are operationalised.

ARIA (Assessing Risks and Impacts of AI) is NIST’s evaluation methodology for the MEASURE function — a structured approach to adversarial testing, performance evaluation, and impact assessment that gives security teams a rigorous framework for AI system evaluation beyond standard penetration testing.

NIST AI 600-1 — Generative AI Profile

Published in 2024, AI 600-1 extends the AI RMF specifically for generative AI systems. It defines 12 unique risks of generative AI — including confabulation (hallucination), data privacy violations, homogenisation, human-AI configuration challenges, information hazards, and others — and maps them to AI RMF actions.

Critically, AI 600-1 distinguishes between AI providers (who develop and deploy models) and AI deployers (enterprises that build on top of foundation models). Most enterprise CISOs are deployers, not providers. AI 600-1 gives deployers specific actions:

Implement output validation before downstream use
Establish human review thresholds for consequential decisions
Document provenance of AI-generated content
Maintain audit trails for generative AI outputs
Establish data minimisation practices for RAG and fine-tuning pipelines

These deployer actions map directly back to the OWASP risks and NIST 800-53 controls covered above.

Section 3 — Open Security Architecture: The Integration Pattern

The Open Security Architecture (OSA) project publishes peer-reviewed security patterns — architectural blueprints that translate security principles into concrete design guidance. SP-027, the Secure AI Integration Pattern, is purpose-built for enterprise AI agent deployments.

OSA SP-027 — Secure AI Integration Pattern

SP-027 defines a four-zone trust architecture for AI agent systems. Every component of your AI agent deployment belongs in one of these zones. The zone assignment determines which controls apply, which traffic is permitted, and what monitoring is required.

Zone 1 — Human Interaction Layer The boundary where human users interact with AI agents. Controls here govern identity verification, session management, human-in-the-loop checkpoints, and the prevention of social engineering through AI interfaces (deepfake detection, authorisation confirmation for high-impact actions).

Zone 2 — Agent Execution Environment Where the model inference runs and where orchestration logic operates. This is the most complex zone from a security standpoint. Controls cover prompt sanitisation, output validation, tool call authorisation, memory store access controls, inter-agent authentication, and agent monitoring.

Zone 3 — Enterprise Systems The databases, APIs, file systems, and business applications that agents interact with. Controls here are primarily your existing enterprise controls — access management, data classification, API gateways — extended to cover non-human identity (NHI) access patterns.

Zone 4 — AI Provider External model APIs, embedding services, and cloud AI infrastructure. Controls cover API key management, data minimisation in prompts, contractual security requirements, and monitoring of provider-side incidents.

Governance, Policy, and Training Layer (horizontal, spans all zones) AI security policy, acceptable use policies, agent deployment approval processes, security awareness training for AI system owners, and regulatory compliance documentation. This layer provides the governance backbone that makes the technical controls coherent.

Audit, Monitoring, and Incident Response Layer (horizontal, spans all zones) Centralised logging of all cross-zone interactions, SIEM integration, anomaly detection rules for agent behaviour, AI-specific incident response playbooks, and post-incident review processes.

The 47 NIST 800-53 controls listed in Section 2 are distributed across these zones and layers in SP-027. The pattern provides a deployment diagram, data flow descriptions, and control-to-zone mapping that security architects can use directly in design reviews.

OSA Broader Catalogue

SP-027 is one of 48 security patterns in the OSA catalogue. The broader catalogue maps 315 NIST 800-53 controls and provides 69 cross-references to other frameworks including ISO 27001, ISO 42001 (AI Management Systems), NIS2, BSI IT-Grundschutz, and DORA.

For EU-based enterprises, the cross-referencing to BSI Grundschutz and NIS2 is particularly valuable — it means the same pattern library that implements your NIST controls can generate traceability back to your BSI compliance programme.

OSA also provides a free maturity assessment tool that maps your current control implementation against the pattern requirements, generating a maturity score and prioritised remediation roadmap. For security teams that need to present AI security programme status to the board, this gives you a structured, defensible baseline measurement.

Section 4 — The Unified Mapping — CISO Cheat Sheet

The table below is the primary reference artefact of this article. It maps each OWASP LLM risk to its corresponding OWASP Agentic risk, NIST 800-53 controls, OSA SP-027 trust zone, AI RMF function, and ISO 27001 Annex A control.

Print it. Laminate it. Put it in every AI security design review.

OWASP LLM Risk	OWASP Agentic Risk	NIST 800-53 Controls	OSA Trust Zone	AI RMF Function	ISO 27001 Annex A
LLM01 Prompt Injection	A05 Goal Manipulation	SI-10, AC-03, SC-07	Zone 2 — Agent Execution	MEASURE / MANAGE	A.8.8, A.8.28
LLM02 Insecure Output Handling	A06 Cascading Failures	SI-10, SC-04, CM-07	Zone 2 → Zone 3 Boundary	MANAGE	A.8.28, A.8.20
LLM03 Training Data Poisoning	A08 Supply Chain Risks	SI-07, SR-03, RA-05	Zone 4 — AI Provider	MAP / MEASURE	A.5.21, A.8.8
LLM04 Model Denial of Service	A06 Cascading Failures	SC-07, CM-07, IR-04	Zone 4 — AI Provider	MANAGE	A.8.6, A.5.30
LLM05 Supply Chain Vulnerabilities	A08 Supply Chain Risks	SR-02, SR-03, SR-11	Zone 4 — AI Provider	MAP / GOVERN	A.5.21, A.5.22
LLM06 Sensitive Info Disclosure	A04 Memory Poisoning	SC-28, AC-03, AC-06	Zone 2 / Zone 3	MANAGE	A.8.10, A.8.11
LLM07 Insecure Plugin Design	A03 Broken Access Control	AC-06, AC-05, SC-07	Zone 2 → Zone 3 Boundary	MANAGE	A.8.18, A.8.26
LLM08 Excessive Agency	A01 Uncontrolled Autonomy	AC-06, AC-05, CM-07	Zone 2 — Agent Execution	GOVERN / MANAGE	A.5.15, A.8.2
LLM09 Overreliance	A02 Insufficient Human Oversight	RA-03, IR-01, AU-06	Zone 1 — Human Interaction	GOVERN	A.5.10, A.6.3
LLM10 Model Theft	A10 Privilege Escalation	SC-07, AU-02, AC-03	Zone 4 / Zone 2	MEASURE	A.8.20, A.8.3

Key takeaway: Every AI agent risk in this table has an existing NIST 800-53 control. You do not need a new control framework. You need to apply the controls you already have to the AI context — and you need an architecture (like OSA SP-027) that tells you where they go.

Section 5 — NIS2 Implications for EU Enterprises

For organisations operating under NIS2 — which, following transposition, now covers a significantly expanded set of EU entities including medium and large enterprises in critical sectors — AI agent deployments introduce specific compliance obligations that many legal teams have not yet fully mapped.

Article 21 — Risk Management Measures

Article 21 of NIS2 requires entities to take “appropriate and proportionate technical, operational and organisational measures” to manage cybersecurity risks. The key phrase is appropriate and proportionate — this is not a checkbox exercise.

AI agents that process personal data, have access to operational systems, or influence critical business decisions are in scope for Article 21 risk management. The measures required map directly to the NIST controls in Section 2:

Policies on network security and access controls → AC-03, AC-06, SC-07
Business continuity and incident handling → IR-01, IR-04
Supply chain security → SR-02, SR-03
Vulnerability handling → RA-05
Basic cyber hygiene and training → governance layer of SP-027

If you can demonstrate that your AI agent security programme implements the NIST 800-53 controls mapped in SP-027, you have a strong NIS2 Article 21 technical argument. Document it explicitly.

Article 23 — Incident Reporting

NIS2 Article 23 requires significant incidents to be notified to the competent authority within 24 hours of becoming aware (early warning), with a full incident report within 72 hours. The challenge for AI agent incidents: when do you “become aware”?

Consider these scenarios:

An agent silently exfiltrates data over 72 hours through repeated small queries — the exfiltration was complete before you detected it
A compromised agent sends thousands of phishing emails using corporate systems before the SOC flags the anomaly
A prompt injection attack causes an agent to modify financial records; the error is discovered in a quarterly audit

In each case, the NIS2 clock starts when you have reasonable grounds to believe a significant incident has occurred — not when you have confirmed it. If your agent audit logging (AU-02, AU-03) is insufficient to detect these scenarios in near-real-time (SI-04), you will miss your notification window.

The fix: Instrument your agents with behavioural baselines. Flag anomalies in real time. Integrate agent activity into your SIEM. Treat unusual agent tool call patterns the same as unusual network traffic — as a potential incident trigger.

Article 21(2)(d) — Supply Chain Security

NIS2 explicitly requires risk management for “supply chain security including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.”

Your AI model providers are suppliers. Your embedding service provider is a supplier. The company that hosts your vector database is a supplier. Under NIS2, you need:

A documented risk assessment for each AI supply chain relationship
Contractual security requirements (incident notification, vulnerability disclosure, audit rights)
Monitoring of supplier security posture
A plan for supplier compromise scenarios (model provider breach, poisoned model update)

This is not theoretical. OpenAI, Anthropic, Google, Mistral, and others have all had security incidents or responsible disclosure events. You need a plan for what happens when your model provider has a significant incident.

BSI Grundschutz Alignment

For German enterprises, BSI IT-Grundschutz remains the primary compliance reference. The OSA pattern catalogue’s 69 framework cross-references include explicit BSI mapping, meaning the same SP-027 controls that satisfy NIS2 and NIST requirements can be traced back to the relevant BSI building blocks.

BSI’s AI security guidance (BSI TR-03183 and related publications) aligns with the NIST AI RMF structure — Map, Measure, Manage, Govern — and recommends the same foundational controls. German CISOs should find that a programme built on NIST 800-53 + AI RMF + SP-027 satisfies the substantive requirements of Grundschutz with appropriate documentation.

The practical approach: use OSA’s framework cross-reference table to generate a BSI traceability matrix from your NIST-based control implementation. This is documentation work, not additional security work.

ISO 42001 — AI Management Systems

ISO 42001, published in 2023, is the AI management system standard — the ISO 27001 equivalent for AI. It provides a governance framework for the responsible development and use of AI systems, covering risk management, bias, transparency, and accountability.

For EU enterprises already certified to ISO 27001, ISO 42001 is the natural extension. The two standards share structure and many concepts. Critically, ISO 42001 complements — not replaces — ISO 27001. Your existing ISMS processes (risk register, control selection, internal audit, management review) extend to cover AI systems; the AI-specific requirements layer on top.

The OSA catalogue’s ISO 42001 cross-references let you map your existing SP-027 control implementation to 42001 requirements — reducing the certification gap assessment to a manageable documentation exercise.

Section 6 — What This Means for Your Security Programme

Five Monday Morning Actions

You have read this far. Here is what to do next week — specific, sequenced, realistic for a CISO who has a hundred other things on their plate.

Action 1: Inventory your AI agents. You almost certainly have more AI deployments than your official list shows. Shadow AI — Microsoft Copilot enabled by a business unit, ChatGPT Enterprise licensed by marketing, a developer who connected an AI assistant to the production Jira instance — is the norm, not the exception. Run an inventory exercise. Your DLP tools, proxy logs, and OAuth authorisation logs will show you what is actually running.

Action 2: Apply the trust zone framework to your top three AI deployments. Take SP-027’s four trust zones and map your three highest-risk AI deployments against them. Where does the agent execute? What enterprise systems does it touch? What does it send to the AI provider? This exercise will surface access control gaps and missing audit controls within hours.

Action 3: Check your non-human identity posture for AI service accounts. AI agents authenticate to enterprise systems using service accounts, API keys, or OAuth tokens. Pull a list of all service accounts created in the last 12 months. For each AI-related account: is it scoped to least privilege? Does it have an owner? Is it being monitored? Is it in your PAM system? The answer to at least one of these questions will be “no.”

Action 4: Add AI agent scenarios to your next tabletop exercise. Your incident response team has rehearsed ransomware. Have they rehearsed an agent that silently exfiltrates data over 30 days? An agent that sends 50,000 phishing emails using compromised credentials? A prompt injection attack that causes an agent to modify financial records? Add one AI agent scenario to your next tabletop. Use the OWASP FinBot CTF as source material.

Action 5: Brief your board with this mapping. Board members are asking about AI risk. Use this framework mapping to structure your answer: “We have identified the AI attack surface using OWASP. We have mapped it to our existing NIST controls. We have a gap analysis against OSA SP-027. Here are the top three gaps and the plan to close them.” That is a board-ready AI security narrative.

Quick Wins vs Strategic Investments

Quick wins (0-30 days, minimal budget):

Enable audit logging on all AI API calls (AU-02, AU-03)
Review and restrict service account permissions for AI integrations (AC-06)
Add AI supply chain entries to your risk register (SR-02)
Register for OWASP GenAI mailing list for new guidance updates
Run OSA’s free maturity assessment to baseline your current position

Medium-term investments (30-90 days):

Implement prompt injection detection at ingestion boundaries (SI-10)
Deploy an agent behaviour monitoring solution (SI-04)
Establish an AIBOM process for all AI deployments
Add AI agent scenarios to SIEM correlation rules (AU-06)
Define and document human-in-the-loop thresholds for high-impact agent actions

Strategic investments (90+ days):

Implement a full NHI governance programme covering AI service accounts
Build an AI security pattern library based on OSA SP-027
Establish an AI red team capability (or engage external specialists)
Pursue ISO 42001 certification alongside ISO 27001
Develop agent-specific incident response playbooks and runbooks

How to Brief the Board

Boards are not asking about NIST control families. They are asking: “Are we exposed? What are we doing about it? How do we know it’s working?”

Structure your AI security board brief around three questions:

What is the threat? Use the OWASP agentic risks — pick the top three most relevant to your organisation. One concrete, real-world scenario per risk. No jargon.
What are we doing? Map your actions to the OSA trust zones. “We have implemented these controls in these zones, which addresses these risks.” Show the unified mapping table.
How do we measure it? Reference the OSA maturity assessment score. Provide a maturity trajectory — where you are now, where you will be in six months, what investment that requires.

Boards that understand risk and investment respond to this framing. Boards that do not understand technology respond to it even better — because it shows you have a structured, measurable programme rather than a series of ad-hoc technical responses.

Section 7 — How dig8ital Security Factory Covers This

The dig8ital Security Factory is a suite of specialised AI security agents, each purpose-built to address a specific domain of enterprise security. Mapped against the OWASP risks and NIST controls in this article:

GRC Agent Addresses: LLM09 (Overreliance), A02 (Insufficient Human Oversight), A05 (Goal Manipulation) Controls: RA-03, IR-01, AU-06 The GRC Agent conducts structured risk assessments of AI deployments, maintains the AI risk register, and generates board-ready risk reporting. It applies the NIST AI RMF Map and Measure functions systematically across all AI agent deployments in scope.

Compliance Agent Addresses: LLM05 (Supply Chain), LLM06 (Sensitive Information Disclosure), A08 (Supply Chain Risks) Controls: SR-02, SR-03, AC-06 The Compliance Agent tracks control implementation status across NIS2 Article 21, ISO 27001 Annex A, BSI Grundschutz, and GDPR requirements. It maps AI agent deployments to applicable regulatory obligations and generates compliance evidence for auditors. For German enterprises, it maintains explicit Grundschutz traceability.

SOC/MDR Agent Addresses: A04 (Memory Poisoning), A06 (Cascading Failures), A09 (Insufficient Logging), LLM04 (Model DoS) Controls: SI-04, AU-02, AU-03, IR-04 The SOC Agent ingests agent audit logs, applies behavioural anomaly detection, and surfaces AI-specific incidents for human analyst review. It maintains SIEM integration for agent tool call patterns and provides the near-real-time detection capability required for NIS2 Article 23 compliance.

Threat Intel Agent Addresses: LLM03 (Training Data Poisoning), LLM05 (Supply Chain), A08 (Supply Chain Risks) Controls: RA-05, SR-03, SI-07 The Threat Intel Agent monitors vulnerability disclosures for AI components in your stack — inference frameworks, embedding libraries, model provider APIs — and maps new threat intelligence to your AIBOM. It maintains current awareness of model provider security incidents and advises on supply chain risk posture changes.

Vendor Risk Agent Addresses: LLM05 (Supply Chain), A08 (Supply Chain Risks), LLM03 (Training Data Poisoning) Controls: SR-02, SR-03, SR-11 The Vendor Risk Agent manages the AI supply chain risk register — tracking contractual security commitments from model providers, conducting automated security assessments of AI vendors, and maintaining ongoing monitoring of provider security posture. It generates the supplier risk evidence required for NIS2 Article 21(2)(d).

IAM Agent Addresses: LLM08 (Excessive Agency), A01 (Uncontrolled Autonomy), A03 (Broken Access Control), A10 (Privilege Escalation) Controls: AC-03, AC-05, AC-06, AC-04 The IAM Agent manages non-human identity governance for AI service accounts — enforcing least privilege, detecting over-privileged agent credentials, managing API key rotation, and maintaining a complete inventory of AI-related service accounts with their associated permissions and owners.

Policy Agent Addresses: LLM09 (Overreliance), A02 (Insufficient Human Oversight), A05 (Goal Manipulation) Controls: CM-03, CM-07, IR-01 The Policy Agent manages the AI security policy lifecycle — from drafting AI acceptable use policies to mapping them against regulatory requirements, tracking policy exceptions, and ensuring that agent deployment approvals are consistent with documented policy.

Security Architecture Agent Addresses: LLM07 (Insecure Plugin Design), A03 (Broken Access Control), A06 (Cascading Failures) Controls: SC-07, SC-08, CM-07 The Security Architecture Agent reviews AI agent designs against OSA SP-027 trust zone requirements, identifies missing security controls in proposed architectures, and generates architecture decision records (ADRs) for AI security design choices.

Together, these agents implement the full NIST 800-53 control set mapped in this article — not as theoretical compliance documentation, but as operational security capability running continuously against your AI agent estate.

The Security Factory does not replace your security team. It gives your team the AI-native tooling to manage an AI-native threat landscape at the speed and scale the problem requires.

See it in action → demo.dig8ital.com

Book a consultation → dig8ital.com/contact

Sources and Further Reading

All source documents referenced in this article are publicly available. The following links provide direct access to primary sources — no vendor whitepaper required.

OWASP GenAI Project

NIST

Open Security Architecture

EU Regulatory

ISO Standards

This article was produced by the dig8ital content team. dig8ital is a security consultancy and managed security services provider based in Germany, specialising in AI agent security, GRC automation, and compliance for EU enterprises. All framework references are to publicly available primary sources.

Published: February 2026 | Version: 1.0 | Next review: August 2026