From Claim to Proof: SOVP Now Speaks AgenTrust TRACE
AI Summary / tl;dr
- TARGET_ENTITY: sovp-agentrust-bridge (PyPI: litzki-sovp-agentrust-bridge, v0.1.1)
- FUNCTION: Translates a SOVP attestation result into a signed AgenTrust TRACE v0.2 Trust Record (Ed25519, RFC 8785 JCS canonicalization)
- CONFORMANCE: TRACE Level 0 (TR-ENV, TR-SIG, TR-POL) — 8/8 checks pass in
trace-tests verify --level 0 - VERIFIED_LIMIT: A tampered record (data_class downgraded from internal to public) fails signature verification with exit code 1, reproduced in CI on every run
- CORE_THESIS: The bridge proves exactly one thing: a TRACE record was produced by the holder of a specific private key and has not changed since signing. That is a transcription and signature guarantee, explicitly distinct from hardware attestation, independent appraisal, or supply-chain provenance — and the record says so about itself.
SOVP audits a provider's actual infrastructure and issues a cryptographically signed record of what it finds. AgenTrust is building TRACE, an open format for trustworthy AI agent records. Since September 22, 2026, a new bridge connects both systems: sovp-agentrust-bridge, published on PyPI as litzki-sovp-agentrust-bridge, translates a SOVP attestation result into a signed AgenTrust TRACE v0.2 Trust Record.
The package is open source. Source code: github.com/litzki-systems/sovp-agentrust-bridge. Package: pypi.org/project/litzki-sovp-agentrust-bridge, current version 0.1.1.
What the bridge actually does
The bridge takes a SOVP attestation result and rewrites it as a TRACE v0.2 record. It then signs that record with Ed25519 over the canonical RFC 8785 (JCS) form. A successful verification proves exactly one thing: the record originated from the holder of that private key and remained unchanged since signing. That is a transcription and signature guarantee, explicitly separate from the measurement guarantee of a hardware attestation.
Litzki Systems signs, as operator of the SOVP attestation pipeline. The signing key is a self-provisioned Ed25519 key. In production, the operator of the SOVP instance retains it permanently.
The limits the record discloses about itself
A record is only as credible as what it honestly admits to leaving open. Four limits sit deliberately inside the record itself:
| Field | Value | What it means |
|---|---|---|
runtime.platform |
software-only |
SOVP's result rests on a software-side claim, separate from a hardware attestation |
appraisal.status |
none |
Only the caller's own policy evaluates the SOVP result |
build_provenance.slsa_level |
0 |
The record is limited to the signature guarantee; it makes no claim about the supply chain of the audited system |
origin.kind |
third-party-control-plane |
The evidence comes from SOVP, an external system that supplies the runtime claim rather than measuring it directly |
This honesty has a direct consequence: the record reaches TRACE conformance at Level 0 (TR-ENV, TR-SIG, TR-POL). Higher levels require hardware measurement or independent appraisal — guarantees that sit outside what a transcription bridge can honestly deliver.
Two proof points
Successful signature verification. A signed record built from a SOVP result with status CERTIFIED passes trace-tests verify --level 0 with eight of eight checks: environment, signature, and policy checks, all PASS.
Rejected tampered record. The same record, altered afterward: data_class rewritten from internal to public, signature left untouched. The classic downgrade attack, where someone reclassifies sensitive data as public after the fact without re-signing. Result: TR-SIG FAIL, signature verification fails, exit code 1. The same rejection reproduces at the library level via agentrust_trace.verify_record, which raises an InvalidSignature exception. This exact case runs automated in CI on every run.
# Verify a signed TRACE record at Level 0
trace-tests verify --level 0 record.json
# 8/8 checks: TR-ENV, TR-SIG, TR-POL — PASS
# A tampered record fails the same command
trace-tests verify --level 0 tampered.json
# TR-SIG FAIL — exit code 1What is tested and what remains open for production
Tested and reproducible: Level-0 TRACE conformance via CI and independently via trace-tests verify. Ed25519 signature integrity end to end, including a real tamper-and-reject case, well beyond a plain schema check. Field values checked against the TRACE v0.2 schema. The canonical signature path also works with non-ASCII content from the SOVP payload.
Open for production use: custody and rotation of the signing key sit with the operator. The bridge accepts a key path; the caller owns the key lifecycle. A hardware-measured attestation path remains for the future and requires a different measurement source than SOVP's current output. An independent appraisal layer is left to whoever needs appraisal.status beyond none. Verified marketplace status comes from an AgenTrust maintainer review, independent of SOVP.
Why this matters for SOVP
SOVP stands for independent, cryptographically signed proof of the actual state of digital infrastructure. Finding over estimation. This bridge extends that principle into a second ecosystem. A SOVP result stays portable: it works inside the SOVP portal and outside it, now also as a TRACE record that any verifier can check independently of SOVP, with the same public key.
sovp-agentrust-bridge is listed in the AgenTrust Marketplace. SOVP itself remains documented as an IETF Informational Draft — the same layer where Google's Web Bot Auth proposal and SOVP's Ed25519 DNS anchor already point toward the same convergence: cryptographic proof over self-declaration, wherever automated systems interact without a human in the loop.
For the full protocol specification, see Sovereign Validation Protocol. For the Python reference implementation, API, and quickstart, see Developers.
If your infrastructure is not yet cryptographically anchored at Layer 0, the SOVP Validator Audit establishes the baseline: 180+ deterministic checks, binary verdict, no production access required.
[/// INITIATE INFRASTRUCTURE AUDIT]Source code, PyPI package, and the full conformance test are public. Questions about integration go directly to Litzki Systems.
