Two teams look at the same system and walk away with two different risk assessments. Not because either team is careless, but because "assess the cyber risk" is rarely a repeatable process. It is a set of judgment calls, made differently by whoever happens to be in the room.
Most engineers will recognize that much from their own projects. The reason this continues to happen deserves a closer look.
The findings that matter are about things nobody examined
An assessment is good at cataloguing what is there. It is much weaker at finding what is absent, and absence only turns up if somebody goes looking for it. The gaps tend to be things like:
- The path through the system that nobody protected, because nobody traced it.
- The behavior nobody tested for. Testing shows that a system does what it is supposed to do. It does not show what the system can be made to do instead.
- The component reused from an earlier program, still carrying assumptions from the system it was designed for. It works exactly as built. It was built for somewhere else.
- The dependency that only matters when one specific subsystem fails, which nobody had mapped.
None of those show up in an inventory of what is installed. Each one is found only if somebody thinks to ask, and which questions get asked depends on who is in the room and how much time is left in the schedule. That is why two competent teams reach different answers.
It is also why the cost of finding these things late is so high. The capabilities needed to detect a problem can be simple to add while the system is still being designed. Added after that system has been built, integrated and tested, the same capability stops being an engineering decision and turns into a risk-acceptance memo that somebody has to sign.
Most of these gaps are unremarkable on their own. Functionality that was left in because removing it seemed like more trouble than leaving it alone. An interface designed for the system the component came from, not the one it now serves. A dependency that only matters in a failure mode nobody walked through. None of it looks like a security problem until somebody makes it one, and whether it surfaces as an accidental failure or a path for attack often comes down to who finds it first.
What Terrain Trace does
Terrain Trace is a local, AI-assisted tool that runs mission assurance end to end, from a program's existing documents through to testable security requirements. It is not intended to replace the engineer's judgment, but to give that judgment a repeatable process to run inside.
What goes in at the start is material a program already holds: the system CONOPS, which carries the purpose and the mission of the platform, the security architecture, and the security mitigations already in place. Everything after that is built on top of those three.
The tool uses seven stages to keep the assessment structured. Each stage addresses a part of the analysis that is often missed when the process lacks that structure.
- Security Architecture. Define the boundary and enumerate every path data takes in and out. Import machine-readable architecture into a pan-and-zoom boundary board, then work on it directly: add or remove subsystems, add or remove information flows, and set the direction each flow runs. Map which missions depend on which subsystems. Without this, a subsystem compromise is a technical finding that nobody can translate into a mission consequence.
- Subsystem Criticality. Rate how much each subsystem matters to the missions it serves. Without this, everything is protected the same amount, which means the things that matter are under-protected and the rest is over-protected.
- Defensive Mitigations. Record the mitigations actually in place. The gap between what is covered and what is not is the thing worth finding, and an inventory alone will never show it to you.
- Threat Assessment. Build scenarios: attack vectors, attack paths, targeted subsystems, decomposed across confidentiality, integrity and availability. Without structure, threat analysis defaults to whatever the team already worries about.
- Risk Assessment. Score Likelihood against Consequence per mission, and map techniques to the mitigations that counter them, flagging where nothing stands in the way. This is where the unprotected paths become visible.
- Security Requirements. Turn the gaps into testable shall-statements, each paired with a verification method. Without this, the assessment ends as a report that changes nothing.
- Report and Exports. A full report carrying the trail from threat to vulnerability to inherent risk to residual risk, plus machine-readable exports for the tools risk and compliance teams already run.
Every one of those stages already happens somewhere in most engineering organizations, on a whiteboard or in a spreadsheet or in somebody's head. What is usually missing is the consistency, so that the same process gets run the same way by whichever team happens to pick it up.
Cyber risk or mission assurance?
Most programs call this work a cyber risk assessment, and that is the label most programs will use when looking for a tool like Terrain Trace. But the term can narrow the analysis toward vulnerabilities, mitigations, and severity ratings rather than the question that matters most: Does the mission still succeed when something goes wrong?
A severity rating tells you how serious a finding appears at the component level, but not what happens to the mission if that component loses a specific function under particular conditions. It does not explain which mission capability is affected, how it fails, or how much that failure matters.
Terrain Trace approaches risk through the lens of mission assurance. It maps mission dependencies across systems and subsystems, then evaluates likelihood and consequence against those named missions rather than a free-floating severity scale.
The result is not simply that a component is rated high, medium, or low risk. It is that a specific threat path can cause a particular mission to lose a particular capability in a defined way. That is a conclusion engineers can challenge, act on, or design out.
When you would run it
It can be used at any time, but two specific moments are most useful. The first is early in design, while the architecture is still open and a change costs very little. The second is after the platform has been updated, when a subsystem has been added or removed, or a flow has been rerouted, and somebody needs to know what that change did to the risk picture. Running the assessment again against the previous state answers that directly, because the two results were produced the same way and can be compared. It is worth running whenever the answer might have changed.
Can you trust an assessment an AI model helped write?
Not on its own, and Terrain Trace is not built as though you should.
Using an AI model in an assessment tool does not guarantee it understands the system correctly. Ask what caused a specific system loss, and it will produce an answer, but that answer may be based on an incomplete view of the architecture or may overlook existing mitigations. Some conclusions will be accurate. Others may be generic, incomplete, or wrong because the information was unclear, contradictory, or disconnected from the broader system. The most dangerous errors are often the most convincing: fabricated details that sound plausible because they match familiar system patterns. Without structure, grounding, and validation, the model can lead the analysis away from the actual platform while sounding certain it is on the right path. That is what the harness around Terrain Trace is built to prevent.
Every AI application runs inside a harness of some kind. It has to, in order to manage context, call tools, and keep track of what has been loaded. That part is unremarkable. What matters is what a harness is built to enforce, and Terrain Trace's is built to keep the model in the role of an assistant rather than a decision maker.
It rates criticality and records its rationale, which means a reviewer can see the reasoning and overrule it rather than take it on trust. It drafts threat scenarios, considerably more of them than a small team has time to brainstorm, and the strongest can be kept. Where techniques are mapped to the mitigations that counter them, that mapping is deterministic rather than recalled by a model, because recall is exactly the step where something plausible and wrong tends to appear. A defense-in-depth check keeps it from recommending every available safeguard simply because it can.
None of that turns the tool into the security engineer. It does mean the security engineer is not starting from a blank page each time, and that whatever the AI proposes has been checked before it counts for anything.
Local by default
Architecture diagrams, findings and mission data are exactly the kind of material that should not leave an organization's network to get processed. Terrain Trace is designed to run on the models an organization already trusts, with a separate model handling each role, pointed at a workstation or a box on the organization's own network.
That setting is the default and can be changed based on your organization's preferences. Terrain Trace can use local models, connect to frontier models through hosted APIs, or combine both approaches. The right configuration depends on the sensitivity of the system being assessed, and that decision belongs to the organization conducting the assessment.
How much security is enough?
The honest answer is that this is a judgment rather than a threshold, and NIST SP 800-160 Vol. 1 Rev. 1 gives that judgment a name. A system is as secure as reasonably practicable, or ASARP, at the point where any further improvement would demand a disproportionate cost in schedule, budget or performance, violate a system constraint, or force an unacceptable change in the way the system is operated. Enough is not a number. It is the edge of that trade space.
It is worth finding that edge deliberately, with the criticality of each subsystem visible in front of you, rather than arriving at it by default because it is what the last project happened to do.
What Terrain Trace is for is making that judgment explicit and repeatable. A process that produces the same answer twice is not an especially exciting claim to make, but it is the durable kind of improvement that holds up when two teams run the same assessment a year apart and have to compare notes.
It is also the problem our Defending Complex Systems in the AI Era workshop was built around: integrating AI into high-stakes systems, and defending those systems once it is there. It runs through Cybersecurity Fundamentals for Space as well, which works from space system architectures through the threats against them and the attack surface they expose, to the protections that answer it, so that security is designed in from the start rather than added once the platform is built. Terrain Trace is one approach to making mission assurance work more structured, traceable, and easier to defend. We believe the approach can work across many platforms and can be customized to reflect an organization's missions, systems, frameworks, terminology, and decision-making processes.
If your team is working out how to bring structure and AI assistance into its own mission assurance work, without sending sensitive architecture somewhere you did not choose, we can help adapt the approach to fit your organization. That is a conversation worth having.
