docs: stop claiming hardware attestation unconditionally; move identifiers off agentrust.io - #423
Merged
Merged
Conversation
…entrust.io The README said "Each session produces a signed, hardware-attested TRACE Claim" with no qualifier, and the TL;DR two paragraphs below tells you to pip install and start in software mode with no hardware required. Both cannot be true. In software mode the claim is signed but not hardware-attested, so the sentence now says so. Separately, agentrust.io is not our domain: it resolves to parked AWS addresses. The JSON Schema $id values for trace-claim, audit-entry and catalog-entry pointed there, as did the @context in two test fixtures and the maintainer email. Those identifiers never resolved, so nothing that worked stops working, but publishing schema ids on a domain someone else could take is not a good position. tag:agentrust.io,2026:trace-v0.1 is left alone on purpose. It is a cross-repo identifier carried inside signed payloads, so it needs a transition decision rather than a find-and-replace. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two accuracy fixes.
1. The README contradicted itself
Line 29 said, unconditionally:
Two paragraphs below, the TL;DR says:
Both cannot be true. In software mode the claim is signed but not hardware-attested. Now reads "hardware-attested when the gateway runs in a TEE and signed-only in software mode", which is what the runtime does.
This is a positioning call as much as a wording one: the honest version is still a strong claim, and it is the one that survives someone running the quickstart and inspecting what they got.
2. Identifiers moved off
agentrust.ioagentrust.iois not ours; it resolves to parked AWS addresses. These pointed at it:$idfortrace-claim,audit-entry,catalog-entry@contextin two test fixturespyproject.tomlAll now
agentrust-io.com. They never resolved, so nothing that worked stops working, but publishing schema$ids on a domain a third party could register is not a position to hold.Deliberately unchanged:
tag:agentrust.io,2026:trace-v0.1. That EAT profile identifier appears in 125 files across the org and sits inside signed payloads. An RFC 4151 tag URI is only valid if the minter controlled the domain on the stated date, so it is wrong rather than misspelled, but changing it is a cross-repo transition with a verifier-compatibility question attached. Raising separately.Note on the test environment
The suite initially failed on
test_post_quantum_manifest_without_pq_extra_fails_closed_cleanly. Not a regression: this clone's venv had agent-manifest 0.5.0 installed whilepyproject.tomlrequires>=0.6.1, so it was reproducing the exactRuntimeErrorthat 0.6.1 fixed. Upgrading the venv to 0.7.0 resolved it. CI installs frompyproject.tomlso it was never affected, but anyone with a stale local env will hit it.893 passed, 8 skipped.