Here is an uncomfortable fact about most of the security stack: when a tool tells you something is fine, you are trusting the tool. The green checkmark is an assertion. If the vendor’s logic is wrong, if the data was stale, if the dashboard was quietly edited, you have no independent way to know. You are not holding evidence. You are holding a claim.
That is acceptable for a lot of software. It is a poor foundation for trust decisions about machine identity — the decisions that show up, months later, in a breach postmortem or an audit finding. For those, the question that matters is not “does the dashboard say it is fine?” It is “can I prove it was fine, to someone who does not trust the vendor, after the vendor is gone?”
Assertions versus artifacts
The distinction we care about is between an assertion and an artifact. An assertion is a statement a system makes while you are logged in: it is true only as long as you trust the system making it. An artifact is a signed, self-contained object that carries its own evidence — it can be handed to a third party, stored for years, and checked independently long after the system that produced it is unreachable.
TrustFix is built to produce artifacts. When we attest to an identity’s authority, or seal a record of a decision, the output is something you can hold: a signed credential and a tamper-evident record, not a row in a database you have to take on faith.
The question that matters is not “does the dashboard say it is fine?” It is “can I prove it was fine — to someone who does not trust the vendor?”
Built on open standards, on purpose
The verifiability only means something if you are not forced to use our verifier. That is why the artifacts are expressed in open, interoperable formats. Agent authority is issued as a W3C Verifiable Credential, with keys you can resolve via did:key. Evidence can be exported in OSCAL for your compliance toolchain and OCSF for your SIEM. Revocation status is published through standard Token Status List mechanisms. None of these are TrustFix inventions; they are public specifications with multiple independent implementations.
The practical consequence is that you can take a TrustFix artifact and verify its signature, its issuer, and its claims using off-the-shelf libraries — no TrustFix account, no API call to us, no network connection to our servers required. If we were unreachable tomorrow, every artifact we ever issued would keep verifying exactly as it does today.
What this is — and what it is not
We want to be precise about the promise, because over-claiming verifiability is its own kind of dishonesty. A signed artifact proves what it states, by whom, at a point in time. It proves the authority an identity was granted and that a record has not been altered since it was sealed. That is a strong and unusual property in this category, and it is the property auditors and incident responders most often wish they had.
It is not a claim that the underlying world cannot change after the fact. A credential attests to a state; states evolve, which is exactly why revocation and expiry are first-class. Nor does an offline-verifiable artifact substitute for the judgment of deciding what should have been granted in the first place. We describe the shape of the guarantee here, not the internals that produce it — but the shape is the part you can actually check.
Why we hold ourselves to this
Pre-launch, it would be easier to ship a beautiful dashboard and ask you to trust it. We are deliberately doing the harder thing: making our most important outputs survive us. A vendor whose proofs only work while you are paying them has an incentive you should be wary of. A vendor whose proofs keep working without them has tied its credibility to something you can independently confirm.
That is the bar we are building to. If a number appears in TrustFix, it should be clickable back to a signed receipt — and that receipt should still mean something the day after you cancel.