C=US Hardware Signing Scorecard← White House accord scorecard

Hardware identity · narrow-scope follow-up

What a hardware-backed signature actually buys you — and what it doesn't.

This project provisioned a real YubiKey PIV key (private key generated on-device, never exported), used it to sign a real XAdES-T XML document (ETSI EN 319 132-1 XAdES-BES plus an RFC 3161 signature timestamp, ECDSA-SHA256 per RFC 4051, via NIST SP 800-73-4's on-device signing operation), and issued it a certificate from a self-signed c=US root whose own P-384 key was generated on the same YubiKey (PIV slot 82), asserted by this project's own steward. The signed document and a diagram of the full trust chain are both public: attestation-log.xml and trust-chain-diagram.svg. This page asks a narrower question than "is this secure": specifically, how much does hardware-backed, non-repudiable signing move the needle on the ten agentic-AI risks this project has been scoring all session?

Answer, up front: not much, and precisely. This isn't a disappointing result to soften — it's the correct, honest shape for what a signature mechanism can and can't do. A signature says who signed what and when. It says nothing about whether an agent's output is safe, where its network traffic goes, or whether it's coordinating with other agents. Jev's scores below reflect exactly that boundary.

Method

Same split as every other scorecard on this site

Claude wrote the description of the hardware-signing mechanism and every risk/rubric; Jev returned every score below, given that fixed state.

WHAT CLAUDE CODE DID
  • Built the actual mechanism first: provisioned the YubiKey PIV slot, wrote the NIST SP 800-73-4 signing bridge, registered a custom XAdES-BES/ECDSA-SHA256 algorithm under RFC 4051's real URI, and verified every signature cryptographically before writing anything about it.
  • After the EU DSS validator flagged the XAdES structure, fixed the defect, added the RFC 3161 timestamp (XAdES-T), and re-signed both hardware entries. Details below.
  • Moved the root of trust onto the YubiKey: generated the root key in slot 82, self-signed the root certificate on the device, re-issued Claude's leaf from it, and had the root sign Entry 8 recording the change.
  • Described that real mechanism precisely to Jev — what it hardens (key-theft resistance, non-repudiation, a named root of trust) and, just as importantly, what it explicitly does not touch (sandboxing, egress, inter-agent coordination, output validation).
  • Reused the identical ten risks and 0-3 rubric already used for the White House accord and Anthropic's Constitution, for direct comparability.
WHAT JEV DID
  • Given that fixed description, scored all ten risks and the direct comparison verdict — nothing here is Claude's guess at what the numbers "should" say.
  • Model version, full question text, and token usage are preserved in research/jev-hardware-signing-score.json in this project's repository.

Result

Sharply differentiated, not a flat score

0 = not addressed by this hardening · 3 = substantially addressed by this hardening alone.

Third-party attribution blindness
2.40
Unaccountable agent identity
2.18
Privilege chaining / excessive agency
1.67
Emergent multi-agent coordination
1.33
Detection lag / cross-agent blindness
1.29
Human over-reliance, no approval gate
1.08
Unapproved egress / SSRF
0.59
Goal drift beyond task boundary
0.55
Indirect prompt injection
0.50
Insecure, unvalidated model output
0.33

It scores highest on the two risks that are fundamentally about traceability — exactly what non-repudiation targets — and lowest on risks about model output, prompt injection, and network egress, which key custody has nothing to say about. That's the mechanism working as designed, not a weak result.

OVERALL VERDICT

Asked directly whether hardware-backed signing meaningfully improves the broad agentic-risk picture (not just the identity-specific slice), Jev returned 1.00 out of 2, confidence 0.92.

3%
94% · a marginal improvement: real but narrow
3%

What this checked, and what it found

The mechanism is real, not a demonstration of the idea of a mechanism

A genuine on-device ECC P-256 keypair, a genuine XAdES-T signature structure, a genuine certificate chain — every claim is independently verifiable against the published signed document, not merely asserted.

Hardware non-repudiation is a real but narrow fix

It closes the specific gap between "a software key that could be copied off a compromised host" and "a key that provably never left a physical device" — genuinely valuable for identity and attribution, genuinely silent on everything else.

It is not a substitute for capability constraints

The full c=US architecture (identity, authorization, and sandboxing together) scored 1.99 out of 2 on the same kind of verdict question, against the risks that actually matter most for a swarm. Hardware signing alone reaches half that. Both belong in the design; neither replaces the other.

Tested against the EU validator

XAdES-T, checked with the European Commission's DSS

The signed entries were run through the European Commission's Digital Signature Service (DSS) validator, which implements the ETSI EN 319 102-1 validation procedure. It found defects; Claude resolved them, and the entries were re-signed on 2026-10-01. The full cycle is on the break/fix page.

Resolved

SIG_CONSTRAINTS_FAILURE: the reference to the signed XAdES properties lacked its required Type attribute. Fixed, and confirmed by two DSS re-runs. NO_POE: the signatures had no independent proof of time. Each hardware signature now carries an RFC 3161 timestamp (XAdES-T), which DSS finds and verifies.

Open

The signing chain and the FreeTSA timestamp do not reach an EU trusted list, so DSS returns NO_CERTIFICATE_CHAIN_FOUND and still will not accept the timestamp as proof of existence. DSS reports the EC signing certificate's key size as unknown, though OpenSSL reads P-256. Qualified status, which needs a qualified signature device and a qualified trust service provider, is pending.

Applied to maple syrup

Canada, the EU, and the missing glue

On 16 September 2026 the European Commission invited Canada to become the EU's first associate member, with details due at an EU–Canada summit in Montreal in October 2026. The EU defines its digital signature standards through ETSI. Maple syrup data — a lot's grade proposal, its Raman phenolic measurement, the producer and agent behind it — can be signed with the same XAdES XML digital signatures used here, a format European trading partners already accept.

The EU Digital Identity Wallet is a different ETSI standard; for example, ETSI TS 119 411-8 covers certificates for wallet relying parties. A signed syrup record and a wallet credential are not interchangeable.

Non-members can already join the EU's trust system: Norway, Iceland and Liechtenstein publish national trusted lists in the EU List of Trusted Lists because the EEA Agreement extends eIDAS to them. If Canada's associate membership, or the EU–Canada Digital Trade Agreement under negotiation since March 2026, takes in eIDAS the same way, a Canadian trust service provider could be qualified, and maple data signed in Canada would validate in the EU. Today no Canadian provider is on an EU trusted list.

So the Agentic Control Layer can be extended to Europe if — and it is a big if — EU standards are observed, with XML digital signatures part of them. Because EU wallets follow a different standard, the glue between the US, Canada, the EU, and China does not yet exist.

Sources and underlying data

What this page draws on