TRACE came out of Web3 security work at Oak Security. Web3 was a useful proving ground because it combines high-value assets, distributed authority, governance, off-chain infrastructure, signing keys and human control paths, with none of them behind a perimeter. The method turned out to be more general than its origin. An organisation with remote teams, cloud and SaaS dependency chains and a few people who can approve consequential things has the same shape of problem.
The name is the model: Threat actors, Roles, Assets, Critical invariants, Edges. The model is built from evidence, then pushed through STRIDE threat identification, attack trees, a collusion and coordination inspection, and a mitigation roadmap. Every material threat has to trace back to a source, a model object, an assumption, a boundary or an attack path.
The specification opens with three practical realities. There is no traditional security perimeter. Meaningful risk crosses protocols, systems and organisations, so all three have to be modelled together. And the third:
AI-human co-working. AI can accelerate extraction, coverage, and draft analysis, but expert human judgement is required for assumptions, ranking, plausibility, collusion analysis, and recommendations.
TRACE methodology specification, primary drivers
Most threat-modelling methods say nothing about tooling. This one put the working arrangement between analyst and model in its foundations, and I want to explain why.
Two problems, two tools
Threat modelling has a coverage problem and a judgement problem.
The coverage problem is the volume of material. A serious assessment means reading specifications, architecture documents, infrastructure-as-code, CI/CD configuration, runbooks, access reviews and interview notes, extracting every candidate component, role, asset, flow and dependency, keeping the terminology consistent, and noticing which sources are missing. People are slow at this and skip things. A model is good at it. It removes the blank page, it improves coverage, and it keeps a large model internally consistent.
The judgement problem is deciding what matters. Which invariant decides whether the system is safe? It is rarely "nothing bad should happen". It depends on market assumptions, approval dynamics, governance latency, vendor behaviour and what people do under stress. Is the approval delay enforceable or only documented? Is the committee independent enough to make capture expensive? Is the attack profitable under realistic conditions? A model is only reasonably good at these questions, and it is wrong in predictable ways: overconfident from incomplete material, drawn to generic perimeter-era threat lists, and inclined to treat formal permissions as if they were operational safety.
A method that ignores AI leaves coverage on the table. A method that hands judgement to AI produces threat models that are elegant and wrong. TRACE's answer was to define what each side does, phase by phase, and to put a human decision point between phases so that a weak assumption is caught before it is amplified into rankings, trees and recommendations.
What that looks like in the method
TRACE is sequential. Each phase produces a reviewable artifact that becomes the input to the next, and the specification says who does what in each one.
The gates are the source inventory before modelling begins, the model before STRIDE expansion, the ranked threat list before attack trees, the trees before recommendations, collusion and coordination assumptions with a senior reviewer, and the final recommendations for severity, feasibility and sequencing.
Under the gates sits a traceability rule. AI output is candidate analysis until a person has checked it. Model objects link to a source or are marked as inferred assumptions. STRIDE threats link to a component, flow, role or edge. Attack-tree roots link to ranked threats and leaves to enabling assumptions or concrete facts. Recommendations link to what they mitigate. A claim that cannot be traced is removed, rewritten as an assumption, or logged as an open question.
The specification also names what AI output is never used for on its own: final invariant definitions, final severity ratings, collusion and governance-capture conclusions, exploitability claims, and final client recommendations. The section closes with a sentence I still think is the most important one in the document:
The model should never be treated as complete merely because the source material was processed. Human review is a required part of TRACE.
TRACE methodology specification, AI usage and human co-working
When the target is an agent
The systems we model at Mostly Harmless are increasingly agents: software in which a model reads inputs the operator does not control, decides with some latitude, and acts through tools, code, messages or other agents. TRACE fits that target well, and each reason comes back to the co-working design.
The sources may be hostile. The system prompts, tool descriptions, memory dumps and transcripts of an agentic target can contain prompt injections, left over from testing or planted on purpose. An analysis assistant that reads them can be steered by them. A method that treats every AI output as a candidate, and requires every claim to be traced to evidence before it is accepted, is already defended against that. Instruction-like text in the sources becomes a finding, because nothing the assistant produces gets into the model without a person tracing it back.
The gates are the same control the agent needs. TRACE puts a human decision between phases because AI judgement compounds errors from one phase to the next. An agent needs a human-approval edge before irreversible actions for the same reason. A team that has run TRACE has practised the pattern it now has to build.
Invariants and edges are objects in the model rather than something derived from a component list. The questions that decide whether an agent is safe are of that kind. Does the agent's effective authority stay inside what its principal delegated? Where does untrusted content cross into instruction? The original text already lists "AI-agent control policy" as a protocol, automation as a threat actor, and bounded authority as an invariant.
Every edge is a zero trust question. TRACE for Systems asks of each one: who or what is crossing, what identity is asserted, what resource and action are involved, what context changes the risk, and what happens if the source is already compromised. For a user, the last question is a hypothetical. For an agent that reads the open web, it is the normal operating assumption, as Anthropic's guide also concludes.
What was missing
TRACE gave the modeller the structure but not the vocabulary. It could hold an agent in the model. It did not say how a compromised agent differs from a compromised user, what memory is as an asset, which invariants an agentic deployment lives or dies by, or how to write an attack tree in the terms the AI security community now shares through MITRE ATLAS. It also did not connect to the NIST AI Risk Management Framework, which is what the governance readers of these reports ask for.
The agentic extension adds those things without changing the meaning of the original. The next post goes through it.