Once an adversary knows which family of model sits behind your product, they can reuse every published attack, jailbreak and weakness for that family instead of starting from nothing. MITRE ATLAS records this as AML.T0014 Discover AI Model Family, a Discovery (AML.TA0008) technique that applies to Predictive, Generative and Agentic AI and is rated Feasible. ATLAS says the family may be revealed in documentation, or worked out by sending carefully constructed examples and analysing the responses. This guide covers both paths, the published fingerprinting research that shows how cheap the query path has become for LLMs, what you can detect, and the mitigations ATLAS maps. It is for AI platform owners, application security teams and anyone running a model behind an API, chat interface or agent. General inference API access is covered in MITRE ATLAS AML.T0096 AI Service API; this page focuses on identifying the model.
Key takeaways
- The family is a shortcut to known attacks. ATLAS notes that knowing the family helps the adversary identify means of attacking the model and tailor the attack.
- Documentation is the cheapest leak. Product pages, API responses, error messages and system prompts that name the model hand the answer over with no probing at all.
- LLM fingerprinting is fast. Published research identified 42 LLM versions with over 95% accuracy in as few as 8 interactions.
- ATLAS maps three mitigations, two of them predictive only. AML.M0004 query limits apply to every model type; AML.M0002 output obfuscation and AML.M0006 ensembles are written for predictive AI.
- Assume the family will be found. Concealment raises cost; the controls that matter most are the ones that keep a known family's weaknesses from being exploitable.
What the technique is
ATLAS defines AML.T0014 as discovering the general family of a model. The entry was created in May 2021 and last modified in May 2026, and ATLAS lists no case study that maps to it in the 2026.10 release; its maturity is Feasible. It sits next to two other Discovery techniques that are easy to confuse:
| Technique | Question the adversary answers | Example result |
|---|---|---|
| AML.T0014 Discover AI Model Family | What kind of model is this? | A specific open-weight LLM family and version, or a convolutional image classifier of a known architecture |
| AML.T0013 Discover AI Model Ontology | What can it output? | The list of classes or identities it can return |
| AML.T0063 Discover AI Model Outputs | What does it actually return, and what is exposed? | Scores, logs or outputs reachable by the adversary |
For LLM applications, discovering the system prompt and configured instructions is a separate technique again, AML.T0069 Discover LLM System Information. ATLAS lists AML.T0040 AI Model Inference API Access as a source of the information this technique needs.
How the family is discovered
From documentation and metadata
This is the path ATLAS mentions first, and in practice it is the most common. Typical sources:
- Product and marketing pages: announcements that name the model vendor and version behind a feature.
- API responses: response bodies or headers that echo the model name, which many chat completion style APIs and gateways do by default.
- Error messages: stack traces and validation errors that name the serving framework, tokenizer or model file.
- System prompts and model self-description: an assistant asked what it is will often say, especially if its instructions name the model.
- Public artefacts: configuration files, model cards, container images and app packages that ship with the model. Finding those is covered in AML.T0004 Search Application Repositories and AML.T0007 Discover AI Artifacts.
From the model's behaviour
Where nothing is published, ATLAS describes sending carefully constructed examples and analysing the responses to categorise the model. For LLMs this has been studied directly. LLMmap (Pasquini, Kornaropoulos and Ateniese, arXiv preprint, latest version February 2025) is an active fingerprinting technique for LLM-integrated applications: it sends crafted queries and analyses the responses to identify the model version. The authors report identifying 42 LLM versions with over 95% accuracy in as few as 8 interactions, and say the method works across open and proprietary models, unknown system prompts, sampling settings, and frameworks such as retrieval-augmented generation. They conclude that against resourceful adversaries effective countermeasures may be challenging or unrealisable. Eight interactions is well below any rate limit a real product could set, which is why concealment alone is not a defence for LLMs.
For predictive models the same idea applies through output behaviour: the shape of confidence scores, the classes returned and how the model reacts to systematically varied inputs all give away architecture characteristics. Rich outputs make this easier, which is why the ATLAS mitigations focus on output fidelity.
Why the family matters to an attacker
| What the family unlocks | Generative and agentic AI | Predictive AI |
|---|---|---|
| Known weaknesses | Published jailbreaks, prompt injection patterns and safety bypasses tested on that family (see AML.T0054 LLM Jailbreak) | Published adversarial example research against that architecture |
| Offline rehearsal | Download the same open-weight model and test attacks locally, with no queries against you | Train a proxy of the same architecture to craft transferable adversarial inputs |
| Vulnerability research | Known issues in the serving stack typically paired with that model (see AML.T0001 Search Open AI Vulnerability Analysis) | Known weaknesses of the framework and model format |
| Cost of the attack | Fewer probing queries, so less chance of tripping rate limits and monitoring | Fewer queries needed to verify an attack before using it |
The offline rehearsal row is the important one. If the model is open weight, identifying it lets the adversary move most of the attack development off your platform and out of your monitoring.
Mitigations
ATLAS 2026.10 maps three mitigations to AML.T0014.
| ATLAS mitigation | What ATLAS says for this technique | Applies to | Practical implementation |
|---|---|---|---|
| AML.M0004 Limit AI Service Query Volume and Rate | Limit inference queries to reduce an adversary's ability to infer the family of the model | All model types | Rate, burst and concurrency limits plus quotas per user, API key or tenant; watch for distributed requests and account rotation |
| AML.M0002 Predictive AI Output Obfuscation | Restrict results shown, limit ontology specificity, randomised smoothing, reduce numerical precision | Predictive AI | Top-1 or decision-only outputs; rounded scores; withhold logits and embeddings from general callers |
| AML.M0006 Predictive AI Ensembles | Use multiple different models to obscure which type of model is used and how | Predictive AI | Diverse architectures combined so that no single family's behaviour dominates the output |
Because the published LLM fingerprinting needs only a handful of queries, query limits mainly help against cruder probing. For generative and agentic systems add these controls:
- Strip model identifiers at the gateway: remove or replace model names in response bodies, headers and error messages returned to external callers. A gateway is the natural place to do this consistently; see the AI Gateway and LLM Gateway Guide.
- Generic errors: do not return stack traces, tokenizer errors or serving framework names to clients.
- Keep the model name out of system prompts unless the product needs it. Telling the model not to reveal its identity is not a control, because prompt instructions can be bypassed; see the OWASP LLM Top 10 LLM07 System Prompt Leakage Guide.
- Decide disclosure deliberately: transparency obligations or customer contracts may require naming the model. Where they do, publish it and rely on the controls below rather than hiding it inconsistently.
- Make known weaknesses irrelevant: keep the model version current, layer input and output filtering that does not depend on the model's own refusals, and limit what tools and data an agent can reach, so a family-specific jailbreak achieves little.
Decision guidance: concealing the model family is worth doing when it is cheap (identifiers in headers and errors) and when the model is a predictive security control an adversary wants to evade, such as fraud, malware or liveness detection. For a general-purpose assistant built on a widely used LLM, assume the family is known and spend the effort on containment and monitoring. Small teams should do the gateway clean-up and per-identity rate limits; larger platforms serving many models can add a version abstraction so external names do not map one to one to internal models.
What to detect and where
| Where | What to log | Signal of model family discovery |
|---|---|---|
| Prompt and conversation logs | Prompts per session and identity | Questions about the model's identity, creator, version, training cut-off or tokenizer; short sessions of unusual, unrelated probing prompts with no task |
| AI gateway | Caller identity, request parameters, error rates | Many new sessions each sending a small fixed set of prompts; requests varying sampling parameters systematically |
| Predictive inference API | Inputs, returned labels and scores per caller | Synthetic or systematically varied inputs; callers always asking for maximum output detail |
| Identity and billing | Trial sign-ups and API key creation | Several new identities with matching probe patterns, the rotation ATLAS warns about for AML.M0004 |
| External responses | Sampled response headers and error bodies | Any model or framework name reaching an external client |
Detection of behavioural fingerprinting is imperfect, because the probes can look like ordinary curiosity. Treat these signals as context that raises the priority of a session already showing jailbreak or injection attempts, rather than as stand-alone alerts.
How to test
- Disclosure review: list everywhere the model family is named: product pages, API docs, response headers, error bodies, system prompts and shipped artefacts.
- Ask the system: in a test environment, ask the assistant directly what model it is and record the answer.
- Error probing: send malformed requests and record whether errors name the model, tokenizer or serving framework.
- Fingerprint yourself: as an authorised AI red team exercise, run a published fingerprinting method against a test deployment to see whether the family can be identified despite your controls. Plan it with the AI Red Team Test Plan Template.
- Check detection and limits: confirm the probing showed up in logs and that per-identity limits held across several test accounts. Remove test identities afterwards.
Measuring it
- Number of external endpoints returning a model or framework name in headers, bodies or errors (target zero, unless disclosure is a deliberate decision).
- Share of AI endpoints with per-identity rate limits and quotas in force.
- Share of predictive endpoints returning only the output detail the application needs.
- Days from a model vendor's security advisory to the deployed model being updated or the advisory assessed.
- Whether red team fingerprinting was detected, and how many queries it needed.
Common failure patterns
- The gateway forwards everything: the upstream provider's response, including the model field and provider headers, is passed unchanged to the client.
- Relying on the prompt: "do not reveal your model" in the system prompt, treated as a control.
- Verbose errors: production errors that name the serving framework and model file path.
- Inconsistent concealment: the API hides the model while the release notes, job adverts or app package name it.
- Stale models: a known family whose published jailbreaks have been fixed in newer versions, left unpatched because nobody tracks model versions as assets.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0014 (AML.TA0008 Discovery) | The technique; information comes from documentation or AML.T0040 inference API access |
| MITRE ATLAS mitigations | AML.M0002, AML.M0004, AML.M0006 | Output obfuscation, query limits, ensembles |
| OWASP Top 10 for LLM Applications 2025 | LLM07 System Prompt Leakage; LLM10 Unbounded Consumption | Model identity in system prompts; uncontrolled query volume |
| NIST AI 100-2 E2025 | Adversarial ML taxonomy | Attacker knowledge and capabilities as a dimension of attacks |
| NIST SP 800-53 Rev. 5 | SC-5, AC-3, AU-12, SI-4 | Rate limiting, access enforcement on detailed outputs, audit records, monitoring for probing |
Practitioner checklist
- Strip model and framework names from external responses, headers and errors at the gateway.
- Decide, document and apply one disclosure position for each model across docs, APIs and packages.
- Keep model names out of system prompts unless the product requires them.
- Apply per-identity rate limits and quotas, and watch for account rotation.
- For predictive models, return only the output detail callers need; consider ensembles for security-critical models.
- Track deployed model versions as assets and act on vendor advisories.
- Log prompts and outputs per identity so probing sessions can be reviewed.
- Include model fingerprinting in authorised AI red team tests.
Standards and references
- MITRE ATLAS: Discover AI Model Family
- MITRE ATLAS: Limit AI Service Query Volume and Rate
- MITRE ATLAS: Predictive AI Output Obfuscation
- MITRE ATLAS: Predictive AI Ensembles
- OWASP: LLM07:2025 System Prompt Leakage
- NIST: AI 100-2 E2025 Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations
- Pasquini, Kornaropoulos and Ateniese: LLMmap: Fingerprinting For Large Language Models
Related NHI Mgmt Group resources: MITRE ATLAS Guide · Model Extraction and Distillation Defence Guide · Rate Limiting and API Abuse Guide · AI Red Teaming Guide