AI isn’t one system, and your threat model shouldn’t be either
In this Help Net Security interview, Naor Penso, CISO at Cerebras Systems, explains how to threat model modern AI stacks without treating them as a single risk. He discusses why partitioning AI systems by function and impact matters, how to frame threat modeling for business leaders, and which assumptions break down as AI becomes core infrastructure.
What’s the right way to partition a modern AI stack for threat modeling so teams avoid lumping everything under the vague label of “AI systems”?
The right way to partition a modern AI stack for threat modeling is not to treat “AI systems” as a monolithic risk category, we should return to security fundamentals and segment the stack by what the system does, how it is used, the sensitivity of the data it touches, and the impact its failure or breach could have.
This distinguishes low risk internal productivity tools from models embedded in mission critical workflows or those representing core intellectual property and ensures AI is evaluated in context rather than by label.
How do you convey to business leaders that threat modeling is not a blocker but a performance and reliability enabler?
Threat modeling is a driver of higher quality that extends beyond security, and the best way to convey this to business leaders is through analogies rooted in their own domain. For example, in a car dealership, no one would allow a new salesperson to sign off on an 80 percent discount. The general manager instantly understands why that safeguard exists because it protects revenue, reputation, and operational stability.
That is a business threat, and identifying it requires the same discipline that threat modeling brings to technology. Framing it this way shows that threat modeling is not a blocker but an enabler of performance, reliability, and sound decision making.
Which traditional threat-modeling heuristics break down first when ML workloads, accelerators, and data pipelines become the core of the environment?
For LLMs more than traditional ML, the first heuristic to break is the assumption of deterministic behavior. In classical systems, the same input fed into the same algorithm yields the same output every time.
With LLMs, parameters such as temperature, top_p, and the specifics of execution introduce inherent nondeterminism, so a model cannot be expected to respond identically to the same prompt. This lack of determinism creates an “unknown unknown” that makes it harder to verify that the system is operating correctly and consistently, and it blurs the boundary between expected behavior and malicious or abnormal behavior.
What’s one type of operational signal from AI pipelines (e.g., token spikes, odd embedding drift, GPU scheduling anomalies) that you believe should be incorporated into threat modeling but rarely is?
Tool calling patterns are one key area to incorporate into threat modeling. Most modern LLM implementations rely on external tool calls, such as web search or internal MCPs (some server side, and some client side). Unless these are tightly defined and constrained, they can drive the model to behave in unexpected or partially malicious ways. Changes in the frequency, sequence, or parameters of tool calls can indicate misuse, model confusion, or an attempted escalation path.
What new categories of business impact need to be represented in threat models when models themselves can become “critical infrastructure”?
The common denominators remain the same: confidentiality, integrity, and availability. But when models become critical infrastructure, these primitives expand into new risk categories that did not previously exist. Integrity now includes integrity drift, model poisoning, and unlawful bias.
Availability now includes model degradation, dependency failures, and inference slowdowns that can halt core business functions. Confidentiality extends to the model itself as sensitive IP, including the risk of model theft or unauthorized replication.
Webinar: Redefining attack simulation through AI