1. What LLM10 Actually Is
Model theft is the unauthorized acquisition or replication of model value. Direct theft means copying weights, adapters, tokenizer files, or fine-tuned artifacts. Indirect theft means using an API to approximate behavior, recover sensitive training patterns, infer proprietary prompts, or build a competing model from outputs. The economics vary, but the defender's job is the same: reduce access, reduce extraction bandwidth, and increase detection probability.
Self-hosting changes the risk profile. You control the storage and network path, but you also run the registry, backups, GPU nodes, admin shells, observability pipeline, and artifact promotion process. A weak internal control can expose more model value than a public API would.
Theft is not only weights
Fine-tuned adapters, system prompts, retrieval corpora, eval sets, tokenizer changes, and response logs may reveal the defensible part of the system even when base weights are public.
2. Attack Shapes (Defanged)
Defensive detail only
This section avoids extraction recipes, query strategies, and operational exfiltration steps.
2.1 Weight or adapter exfiltration
An insider, compromised service account, exposed backup, or weak registry permission allows copying model artifacts. Large files make this visible if storage and network telemetry are monitored, but invisible if model stores are treated as ordinary shared folders.
2.2 API-based extraction
An attacker sends high-volume, systematic queries to approximate model behavior or harvest proprietary responses. The individual calls may look valid; the pattern is visible in volume, coverage, repetition, and account relationships.
2.3 Prompt and policy theft
The attacker tries to recover system prompts, tool schemas, guardrail policies, or routing logic through conversation. Even without weights, these assets reveal how to bypass or clone the application behavior.
2.4 Log and trace leakage
Observability stores can contain prompts, responses, retrieved context, and model identifiers. If traces are over-retained or broadly accessible, they become a second model-knowledge repository.
3. Blue-Team Detection
Model-theft detection combines data-loss prevention, identity analytics, storage monitoring, API abuse detection, and inference telemetry. The baseline is to know which principals can read artifacts and what normal artifact movement looks like.
| Signal | Why it matters | Response |
|---|---|---|
| Large artifact read by unusual principal | Possible weight or adapter staging | Block session, rotate credentials, inspect host |
| Model registry export outside release window | Artifact movement bypassing change control | Require approval and compare manifest |
| High-volume systematic API queries | Possible extraction attempt | Throttle, challenge, or suspend account |
| Repeated prompt-disclosure probes | Attempt to recover policy or tool schemas | Return safe refusal and alert |
| Trace access spike | Logs may be used as model-data source | Restrict trace access and review exports |
Map direct artifact theft to conventional MITRE ATT&CK collection/exfiltration behaviors and LLM-specific extraction to MITRE ATLAS. The investigation usually needs both views: host access tells you how files moved; model telemetry tells you whether behavior was extracted through the API.
4. Mitigation and Build Controls
- Artifact access control. Treat weights, adapters, tokenizers, and eval sets as crown-jewel assets. Use least privilege, just-in-time access, and separate duties for build, deploy, and operate.
- Encryption and key separation. Encrypt model stores and backups. Keep decryption keys away from broad application roles and CI workers that do not need raw artifacts.
- Immutable registries and signed manifests. Use digest-pinned releases so artifact movement is expected and auditable.
- API extraction controls. Rate-limit by tokens, task, account, and similarity. Detect systematic coverage patterns rather than only high request rates.
- Output watermarking and canaries. Where appropriate, include defensible markers or canary behaviors to support investigation. Do not rely on watermarking as the only control.
- Trace minimization. Redact secrets, shorten retention for sensitive prompts, and restrict trace export. Observability should not become an ungoverned model replica.
- Incident-ready rollback. If a fine-tuned model is stolen, know which downstream customers, deployments, prompts, and keys are affected.
# ILLUSTRATIVE - artifact access policy
resource: model_registry/prod/*
read_raw_artifact:
allowed_roles: [release_engineer]
requires_jit: true
requires_ticket: true
network_zone: build_subnet_only
serve_artifact:
allowed_roles: [inference_service]
raw_export: false
alert_on:
- bulk_download
- access_outside_release_window
- backup_restore_to_unapproved_host5. Mapping to WSTG, ATLAS, and Related LLM Risks
| Theft path | OWASP WSTG / ASVS lens | MITRE view | Related LLM risks |
|---|---|---|---|
| Raw artifact access | Authentication, authorization, secrets, and storage testing | ATT&CK collection/exfiltration; ATLAS model theft | LLM05 |
| API extraction | Rate limiting, abuse-case testing, and monitoring | ATLAS extraction through inference endpoint | LLM04, LLM09 |
| Prompt or tool schema disclosure | Information disclosure and access-control testing | Discovery through application interface | LLM01, LLM07 |
| Trace/log leakage | Logging, privacy, and data-retention testing | Collection from observability systems | LLM06 |
Model theft defense is not a single feature. It is a chain of storage security, deployment discipline, endpoint abuse controls, and incident response. If any link is informal, that is where the model value will leave.
Protect the Model Like a Crown-Jewel Asset
These risks are not solved by a policy paragraph. They need adversarial testing, defensive telemetry, and architecture changes that can be inspected. Use the AI red-teaming path to validate controls, the blue-team guide to operationalize detections, and the contact route to request a focused review.