A threat model formally defines the attacker's knowledge (white-box vs. black-box access), goal (targeted misclassification vs. availability disruption), and capability (perturbation budget under an Lp norm). This structured framework establishes the precise security boundary and trust assumptions for evaluating a machine learning system's resilience.
Glossary
Threat Model

What is a Threat Model?
A threat model is a formal characterization of an adversary's capabilities, goals, and knowledge, defining the security assumptions under which a system is evaluated.
Without a rigorous threat model, adversarial robustness claims are meaningless. A defense against a weak Fast Gradient Sign Method (FGSM) attacker may fail trivially against a stronger Projected Gradient Descent (PGD) adversary. The model dictates the evaluation protocol, ensuring that security metrics like certified robustness are measured against a realistic, well-defined opponent.
Core Dimensions of a Threat Model
A threat model is a structured representation of an adversary's capabilities, goals, and knowledge. It defines the precise security assumptions under which a system's defenses are evaluated, moving security from guesswork to rigorous engineering.
Adversarial Goal
Defines the security violation the attacker aims to achieve. This dimension specifies whether the adversary seeks integrity violation (triggering misclassification without detection), availability violation (causing denial of service), or privacy violation (extracting sensitive training data).
- Targeted: Force a specific incorrect output (e.g., classify a stop sign as a speed limit sign)
- Untargeted: Cause any misclassification
- Model Extraction: Steal the model's functionality via API queries
- Membership Inference: Determine if a record was in the training set
Adversarial Knowledge
Characterizes the information available to the attacker about the target system. This spectrum ranges from white-box (full access to architecture, weights, and gradients) to black-box (only input-output query access).
- White-Box: Attacker has complete knowledge of model architecture, parameters, and training algorithm. Enables gradient-based attacks like FGSM and PGD.
- Black-Box: Attacker can only query the model API and observe outputs. Requires transfer attacks or score-based optimization.
- Gray-Box: Partial knowledge, such as knowing the architecture but not the weights, or having access to confidence scores but not gradients.
Adversarial Capability
Specifies the constraints and resources available to the attacker when manipulating inputs. This is formalized mathematically using Lp norm bounds that limit perturbation magnitude.
- L-infinity (L∞): Limits the maximum change to any single pixel or feature. Common bound: ε = 8/255 for images.
- L2: Constrains the Euclidean distance of the perturbation vector.
- L0: Limits the number of pixels or features that can be modified.
- Physical Constraints: For real-world attacks, includes robustness to lighting, angle, and printability (e.g., adversarial patches).
- Query Budget: In black-box settings, limits the number of API calls allowed.
Attack Surface
Identifies the entry points where an adversary can interact with the ML system. This dimension maps the pipeline stages vulnerable to manipulation.
- Training-Time: Attacker poisons the dataset or modifies pre-trained weights before deployment. Includes backdoor injection and data poisoning.
- Inference-Time: Attacker crafts adversarial examples at prediction time. The model is frozen, but inputs are manipulated.
- Supply Chain: Compromise of third-party models, libraries, or datasets before integration.
- API Exploitation: Query-based attacks that extract model behavior or training data through the inference endpoint.
Defender's Assumptions
Explicitly states what the defender can and cannot do, establishing the baseline for security guarantees. This prevents evaluating defenses under unrealistic conditions.
- Data Sanitization: Can the defender filter or clean training data? If not, poisoning defenses must be robust to raw inputs.
- Model Access: Is the model publicly deployed or gated behind authentication?
- Detection Capability: Can the defender detect attacks in real-time, or must the model be inherently robust?
- Retraining Frequency: How often can the model be updated to patch vulnerabilities?
- Gradient Obfuscation: Explicitly note if gradients are hidden—this is often a brittle defense (gradient masking) that fails against black-box transfer attacks.
Frequently Asked Questions
A threat model is the foundational blueprint for any security evaluation, defining the assumptions about an adversary's capabilities, goals, and knowledge. Understanding these formal characterizations is critical for security engineers and CTOs evaluating the robustness of preemptive algorithmic defenses.
A threat model is a formal characterization of an adversary's capabilities, goals, and knowledge, defining the precise assumptions under which a system's security is evaluated. It establishes the rules of engagement by specifying what an attacker can observe, modify, and access. In machine learning, this includes defining the attack surface (training data, model weights, inference API), the adversarial objective (integrity violation, privacy breach, availability disruption), and the capability constraints (Lp-norm budget, query limits, computational resources). Without a rigorous threat model, security claims are meaningless, as a defense against a weak attacker offers no guarantee against a sophisticated one.
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 defines the rules of engagement. These related concepts represent the specific attack vectors, defensive methodologies, and formal guarantees that are evaluated within that defined security framework.

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