The European Union's Cyber Resilience Act (CRA), Regulation EU 2024/2847, introduces stringent cybersecurity requirements for products with digital elements entering the EU market. For developers building AI applications and agentic systems, this regulation presents a unique challenge: translating its technology-neutral legal language into concrete, actionable security controls. This article provides a technical implementation guide, detailing how to prepare AI systems for CRA compliance, focusing on the engineering efforts required to meet these new obligations.
The Cyber Resilience Act: Key Dates and Scope for AI
The CRA mandates a secure-by-design approach, making it a legal obligation for any product with digital elements. AI applications and AI agents are explicitly within its scope. Developers must be aware of two critical deadlines:
- September 11, 2026: Reporting obligations under Article 14 come into effect. This requires manufacturers to report actively exploited vulnerabilities within 24 hours of discovery, even for products already on the market.
- December 11, 2027: The main provisions of the CRA become applicable, encompassing broader security requirements throughout the product lifecycle.
Ignoring these dates can lead to significant penalties, reaching up to €15 million or 2.5% of worldwide annual turnover. The challenge for AI systems lies in the CRA's technology-neutral stance. While it doesn't explicitly name AI-specific threats like prompt injection or tool abuse, its requirements for vulnerability handling, unauthorized access protection, and security logging inherently demand controls tailored for AI's unique attack surface.
Why AI Systems Challenge Traditional CRA Assumptions
Traditional software development often operates with a clear distinction between code and data. The CRA's framework, largely built on this paradigm, struggles with the inherent nature of AI systems, particularly LLMs. AI blurs the line between instructions and data, introducing novel security challenges:
- Executable Untrusted Input: In LLMs, a user message or retrieved document can become an instruction the model executes. This means the attack surface extends to every piece of text ingested, not just API parameters. Prompt injection, ranked as the number one risk in the OWASP Top 10 for LLM Applications (2025), exemplifies this.
- Non-Deterministic Behavior: The probabilistic nature of AI means the same input can yield different outputs. This complicates the definition of a
"known exploitable vulnerability," as it may manifest as a tendency rather than a fixed flaw.
- Opaque Supply Chains: The AI supply chain extends beyond traditional software packages to include model weights, training data, fine-tunes, and third-party tools. A standard Software Bill of Materials (SBOM) is insufficient for capturing these risks.
- Excessive Agency: When AI agents can interact with external systems, a successful injection attack can lead to unauthorized actions with real-world consequences, moving beyond simple information leakage.
Mapping CRA Requirements to AI Security Controls
To achieve CRA compliance, developers must translate the regulation's essential requirements (Annex I) into specific, buildable controls for AI systems. The following table outlines this mapping:
| CRA Essential Requirement (Annex I) | Technical Implementation for AI |
|---|
| Secure by design | AI threat modeling (e.g., STRIDE, OWASP GenAI Top 10), secure SDLC, policy enforcement at the gateway. |
| Secure by default | Least-privilege tool scopes, conservative model configuration, restricted out-of-the-box system access. |
| Protection from unauthorized access | Identity management for agents and workloads, scoped tool permissions, mTLS between services. |
| Confidentiality and integrity of data | Secret and PII leakage prevention, memory protection, context isolation between sessions. |
| Minimize attack surface | Implementation of an AI gateway as a single chokepoint, input/output guardrails, restricted tool catalog. |
| Vulnerability handling | Continuous AI red teaming, a disclosure process covering model-level findings, managed model updates. |
| Logging and monitoring | Immutable audit logs, runtime monitoring, behavioral anomaly detection. |
| Secure updates | Signed model and prompt updates, rollback capability, change tracking. |
| Supply chain security | Model provenance checks, MCP server validation, an extended SBOM (AI-BOM) for AI components. |
Redefining Vulnerability Handling for AI
The CRA requires manufacturers to address and remediate vulnerabilities without delay. For an LLM application, a vulnerability might be a jailbreak bypassing safety policies or a prompt injection pattern exfiltrating system instructions. These linguistic failure modes won't appear in traditional CVE databases. Continuous AI red teaming is essential for discovering and mitigating these model-level vulnerabilities, satisfying the CRA's requirement to test and remediate.
Runtime Monitoring for Autonomous Agents
The CRA mandates recording and monitoring relevant internal activity. For deterministic applications, this often means request logging. However, for autonomous agents, it requires monitoring actual decisions: which tools were called, with what arguments, and in response to which inputs. This behavioral monitoring is crucial for detecting active exploits and meeting the 24-hour reporting window.
Securing the AI Supply Chain
The regulation expects manufacturers to identify and document product components. For AI, this inventory must include the model, its origins, connected MCP servers, and accessible tools. An unvetted MCP server acts as a third-party component with write access to the agent's behavior. Implementing an AI Bill of Materials (AI-BOM), such as the CycloneDX ML-BOM, is necessary to track these dependencies.
// Example CycloneDX ML-BOM snippet for an AI model
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"components": [
{
"type": "machine-learning-model",
"name": "example-llm",
"version": "1.0.0",
"modelCard": {
"modelParameters": {
"approach": {
"type": "neural-network"
}
}
}
}
]
}
A critical aspect of securing AI agents is enforcing least privilege for tool calls. This aligns with the CRA's requirement for protection from unauthorized access. Developers must define strict scopes for what an agent can do.
# Example of defining a scoped tool for an AI agent
tools = [
{
"type": "function",
"name": "get_user_data",
"description": "Retrieve non-sensitive user profile information.",
"parameters": {
"type": "object",
"properties": {
"user_id": {
"type": "string",
"description": "The unique identifier for the user.",
},
},
"required": ["user_id"],
},
},
]
By explicitly defining the parameters and expected behavior of tools, developers can restrict the agent's capabilities, mitigating the risk of excessive agency and unauthorized actions.
Key Takeaways
- Compliance is an Engineering Effort: CRA compliance for AI requires concrete technical measures, not just paperwork.
- Early Action is Crucial: The September 2026 reporting deadline applies to existing products, necessitating immediate attention to vulnerability detection and reporting mechanisms.
- Rethink Security Controls: Traditional AppSec practices must be adapted to address AI's unique challenges, such as prompt injection and non-deterministic behavior.
- Focus on the Supply Chain: Implement AI-BOMs to track the complex dependencies of AI systems, including models, training data, and third-party tools.
By proactively addressing these technical requirements, developers can ensure their AI applications are not only compliant with the Cyber Resilience Act but also robust against emerging threats.