Security design review · Threat model

AI Threat Modeling

Threat modeling works when each consequential trust change leads from a credible attacker path to an owned control, runnable test, residual-risk state, and review trigger.

We follow data, models, tools, identities, permissions, and people across the points where trust changes. Credible attacker goals and misuse cases then lead to a control, a test someone can run, an accountable owner, and a condition for reopening the risk.

With a trust-boundary map and open-threat log, your risk owner can see which paths are controlled, tested, accepted, or still unresolved.

Map the threat boundaryExplore security and red teaming
Illustration of AI Threat Modeling: a team probing an AI system for security weaknesses

Some of the 500+ brands we've worked with

See all references
  • Hyundai
  • Sanofi
  • CHIP Online
  • Aksigorta
  • Desa
  • DYO

Steps, gates, and who decides

How we work

We begin with how the system is meant to work, compare that view with the evidence available, and then follow credible attacks until each priority threat reaches an owned control or remains an explicit gap.

  1. Draw every consequential trust change

    We review intended use, architecture, data flows, model and tool dependencies, identities, permissions, protected assets, known incidents, and planned changes. The first diagram marks each point where another actor or component receives trust.

    AI assist
    We compare approved architecture documents with configuration evidence to flag likely drift. A specialist checks each mismatch.
    Human gate
    Does the boundary confirmed by your architecture owner include every consequential actor, tool, identity, and data path currently known? Your architecture owner confirms the system view and the trust hops it contains.

  2. Follow the attacker through the boundary

    We work from attacker goals and misuse cases through assets, entry points, trust changes, existing controls, and likely impact. Likelihood and impact stay tied to evidence, while unknown conditions remain marked as unknown.

    AI assist
    Known attacker patterns seed candidate misuse cases, which security specialists reshape or discard.
    Human gate
    Which credible threats are important enough to require a control or test in this review? Priority among the threats is your security lead's call.

  3. Give priority threats something runnable

    Each priority threat is connected to a control and an executable test. When no adequate control or test exists, the missing link remains visible and becomes a decision rather than a polished row in a register.

    AI assist
    The model suggests controls and tests from the approved threat record. The control owner reviews them.
    Human gate
    Can every priority threat be followed to a control, a runnable test, or a clearly owned gap? The relevant control owner confirms that the test exercises the threat it is meant to address.

  4. Record the open risk

    We document mitigation choices, accountable owners, residual risk, and the events that should reopen the model. Your risk owner decides what can be accepted now and what must remain open.

    AI assist
    Approved findings are formatted into draft register entries for the risk owner to check.
    Human gate
    Is every open priority threat attached to an owner, decision state, and review trigger? Your risk owner accepts the residual risk or keeps the item open.

Named artifacts you keep

What you get

The outputs work as one evidence chain. A reviewer can start at a trust boundary, follow an attack path to its control and test, and then see who owns the risk that remains.

  • Architecture document

    Trust-boundary and system-flow map

    The agreed assets and actors, with the routes followed as data, models, tools, identities, and permissions cross trust boundaries.

  • Playbook

    Attacker-goal and abuse-path dossier

    Attacker goals, misuse cases, entry points, affected assets, likelihood, impact, evidence, assumptions, and existing controls.

  • Matrix

    Priority threat-to-control test map

    The trace from each priority threat to its control, executable test, owner, and any unresolved gap.

  • Risk register

    Open-threat mitigation and review log

    The mitigation choice for each open threat, who owns it, the exposure left, and the date or event that returns it to review.

Scope and honest limits

When to bring us in

Run this while the architecture can still move. Once an untested assumption is embedded in permissions, data flows, or tools, change gets harder.

A good fit when

  • Data, models, tools, identities, and people cross trust boundaries, but nobody has reviewed the resulting paths as one system.
  • Threats are listed, yet no control owner has a runnable test showing whether each priority path is addressed.
  • Residual-risk choices are approaching, but no named owner has set which threats take priority or what change should reopen the model.
  • Your assets and data flows are documented, while model dependencies, tool calls, identities, permissions, and trust boundaries remain split across sources.
  • Credible attacker goals exist, but nobody has followed each misuse case from its entry point through controls to likely impact.
  • Priority threats have proposed controls, yet the executable tests, accountable owners, residual risk, or review triggers are missing.
  • Assumptions and evidence gaps are known, but nobody has decided which need an architecture change now and which require a later security test.

Better handled as other work when

  • You need the threat model to carry legal, regulatory, audit, or certification approval. Those judgments remain with your qualified authority.
  • You need complete attacker coverage, although the trust-boundary map can document only credible paths supported by the reviewed system state.
  • You need the missing controls implemented, but threat modeling stops after each open gap has an owner, risk state, and runnable test path.

If one of these is closer to your situation, start here instead: Explore security and red teaming

We operate the systems we test

It's hard to test a system well if you've never had to keep one running. We operate production AI ourselves, so our evaluation, security testing, and LLMOps work starts from what actually breaks. The people on it are senior engineers, and Zeo has been doing client work since 2011.

Content we've produced on this topic

Articleby Burak PehlivanWhat is WebMCP? Agentic Web and Websites Interacting with AI AgentsArticleby Yiğit KonurMCP Server Architecture: State Management, Security & Tool Orchestration

Tools we use

Tools behind this work

  • Traceloop

    the production trace showing whether a modeled trust boundary matches real behavior

  • IriusRisk

    generates the diagram from text first, then derives the threat model

  • Mindgard

    the executable test that turns a priority threat into a runnable check

  • Lakera Guard

    the observed-attack telemetry a threat model's attacker goals get grounded against

Next step

Trace the attack path early

Bring the current system view, the concerns already on your radar, and the risk owner who can decide what moves forward. The review traces credible paths to their controls, tests, and open risks.
Map the threats

Before you decide

Questions we hear a lot

Bring the intended use, architecture and data flows, model and tool dependencies, identities and permissions, protected assets, known incidents, current controls, and planned changes. A risk owner must also be available to settle priorities and residual-risk decisions.