Historical position paper
From Declaration to Proof
The March 2026 paper proposed a Seal, Capture, Prove architecture for retaining signed governance decisions. Read it alongside the corrections below and the current implementation guide.
Attested Intelligence · Originally published March 28, 2026 · Web summary revised October 3, 2026
RecordHistorical PDF: From Declaration to Proof: published March 2026. The original document is preserved. Its proposals and descriptions may differ from the published implementation. For current capabilities and limits, see Trust and scope.
Web revision history
On September 28, 2026, the web version removed named-company examples, corrected typography and added implementation notes. On October 3, 2026, the web transcription was replaced with this summary and current corrections. This avoids repeating the paper's broad claims about logs, complete capture and signed-policy configuration as current product statements. The original URL, publication date and downloadable PDF are retained.
The retained-record question.
A recipient may need to check an exported tool-decision record outside the producer's dashboard. AGA supplies a defined construction for that check: signed fields, linked receipts, Merkle proofs and a signed checkpoint. An expected signing key must be obtained through a separately trusted channel.
The result concerns the supplied record as the verifier parses it. It does not establish that every action was captured, that the export is fresh, that a permitted action ran, or that the key holder never signed another history.
Corrections to the original argument.
- Signed policy and suitable policy
- A signature can bind a policy without making it appropriate. An authorized signer can sign an unsafe configuration. aga-proxy uses unsigned JSON policy bound into receipts by its canonical hash; the sealed Policy Artifact is a separate aga-mcp-server construction.
- Key custody and attribution
- A separate process does not keep a signing key away from an agent that shares its filesystem permissions. Establish the actual OS identities and credential access. A pinned gateway key alone does not identify a particular agent, user or tool operator.
- Capture and refusal
- aga-proxy does not forward covered tools/call requests it denies. Its default permissive profile denies nothing on policy grounds. Some refusal paths produce no receipt, and alternate routes require separate deployment controls. A fail-closed action does not necessarily leave signed evidence of the failure. See the capture limitation.
- Other evidence systems
- Signed logs, protected retention, independent collection and existing exports can support a reviewer's evidence requirements. The paper's category-wide contrast with logging is too broad. Compare the actual artifact, collection boundary, key distribution and recipient's task.
- Integrity and disclosure
- Hashing arguments is not a general confidentiality guarantee. Low-entropy values may be guessed, and receipt metadata or denial reasons can disclose information. Published verifiers also have documented parser differences. See the current security notes.
Evaluate the shipped implementation.
The historical examples and standards mappings are proposals, not evidence of compliance, endorsement, complete threat coverage or deployed runtime assurance. Continuous binary measurement and the proposed synthetic-response mode are not established by the published decision-record path.
Start with the current synthetic reviewer case. It supplies the policy, request fixture, bundle and manifest, with reproducible success and failure controls. Qualify interception, identity, key custody, restart behavior and independent observation separately for a selected integration.
Related research records.
The NIST response, NCCoE response and CoSAI analysis retain their own dated scope. They do not constitute third-party approval of AGA.