Summary: The most prescriptive security control set in this corpus. Five control families protecting unreleased model weights: general hygiene, parameter protection, interface hardening, insider threat, and security assurance.
Sources: raw/Laws/Overview of the Code of Practice _ EU Artificial Intelligence Act.md (Commitment 6, Appendix 4)
Last updated: 2026-07-28
Scope and the Security Goal
Commitment 6 — signatories “maintain robust cybersecurity measures throughout the model lifecycle to prevent risks arising from unauthorized release, access, or theft.”
Two scoping rules (source: Overview of the Code of Practice…md):
- Excludes “models with capabilities lower than at least one model with parameters available for public download.” If an open-weight model already matches your capabilities, protecting yours protects nothing.
- Measures “remain in effect until model parameters are made publicly available or securely deleted.”
Measure 6.1 — Security Goal: signatories “shall establish a comprehensive Security Goal that identifies threat actors their mitigations are intended to protect against, informed by current and projected model capabilities.”
This is a threat-model-first requirement, and the “projected model capabilities” clause means the goal has to be set against where the model is going, not where it is.
Measure 6.2 — deviations from Appendix 4.1–4.5(a) “must demonstrate equivalent protective outcomes.” Implementation “may be phased to correspond with model capability advancement.”
Appendix 4.1 — General security mitigations
Baseline hygiene, unremarkable but stated:
- Network access control — “Identity and access management (e.g. MFA, strong passwords, zero trust architecture, wireless security equal to wired, guest network isolation).”
- Social engineering protection — “Email filtering to detect phishing and suspicious attachments.”
- Malware and removable media — “Policies restricting the use of USBs and similar devices.”
- Software security — “Regular software updates and patch management.”
Appendix 4.2 — Protection of unreleased model parameters
This is the distinctive part — weights treated as crown-jewel material:
- Track all stored copies — “Maintain a secure registry of devices/locations holding model parameters.”
- Restrict copying to unmanaged devices — access controls plus monitoring for unauthorised transfer.
- Encrypt in transit and at rest — “Use 256-bit encryption and secure key storage (e.g. TPM).”
- Secure temporary storage — “Decrypt parameters only in non-persistent memory for legitimate use.”
- Secure parameters in use — “Deploy confidential computing techniques such as attested trusted execution environments.”
- Control physical access — limit access to data centres, “perform inspections for unauthorised presence or devices.”
The “secure parameters in use” requirement is the demanding one. Encrypting at rest and in transit is standard; requiring attested TEEs for weights in use closes the memory-dump path and is a materially higher bar than most production ML infrastructure meets.
Appendix 4.3 — Hardening interface access
- Limit interface access — authorised users/software only, MFA, “review permissions at least every 6 months.”
- Secure interface code — “in-depth manual or automated security reviews of code linked to model parameter access.”
- Prevent exfiltration — “Apply methods such as output rate limiting on interfaces.”
- Minimise insider access — limit who can reach non-hardened interfaces.
Output rate limiting appears here as an anti-exfiltration control. It is the same control that limits T09 gradient-based attacks and best-of-N search, which “require… the ability to send thousands of queries.”
Appendix 4.4 — Insider threats
Explicitly scoped to sabotage or theft “including by or through models”:
- Personnel vetting — background checks for those with access to sensitive model data/systems.
- Insider threat awareness — train staff to recognise and report.
- Prevent self-exfiltration by models — “Use sandboxing and code execution isolation.”
- Safeguard model training — “Inspect training data for tampering or sabotage.”
Two of these four are unusual in a security baseline. “Prevent self-exfiltration by models” treats the model itself as a potential insider threat — the concrete control against the “autonomy, self-replication” and “self-reasoning and evasion of oversight” capabilities listed as systemic risk sources. “Inspect training data for tampering” is the operational answer to Art 15(5) data poisoning.
Appendix 4.5 — Security assurance
- Independent external reviews “if internal capacity is insufficient.”
- Red-teaming “to identify security gaps in networks and facilities.”
- Bug bounty programs for public-facing endpoints “where appropriate.”
- Test insider mitigation protocols, “including personnel integrity assessments.”
- Secure third-party channels for issue reporting.
- Active monitoring with “Endpoint Detection and Response (EDR) or Intrusion Detection Systems (IDS).”
Note the red teaming here is infrastructure red teaming — networks and facilities — distinct from the model adversarial testing required under Commitment 3 and Art 55(1)(a). Both are required; they are different exercises with different teams.
What this control set is actually defending
Read as a whole, Appendix 4 defends against weight theft, not against misuse of the deployed model. Registry, encryption, TEEs, interface hardening, insider vetting, physical inspection — the asset is the parameter file.
That is coherent with the threat model: once weights leak, abliteration removes safety behaviour entirely and no model-level control survives. Weight confidentiality is the precondition for every other safety measure holding.
The corresponding model-behaviour controls live in Commitment 5 (safety mitigations): “filtering, continuous monitoring, refusal training, phased access controls, downstream tool safeguards, and secure deployment environments” (source: Overview of the Code of Practice…md).
Gap worth noting
Appendix 4 has nothing on prompt injection, tool poisoning or agentic containment beyond “sandboxing and code execution isolation” for model self-exfiltration. The agentic attack surface is acknowledged in the systemic-risk taxonomy (“tool use and control of physical systems”) but not in the control set. For an organisation deploying agents, Appendix 4 is necessary and nowhere near sufficient.