Receipt Verification

Every receipt created by Relynt includes an HMAC-SHA256 signature. This page explains how signing works, what fields are covered, and how to verify receipt integrity.

How HMAC-SHA256 works

HMAC (Hash-based Message Authentication Code) is a mechanism for verifying both the integrity and authenticity of a message:

A message (the receipt data) is combined with a secret key (the signing key)
The combination is hashed using SHA-256
The resulting signature is stored with the receipt
To verify, the same process is repeated — if the signatures match, the receipt is authentic and unmodified


receipt data + signing key → SHA-256 → signature

What fields are signed

The HMAC signature covers the following receipt fields in canonical order:

Field	Purpose
`receipt_id`	Unique identity of the receipt
`created_at`	Timestamp (prevents backdating)
`organization_id`	Tenant scoping
`agent_id`	Which agent acted
`instance_id`	Which agent run
`action`	What was attempted
`resource`	What was targeted
`decision`	The policy decision
`risk_level`	Risk classification
`policy_version`	Which policy was used
`request_hash`	Integrity of the original request

The signature covers all critical fields. Modifying any of these fields — even a single character — will cause verification to fail.

Verifying a receipt

Via the dashboard

Navigate to Receipts in the dashboard
Click on any receipt to view its detail page
Click the Verify button
The result shows whether the receipt is valid or tampered

Via the API


curl -X GET "https://your-relynt-instance/v1/receipts/rec_abc123/verify" \
  -H "Authorization: Bearer <token>"

Valid response


{
  "valid": true
}

Tampered response


{
  "valid": false
}

Verification process

When you call the verify endpoint, Relynt:

Loads the receipt from the database
Reconstructs the canonical representation of the signed fields
Recomputes the HMAC-SHA256 signature using the server-side signing key
Compares the recomputed signature with the stored signature
Returns valid: true if they match, valid: false if they don’t

Why verification matters

Audit compliance — prove that records haven’t been altered after creation
Incident investigation — confirm that a receipt accurately reflects what happened
Trust — give security teams confidence that the audit trail is authentic

Security properties

Property	How it’s achieved
Integrity	Any modification to signed fields changes the hash
Authenticity	Only the server with the signing key can produce valid signatures
Non-repudiation	Signed receipts prove that Relynt processed the request
Tamper evidence	Verification detects any post-creation modifications

Receipt verification is performed server-side. The signing key is never exposed to clients, ensuring that only Relynt can produce valid signatures.

Limitations in v0

HMAC-SHA256 is used for signing. Future versions may support asymmetric signatures (RSA/ECDSA) for independent verification without the signing key.
Server-side verification only — clients must call the verify endpoint rather than computing signatures locally.
Single signing key — key rotation is planned for future versions.