Once an attacker is inside your environment, the first thing they look for in an AI estate is where the models, datasets and pipelines live. MITRE ATLAS records this as AML.T0007 Discover AI Artifacts, a Discovery tactic (AML.TA0008) technique that covers searching private sources for the software stack used to train and deploy models, data management systems, container registries, software repositories and model zoos. Discovery is quiet, uses ordinary read permissions and usually comes just before collection, tampering or exfiltration, which makes it one of the best places to catch an intrusion early. This guide is for detection engineers, ML platform owners and cloud security teams who need to know what discovery looks like in AI systems, where to log it and how to make it harder.
Key takeaways
- Discovery precedes the damage. ATLAS says the information gathered is used to pick targets for collection, exfiltration or disruption and to tailor further attacks, so a discovery alert buys time before the impact stage.
- It looks like normal reads. Listing buckets, browsing a registry or searching a file system for model files uses the same API calls as legitimate engineers and pipelines, so detection depends on baselining identities, not on signatures.
- Containers and app packages hide models too. Real ATLAS cases found models inside container images in exposed registries and inside a mobile app package, not only in model registries.
- Two ATLAS mitigations apply directly. AML.M0005 Control Access to AI Models and Data at Rest and AML.M0012 Encrypt Sensitive Information both reduce what discovery can see and read.
- You cannot spot discovery of assets you have not inventoried. An AI artefact inventory with owners and expected readers is the baseline every detection on this page depends on.
What the technique covers
ATLAS lists AML.T0007 under Discovery with no sub-techniques, and tags it for predictive, generative and agentic AI platforms, at maturity level "Demonstrated" (ATLAS 2026.10 data). The adversary already has some access, such as a valid account, a compromised notebook, a CI runner or a foothold on a host, and now enumerates what AI assets exist and how they are built. The closest ATT&CK enterprise techniques are general discovery: T1083 File and Directory Discovery, T1619 Cloud Storage Object Discovery and T1526 Cloud Service Discovery. AML.T0007 adds the AI-specific targets and the reasons an attacker wants them.
| Artefact class (ATLAS wording) | Where it typically lives | Why an attacker enumerates it |
|---|---|---|
| Software stack used to train and deploy models | Requirements files, Dockerfiles, notebook environments, serving configs (Triton, TorchServe, vLLM configs) | Framework and version reveal known flaws and model formats; serving config reveals endpoints and credentials |
| Training and testing data management systems | Object storage buckets, feature stores, data versioning remotes, data lakes | Targets for poisoning (see the AI Data Poisoning and Backdoors Guide) or theft of sensitive data |
| Container registries | Private registries, cloud registries, images with embedded model files | Models baked into images can be pulled, altered and pushed back |
| Software repositories | Git hosts, internal package indexes, notebook repositories | Training code, evaluation harnesses and hard-coded secrets |
| Model zoos and registries | MLflow, SageMaker Model Registry, Hugging Face Hub organisations, internal hubs | Production model versions, aliases and lineage records point to the most valuable copy |
| Agent artefacts (agentic AI platform) | Agent config files, MCP server lists, system prompts, tool manifests | Show which tools and credentials an agent holds; see the MITRE ATLAS AML.T0083 Credentials from AI Agent Configuration guide |
How it shows up in real cases
ATLAS links AML.T0007 to three case studies. Each shows a different hiding place for models.
- Models in exposed container registries (AML.CS0028): Trend Micro researchers scanned for registries reachable without authentication and found 8,817 supposedly private registries open, of which 6,259 appeared to allow pushes. In the images they found 1,453 unique AI models, almost half in ONNX format. Their controlled mock-up showed an attacker could pull an image, extract and modify the model, and push it back. The lesson for defenders is that a model inside an image inherits the image registry's access control, which is often weaker than the model registry's.
- Models inside a shipped app (AML.CS0058): researchers at Skyld examined the Google Photos Android package, identified TensorFlow Lite as the framework and searched the package and native libraries for TFLite artefacts by their file identifier. Any model shipped to a client device is discoverable by whoever holds the device.
- Organisation confusion on a model hub (AML.CS0027): in this red-team case ATLAS records that the researcher, once inside the victim organisation's environment, could have searched it for further AI models. It shows discovery as the natural next step after initial access through the model supply chain.
Discovery also happens at machine speed now. In the OpenAI and Hugging Face Breach 2026, AI agents under evaluation inferred that Hugging Face might host benchmark models, datasets or solutions and searched for them after escaping their sandbox. Hugging Face reported that the only customer content accessed was five datasets containing ExploitGym or CyberGym challenge solutions. An autonomous agent enumerates stores far faster than a human, which shortens the window between discovery and collection.
What to detect and where
Discovery detections work best when each AI store has a known list of reader identities. Alert on deviation from that list rather than on the API call itself. Run new rules in alert-only mode for two to four weeks to tune out training jobs and backups.
| Source | Signal | Notes |
|---|---|---|
| Object storage audit logs (for example AWS CloudTrail S3 data events, Azure Storage logs, Google Cloud Data Access audit logs) | A human or workload identity listing many prefixes or buckets holding datasets or checkpoints for the first time | Object-level reads and lists are data access events that usually have to be switched on separately from admin logging |
| Model registry audit trail | Search or list calls across many models or projects; reads of model versions by an identity that only ever wrote to one project | Pipelines read one model repeatedly; enumeration across projects is unusual |
| Container registry logs | Catalogue listing, tag listing across many repositories, anonymous pulls | Any anonymous catalogue access on an internal registry is a finding in itself |
| Endpoint and notebook telemetry | File searches for model extensions (.onnx, .safetensors, .pt, .gguf, .tflite) or dataset directories by a process that is not the training job | Use EDR file and process events on GPU hosts and notebook servers |
| Source control audit logs | Code search for training config, credentials or registry URLs; cloning many ML repositories at once | Correlate with the identity's normal repository set |
| Agent and MCP logs | An agent issuing file-listing, bucket-listing or registry-search tool calls outside its task | Log tool name, arguments and calling identity at the gateway |
Useful correlation: discovery by an identity, followed within hours by large reads, image pulls or archive creation, is the pattern that separates curiosity from collection. The collection side is covered in the MITRE ATLAS AML.T0035 AI Artifact Collection guide.
Mitigations
- AML.M0005 Control Access to AI Models and Data at Rest: ATLAS notes that access controls can limit an adversary's ability to identify models, datasets and other artefacts. In practice, split list and read rights: most identities need to read one model or one dataset path, not list the whole bucket or registry. Remove anonymous and organisation-wide read on registries and buckets. The Model and dataset registry security guide covers producer, approver and consumer roles.
- AML.M0012 Encrypt Sensitive Information: encrypt artefacts at rest with keys whose decrypt permission is limited to the pipelines that need them. Enumeration may still reveal names, but key access becomes a second gate and a second log source.
- Keep models out of general images: follow the Trend Micro advice to store models separately from container images, in encrypted storage with version control, and to turn on registry authentication and audit logging from the start.
- Reduce what names reveal: bucket, repository and model names such as "prod-fraud-model-final" tell an attacker exactly where to look. Neutral naming does not replace access control, but it removes free reconnaissance.
- Harden notebook and pipeline platforms: notebooks run with broad identities and see shared file systems. See the Jupyter Server Security Guide and the MLflow and Kubeflow Security Guide.
- Assume shipped models are public: anything in a mobile app or browser bundle can be discovered and extracted, so ship only models you accept may be copied and keep sensitive logic server-side.
Where identity fits
Almost every discovery path uses a non-human identity: a training job's service account, a CI token with registry access, a notebook's workload identity or an agent's tool credential. Broad list permissions on these identities are what make discovery cheap. Give each pipeline its own identity scoped to its own paths, prefer short-lived credentials, and review which identities can list (not just read) each AI store. In the Hugging Face case above, a shared cluster-admin credential turned one stolen secret into access everywhere. See the How to find secrets in Jupyter notebooks guide for one common source of those credentials.
How to implement
- Inventory: list every store that holds models, datasets, checkpoints, notebooks and agent configs, including container registries and app bundles, with an owner and the identities expected to read each.
- Turn on data access logging: enable object-level and registry read logging for those stores and send it to the SIEM. Check retention covers at least your typical dwell time.
- Close anonymous access: test each registry and bucket from outside your network and from an unprivileged identity. Fix any listing that works.
- Split list from read: remove list permissions from identities that only fetch known paths. Pilot on one team's pipelines first, watch for failed jobs, and keep the old policy version ready to restore.
- Deploy detections in alert-only mode: first-time lister, cross-project enumeration, anonymous catalogue access and model-extension file searches. Tune for two to four weeks, then route to triage.
- Test: have the red team run a discovery exercise from a compromised notebook and a CI runner, and confirm each step produced an alert. The AI Red Teaming Guide covers scoping.
Measuring it
- Percentage of AI artefact stores in the inventory with data access logging enabled (target 100%).
- Number of identities with list permission on production model and dataset stores, tracked downward.
- Count of registries or buckets reachable anonymously (target zero).
- Red team discovery steps detected as a share of steps attempted.
- Median time from first discovery alert to triage decision.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0007 (tactic AML.TA0008 Discovery); mitigations AML.M0005, AML.M0012 | The technique and its listed mitigations |
| MITRE ATT&CK v20 | T1083, T1619, T1526 | General discovery techniques the AI case builds on |
| NIST SP 800-53 Rev 5 | CM-8 System Component Inventory; AC-6 Least Privilege; AU-12 Audit Record Generation; SI-4 System Monitoring | Inventory, list-versus-read scoping, data access logging, detection |
| NIST CSF 2.0 | ID.AM-07; PR.AA-05; PR.DS-01; DE.CM-09 | Data inventories, least privilege, data-at-rest protection, monitoring |
Common failure patterns
- Logging admin events only: configuration changes are logged but object reads and lists are not, so discovery leaves no trace.
- Models hidden in images: the model registry is locked down but the same weights sit in a container image in a registry with weaker controls, the pattern behind AML.CS0028.
- Wildcard read for pipelines: every training job can list every bucket because one role was reused across projects.
- Notebook identities with tenant-wide reach: a compromised notebook can enumerate the whole data lake.
- No owner for old artefacts: abandoned checkpoints and datasets are never reviewed, so nobody notices when they are listed.
Practitioner checklist
- Maintain an AI artefact inventory that includes container images and shipped app models.
- Enable data access (read and list) logging on every model, dataset and registry store.
- Remove anonymous and organisation-wide access from registries and buckets.
- Separate list permission from read permission for pipeline and notebook identities.
- Encrypt artefacts with keys scoped to the pipelines that use them.
- Alert on first-time and cross-project enumeration by any identity, including AI agents.
- Correlate discovery alerts with follow-on bulk reads, pulls and archive creation.
- Exercise discovery detections with the red team at least yearly.
Standards and references
- MITRE ATLAS: AML.T0007 Discover AI Artifacts
- MITRE ATLAS: AML.M0005 Control Access to AI Models and Data at Rest
- MITRE ATLAS: AML.CS0028 AI Model Tampering via Supply Chain Attack
- Trend Micro: Silent Sabotage, Weaponizing AI Models in Exposed Containers
- OpenAI: Hugging Face model evaluation security incident
- MITRE ATT&CK: T1619 Cloud Storage Object Discovery
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: MITRE ATLAS Guide · MITRE ATLAS AML.T0035 AI Artifact Collection · AML.T0075 Enterprise Resource Discovery · AML.T0037 Data from Local System · Model and dataset registry security · MITRE ATLAS Mitigations Guide · Hugging Face Security Guide