The 401 response
When the parser rejects a request, it returns 401 with a body of approximately the shape:
{
"error": {
"code": "verifier_fail",
"correlation_id": "<uuid>",
"support_ref": "<short-token>",
"reason_code": "<machine-readable code>"
}
}
Privacy guarantee (ratified 2026-05-07): The 401 body does not include a classification field. Classification is a registry-side post-hoc tag added when the verifier failure is logged to
anomaly_events; it is not present at the parser request boundary.
Self-diagnosis path
- Capture the
correlation_idfrom your 401 response body. - Call
GET /registry/anomaly/my_events?correlation_id=<id>with your operator HMAC. - The response includes
severity,reason_code,agent_id,detail,observed_at,source,classification, andclassification_version— see my_events self-diagnosis.
Common reason_code values (placeholder)
The full list lands during observation week as real-traffic codes are catalogued. Initial set:
GOVERNANCE_SIGNATURE_INVALID— Ed25519 verify failed against the published key.ATTESTATION_SIGNATURE_INVALID— passport attestation didn't validate.PUBKEY_URL_REJECTED—pubkey_urlresolved to a rejected target (private IP range, non-https, etc.).GOVERNANCE_TRUST_ROOT_NOT_SEPARATE— operator's governance and signing keys are not distinct.CAPABILITY_SCOPE_ANOMALY— agent attempted action outside its declared capability scope.
Each row above will be expanded with: probable cause, customer remediation, and when to escalate.
When to escalate
Escalation criteria placeholder — observation-week triage data sets the bar. For now: if the correlation_id is not surfaced in /registry/anomaly/my_events within 5 minutes of the 401, file a support ticket including correlation_id and support_ref.