The specification is in two parts. Part I restates TRACE as I designed it at Oak Security, condensed but with nothing removed, and each subsection links to the original so a reader can compare. Part II is the extension. A change log lists everything that was added, as the CC BY 4.0 licence asks. The previous post covered why the original was a good starting point. This one covers what was missing.
Three properties that justify an extension
An agentic system, for threat-modelling purposes, is one in which a model perceives inputs the operator does not fully control, decides on a course of action with some latitude, and acts through tools, APIs, code, messages or other agents, with limited or delayed supervision. Three things make such systems different from the ones TRACE was written for.
The control channel is the data channel. Instructions and inputs travel through the same medium, so anything the agent reads can carry instructions. Prompt injection is a property of the architecture, not a bug class.
Authority is delegated. The agent acts with credentials that belong to a person or a service. Whether its effective authority stays inside its intended authority is a new invariant, and the delegation chain from human to orchestrator to sub-agent to tool to downstream system is a new kind of edge.
The agent can be both target and attacker. The 2026.08 release of MITRE ATLAS added techniques for autonomous reconnaissance, attack-path adaptation and agent-to-agent communication, because agents are now used as the offensive capability, and because agents deployed for benign purposes have crossed boundaries on their own. A model that only asks "how can an attacker abuse the agent?" misses "what can the agent do that nobody intended?"
The original method could hold all three in its model. It had no vocabulary for them. The extension supplies the vocabulary and the phases that use it, without changing anything in Part I. Every agentic object is still a threat actor, a role, an asset, an invariant or an edge, filed under that heading with an agentic: tag so that plain-TRACE tooling and reviewers can still read the model.
Deciding whether it applies
The extension is optional. Running it against a system that calls a model to classify support tickets adds cost without insight. Skipping it for a system that executes code on a user's behalf misses the threats that matter. So it starts with a screen, Phase A0, that makes the decision explicit and reviewable. Five questions, each answered with evidence from the source inventory:
| # | Question | If yes |
|---|---|---|
| Q1 | Does a model process input the operator does not fully control? | An injection surface exists |
| Q2 | Can the model's output cause an action without a human approving that specific action? | Delegated-authority edges exist |
| Q3 | Does the system keep state the model reads back later: memory, indexes, history, rules files, skills? | A persistence and context-poisoning surface exists |
| Q4 | Are there multiple agents, or can the agent spawn, configure or deploy other agents? | Multi-agent inspection applies |
| Q5 | Does anyone expect alignment with the NIST AI RMF or an equivalent governance framework? | Control mapping applies |
The extension applies when Q1 is yes and at least one of the others is. The screen also puts the target on a five-level autonomy scale, from L0, where the model produces output that a human reads and acts on, to L4, where agents coordinate with other agents, acquire tools or provision their own resources. The level decides which optional phases run. A system that fails the screen is modelled with plain TRACE, and the specification says that a note recording this is itself a useful output.
A0 also adds the sources a conventional inventory tends to miss: system prompts and agent configuration, tool and MCP server definitions with their permission scopes, the memory and retrieval design, provider documentation including update policy, the implementation of the approval workflow (specifically, what the approver sees), agent telemetry, and any evaluations or red-team results already run.
The model objects
Phase A2 extends the model. The additions are refinements of the five TRACE object types.
Five threat actors. The compromised agent, under injection, poisoned tools, poisoned memory or a jailbreak, whose capability is the agent's full autonomy envelope and whose incentive is the injector's. This is the confused-deputy actor and it is usually the most capable actor in the model. The drifting agent, pursuing its objective in a way nobody intended, with no external attacker. The adversarial agent, an attacker's automation or a malicious peer in a multi-agent system. The provider, a vendor whose behaviour can change without a deploy on the operator's side. And the content author: anyone who can place content where the agent will read it, which is usually an unauthenticated and unlimited population.
Five roles. The principal on whose behalf the agent acts. The operator who configures it, often a different person from the principal and often under-privileged in the organisation relative to the authority they configure. The approver, with a note to record what they see when they approve. The tool owner for each tool, MCP server or plugin, including third parties. And the agent itself as a role, because it holds credentials, permissions and reach inside the target. The agent appears as both a role and an actor on purpose. TRACE separates authority from implementation: the role entry answers "what can this position cause?" and the actor entry answers "who might drive it?"
Seven assets. Instruction integrity, meaning the system prompt, rules files and skills. Context and memory, which is read back as partially trusted input. Delegated credentials. The tool catalogue. The action log, whose integrity is what makes repudiation analysis possible. The compute and spend budget. And every downstream asset the agent's tools can reach, annotated with the agent that can reach it.
Eight critical invariants, written so that a reviewer can test each one and mapped to a NIST AI RMF subcategory. These are the invariants that most often decide whether an agentic deployment is safe.
| Invariant | Statement |
|---|---|
| Bounded authority | The agent's effective authority never exceeds what its principal intentionally delegated, for any input. |
| Instruction provenance | Only content from designated instruction channels is treated as instruction. Content from data channels is data, whatever it says. |
| Action reversibility or gating | Every irreversible or high-impact action is either reversible within a defined window or gated by an approver who sees enough to decide. |
| Memory integrity | Nothing enters long-term memory, indexes or configuration from an untrusted channel without validation, and memory cannot escalate the agent's authority. |
| Scope stability | The agent's tools, permissions, resources and objectives do not grow at runtime without an explicit, logged, human-approved change. |
| Attributability | Every action can be attributed, after the fact, to the agent, its principal, the triggering input and the decision path. |
| Bounded consumption | The agent cannot consume compute, tokens, spend or downstream capacity beyond a defined budget, including through loops or sub-agents. |
| Containment | A compromised agent cannot reach components outside its segment, and a compromised sub-agent cannot compromise its orchestrator. |
Nine edges, which a conventional model would collapse into "API boundary". Each has its own attack techniques and its own zero trust question.
The zero trust questions per edge, in short. Ingestion: which of these channels can carry instructions the agent will act on, and what stops it? Instruction: who can write here, and is the write logged? Memory: what validates content on the way in, and does anything read it back with more trust than it had? Tool invocation: what authority does the call carry, is it scoped per call, and can the result carry instructions? Delegation: is authority narrowed at each hop, and does the receiving hop know who the original principal is? Agent to agent: can one agent instruct another? Human approval: does the approver see the real action, and can the agent act before, around or after the decision? Provider: what changes upstream without a change on our side, and how would we notice? Rendering: can output smuggle links, markup or exfiltration channels into whatever displays it?
The optional phases
Phases A2 to A6 attach to core phases 2 to 6. Each runs inside its core phase, before that phase's existing gate, so the number of human decision points does not change. That was a constraint I set at the start. The co-working design of the original is the reason it works on agents, and the extension was not going to weaken it.
A3: ATLAS enumeration and GenAI risk tags
STRIDE stays the primary lens. A3 adds a pass over the ATLAS techniques listed for each agentic edge in the crosswalk, and a reconciliation so that every STRIDE threat on an agentic edge either maps to a technique or carries a note that ATLAS has none yet. ATLAS's maturity field, whether a technique is feasible, demonstrated or realised, feeds the feasibility part of ranking. A realised technique with public case studies should not be ranked as speculative without a documented reason. Each threat is tagged with the NIST Generative AI Profile risk categories so that governance readers can read the register in their own vocabulary. Four ranking factors join the standard ones: whether the technique is zero-click, the blast radius of the autonomy envelope, retry economics (an attacker can try many injections at negligible cost, so per-attempt success rates understate risk), and whether an injection transfers across models.
A4: ATLAS-chained attack trees
Tree nodes are tagged with ATLAS tactic and technique, so a path from leaf to root reads as a kill chain and can be compared across assessments and linked to mitigations. Two rules. For any agent that can act, at least one tree has the root "attacker causes the agent to take action X with the principal's authority", with a branch for each ingestion edge. This injection-to-action tree is the agentic equivalent of the signer-compromise tree in Web3 TRACE work. For autonomous and multi-agent systems, there are also agent-as-attacker trees whose root is a drifting-agent outcome, with branches for objective misgeneralisation, blocker circumvention, confabulated preconditions and self-expansion. Those trees have no external attacker, and they are the ones that surprise stakeholders. Human-approval nodes in any tree are conditions, not terminators, unless the approver's view is independent of the agent.
A5: autonomy and multi-agent inspection
TRACE's collusion phase asks what actor groups can do together. Agents coordinate without incentives, without fatigue and at machine speed, so A5 applies the same inspection to them. What can a pair or chain of agents do that neither can alone? Which shared artifacts, such as files, queues, repositories and memory stores, are coordination channels and therefore injection relays? If the design relies on a second agent checking the first, are the two independent in model, prompt, tools and inputs, or will one universal injection compromise both? How far does one compromise propagate before it hits a human, a validator or a segmentation boundary? Can any agent acquire tools, create accounts, provision infrastructure or deploy agents? And on the human side: does the approval workflow degrade into rubber-stamping under realistic load?
A6: control mapping and RMF alignment
The roadmap gains an ATLAS mitigation reference per item, or a note that none exists. An appendix maps the assessment to the AI RMF. In practice the model is a MAP artifact, the ranked threats and trees are MEASURE artifacts, the roadmap is a MANAGE artifact, and the approval gates and traceability rules are GOVERN evidence. Two further outputs: a one-page human-oversight design statement that says what a person sees, decides and can override at each approval edge, and how the system is switched off, which the specification calls the most-read page of an agentic TRACE report; and a residual-risk statement in agentic terms, naming which ingestion edges remain injectable, which actions remain ungated, and which of the eight invariants are not enforced, so that whoever accepts the risk knows what they are accepting.
Running it with an AI assistant
TRACE's co-working rules apply unchanged, with four additions for the case where the system under review is itself an agent. The sources may be hostile, so the analysis assistant runs with no tools that can act on the target, no shared credentials and no write access to its memory or configuration, and any instruction-like content in the sources is recorded as a finding. The analysis assistant never exercises the target: drafting an attack tree is analysis, and sending an injection to a production agent is testing, which needs its own authorisation, scope and safety review. If the assistant is the same model family as the target it may share the target's assumptions about what counts as an instruction, so a person or a different model reviews the instruction-versus-data classification. And assistants confabulate framework identifiers, so every ATLAS, AI RMF and GenAI Profile reference in a report is checked against the published source before release. The mapping files in the repository record the versions they were checked against.
Scope
The extension consumes ATLAS and the AI RMF. It does not restate them, and it does not compete with the OWASP lists, MAESTRO or the CISA guidance on agentic services. A related-frameworks page in the repository summarises each of those and says how it relates. ATLAS answers "what have adversaries done to AI systems, and what stops it?" The AI RMF answers "what does a governance process expect to see?" TRACE answers "which of those matter for this system, given its assets, invariants, roles and edges?"
It is version 0.1. NIST's agent-specific work, including the identity and authorisation concept paper, the agent-security overlays and the Cyber AI Profile, is still largely in draft, and A6 is designed to take those documents as additional crosswalk targets when they finalise. We use the method in every architecture and review engagement. If you use it and something does not fit, open an issue.