When model weights turn up somewhere they should not be, or a competitor's model starts answering suspiciously like yours, most organisations have no procedure for proving what was taken, stopping further loss and preserving the legal options that depend on acting quickly. Model theft has two very different shapes. Weight theft is a classic exfiltration of files, usually through a stolen credential, an over-privileged pipeline identity or an insider. Extraction or distillation is theft through the front door: someone queries your model API at scale and trains a copy from the outputs. This playbook is a ready-to-adapt procedure for both, written for AI platform, security operations, legal and product teams. Prevention is covered in the Securing AI Model Weights Guide and the Model Extraction Defence Guide; this page is what to do once you suspect a loss.
How to use this template
- Replace text in square brackets, such as [Organisation], [AI platform team], [SOC], [Legal counsel] and [Model owner], with your own names, and complete the contact table in Section 2 before you need it.
- Attach this playbook to your main incident response plan as an annex. See the Incident Response Plan Template.
- Decision points are marked Decision: with the owning role. Evidence steps are marked Evidence: and come before the containment step that follows them, because many legal remedies depend on evidence collected before accounts are suspended.
- Run Track A (weight theft) or Track B (extraction) from Section 3 onwards, or both if the route is unclear.
- This playbook describes defensive and legal steps only. Legal points are summaries for planning, not legal advice; your counsel decides what applies in your jurisdiction.
1. Scope and triggers
1.1 This playbook covers suspected unauthorised acquisition of any [Organisation] model asset: trained or fine-tuned weights, adapters (for example LoRA files), checkpoints, quantised builds, tokenisers, system prompts and training recipes, and functional copies created from model outputs.
1.2 Invoke it on any of these triggers:
- Weights or checkpoints, or files with matching hashes, found on a public hub, file share, torrent or third-party server.
- Large or unusual reads of model storage, registry downloads or snapshot copies by an identity that does not normally perform them.
- A leaked credential with read access to model storage, the model registry or training infrastructure.
- An employee or contractor leaver who had weight access and shows unusual transfers before departure.
- Inference traffic patterns consistent with extraction: high-volume systematic prompts, coverage of a capability space, requests for full probability outputs, or clusters of linked accounts.
- A third-party model that reproduces your model's distinctive outputs, refusals, watermarks or canary responses.
1.3 The ATLAS techniques most relevant are AML.T0025 Exfiltration via Cyber Means and AML.T0048.004 AI Intellectual Property Theft for weight theft, and AML.T0024 Exfiltration via AI Inference API, AML.T0024.002 Extract AI Model and AML.T0005.001 Train Proxy via Replication for extraction. OWASP now covers model extraction and functional model replication under LLM10:2025 Unbounded Consumption.
2. Roles and contacts
| Role | Responsibility | Name and contact |
|---|---|---|
| Incident lead | Runs the playbook, owns the timeline and decision log | [Name, phone] |
| Model owner | Confirms what the asset is, its versions, value and where copies should exist | [Name] |
| AI platform team | Storage, registry, training cluster and inference gateway logs and changes | [Team, on-call] |
| SOC | Identity, endpoint, network and cloud telemetry; containment actions | [On-call] |
| Legal counsel | Legal hold, privilege, trade secret and contract remedies, regulator and law enforcement decisions | [Name, external firm] |
| HR | Employee or contractor actions where an insider is suspected | [Name] |
| Trust and safety or abuse team | Account clusters, terms of service enforcement, payment data (Track B) | [Name] |
| Communications | Internal and external statements, customer questions | [Name] |
Decision: [Legal counsel] decides at the start whether the investigation runs under legal privilege and who may see findings. Record the decision.
3. Detection and triage
3.1 Within [2 hours], answer these questions and record each answer with its source:
- Which asset and which versions? Identify by registry entry and file hash, not by name.
- Route: weight theft (Track A), extraction (Track B), or unknown?
- Is loss continuing? Is the credential, account or path still active?
- Which identities touched the asset in the relevant window, human and non-human?
- Does the asset contain or reveal personal data, customer data or third-party licensed material?
- Does the model carry obligations to others: a customer contract, a licence, or EU AI Act duties as a general-purpose AI model with systemic risk?
3.2 Severity:
| Severity | Example | Response |
|---|---|---|
| Critical | Frontier or core commercial model weights confirmed outside your control; loss continuing | Full team, executive sponsor, legal within [1 hour] |
| High | Confirmed theft of fine-tuned weights or adapters; or confirmed extraction campaign against a core model | Full team, legal within [4 hours] |
| Medium | Credential with weight access exposed, no evidence of use; or suspicious query cluster under investigation | SOC and AI platform team, legal informed |
| Low | Public or open-weight model copied within its licence terms | Model owner review; close or monitor |
Evidence: before any change, export and hash the relevant storage access logs, registry download logs, cloud audit logs, identity provider sign-ins, inference gateway logs and billing records, and place them under legal hold. See the Evidence Handling and Chain of Custody Guide and the Legal Hold Notice Template.
4. Containment
Track A: weight theft
- Evidence: snapshot the access policies, role assignments and bucket or registry permissions as they stand.
- Revoke or rotate every credential that could read the asset and was used in the window: user sessions, service account keys, access tokens, registry tokens and CI/CD secrets. Prefer revocation of sessions plus rotation of keys, not only password resets.
- Remove broad read grants on model storage and restrict to a break-glass group while the investigation runs.
- Block the destinations seen in egress logs and pause any replication or sync jobs that copy weights to other locations.
- Where an insider is suspected, coordinate with HR and [Legal counsel] before any action that alerts the person. See the Insider Data Theft Response Playbook.
- Decision: [Legal counsel] decides whether to request removal from a hosting platform now (takedown under the host's policy) or to first preserve evidence of the copy, its uploader and download counts.
Track B: extraction or distillation
- Evidence: export account records, API keys, payment details, request and response logs, and samples of outputs for every account in the suspected cluster before suspension.
- Map the cluster through shared attributes (payment instruments, IP ranges, organisation identifiers, prompt templates) so you act on the whole network at once.
- Suspend or rate-limit the cluster together, rotate any keys shared with resellers or partners, and watch for re-registration.
- Reduce what each response gives away where your product allows, for example removing full probability outputs for untrusted tiers, as an interim measure owned by the product team.
5. Eradication
- Establish the root cause: which identity or path gave access, and why it had it. Common causes are long-lived service account keys, broad storage roles for training jobs, weights copied to developer laptops or notebooks, and insufficient egress control on training clusters.
- Remove standing access to weights for humans; move to just-in-time, approved access with recording. Scope non-human identities to the single bucket, prefix or registry project they need.
- Find and remove unmanaged copies: notebooks, scratch buckets, old checkpoints, laptop caches and partner environments. RAND's report on securing model weights recommends consolidating weight copies into a small number of access-controlled, monitored systems.
- For Track B, close the account-creation and payment routes the cluster used and add detection for the query patterns seen.
6. Recovery
- Restore normal access only through the new access model, with owners and review dates for every identity.
- Verify the integrity of the production model and registry entries against known-good hashes or signatures before declaring recovery, in case the attacker also altered files. See the Model Signing and OpenSSF Model Signing Guide.
- Decision: [Model owner] and [Executive sponsor] decide whether the stolen version changes product or commercial plans, such as accelerating the next release or changing pricing for exposed capabilities.
- Monitor for the stolen model's appearance on hubs and file sharing sites, and for renewed extraction patterns, for at least [90 days].
7. Legal steps and notification
7.1 Trade secret remedies depend on showing the model was a protected secret and that you acted promptly. [Legal counsel] leads; the points below are planning summaries of the primary texts.
| Regime | What it provides | What the response team must supply |
|---|---|---|
| EU Trade Secrets Directive (EU) 2016/943 | Article 2(1): information is a trade secret if it is secret, has commercial value because it is secret, and is subject to reasonable steps to keep it secret. Article 4(2)(a): unauthorised access to or copying of files is unlawful acquisition. Article 10: provisional measures including stopping use and seizure of infringing goods. Article 12: orders after a decision, including destruction or delivery up of files. Article 14: damages. Article 8 caps national limitation periods at six years. | Evidence of the access controls, NDAs and classification that show "reasonable steps"; the access and egress logs; asset value estimates |
| US Defend Trade Secrets Act, 18 U.S.C. 1836 | Civil action in federal court; ex parte civil seizure only in extraordinary circumstances on specific findings; injunctions; damages for actual loss and unjust enrichment or a reasonable royalty; up to two times damages for wilful and malicious misappropriation; action within three years of discovery | A precise description of the asset and where copies are; evidence the defendant holds it; evidence it would be destroyed or hidden if notice were given |
| Contract and terms of service | Breach of licence, API terms or employment and contractor agreements, often the fastest route for Track B and insider cases | Signed agreements, accepted terms versions, account records |
7.2 Notification triggers to assess:
- Personal data: if training data or outputs that left include personal data, assess GDPR Article 33: the controller must notify the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach, unless it is unlikely to result in a risk to people's rights and freedoms. See the Data Breach Notification Checklist.
- EU AI Act, systemic-risk GPAI providers: Article 55(1)(c) requires tracking, documenting and reporting serious incidents to the AI Office without undue delay, and 55(1)(d) requires adequate cybersecurity protection for the model and its physical infrastructure. Commitment 9 of the Safety and Security chapter of the General-Purpose AI Code of Practice covers serious incident reporting; see the EU General-Purpose AI Code of Practice Guide and confirm the current text before relying on it.
- Customers and partners: contractual notice duties where a customer's fine-tuned model or data was involved.
- Law enforcement: [Legal counsel] decides whether to report; theft by a foreign state actor or organised group usually warrants it. See the Engaging Law Enforcement During a Cyber Incident Guide.
8. Post-incident review
8.1 Within [10 working days] of closure, hold a blameless review covering timeline, root cause, which detection fired and when, evidence quality, and legal outcome. Record actions with owners and dates.
8.2 Track these measures across incidents and exercises:
- Time from first signal to credential revocation.
- Share of identities with weight access that have an owner and a review date.
- Number of unmanaged weight copies found and removed.
- Time from extraction alert to whole-cluster suspension.
- Completeness of evidence packs handed to counsel (logs hashed, held and complete for the window).
Implementation guidance
- Prepare the evidence before the incident: retain storage access logs, registry downloads and inference logs long enough to cover a slow theft discovered months later; [Legal counsel] should set the period with the limitation periods above in mind.
- Make "reasonable steps" visible: classification labels on weights, access reviews, NDAs and recorded approvals are what a court looks at. See the Trade Secret Protection guide.
- Plant canaries: distinctive watermark or canary behaviours in your model make a functional copy easier to recognise later; keep their design confidential and documented for counsel.
- Treat model access as an NHI problem: most weight theft routes run through service accounts, CI/CD tokens and storage keys. Inventory them and remove long-lived keys. See the Securing the model registry itself guide and the planned If your model registry is compromised playbook.
- Small organisations: most consume third-party models; focus on protecting your fine-tuned adapters and API keys, and on Track B if you expose an API. Large model developers should rehearse both tracks with counsel at least [once a year].
- Framework alignment: NIST SP 800-61 Rev. 3 (incident response as a CSF 2.0 Community Profile); NIST SP 800-53 Rev. 5 IR-4 Incident Handling, IR-6 Incident Reporting, IR-8 Incident Response Plan, AC-2 Account Management, AC-6 Least Privilege, AU-9 Protection of Audit Information and SI-4 System Monitoring; NIST CSF 2.0 RS.MA-01, RS.AN-03, RS.MI-01, RS.CO-02 and RC.RP-03.
Sources: MITRE ATLAS · OWASP: LLM10:2025 Unbounded Consumption · RAND: Securing AI Model Weights · EUR-Lex: Directive (EU) 2016/943 on trade secrets · LII: 18 U.S.C. 1836 · AI Act Service Desk: Article 55 · NIST SP 800-61 Rev. 3. This playbook summarises legal provisions for planning and is not legal advice.
Related NHI Mgmt Group resources: Securing AI Model Weights Guide · Model Extraction Defence Guide · AI Model Security Guide · AI Model Poisoning Incident Playbook