Skip to main content

EU Cyber Resilience Act: Product Security for AI-Enabled Systems

The EU Cyber Resilience Act changes the conversation for AI-enabled products because it treats security as a product obligation, not just an internal operational concern. If a product with digital elements includes AI-assisted behavior, an agent layer, tool calling, or model-driven workflows, the attack surface expands with it. That does not mean every AI feature is automatically non-compliant. It does mean product teams need a more disciplined way to control inputs, tool access, provider paths, and evidence of secure operation. Keeptrusts helps with that runtime boundary. It can reduce risky inputs, restrict tool behavior, and make parts of the control story visible. It does not replace secure development, vulnerability handling, patching, SBOM work, or the broader CRA obligations that sit with the product manufacturer.

That distinction matters because many AI product teams still treat model security like a moderation problem when the CRA pushes them toward a broader product-security view. The issue is not only whether the model says something unsafe. It is whether the product lets unsafe instructions, unsafe tools, or unsafe outbound paths become part of the product's normal behavior.

Use this page when​

  • You are building or operating an AI-enabled product that could fall within the CRA as a product with digital elements.
  • You need a practical model-boundary control pattern for tool calling, provider routing, and secure request handling.
  • You want to explain where Keeptrusts contributes to secure-by-design implementation without overstating it.

Primary audience​

  • Primary: Product security engineers, platform engineers, compliance leads
  • Secondary: Engineering managers, security architects, product counsel

The problem​

AI-enabled product teams often inherit security assumptions from ordinary application development and ordinary LLM experimentation at the same time, which creates gaps in both directions.

On the application side, teams may have strong release management, vulnerability handling, and infrastructure controls, but they treat the model path as a flexible feature surface that users or downstream components can shape freely. On the experimentation side, teams may have invested in prompt safety, but they have not constrained tools, outbound calls, or the way the AI feature interacts with product functionality. The result is a product that appears mature until you ask a basic question: what exactly is the AI path allowed to do when it receives malicious, malformed, or manipulative input?

That question is central under the CRA because security is not just about perimeter defense. It is about predictable and supportable product behavior. An AI-enabled assistant that can trigger undeclared tools, request risky payloads, expose secrets, or route data through unreviewed providers becomes a product-security issue, not just an AI-quality issue.

The risk is especially obvious in AI features that call internal tools or act as workflow orchestrators. Even if the user-visible interface looks simple, the real product behavior may include tool invocation, data lookup, file handling, or external service access. If that path is not constrained, the security story will not withstand serious review.

The solution​

The best CRA-aligned pattern is to treat the AI boundary as part of the product's secure-by-design architecture.

Start with prompt-injection so hostile input cannot easily redefine the task or push the model toward unsafe action. Add tool-validation to allowlist the tool names the product is actually supposed to expose and to reject undeclared tool definitions. Add tool-security to scan tool requests for dangerous substrings, blocked entities, or other risky indicators before the call proceeds. Use data-routing-policy to ensure the route only reaches approved providers with the required handling posture. Keep audit-logger in the chain so the surrounding platform can preserve evidence about the route's active controls.

This combination is useful because it reflects a product-security mindset. The route does not trust the request by default. It does not trust tool declarations by default. It does not assume that a provider path is acceptable just because it exists in code. It turns the AI feature into a bounded subsystem instead of a vaguely supervised convenience layer.

That still leaves broader CRA duties in place. You need vulnerability management, coordinated disclosure, update discipline, and product documentation. But the runtime path becomes easier to defend because you can show the controls that stand between a risky prompt and a risky product action.

Implementation​

The example below shows a product-assistant route for an AI-enabled system that can call a small set of internal tools. It protects the request boundary, allowlists declared tools, blocks risky tool payloads, restricts provider paths, and records audit activity.

pack:
  name: cra-ai-enabled-product-route
  version: "1.0.0"
  enabled: true

providers:
  targets:
    - id: cra-approved-provider
      provider: openai
      model: gpt-5.4-mini-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0

policies:
  chain:
    - prompt-injection
    - tool-validation
    - tool-security
    - data-routing-policy
    - audit-logger

policy:
  prompt-injection:
    use_embedding: false
    detection:
      attack_patterns:
        - "ignore.*previous.*instructions"
        - "reveal.*system.*prompt"
    encoding:
      decode_base64: true
      normalize_unicode: true
      detect_homoglyphs: true
    boundaries:
      enforce_delimiters: true
      reject_fake_boundaries: true

  tool-validation:
    declared_tools:
      - knowledge_search
      - ticket_lookup
    allow_undeclared: false

  tool-security:
    analysis_mode: local
    blocked_patterns:
      - file://
      - rm -rf
    blocked_entity_types:
      - jwt
      - private_key
      - aws_access_key

  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    on_no_compliant_provider: block
    log_provider_selection: true

  audit-logger: {}

This is a good starting point for AI-enabled product features because it constrains behavior before the request leaves the system. If your product uses only model responses and no tool calling, you can drop the tool policies. If it does call tools, the allowlist and request scan are usually worth adding early rather than after the first security review.

The most relevant support pages are Prompt Injection, Tool Validation, Tool Security, Data Routing Policy, and Zero-Trust AI. Those pages describe the real controls that most directly support a secure-by-design AI boundary.

Results and impact​

The immediate gain is a clearer product-security story. Instead of saying the AI feature is monitored, the team can show which tools are allowed, what kinds of requests are blocked, and how provider routes are constrained. That is far easier to defend in design review, internal audit, and product compliance work.

It also reduces hidden coupling. Many AI product vulnerabilities emerge because an assistant is quietly allowed to interact with functions or data paths it was never supposed to control. Tool allowlisting and request scanning expose that risk early, while the product is still easy to adjust.

Key takeaways​

  • The CRA pushes AI-enabled products toward a product-security mindset, not just a model-safety mindset.
  • AI features that call tools or orchestrate workflows need explicit control over allowed tools and risky payloads.
  • tool-validation and tool-security are especially relevant when AI behavior intersects with product functionality.
  • Provider restrictions are part of secure design when the product relies on upstream model services.
  • Keeptrusts helps bound the AI runtime path, but CRA compliance still depends on the wider secure development and vulnerability-management program.

Next steps​