---
title: "The Model Is Not the Target. The Pipeline Is."
description: "A field methodology for using MITRE ATLAS without turning an AI assessment into matrix theatre: map the production system, follow authority into tools and data, test reachable attack paths, and label the evidence only after impact is proven."
date: 2026-07-09
author: Sevban Dönmez (@jankesec)
canonical: https://jankesec.com/posts/mitre-atlas-methodology/
---
## MITRE ATLAS in 60 seconds
An AI security assessment can fail before the first request is sent.
The failure usually begins with scope. A team opens the MITRE ATLAS matrix, selects several
techniques that look relevant, and starts testing “the model.” The resulting report may contain
prompt injection, jailbreaks, unsafe output, model extraction, and training-data poisoning. It
may also miss the internet-facing API, the build identity that can replace a model, the retrieval
store containing secrets, and the agent tool that can approve a real transaction.
That is matrix theatre: broad technique coverage without a defensible account of how an attacker
reaches a meaningful outcome.
ATLAS is far more useful when it is applied in the opposite direction. First reconstruct the
production system. Then identify who can reach each component, what authority that component
holds, and where untrusted data becomes an instruction or an action. Test the reachable paths.
Only then use ATLAS to name what happened.
The model is one component. The attack path is the system.
## What ATLAS gives you—and what it does not
[MITRE ATLAS](https://atlas.mitre.org/) is a living knowledge base for adversary behavior against
AI-enabled systems. Its current public matrix covers Predictive AI, Generative AI, Agentic AI,
and Enterprise platforms. It also distinguishes techniques by maturity: *feasible* in research,
*demonstrated* in realistic conditions, or *realized* in observed operations.
Those distinctions matter. They stop a laboratory possibility from being presented as if it were
an established intrusion pattern. They also show that AI systems inherit ordinary enterprise
attack surface. ATLAS marks techniques adapted from ATT&CK and distributes explicit relationships,
mitigations, and case studies through its [versioned data repository](https://github.com/mitre-atlas/atlas-data).
But the matrix cannot answer the questions that decide risk in your environment:
- Is the inference route reachable from an untrusted network?
- Does the agent carry a service identity, a user identity, or both?
- Can retrieved content influence tool selection?
- Can a model artifact be replaced without an independent approval?
- Which secrets enter the prompt, memory, logs, or tracing system?
- Can an unsafe model decision produce an external side effect?
ATLAS supplies vocabulary and known behavior. The assessment still has to supply system context,
reachability, authority, and evidence.
## Start with six assets, not one model
“The AI application” is not a useful asset name. A production service is normally at least six
different security surfaces:
1. **Inputs and knowledge** — prompts, files, events, training data, retrieval documents, and memory.
2. **Build and evaluation** — source repositories, package installation, training jobs, test gates,
and deployment automation.
3. **Model and artifact storage** — weights, adapters, model registries, object storage, and signing data.
4. **Inference and orchestration** — model endpoints, routing, guardrails, prompt construction, and
agent planning loops.
5. **Tools and connected services** — browsers, code runners, ticketing systems, email, databases,
cloud APIs, and internal functions.
6. **The business application** — authentication, tenancy, authorization, billing, audit, and the
user-visible workflow.
Treat each as an independent asset. Record its owner, listener, data classification, identity,
and outbound access. If the team cannot name those five properties, the system is not ready for
technique selection.
A model-only scope ignores both sides of the real system: the application path that gives the model context and tools, and the control plane that can replace or impersonate it.
## The first map is data flow; the second is authority
A component diagram is necessary but incomplete. Two connected boxes do not tell you which side
can make a decision for the other. The second map records authority.
For every component, write down:
| Question | Why it changes the test |
| --- | --- |
| What input can an attacker influence? | Establishes the entry point: direct prompt, retrieved document, webhook, training sample, package, or model artifact. |
| Which identity handles that input? | Separates an untrusted user request from a privileged workload action. |
| What can that identity read? | Defines potential disclosure through prompts, retrieval, logs, memory, and tools. |
| What can it change or execute? | Defines impact: a generated sentence is different from a committed transaction or a deployed artifact. |
| Where is approval required? | Identifies whether the model can cross from recommendation into action without an independent decision. |
| What evidence survives? | Determines whether the conclusion can be reproduced and defended after the test. |
This map exposes the most important difference between a chatbot and an agent. A chatbot can emit
unsafe text. An agent may hold credentials, select a tool, supply parameters, and create a side
effect. The same prompt injection moves from content-quality risk to an authorization problem when
that authority is added.
Prompt injection becomes material when model output is accepted as authority. A separate policy decision—outside the model—must validate identity, tool, arguments, and approval.
## Divide the assessment into three lanes
The current ATLAS platform model makes a useful operational split possible. Do not run one large
“AI test.” Run three related lanes and join their results into attack paths.
### Lane 1 — inherited enterprise exposure
This is the infrastructure the AI service inherited: public applications, valid accounts, cloud
roles, CI/CD, artifact registries, secrets, network routes, and third-party dependencies. ATLAS
deliberately keeps these behaviors visible because adversaries do not stop using ordinary access
methods when the target contains a model.
Start here. An exposed orchestration endpoint or registry write role can make every sophisticated
model test irrelevant.
### Lane 2 — AI-native behavior
This lane covers the properties that arise from the AI component itself: adversarial inputs,
model access, extraction, evasion, data poisoning, prompt injection, sensitive-context leakage,
and unsafe output handling.
Test these against a named component and a stated capability. “The model can be jailbroken” is
not enough. Which policy was bypassed? Which data became available? Which downstream decision
trusted the output?
### Lane 3 — agentic authority
Agentic systems add planning, memory, tool discovery, parameter generation, and repeated actions.
The relevant surface includes context poisoning, tool poisoning, credential harvesting, tool
invocation, and exfiltration through a connected service.
The model is still not the authorization layer. The critical question is whether the system treats
a probabilistic model decision as permission to use a deterministic capability.
| Lane | First question | High-value proof | Common false positive |
| --- | --- | --- | --- |
| Enterprise | Can an attacker reach or impersonate a component? | Unauthorized access to a named service, identity, registry, or secret | Reporting a visible banner or model name without access impact |
| AI-native | Can crafted data change a protected model behavior? | Repeatable policy bypass, disclosure, integrity change, or measurable evasion | A strange response with no protected decision attached |
| Agentic | Can untrusted input cause a privileged tool action? | Bounded external side effect under the agent identity | The model merely describing a forbidden action |
## Use ATLAS after the hypotheses exist
Once the two maps are complete, technique selection becomes precise. Each test hypothesis should
contain four parts:
> **Entry point → component → authority → observable effect**
Examples:
- A public file is retrieved into agent context → the orchestrator treats its content as an
instruction → the workload identity invokes a ticketing tool → an unauthorized ticket change
appears in the audit log.
- A developer token reaches the model registry → an unsigned adapter is promoted → the inference
deployment loads it → a known evaluation case changes while the negative control does not.
- A tenant-controlled document enters shared retrieval → another tenant's session retrieves it →
the model exposes the planted marker → tenant separation is disproved without accessing real data.
Now ATLAS labels help. The first path may involve prompt injection, context poisoning, tool
invocation, and a conventional valid account. The second combines supply-chain behavior, artifact
access, and model manipulation. The third joins retrieval content manipulation to cross-tenant
data exposure.
Without the path, those labels are a list. With the path, they become an explanation of how the
system failed.
A model response is intermediate evidence. The strongest finding joins a controlled source to a logged external effect and includes a clean comparison run.
## A five-pass assessment workflow
### Pass 0 — authorization and safety
Name the environments, tenants, model endpoints, tools, identities, and data classes that may be
tested. Decide which actions are simulation-only and which bounded side effects are permitted.
Create synthetic markers and test accounts before touching retrieval or memory. For agent tests,
set spending, request, and iteration limits.
AI systems are non-deterministic; safety controls must not be. A test that can repeatedly call a
tool needs a deterministic ceiling outside the model.
### Pass 1 — inventory the production path
Collect deployed architecture, not the architecture slide. Confirm listeners, routes, service
identities, secret mounts, model and vector-store locations, tool manifests, egress rules, logging,
and approval points. Record what is present, absent, or still assumed.
The deliverable is a path map with evidence references. A diagram copied from a design document is
context, not proof of the running system.
### Pass 2 — test ordinary access first
Validate authentication on inference and orchestration routes. Review tenant scoping, registry
permissions, build roles, exposed management endpoints, secret handling, and dependency sources.
Test the same controls around the AI service that you would test around any privileged application.
This pass often produces the highest-value findings because it determines who reaches the AI-native
surface in the first place.
### Pass 3 — test AI-native decisions
Use controlled prompts, documents, model artifacts, and evaluation cases. Change one variable at a
time. Capture prompt construction, retrieval identifiers, model and policy versions, tool requests,
and response metadata where authorized.
Do not treat stochastic variation as a bypass. Repeat the test, record the success rate, and compare
it with a negative control. If the protected behavior cannot be named, the test is not ready.
### Pass 4 — test tool and data authority
For every available tool, verify:
- the identity used to invoke it;
- the resources that identity may access;
- argument validation and object-level authorization;
- whether the user sees and approves the final action;
- whether untrusted context can select the tool or alter parameters;
- whether the invocation and result are logged without leaking secrets.
This is where prompt injection becomes a systems finding. The issue is not that the model followed a
sentence. It is that the application converted that sentence into an authorized operation.
### Pass 5 — replay, clean up, and route the fix
Reproduce the smallest complete chain. Run the negative control. Remove planted documents, test
artifacts, memory, tokens, and external side effects. Give each finding to the team that owns the
failed decision—not automatically to the model team.
## Evidence matrix for AI findings
AI testing produces persuasive screenshots and weak conclusions unless the evidence standard is
explicit. Use this matrix before calling something a finding.
| Evidence | Minimum required | What it rules out |
| --- | --- | --- |
| Source control | Unique synthetic marker or bounded test artifact | Confusion with pre-existing content or another tester's data |
| Reachability | Request route, caller position, and effective identity | Claims based only on configuration or intended architecture |
| Model state | Model/deployment version and relevant policy version | Results that cannot be compared after an update |
| Causal link | Trace from source through retrieval or context into the decision | Coincidental model output or unsupported inference |
| External effect | Tool audit, state diff, or defender-observed event | Treating generated text as successful exploitation |
| Negative control | Same path with one decisive variable removed | Non-determinism, stale memory, or an unrelated permission issue |
| Cleanup | Removal of artifacts, memory, tokens, and side effects | Leaving the environment changed after validation |
A prompt that reveals its own marker proves instruction influence. It does not automatically prove
cross-tenant access, secret disclosure, or tool compromise. Each larger claim needs its own evidence.
## Rank attack paths, not technique names
Technique maturity in ATLAS is valuable context, but environmental risk still depends on local
conditions. Prioritize with four questions:
1. **Can an attacker reach the entry point?** Public, tenant-controlled, partner-controlled, or
privileged-only are different threat models.
2. **What authority accepts the result?** A read-only assistant and a deployment agent do not share
a severity merely because both use the same model.
3. **What changes outside the conversation?** Data disclosure, durable memory, a modified artifact,
a sent message, or a financial action is stronger than unsafe prose.
4. **Which independent control should have stopped it?** Authentication, tenant isolation, tool
authorization, approval, signing, egress, or monitoring should remain effective even when the
model behaves badly.
If the conclusion depends on the model refusing perfectly, the design is already fragile. Model
behavior is one layer; important actions need controls that do not share the model's failure mode.
## Write the finding so a defender can act
Avoid findings such as:
> The application is vulnerable to AML.T0051 LLM Prompt Injection.
That states a label, not a failure. Prefer:
> A document uploaded by a standard tenant was retrieved into the support agent's context. Its
> embedded instruction changed the selected ticketing action, and the agent's service identity
> modified a ticket outside the user's permitted queue without a separate authorization check.
Then attach the ATLAS techniques, affected platform, maturity context, and mitigations. The label
helps defenders correlate the behavior. The path tells them what to fix.
A complete handoff contains:
- the deployed component and owner;
- the entry point and required attacker position;
- the identity and permissions used at each step;
- the protected decision that failed;
- the smallest reproducible evidence chain;
- the negative control and cleanup result;
- the independent control that should be added or repaired;
- the relevant ATLAS and ATT&CK labels as metadata.
## What defenders should receive
**A production attack-path map.** It should show data, identities, artifacts, tools, and egress—not
just a box labeled “LLM.”
**An authority ledger.** For each service and tool: who invokes it, what it can read or change, and
where human or policy approval occurs.
**A reproducible evidence pack.** Synthetic markers, request and trace identifiers, versions,
audit events, comparison runs, and cleanup state.
**Two remediation queues.** Ordinary platform failures should go to the teams that own identity,
network, application authorization, CI/CD, or storage. AI-native design failures should go to the
teams that own context construction, retrieval, evaluation, model policy, and agent orchestration.
Separating the queues prevents an exposed API from waiting behind a long-term prompt-injection
research program. It also prevents model tuning from being presented as the fix for an authorization
failure.
## The matrix is the index, not the report
ATLAS has become more useful as AI systems have become more complicated. The addition of agentic
and enterprise views makes the central lesson clearer: adversaries operate across the whole
AI-enabled system. They do not respect the organizational line between “the model team” and
“normal security.”
Use the matrix to discover behaviors you may have missed, compare them with public cases, and give
the final path a common name. Do not use it to replace asset discovery, authorization analysis, or
evidence.
Map the system. Follow the authority. Prove the external effect. Then label it.
That order produces fewer techniques in the report—and far more useful findings.