A threat model formally defines the security assumptions under which a machine learning system is evaluated by specifying the adversary's objective, knowledge (white-box or black-box access), and capabilities (e.g., Lp-norm perturbation budget). This structured framework prevents vague security claims by establishing a precise, reproducible contract for what an attacker can and cannot do.
Glossary
Threat Model

What is Threat Model?
A threat model is a formal specification of an adversary's goals, knowledge, and capabilities used to evaluate the security posture of a machine learning system.
Without a rigorous threat model, robustness evaluations are meaningless. A defense against evasion attacks with an L-infinity bound of 8/255 does not imply resistance to adversarial patches or data poisoning. Standardizing assumptions using tools like RobustBench ensures that comparisons between defensive techniques are scientifically valid and not artifacts of a weak adversary.
Core Components of an AI Threat Model
A formal specification of an adversary's goals, knowledge, and capabilities used to evaluate the security posture of a machine learning system.
Adversary Knowledge Spectrum
Categorizes attacker access to model internals along a continuum:
- White-box access: Full knowledge of architecture, parameters, gradients, and training data. Enables Projected Gradient Descent (PGD) and Fast Gradient Sign Method (FGSM) attacks
- Black-box access: Query-only interaction with the model API. Relies on transferability of adversarial examples or model extraction to build substitute models
- Gray-box access: Partial knowledge such as training data distribution or feature representations
Adaptive attacks assume the adversary knows the defense mechanism and actively circumvents it.
Attack Surface Enumeration
Maps all entry points where an adversary can interact with the ML pipeline:
- Training phase: Data poisoning injects malicious samples into datasets; supply chain attacks compromise pre-trained weights or third-party dependencies
- Inference phase: Evasion attacks modify inputs at test time; adversarial patches physically alter scenes for computer vision systems
- API boundary: Model extraction steals intellectual property through prediction queries; membership inference leaks training data presence
Each surface requires distinct defensive strategies like adversarial training or differential privacy.
Capability Assumptions
Defines the computational budget and constraints of the attacker:
- Perturbation budget: The maximum allowable distortion measured by Lp-norms (e.g., L∞ ≤ 8/255 for pixel values)
- Query budget: Limits on API calls for black-box adversaries before rate limiting or cost thresholds trigger
- Computational resources: Distinguishes between academic researchers with GPU clusters and nation-state actors with exascale compute
Certified robustness via randomized smoothing provides formal guarantees that predictions remain stable within specified perturbation bounds regardless of attacker capability.
Defense Taxonomy
Systematically catalogs countermeasures mapped to specific threats:
- Proactive defenses: Adversarial training augments data with PGD examples; gradient masking obfuscates loss surfaces (brittle, not recommended)
- Detective defenses: Out-of-distribution detection flags anomalous inputs; feature squeezing reduces adversarial perturbation space
- Certified defenses: Randomized smoothing and neural network verification provide mathematical guarantees of robustness
- Operational defenses: Red-teaming simulates real attacks; AI incident response protocols enable model rollback
AutoAttack and RobustBench provide standardized evaluation to prevent inflated robustness claims from obfuscated gradients.
Threat Scenario Documentation
Formalizes concrete attack scenarios with structured templates:
- Actor profile: Script kiddie, organized crime, corporate competitor, nation-state APT
- Attack vector: Federated adversarial robustness threats from malicious clients poisoning the global model
- Impact assessment: Financial loss, safety-critical failure, regulatory non-compliance under the EU AI Act
- Mitigation mapping: Links each scenario to specific controls like differential privacy defense for training data leakage
Example: A competitor uses transferability to craft black-box evasion attacks against a fraud detection API, requiring continuous compliance monitoring.
Frequently Asked Questions
A threat model is the foundational blueprint for securing machine learning systems. It formally defines who you are defending against, what they want, and how they might get it. These FAQs clarify the core components, adversary types, and practical applications of threat modeling in adversarial robustness evaluation.
A threat model is a formal specification of an adversary's goals, knowledge, and capabilities used to evaluate the security posture of a machine learning system. It defines the attack surface by answering four critical questions: What is the adversary's objective (e.g., cause misclassification, steal intellectual property)? What knowledge do they possess about the model (white-box access to parameters vs. black-box API queries)? What capabilities do they have to manipulate data (perturbing inputs, injecting training samples)? And what are the constraints on their actions (perceptibility limits, query budgets)? Without a precise threat model, robustness claims are meaningless—a defense against a weak attacker offers no guarantee against a stronger one. Standard models include the CIA triad (Confidentiality, Integrity, Availability) adapted for ML, and formal frameworks like the NIST Adversarial Machine Learning Taxonomy which categorizes attacks by timing (training vs. inference), goal (targeted vs. untargeted), and adversary leverage.
Threat Model vs. Attack Model vs. Risk Assessment
Distinguishing the foundational security analysis frameworks used to evaluate, simulate, and prioritize risks in machine learning systems.
| Feature | Threat Model | Attack Model | Risk Assessment |
|---|---|---|---|
Primary Purpose | Formal specification of adversary goals, knowledge, and capabilities to define the security posture. | Concrete algorithmic definition of a specific exploit mechanism against a vulnerability. | Systematic process to identify, analyze, and prioritize potential hazards and their business impact. |
Key Output | Adversary profiles, trust boundaries, and a prioritized list of potential security violations. | A reproducible mathematical procedure (e.g., PGD, FGSM) for generating malicious inputs. | A risk matrix mapping likelihood and impact, with recommended mitigation controls. |
Temporal Focus | Design-time and architecture review phase. | Implementation and evaluation phase. | Continuous lifecycle management and pre-deployment audit. |
Scope | System-wide analysis of assets, entry points, and data flows. | Point analysis of a specific model input-output mapping. | Organizational analysis including legal, reputational, and operational domains. |
Adversary Specification | |||
Quantifies Business Impact | |||
Standard Framework | STRIDE, LINDDUN, PASTA | Carlini & Wagner, PGD, AutoAttack | NIST SP 800-30, ISO 27005, FAIR |
Defensive Counterpart | Security architecture and trust zone enforcement. | Adversarial training and certified robustness. | Risk mitigation, transfer, and acceptance strategies. |
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
A threat model is only as effective as the attack vectors it anticipates. Explore the core adversarial techniques and defensive countermeasures that define the modern AI security landscape.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us