The newsroom flagged AgentField’s signed-audit-chain documentation because a docs URL cannot tell builders whether this is a new launch, a paper, or shipping infrastructure. AgentField is a Toronto open-source control plane that emerged from stealth on 10 December 2025, arguing that autonomous agents need W3C DIDs, verifiable credentials, and cryptographic receipts rather than shared API keys and editable logs. For teams putting agents on money, health, or other regulated paths, the difference between a marketing page and an exportable, independently verifiable chain is the difference between logs and evidence.
The current quick guide says a multi-agent workflow can emit a signed credential per step, return the chain in one request, verify it with a single POST or CLI command, and audit the JSON offline from a Provenance page using bundled DID data. That is a serious governance primitive if it is implemented, versioned, and used. This review checks those claims against official docs, control-plane source, GitHub history, the 2025 launch record, and independent reporting.
What we checked
- Is this newly launched functionality or pre-existing documentation? confirmed. It is pre-existing documentation of a control-plane capability, not a newly launched 2026 product. AgentField already advertised verifiable credentials and tamper-proof audit receipts at its 10 December 2025 launch. By 11 April 2026, GitHub issue 415 treated GetWorkflowVCChain and GET /api/v1/did/workflow/{id}/vc-chain as existing code being split, not invented. [11][7][8][1]
- Is there a product announcement, changelog, repo release, or customer use case validating adoption? partly confirmed. A company launch announcement and independent SiliconANGLE coverage exist, and the GitHub repo still ships the VC-chain path in current 0.1.x releases. No named production customer, case study, or regulator-facing audit of this chain was found. The latest staging tag, v0.1.143-rc.4, is explicitly marked not recommended for production use. [11][12][13][10]
- Does the shipped code match the documented DID, hash, chain, verify, and offline-audit story? partly confirmed. Docs and README specify DID-backed agents, SHA-256 input and output hashes, workflow VC chains, HTTP verify endpoints, af vc verify, and a Provenance UI. GetWorkflowVCChain does return component VCs, an on-demand workflow VC, and a DID-resolution bundle, but this file does not itself topologically sort steps, and DID-bundle collection failures are swallowed rather than failing the export. [1][2][9][10]
- Has any independent customer production use of the signed audit chain been shown? unresolved. Launch coverage cites target industries and an analyst comment about traceability, but names no paying customer running these chains in production. Public GitHub examples and the docs’ five-agent scenario are product demos, not adoption proof. [12][11][1]
What we found
- AgentField documents signed workflow audit chains as a first-class product surface, not a hidden API. The signed-audit-chain guide says each step can produce a signed credential, one request returns the chain, verification is a single POST, and each credential carries SHA-256 hashes of input and output so a step can be checked without exposing the data. The credentials reference adds execution VCs, a three-tier platform/node/function hierarchy, Ed25519 signatures tied to agent DIDs, workflow VC chains in topological order, HTTP verify and export endpoints, and offline verification with af vc verify. Feature docs list signed audit chains and offline verification under cryptographic proof. [1][2][3][4]
- Identity is DID-based and designed to travel with the agent. Official identity docs assign each agent and function a did:key identifier backed by Ed25519, optionally expose did:web documents, and store private keys with AES-256-GCM in a local filesystem keystore; HSM and cloud KMS integration is described as future work. The IAM blog presents DIDs and W3C Verifiable Credentials as the answer to OAuth’s callback and static-scope limits, and shows exporting GET /api/v1/did/workflow/{id}/vc-chain then running af vc verify offline. That same path is named in GitHub issue 415 as the audit-chain builder. [5][6][7]
- The control-plane implementation exists and predates the current docs framing. Issue 415, created 11 April 2026, says vc_service.go already owned issuance, validation, storage, and audit-chain building, and proposes moving chain assembly to vc_chain.go. The v0.1.70 to v0.1.71-rc.1 compare shows a refactor extract that added vc_chain.go rather than a greenfield feature. Raw source for GetWorkflowVCChain requires the DID system to be enabled, loads execution VCs for the workflow, generates a workflow VC on demand, and attaches a DID-resolution bundle for offline checks. [7][8][9]
- Two implementation details matter more than the marketing copy. First, vc_chain.go does not sort component credentials; order is whatever GetExecutionVCsByWorkflow returns, so the docs’ topological-order claim is not proven in this file. Second, collectDIDResolutionBundle skips unresolvable DIDs and, if bundle collection fails, GetWorkflowVCChain continues with an empty map instead of failing closed. Builders who treat the export as auditor-ready should verify sort order and refuse exports that lack a complete DID bundle. [9][2][1]
- Offline verification is real but not fully air-gapped. Credentials docs say the verifier checks Ed25519 signatures, issuer DID resolution, document integrity, expiry, and revocation, and they explicitly mark revocation as an online check only. The receipts guide and credentials page describe a Provenance UI that verifies exported JSON against bundled DID data. CLI naming is inconsistent in first-party material: the audit-chain guide says download for af verify, while the credentials page and README say af vc verify. [2][4][1][10]
- The product launched around these ideas in December 2025, but adoption remains unproven. ACCESS Newswire published AgentField’s 10 December 2025 announcement of an Apache 2.0 control plane with DIDs, verifiable credentials, and cryptographic receipts; SiliconANGLE independently reported the same launch and quoted Constellation Research on traceability. GitHub still lists Apache 2.0, DID identity, VCs, and af vc verify. Releases show v0.1.142 dated 19 October 2026 and staging v0.1.143-rc.4 dated 20 October 2026, the latter labeled not recommended for production. No named customer deployment of the signed audit chain appears in those sources. [11][12][10][13]
What it means
Treat AgentField’s signed audit chain as a usable provenance export inside this control plane, not as a newly launched standard and not as a drop-in substitute for a regulated audit program. If you already run AgentField, enable DIDs, keep require_vc_execution and persist_execution_vc on, export GET /api/v1/did/workflow/{id}/vc-chain, store the JSON with its DID bundle, and verify with the CLI and an independent hash check of inputs and outputs. Fail closed when the DID bundle is empty, when CLI command names disagree with your installed binary, or when you need revocation status while offline.
If you are choosing an agent backend for finance, health, or cross-org delegation, this is one of the few open-source stacks that makes cryptographic receipts a default product idea. Pin a non-rc 0.1.x release, read identity and credentials docs as the contract, and run your own conformance tests against W3C VC verification and key custody. Local AES-256-GCM file storage is not an HSM. Do not cite AgentField as proven in production until a named customer or independent audit exists.
Still open
- When was the signed-audit-chain docs page itself added or rewritten, versus the older credentials API?
- Does GetExecutionVCsByWorkflow return topological order, or only insertion order?
- How complete is W3C Verifiable Credentials interoperability beyond AgentField’s own verifier?
- Where are private keys held in Kubernetes or multi-replica deployments, given the local-filesystem keystore?