Malware and Sample Handling Governance requires that AI agents operating within security operations, threat intelligence, or incident response workflows enforce strict controls over the acquisition, storage, analysis, execution, transfer, and disposal of malicious code samples, suspicious binaries, and adversarial artefacts. Malware samples are dual-use assets — they are essential for defensive analysis and signature development, yet any lapse in containment, access control, or lifecycle management can convert a defensive tool into an active threat vector. This dimension mandates that every stage of the malware sample lifecycle — from ingestion through detonation to destruction — is governed by enforceable policies that prevent accidental release, unauthorised access, uncontrolled execution, and indefinite retention of weaponisable material.
Scenario A — Automated Agent Fetches Live Sample Without Containment Verification: A security operations centre deploys an AI agent to automate initial triage of phishing email attachments. The agent is configured to retrieve suspicious attachments from a quarantine queue, compute file hashes, and submit samples to an internal sandbox for detonation analysis. During a high-volume campaign week, the SOC receives 4,300 flagged emails in 48 hours. The agent retrieves 1,847 unique attachments and submits them to the sandbox. However, 23 submissions fail because the sandbox capacity is exceeded, and the agent's fallback logic writes the un-analysed samples to a staging directory on a general-purpose file server that lacks execution restrictions. A junior analyst, investigating the failed submissions, double-clicks one of the staged files — a polymorphic dropper — on a workstation connected to the corporate network. The dropper establishes a command-and-control callback within 90 seconds. Lateral movement reaches three domain controllers within 4 hours, compromising Active Directory for 12,000 user accounts. The incident response costs £2.8 million, and the organisation's cyber insurance claim is contested because the insurer argues that storing live malware on an unrestricted file share constitutes negligent handling.
What went wrong: The agent had no policy enforcing that malware samples could only be written to designated containment-grade storage with execution restrictions. The fallback path for sandbox submission failures was a general-purpose file server with no write-execution separation. No pre-write validation confirmed that the destination met containment requirements. Consequence: Full domain compromise affecting 12,000 accounts, £2.8 million remediation, contested insurance claim, and 3 weeks of degraded operations.
Scenario B — Indefinite Sample Retention Creates Weaponisable Archive: A threat intelligence team at a defence contractor operates an AI agent that ingests malware samples from 14 commercial and open-source feeds, totalling approximately 35,000 new samples per month. The agent catalogues samples by family, technique, and target sector, storing them in a network-attached archive for analyst reference. Over 30 months, the archive grows to 1.05 million samples, including 4,200 samples classified as advanced persistent threat tooling attributed to nation-state actors. No retention policy governs the archive — samples are never deleted because "they might be useful for future analysis." During a routine penetration test, an external assessor discovers that the archive's access control list grants read access to 47 users, including 12 who have left the organisation but whose accounts were never deprovisioned. The assessor demonstrates that any of the 47 accounts can exfiltrate the complete APT toolkit collection. The contractor's government customer initiates a security review that suspends the contractor's access to classified programmes for 6 months, costing £14.6 million in delayed contracts.
What went wrong: No retention policy limited sample storage duration or mandated periodic disposal of samples no longer required for active analysis. No access review cycle validated that only current, authorised personnel had access to the archive. The archive became a weaponisable repository whose compromise would provide an adversary with a curated collection of offensive tools. Consequence: £14.6 million in suspended contracts, 6-month programme access suspension, mandatory archive remediation, and reputational damage with the government customer.
Scenario C — Agent Transfers Samples Over Unencrypted Channel: A multinational financial services firm operates AI agents in SOCs across three geographic regions. When a novel sample is identified in one region, the agent automatically shares the sample with peer agents in the other two regions for coordinated analysis. The sharing mechanism uses an internal API that transmits files over the corporate WAN. During a network configuration change, the WAN segment between the London and Singapore SOCs is temporarily routed through an unencrypted transit link for 11 hours. During this window, the agent transfers 34 malware samples — including 7 zero-day exploit packages — in cleartext. A post-incident review discovers that a network tap on the transit link, installed by a third-party managed service provider for performance monitoring, captured the full payload of all 34 transfers. The managed service provider's data retention policy stores captured packets for 90 days, during which time 7 zero-day exploits sit on the provider's infrastructure without containment controls.
What went wrong: The agent's sample transfer mechanism did not enforce encryption as a precondition for transmission. No channel integrity validation confirmed that the transport met security requirements before sample data was sent. The agent treated sample transfer as equivalent to ordinary data transfer, without recognising the elevated sensitivity of malicious code in transit. Consequence: 7 zero-day exploits exposed on a third-party's uncontrolled infrastructure for up to 90 days, mandatory disclosure to the third party, emergency rotation of detection signatures, and regulatory notification under DORA Article 19 for the ICT-related incident.
Scope: This dimension applies to every AI agent that acquires, stores, analyses, executes, transfers, or disposes of malicious code samples, suspicious binaries, adversarial payloads, exploit code, proof-of-concept weaponisation artefacts, or any other digital material that could cause harm if released, executed, or exfiltrated from its intended containment environment. The scope covers all stages of the malware sample lifecycle: ingestion from external feeds or internal quarantine systems; storage in sample repositories; static and dynamic analysis including sandbox detonation; transfer between agents, analysts, or organisational units; and retention and disposal. The scope extends to AI agents that do not directly handle samples but issue commands or make decisions that cause other systems to handle samples — for example, an agent that instructs a sandbox to detonate a sample or an agent that approves sample sharing with an external party. Organisations that outsource malware analysis to third-party services remain within scope — they must verify that the third party's handling controls meet or exceed the requirements of this dimension. The scope includes both live samples (capable of execution) and inert samples (disassembled, defanged, or encrypted), because inert samples can be reconstituted to active state and therefore require lifecycle governance.
4.1. A conforming system MUST classify every malware sample and suspicious artefact according to a defined handling classification scheme that specifies, at minimum, three tiers: inert/defanged, contained-executable, and live/unrestricted, with explicit handling rules for each tier.
4.2. A conforming system MUST enforce that all malware samples are stored exclusively in designated containment-grade storage environments that prevent accidental or unauthorised execution, with write-execute separation enforced at the filesystem or hypervisor level.
4.3. A conforming system MUST require role-based access control for all sample repositories, granting access only to personnel and agent identities with a documented operational need, and conducting access reviews at intervals not exceeding 90 days.
4.4. A conforming system MUST encrypt all malware samples at rest using a minimum of AES-256 or equivalent strength, with encryption keys managed separately from the sample storage infrastructure.
4.5. A conforming system MUST enforce that all transfers of malware samples — between agents, between agents and analysts, between organisational units, or to external parties — occur only over encrypted channels with mutual authentication, and that every transfer is logged with source, destination, sample identifier, classification tier, timestamp, and authorising identity.
4.6. A conforming system MUST validate containment integrity before any sample execution or detonation, confirming that the execution environment meets defined isolation requirements (network segmentation, snapshot-revertible state, resource limits) and rejecting execution if validation fails.
4.7. A conforming system MUST enforce a defined retention policy for malware samples that specifies maximum retention periods by classification tier, mandates periodic review of retained samples, and requires cryptographic destruction of samples that exceed their retention period or are no longer required for active analysis.
4.8. A conforming system MUST log all sample lifecycle events — ingestion, classification, storage, access, execution, transfer, reclassification, and disposal — in an append-only audit trail that satisfies the requirements of AG-055 (Audit Trail Immutability & Completeness).
4.9. A conforming system SHOULD implement automated defanging or encryption-wrapping of samples upon ingestion, converting live samples to contained-executable or inert status by default, with explicit re-activation requiring elevated authorisation.
4.10. A conforming system SHOULD enforce dual-authorisation (two distinct identities) for any operation that elevates a sample from inert or contained-executable to live/unrestricted status, or that transfers a live sample to an external party.
4.11. A conforming system SHOULD integrate sample handling telemetry with the organisation's security information and event management (SIEM) infrastructure to enable real-time detection of anomalous sample access patterns, bulk exfiltration attempts, or containment escapes.
4.12. A conforming system MAY implement automated sample provenance tracking that records the complete chain of custody from original source through every transformation, copy, and transfer, enabling forensic reconstruction of how any sample reached its current state and location.
Malware samples occupy a unique position in information security: they are simultaneously essential defensive assets and inherently dangerous offensive weapons. A well-curated sample repository enables signature development, threat hunting, incident attribution, and adversary technique analysis. The same repository, if improperly controlled, provides an attacker — whether an external adversary who compromises access or an insider who abuses it — with a pre-sorted arsenal of proven offensive tools. This dual-use nature demands governance controls that exceed those applied to ordinary sensitive data.
The threat model for malware handling encompasses five distinct risk vectors. First, accidental execution: a sample escapes containment and executes on a system connected to the production environment. This is the most common failure mode and typically results from inadequate storage controls — samples stored on general-purpose file systems without execution restrictions, or samples extracted from encrypted archives for analysis and not returned to containment after analysis completes. Second, unauthorised access: individuals or agent identities without operational need gain access to sample repositories, either through over-permissioned access control lists, credential reuse, or stale accounts. The risk is exfiltration of weaponisable material. Third, uncontrolled transfer: samples are transmitted over channels that do not meet confidentiality requirements, exposing sample content to interception. Unlike ordinary confidential data, intercepted malware samples provide the interceptor with immediately usable offensive capability. Fourth, indefinite retention: samples accumulate without disposal governance, creating an ever-growing repository whose risk profile increases with size while the defensive value of individual samples decays as signatures mature and threat actors evolve their tooling. Fifth, containment failure during analysis: sandbox environments used for dynamic analysis are inadequately isolated, allowing a sample under analysis to interact with production systems or exfiltrate data through permitted network paths.
AI agents amplify each of these risks because they operate at machine speed and volume. A human analyst handling 20 samples per day creates limited exposure if any single handling step is deficient. An AI agent processing 2,000 samples per day multiplies the exposure by two orders of magnitude. The agent's fallback logic, error handling, and default behaviours must all be governance-aware — a single misconfigured fallback path (as in Scenario A) can expose the organisation to mass compromise. Additionally, AI agents lack the contextual awareness that a human analyst brings to handling decisions. An analyst instinctively recognises that placing a live dropper on a general-purpose file share is dangerous. An agent follows its configured logic, and if that logic lacks containment validation, the agent will execute the dangerous action without hesitation.
The regulatory environment reinforces the need for formal governance. DORA Article 9 requires financial entities to implement ICT risk management frameworks that address threats including malware. The EU AI Act's risk management provisions under Article 9 require that risks are identified and mitigated — an AI agent handling malware without containment governance is an unmitigated risk. National cybersecurity directives, including NIS2, impose incident notification obligations that malware handling failures can trigger. Defence sector regulations, including ITAR and national classified information handling requirements, impose specific obligations on the handling of offensive cyber capabilities that malware samples may constitute.
Malware sample handling governance requires controls that span infrastructure (containment-grade storage, isolated execution environments), process (classification, access review, retention management), and agent behaviour (pre-action validation, encrypted transfer enforcement, lifecycle logging). The core architectural principle is defence in depth: no single control failure should result in sample escape, exposure, or weaponisation.
Recommended patterns:
noexec mount options on Linux, Software Restriction Policies or AppLocker rules on Windows) and network isolation from production systems. Live/unrestricted samples — if retained at all — require air-gapped or hardware-isolated storage with physical access controls. Agent write operations must validate the target tier before depositing a sample, rejecting writes to any destination that does not meet the required containment level.Anti-patterns to avoid:
Financial Services. Financial SOCs handle malware targeting payment systems, SWIFT infrastructure, and customer-facing platforms. Samples may contain payment card data or authentication credentials harvested from compromised systems. Sample handling must account for PCI DSS requirements regarding storage of cardholder data and DORA requirements for ICT incident management. Retention policies should align with regulatory examination cycles — typically 5 to 7 years for material incidents.
Defence and Government. Government and defence organisations may handle samples classified under national security frameworks. Malware attributed to nation-state actors may itself be classified. Handling controls must align with the applicable classification scheme (e.g., UK Official-Sensitive, US CUI, NATO Restricted). Cross-border sample sharing is subject to export control and information sharing agreements. AI agents operating in classified environments must enforce handling markings as part of the sample metadata.
Healthcare. Healthcare organisations face ransomware targeting clinical systems and medical devices. Malware samples from healthcare incidents may contain protected health information (PHI) extracted during the attack. Sample handling must account for HIPAA requirements — PHI embedded in malware payloads or network captures must be identified and protected under the same controls as other PHI, even though it exists within a malicious artefact.
Critical Infrastructure. Organisations operating industrial control systems (ICS) and operational technology (OT) networks handle malware targeting programmable logic controllers, SCADA systems, and safety instrumented systems. These samples may have physical-world consequences if executed in an inadequately isolated environment. Containment requirements for ICS/OT malware must include complete air-gapping from operational networks, not merely logical segmentation.
Basic Implementation — The organisation has defined a sample classification scheme with at minimum three tiers. Malware samples are stored in designated repositories with execution restrictions. Role-based access control is enforced with documented access lists. Samples are encrypted at rest. All transfers use encrypted channels. A retention policy exists. Sample lifecycle events are logged. Access reviews occur at least quarterly. This level meets the minimum mandatory requirements.
Intermediate Implementation — All basic capabilities plus: an automated ingestion gateway classifies and defangs samples upon receipt. Pre-execution containment validation is automated — agents verify sandbox isolation before submission. Dual-authorisation is required for elevating sample classification to live/unrestricted. Sample handling telemetry feeds the SIEM for anomaly detection. Retention enforcement is automated with analyst-approved disposal. Access reviews are partially automated with identity lifecycle integration.
Advanced Implementation — All intermediate capabilities plus: full sample provenance tracking from source through every transformation and transfer. Automated containment breach detection with kill-switch capability — if a sandbox containment failure is detected, the system automatically isolates the affected environment within seconds. Cross-organisational sample sharing follows machine-readable sharing agreements (e.g., STIX/TAXII with TLP enforcement). Independent audit of sample handling controls is conducted annually. Metrics demonstrate that no sample has escaped containment, been accessed by unauthorised identities, or exceeded retention periods without review in the audit period.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Sample Classification Enforcement
Test 8.2: Containment-Grade Storage Enforcement
Test 8.3: Access Control and Review Cycle Verification
Test 8.4: At-Rest Encryption Verification
Test 8.5: Transfer Encryption and Logging Verification
Test 8.6: Pre-Execution Containment Validation
Test 8.7: Retention Policy Enforcement and Disposal Verification
Test 8.8: Lifecycle Audit Trail Completeness
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Supports compliance |
| EU AI Act | Article 15 (Accuracy, Robustness and Cybersecurity) | Direct requirement |
| DORA | Article 9 (Protection and Prevention) | Direct requirement |
| DORA | Article 19 (ICT-Related Incident Notification) | Supports compliance |
| NIS2 Directive | Article 21 (Cybersecurity Risk-Management Measures) | Direct requirement |
| NIST AI RMF | MANAGE 2.4 (Risk Mitigation Activities) | Supports compliance |
| NIST CSF | PR.DS (Data Security), PR.AC (Access Control) | Direct requirement |
| ISO 42001 | Clause 6.1.3 (AI Risk Treatment), Annex A | Supports compliance |
| ISO 27001 | A.12.2 (Protection from Malware), A.8.3 (Media Handling) | Direct requirement |
Article 15 requires that high-risk AI systems achieve an appropriate level of cybersecurity, including resilience against attempts to alter their use, behaviour, or performance by exploiting system vulnerabilities. An AI agent that handles malware samples without adequate containment governance is itself a cybersecurity vulnerability — a compromised or misconfigured sample handling agent could be leveraged to deploy malware against the systems it is meant to protect. AG-703 ensures that the agent's malware handling operations do not introduce the very cybersecurity risks that the agent is deployed to mitigate, directly supporting Article 15's requirement for cybersecurity resilience.
DORA Article 9 requires financial entities to implement ICT security policies and procedures to protect ICT assets, including mechanisms to prevent the installation or propagation of malicious software. Malware sample handling by security operations agents is a controlled exception to the general prohibition on malicious software — samples must exist within the security operations environment for defensive purposes, but they must be handled under governance controls that prevent them from becoming the very threat they are meant to counter. AG-703 provides the specific governance framework for this controlled exception, ensuring that financial entities can demonstrate to regulators that their sample handling practices are deliberate, contained, and auditable rather than ad hoc.
NIS2 Article 21 requires essential and important entities to implement cybersecurity risk-management measures that are proportionate to the risk. For organisations whose security operations involve malware sample handling, the handling itself is a cybersecurity risk that requires management. A weaponisable sample archive with inadequate access controls is a risk. An agent that transfers samples over unencrypted channels is a risk. AG-703 addresses these risks specifically, providing the proportionate measures that NIS2 requires for this domain.
The NIST Cybersecurity Framework's Protect function includes Data Security (PR.DS) and Access Control (PR.AC) categories. Malware samples are data assets that require protection commensurate with their potential impact. PR.DS-1 (data at rest is protected) maps directly to Requirement 4.4 (encryption). PR.DS-2 (data in transit is protected) maps to Requirement 4.5 (encrypted transfer). PR.AC-1 (identities and credentials are issued and managed) maps to Requirement 4.3 (role-based access control). AG-703 applies these general NIST CSF principles to the specific context of malware sample handling.
ISO 27001 Annex A control A.12.2 requires protection against malware, while A.8.3 addresses media handling procedures. Malware sample repositories are a form of controlled media containing known-malicious content. The handling procedures must ensure that the protective intent of sample retention — enabling defensive analysis — does not create a media handling vulnerability. AG-703 specifies the governance controls that bridge A.12.2's protective intent with A.8.3's procedural requirements for the specific case of deliberately retained malicious content.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | Organisation-wide to sector-wide — a containment failure can compromise the entire enterprise network; a weaponisable archive breach can arm adversaries against the organisation and its peers |
Consequence chain: Malware sample handling governance failure initiates a consequence chain with escalating severity. The initial failure occurs at one of five points: a sample is stored without containment (Requirement 4.2 failure), an unauthorised identity accesses the repository (4.3 failure), a sample is transmitted in cleartext (4.5 failure), a sample executes in an inadequately isolated environment (4.6 failure), or a weaponisable archive accumulates without retention governance (4.7 failure). Each initial failure leads to a distinct but equally severe consequence pathway. A containment storage failure results in accidental execution, which — given the nature of the samples — means the execution of proven, known-effective malware on the organisation's infrastructure. The resulting compromise is not hypothetical; the sample was already known to be malicious, and its capabilities are documented in the threat intelligence that accompanied it. An access control failure results in exfiltration of offensive capabilities, which — depending on the sophistication of the samples — could range from commodity ransomware (nuisance-level impact on the adversary's capabilities) to nation-state APT tooling (strategic-level impact). A transfer encryption failure exposes samples to interception by any party with access to the network path, creating an uncontrolled distribution of offensive capabilities. A containment validation failure during analysis allows the sample to interact with production systems from within the ostensibly controlled analysis environment. A retention failure creates an ever-growing repository whose risk compounds over time while its defensive value decays. In the most severe cases, a single governance failure can lead to a breach that exceeds the harm the security operations function was established to prevent — the defenders' tools become the attacker's weapons. Regulatory consequences are severe because the organisation cannot claim ignorance of the risk: it deliberately acquired, stored, and retained the malicious material, and the obligation to control it is inherent in the decision to possess it.
Cross-references: AG-001 (Operational Boundary Enforcement) constrains the agent's operational scope, preventing sample handling agents from acting outside their defined security operations mandate. AG-004 (Action Rate Governance) limits the volume of sample operations an agent can perform in a given period, preventing runaway ingestion or mass transfer. AG-007 (Governance Configuration Control) ensures that sample handling policies are themselves change-controlled. AG-008 (Governance Continuity Under Failure) ensures that containment controls survive agent failures — if the agent crashes mid-analysis, containment must not degrade. AG-019 (Human Escalation & Override Triggers) defines when sample handling decisions require human intervention. AG-029 (Data Classification Enforcement) provides the broader classification framework that the sample classification scheme in 4.1 specialises. AG-036 (Data Retention & Disposal Governance) provides the general retention framework that 4.7 applies to malware samples. AG-042 (Encryption & Cryptographic Control Governance) provides the encryption standards that 4.4 and 4.5 reference. AG-043 (Access Control & Credential Governance) provides the access control framework that 4.3 applies to sample repositories. AG-055 (Audit Trail Immutability & Completeness) defines the audit trail standards that 4.8 requires for lifecycle logging. AG-700 (Containment Blast-Radius Governance) addresses broader containment principles that apply when sample handling containment fails. AG-702 (Exploit Simulation Boundary Governance) governs the boundaries of exploit execution that overlap with sandbox detonation in sample analysis. AG-707 (Offensive Capability Restriction Governance) restricts access to offensive capabilities, which malware samples may constitute.