Sentinel Automata

The Provenance Question in Defense Autonomy

Sentinel Automata · · 6 min

The Provenance Question in Defense Autonomy

There is a deceptively simple question you can ask about any piece of hardware: where did this come from? For a phone or a laptop, the honest answer is usually a shrug, and it doesn’t much matter. For an autonomous system operating in a contested environment, the same shrug is a problem. As these systems take on more responsibility, that shrug turns from a compliance footnote into a first-order design constraint.

This is a public, industry-level argument. It names no specific system, customer, or program; it’s about a trend the whole sector is now reckoning with.

Autonomy raises the stakes on every component

A human-operated platform has an operator in the loop who can catch a fault and answer for the outcome. Autonomy removes that backstop by design. The system senses and acts on its own, which means the trust you used to place in the operator now has to be placed in the hardware and software themselves.

That shift changes what you need to know about your parts. It is no longer enough that a component works on the bench. You need to be able to say, credibly, where it came from and whether anyone in its supply chain could have influenced how it behaves. For an autonomous system, provenance is part of trustworthiness.

There’s a second-order effect worth naming. When a human operator is present, a marginal component fails safe: the operator catches the fault and compensates. Remove the operator, and the same marginal component fails into an autonomous decision loop, where a small irregularity can propagate into behavior no one intended and no one is watching. The tolerance for “we’re not totally sure about that part” drops sharply the moment nobody is holding the controls.

Why the honest answer is often “we’re not sure”

Modern robotics stacks are assembled from deep, global supply chains. A single subsystem may pass through many hands across many countries before it reaches an integrator, and each hop blurs the picture. The economics of the last few decades rewarded exactly this: source the cheapest capable part from wherever it’s made, and don’t ask too many questions.

For consumer electronics, that’s a rational trade. For defense autonomy it produces an uncomfortable situation: capable systems whose full provenance no one can actually account for. When you can’t trace a component to its origin, you can’t fully reason about its security or its reliability under stress, and you can’t rule out that someone had the opportunity to tamper with it. You are asked to trust a system whose parts you can’t vouch for.

The problem compounds with depth. It’s not only the visible subsystem you have to account for; it’s the components inside that subsystem, and the components inside those. Provenance is only as strong as the least-documented layer, and in a global supply chain the least-documented layer is usually several levels below where anyone is looking.

It’s worth being precise about what provenance is. It isn’t a guarantee that a component is flawless. Good parts fail, and accountable suppliers make mistakes. What it gives you is the ability to reason honestly about a component: to know its origin and its handling, and to know who had the chance to shape its behavior, so that when something goes wrong you can investigate rather than guess. Provenance you can account for is what lets you debug a system and stand behind it. Without it, when something goes wrong you are left hoping, and hope is not an engineering discipline.

Provenance as a design constraint, not a paperwork exercise

The instinct is to treat this as a documentation problem: collect the certificates, satisfy the auditor. That’s necessary but not sufficient. Provenance you bolt on at the end is only as good as the weakest undocumented hop upstream.

Treating provenance as a design constraint flips that. You decide, up front, that you will only build from parts and processes you can account for, and you accept that the decision narrows your options and raises your costs. In practice it means favoring domestic sourcing and ITAR-clean supply where it matters, building traceability into the system rather than around it, and being willing to say “we won’t use this component, capable as it is, because we can’t stand behind where it came from.”

That costs more than the cheapest-capable-part approach, and it is what separates a system you can vouch for from one you can only hope about. It also has a structural consequence. Once provenance is a real constraint, it pushes you toward owning the parts of the stack that carry the most trust, the case for building rather than assembling, because the layers that matter most for autonomy are exactly the ones you least want to take on faith.

Where provenance bites hardest

Not every component carries the same weight. A bracket is a bracket. But the layers that determine how an autonomous system actually behaves — the actuation that turns decisions into motion, the embedded compute that makes the decisions — are precisely where an unknown origin is most consequential and hardest to audit after the fact. A disciplined program spends its provenance budget there first, on the load-bearing layers, rather than spreading it thin across every part in the bill of materials.

The direction of travel

The provenance question is only going to get louder. As autonomous systems take on more consequential roles, the people who field them, and the public they answer to, will expect a straight answer to “where did this come from?” for the components that matter. Building toward a robotics stack whose provenance you can actually account for, US-built and ITAR-clean by design, is the harder path today and, we think, the correct one. The alternative is to keep shipping capable systems no one can fully stand behind, and to hope the question never gets asked in earnest.

It will.

Sentinel Automata is a U.S. robotics operating company.