This page is written for the party that creates the requirement rather than the party that has to meet it. You are not our customer, there is nothing here to sign up for, and using any of it implies no endorsement of us in either direction.
Not because anyone is hiding anything. Because that is the only artifact that exists. Every record of what an automated system was permitted to do is produced by, stored in, and formatted for the system being examined.
You request records. The firm assembles them, from logs its own applications wrote, into a format it chooses, covering a period it selects. The firm is cooperative and the records are probably accurate. But cooperation is a precondition of the exercise, and every step of the chain runs through the entity whose conduct is in question. A firm that could not produce the records and a firm that would not are indistinguishable from outside.
A signed attestation verifies against a public key. It does not need our servers, the firm's servers, or anyone's permission. Whoever holds a copy can check it — the counterparty who received it, the beneficiary who was affected by it, you. The firm is no longer the sole custodian of the evidence about its own conduct, and it cannot make an artifact stop verifying by declining to help.
That inversion is the whole argument. It does not make a firm more honest and it is not a substitute for examination. It moves one specific thing — the question of whether an action fell inside granted authority — out of the category of things you must be given and into the category of things you can check. It does not move when the authority was created. An artifact you hold verifies without the firm's help; nothing in it establishes that it existed before the action it covers, and section 02 says so rather than leaving you to find out.
We attest to a decision something else made. We do not observe the decision being made. That is a scope line, not a roadmap item, and it does not close with more engineering.
An attestation records that a deciding system declared an outcome, under a named policy, over a stated set of inputs. It does not record whether the reasoning was sound, whether the inputs were honest, or whether the decision was made in good faith. An agent acting maliciously inside its mandate, citing a genuine determination, passes every check on this page. The bound holds. The intent is not examined, and nothing here claims to examine it.
Stated as a list of what does and does not follow, because the difference matters more than the total. Every "yes" below was run against a live artifact before this page was written.
validFrom set to last March, and it verifies perfectly: signature good, window covering the action, every other check on this page green. Re-signing a backdated document produces a valid signature over a backdated document. Nothing in these artifacts binds a signature to a wall-clock moment.enforcementMode: "pre_transaction_check". That is the issuer's intent, recorded in a document. Whether a check ran, and failed closed, is a property of a deployment and has to be measured there. A field cannot enforce anything.Including the two artifacts that must fail. A tool that returns success for everything establishes nothing, so the failing cases are published beside the passing one.
Any single artifact either verifies or it does not, and that is a five-second answer. The supervisory question underneath it is different: what proportion of a firm's automated activity is conducted under mandates that produce checkable artifacts at all?
A firm with complete enforcement and a firm with enforcement on one desk both hand you artifacts that verify. The artifacts look identical. What separates them is coverage, and coverage is a property of a population rather than of a document — which means it is not something any individual attestation can tell you, no matter how well it is signed.
We think coverage is the right shape for a supervisory metric here, and we want to be precise that this is an argument we are making, not a capability we have built. There is no coverage measurement in the protocol today, no agreed denominator, and no way for an examiner to establish one from artifacts alone. Defining the denominator honestly is most of the problem, and it is not a problem a vendor should define by itself.
Two different records exist about an agent's behaviour, and each is blind to a different half.
An attestation layer records what a deciding system declared — the policy, the inputs, the outcome, signed. It cannot tell you whether the thing it describes ever executed.
A runtime observation layer records what actually executed — calls made, payments attempted, paths taken. It cannot tell you what was authorised, because authority is not visible in a trace.
Four conditions are visible only to the pair:
Each of these is a discrepancy between the records. Neither layer computes any of them alone, and a firm holding only one of the two can report itself clean while every one of them is occurring.
An attestation carries an assurance level with two values: self-declared and
independently-observed. The second has been specified since July 2026 and no implementation
ships today. The first implementation is scoped to Arbis, a runtime assurance partner. Everything above
describes what the pair would make visible. Specified is not shipped, and every attestation you can obtain
from us today is self-declared.
What the pair still cannot establish. Arbis's own stated limit travels with this claim: it describes the executions it sees, and cannot prove that an unobserved path does not exist. A page arguing that pairing two layers closes a gap has to say what the pair still leaves open, and that is the thing it leaves open. The four conditions become visible; the universe they are visible across is still bounded by what the observation layer was routed through.
Portable attestations solve authenticity. They do not solve completeness, and nothing on this site should be read as claiming otherwise.
A firm can hand over a hundred clean determinations and withhold the hundred-and-first, and all hundred verify. That is the whole problem, and no property of the signatures addresses it. The cryptography for transparency logs is solved. What is unsolved is who runs the log, who is obliged to publish to it, what a gap in it legally means, and how a firm demonstrates completeness without exposing commercially sensitive volume. Those are governance and regulatory questions, and we cannot answer them by ourselves or by shipping anything.
This is the point at which the guarantee stops and ordinary examination resumes. A cryptographic record can establish that what you were shown is genuine. Establishing that you were shown everything is a different kind of problem, and it is not one signatures can reach.
Enforcement at the signing boundary narrows the gap, because an action that cannot be signed without passing a check cannot occur silently — the population of possible actions and the population of recorded ones converge. That is why the enforcement point matters more than the record format.
It narrows the gap; it does not close it. It holds only for actions routed through that boundary, and establishing that all of them are is, again, a coverage question rather than a cryptographic one.
Every artifact on this site identifies parties by cryptographic key. Cryptography gives continuity, not identity: it establishes that the same key signed both of these things. It does not establish who holds that key, whether they are who they claim, or whether they are the same legal person as last quarter.
A workable Know Your Agent standard therefore needs a registry layer that cryptography cannot supply — something that binds a key to an accountable party and keeps that binding current. What that layer should be, who operates it, and what obligations attach to an entry are regulatory questions rather than engineering ones, and we would rather say so than imply that a better signature scheme reaches them.
There is no supervisory dashboard here and we are not going to publish one yet. A console designed without supervisory requirements is a vendor guessing in public about what oversight needs, and shipping it would make the guess look like a standard. Verification is different: the artifact already exists and the checks are already defined, so it can be built before anyone specifies requirements. That is why this page offers a verifier and not an interface.
Nothing here asks for your details. There is no form, no account, and no commercial call to action on this page or on the verification page, deliberately. Examining a record produced by a firm we sell software to does not put you in a relationship with us, and a verification surface with a lead-capture form on it is not a verification surface.
The tooling is MIT-licensed and self-hostable, and a verifier you run from your own infrastructure is worth more than one you load from us. If any of the above is wrong, or the limits are stated in a way that would mislead an examiner, we would rather be told than not.