Evidence bundle
A file of signed decisions, hash-linked in order and bound by a signed checkpoint. The export covers the receipts present. It does not prove every action was recorded.
For agent vendors
When your customer asks for evidence.
Give a technical reviewer a signed export of recorded tool decisions they can inspect outside your service. Start with the question they need to answer and one covered tool path.
The proposed handoff
A signed export your reviewer can retain.
Keep your existing logs and retention controls. AGA adds a portable signed export for a reviewer who does not have access to the system that produced it. Other signed-record systems may serve the same need; compare the fit before integrating.
Published verifier
A specified format, conformance examples and a separately published verifier. A reviewer can run the check locally without the producer's service.
Review summary
The agreed scope, expected signing key, deployment assumptions and observed limitations. A useful handoff explains the result without overstating it.
When an evaluation is worth doing
The recipient needs an offline record they can retain, your existing export does not meet that need, and both parties can establish an expected signing key. Agree what the export covers and which review decision it supports. If your current signed export already suffices, another format may add no value.
Scope of a passing check
What the reviewer can conclude.
- Integrity of the recorded receipts
- Signatures, ordering and Merkle commitments check as the verifier parses them. Duplicate JSON fields are accepted with the last value retained, so inspect the parsed output. An earlier genuine export can still pass; freshness needs an independently obtained checkpoint.
- Issuer, if the key is already trusted
- Pin the expected gateway public key from a separate trusted channel. A key copied from the bundle checks only internal consistency. The key holder can sign another history.
- Not complete capture
- A passing file cannot reveal actions never recorded. Some calls are refused without receipts. Coverage depends on the interception point and its deployment.
- Not execution or containment
- A receipt records a decision, not execution or a returned result. A passthrough receipt records an unevaluated method sent toward the upstream, not delivery. Whether an agent can bypass the gateway is a deployment question.
Read the trust model and known issues. The published format and company-authored verifier are not independent certification.
Evaluate before integrating
Make the sample pass.
Then make it fail.
Download the current case, inspect its policy and requests, and run the included verifier. Check a wrong signing key and a changed signed decision. The synthetic case does not contact a live gateway or demonstrate containment.
JavaScript and Python verifiers differ outside the tested corpus. Use the documented versions and read the exact result, not just a green badge.
Follow the static evaluationTechnical evaluation
A focused technical evaluation.
A proposed evaluation covers one selected workflow, an agreed policy and evidence scope, verification by your reviewer, and a written readout.
Attested Intelligence is founder-operated and before its first external pilot. Runtime work begins only after isolation, routing, key custody and data handling have been reviewed.
Fees, dates, support and acceptance criteria are agreed with the partner. A public reference or case study requires separate permission.