ShieldScoreStart Free Trial

Legal

Incident R13.AG — Trust Center signing-key lifecycle row gap

Last updated May 19, 2026

This page is the incident disclosure for an internally-identified substrate gap in ShieldScore's Trust Center signing-key lifecycle. It is published in the spirit of build-complete transparency. The Discovery and Containment section below preserves the 2026-05-18 snapshot of what was known at discovery time and the enforcement substrate shipped same-day to prevent recurrence. The Closure section below documents the 2026-05-19 receipt-verifiability remediation: the 14 historical receipts now resolve as incident-period artifacts under a β-anchored sealed-archive endpoint, with the original signing key honestly named as cryptographically unrecoverable.

This is not a personal-data breach under HIPAA §164.404, GDPR Art. 33, U.S. state breach-notification statutes, or SEC Item 1.05 (Form 8-K). See the Compliance posture section below for the rationale and the standards under which the ≤72h closure ETA is anchored.

Discovery and Containment (2026-05-18)

On 2026-05-17, during R13.AC L2 post-execute review, we identified that the 14 deletion receipts published that day cite a Trust Center signing key (kid=ts-v1-2026-04-25) whose lifecycle row was not preserved in our DB-row source of truth, rendering those receipts currently unverifiable against our published JWKS endpoint. Today (2026-05-18) we shipped enforcement substrate that prevents this class of substrate gap from recurring: a throw-on-missing-DB-row guard at our signer entry point, a boot-time equality assertion between our signer env-var and the active DB-row kid (fail-closed on mismatch), and a structural-contract test enforcing both invariants. Receipt-verifiability remediation for the 14 historical receipts is in flight; we are executing an operator-supervised AWS KMS GetPublicKey probe to determine whether the original key material can be cryptographically restored to the lifecycle row (full restoration), or whether the 14 receipts will be served as incident-period artifacts via a sealed-archive endpoint cross-signed by our current Trust Center signing key with AuditLog Merkle-chain evidence anchoring. ETA for resolution and full closure disclosure: ≤72h.

This Discovery and Containment section is preserved as the 2026-05-18 incident-timeline snapshot. The earlier inline verification block has been removed: those commands referenced a posture probe that is not a public reader endpoint in production and would return an error payload for an outside reader. For current substrate verification (sealed-archive endpoint, jwks-history lifecycle endpoint, and AuditLog Merkle witness), see the Closure (2026-05-19) section below, which contains the canonical self-test.

Closure (2026-05-19)

The 14 historical deletion receipts cited by kid=ts-v1-2026-04-25 are now framed as incident-period artifacts: their existence and content integrity are provable from a frozen 14-receipt SHA-256 hash set anchored by the TRUST_CENTER_INCIDENT_ARCHIVE_PUBLISHED AuditLog Merkle-witness row written at incident closure, cross-signed by the current ACTIVE Trust Center signing kid, and served at the sealed-archive endpoint /.well-known/jwks-archive/2026-04.json. The orphan kid's full lifecycle (activation, retirement, kmsKeyVerifiable: false, and a back-reference to the incident-artifact archive) is surfaced at /.well-known/jwks-history.

No rehabilitation. The β-anchoring (cross-signature by the current ACTIVE kid ts-v1-2026-04-27) is forward-binding — it attests the receipt set's existence, integrity, and authoritative publication at the time of incident closure. It is not a back-dating of the original ts-v1-2026-04-25 material and does not reconstitute verifiability of those 14 receipts against the original signing key. The original private key material was destroyed by an out-of-band AWS KMS resource replacement on 2026-04-27; per Probe A (session-14, 2026-05-18), 0 of 14 receipts verify against any extant key material. This archive preserves tamper-evidence, not original signature mathematics.

Independent receipt-verifiability self-test

From any terminal with curl and jq, run the four probes below to independently verify (i) the sealed archive serves and self-classifies, (ii) the cross-signature kid is the current ACTIVE kid (forward-binding, not back-dating), (iii) the AuditLog Merkle-witness row exists and seals the archive, and (iv) the jwks-history endpoint surfaces the orphan kid as RETIRED with kmsKeyVerifiable: false.

  1. Sealed archive serves and self-classifies as incident artifact:

    curl -s https://api.shieldscore.ai/.well-known/jwks-archive/2026-04.json \
  | jq '{
      class,
      incidentId,
      receiptCount: .receiptSet.count,
      receiptFingerprint: .receiptSet.fingerprint
    }'

    Expected: class: "INCIDENT_ARTIFACT", incidentId: "r13-ag", receiptCount: 14, and a deterministic 64-char hex receipt-set fingerprint.

  2. Cross-signature kid is the current ACTIVE kid (forward-binding, not rehabilitation):

    curl -s https://api.shieldscore.ai/.well-known/jwks-archive/2026-04.json \
  | jq '{ crossSigKid: .signature.kid, orphanKid: .kidLifecycle.kid }'

    Expected: crossSigKid: "ts-v1-2026-04-27" (current ACTIVE, distinct from the orphan), and orphanKid: "ts-v1-2026-04-25" (the destroyed kid being attested-around, not rehabilitated).

  3. AuditLog Merkle-witness row exists and seals the archive:

    curl -s https://api.shieldscore.ai/.well-known/jwks-archive/2026-04.json \
  | jq '.auditWitness | { action, entityType, entityId, rowId, hash }'

    Expected: action: "TRUST_CENTER_INCIDENT_ARCHIVE_PUBLISHED", entityType: "TrustCenterSigningKey", entityId: "ts-v1-2026-04-25", a non-null rowId (CUID), and a non-null 64-char SHA-256 hash. The archive endpoint fails closed with HTTP 5xx if this row is absent (PR-B-2 fold-in #2, codex 0.94 BLOCKING verdict).

  4. jwks-history surfaces the orphan kid as RETIRED + non-KMS-verifiable + incident-linked:

    curl -s https://api.shieldscore.ai/.well-known/jwks-history \
  | jq '.entries[] | select(.kid == "ts-v1-2026-04-25") | {
      status,
      kmsKeyVerifiable,
      incidentArtifactRef
    }'

    Expected: status: "RETIRED", kmsKeyVerifiable: false, and incidentArtifactRef.archiveUrl: "/.well-known/jwks-archive/2026-04.json" — a positive cross-link from the lifecycle surface back to this archive.

Auditors operating under our existing customer-trust agreements (with read-only access to the production database) can verify the witness row directly:

-- AuditLog β-cross-signature witness row (read-only):
SELECT id, action, "entityType", "entityId", "orgId", "createdAt"
FROM "AuditLog"
WHERE action = 'TRUST_CENTER_INCIDENT_ARCHIVE_PUBLISHED'
  AND "entityType" = 'TrustCenterSigningKey'
  AND "entityId"   = 'ts-v1-2026-04-25'
  AND "deletedAt" IS NULL
ORDER BY "createdAt" DESC
LIMIT 1;
-- The returned id MUST equal auditWitness.rowId in the jwks-archive payload.

The canonical decision record for this incident is preserved in the public source repository under docs/operational/sessions/ (session-9 through session-15). The Static Play Compliance Governance (SCG) ruling that classifies this incident as a cryptographic-evidence integrity gap (not a personal-data breach) is recorded at SPCG session-14 (2026-05-18) and is referenced from inside the archive payload at .references.spcgRuling.

Compliance posture

This incident is not a breach-notification event under HIPAA §164.404, GDPR Art. 33, U.S. state breach-notification statutes, or SEC Item 1.05 (Form 8-K) per the Static Play Compliance Governance (SCG) ruling dated 2026-05-18 (no unauthorized acquisition, access, use, or disclosure of personal data; cryptographic-evidence integrity gap, not a confidentiality breach). The ≤72h closure ETA is a buyer-trust calibration anchored in SOC 2 CC2.3 (communication of information to external parties), AICPA SSAE 21 §AT-C 105.A29 (matters affecting subject-matter evaluation), and NIST CSF 2.0 RC.CO-04 (recovery activities and progress communicated to stakeholders). Auditor disclosure under our existing SOC 2 Type II audit relationship will reflect this incident in the next management-response section per TSC CC7.1 (detection of events and anomalies) and CC9.2 (vendor and business-partner risk management).

Questions or verification requests

For verification questions, receipt-verifiability requests for a specific historical deletion receipt, or correspondence under our existing customer-trust agreements, contact privacy@shieldscore.ai. The canonical decision record and remediation evidence are maintained in our public source repository under docs/operational/sessions/ and the incident-specific audit artifacts will be linked from this page at PR-B-2 closure.