Audit

rensei audit exposes session-attestation metadata and a hidden audit-chain client surface. The attestation show command is available today. It retrieves the stored attestation record; it does not cryptographically verify the signature. The audit chain subcommands are implemented but hidden from --help and are not a supported public CLI surface. They are documented here only to make that boundary explicit.

receipt verify

rensei receipt verify independently verifies the Ed25519 signature in a BYOA dispatch audit receipt. The receipt identifies the signed audit entry hash and signing key. The verifier decodes the entry hash to its raw bytes, selects the matching public key from the workspace JWKS, and checks the signature locally.

A receipt holder can perform this check without a Rensei login, token, or hosted verifier. The holder needs the receipt JSON and its public JWKS. The organization that created the receipt may use an authenticated route to retrieve it, then share the artifact with an auditor, counterparty, or regulator for account-free verification.

Receipt sources

Pass one receipt source to the command:

# A local receipt JSON file
rensei receipt verify --file run-receipt.json

# A receipt artifact at a URL that accepts an unauthenticated GET
rensei receipt verify --url https://example.invalid/shared-run-receipt.json

# Standard input when neither --file nor --url is set
cat run-receipt.json | rensei receipt verify

--file and --url are mutually exclusive. With neither flag, the command reads receipt JSON from standard input. --url itself sends no authorization header, so do not point it at the authenticated dispatch-receipt API. An authorized organization retrieves /api/cli/dispatch/<id>/receipt using its normal authenticated API flow, saves or shares the returned receipt JSON, and the third party then verifies that artifact from a file, standard input, or an independently accessible URL.

Verification flags

The JWKS fetch is unauthenticated. You can override the receipt's JWKS pointer with --jwks-url when your verification procedure provides a known public-key location.

Fully offline verification

Save both artifacts locally to eliminate the receipt and JWKS network requests:

rensei receipt verify \
  --file run-receipt.json \
  --jwks-file workspace-keys.json \
  --json

This command does not require a Rensei account. Keep the JWKS document with the receipt when preparing an offline review package, especially when the package must be checked after a signing-key rotation.

Key rotation

Each receipt names its signing key through signingKeyId. The verifier selects the JWKS key with the corresponding kid, so it can verify a historical receipt against the key that signed it rather than only the active key.

The published Audit JWKS includes replacement keys and revoked historical keys. A revoked key is no longer selected for new entries, but its public material remains available for checking retained receipts. If the named kid is absent from the supplied JWKS, verification stops with an error; obtain the JWKS that contains the receipt's signing key. Key lifecycle and timestamp assessment are separate from the CLI signature result.

Tamper check

The signed payload is the raw bytes represented by the receipt's hex-encoded entryHash. Make a copy of a valid receipt, change one hex byte in decision.entryHash, and verify the copy:

rensei receipt verify --file changed-receipt.json
# FAILED  receipt signature did not verify
# Exit status is non-zero.

A changed byte that still forms valid hexadecimal causes FAILED because the signature no longer matches the changed payload. Invalid hexadecimal, invalid base64, or an incorrectly sized signature also produces a failed verification result and a non-zero exit. Conversely, the verifier does not recompute entryHash from the other receipt fields, so edits outside the signed hash and signature are not detected by this command alone.

Receipt verification is independently verifiable and tamper-evident for the signed payload. It is not a compliance certification.

audit attestation show

Retrieve the stored VCS attestation metadata for a completed agent session. The record links a session to commit and signing metadata. Signature presence is not verification, and this command does not perform a cryptographic check of the returned signature or commit trailer.

rensei audit attestation show <session-id> [--json]

rensei audit attestation show ses_abc123
rensei audit attestation show ses_abc123 --json

Example output (pretty):

Session:     ses_abc123
Provider:    git
Attestation: verified ed25519:ksk_example
Commit:      a1b2c3d4e5f6...  (main)
Algo:        ed25519
Trailer:     Rensei-Attestation: v1:example
At:          2026-06-02T14:02:18Z

The displayed verified attestation state is currently derived from audit-row signature presence, not the output of a cryptographic verifier. Do not treat that chip as proof that the signature, key, commit contents, or repository state was checked.

Example JSON output:

{
  "sessionId": "ses_abc123",
  "provider": "git",
  "commitSha": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2",
  "commitRef": "main",
  "signatureAlgo": "ed25519",
  "fingerprint": "ed25519:ksk_example",
  "attestationState": "verified",
  "trailerKey": "Rensei-Attestation",
  "trailerValue": "v1:example",
  "occurredAt": "2026-06-02T14:02:18Z"
}

attestationState: "verified" has the same signature-presence limitation as the pretty chip. The response does not include the detached signature bytes needed to perform an independent Ed25519 check.

Attestation methods

audit chain (hidden client surface)

The hidden audit-chain client queries authenticated platform endpoints for a tenant-scoped retained segment. Entries produced by the current platform append path are hash-linked and carry per-workspace Ed25519 signatures; retained history can include legacy unsigned entries. Because the commands are hidden, they are not a supported public CLI contract.

audit chain show

Show the audit chain for a project over a time range.

# Hidden from --help; not a supported public CLI surface
rensei audit chain show \
  [--project <slug>] \
  [--since <RFC3339>] \
  [--until <RFC3339>] \
  [--json]

The endpoint returns a capped segment with entry and predecessor hashes plus signature metadata where present. The default cap is 1,000 entries and the maximum is 5,000; there is no pagination token or automatic next-page fetch. The response must not imply that every entry has a timestamp anchor, that the segment is complete history, or that its attestationState label is a cryptographic verifier result.

audit chain verify

Without --offline, the hidden command asks the server to run hash, predecessor-link, and signature checks over its retained segment. A successful server result establishes tamper-evidence for that checked segment only. It does not establish event capture, full-history completeness, truth at capture, retention outside the segment, scheduled monitoring, or external anchoring.

With --offline, the client fetches the capped authenticated chain response and checks Ed25519 signatures that are present against the public JWKS. Offline mode does not recompute entry hashes or predecessor links, so its result is a signature-check summary rather than a chain-integrity result.

# Hidden from --help; not a supported public CLI surface
rensei audit chain verify [--offline] [--json]

audit chain export

Export the capped retained segment returned by the authenticated chain endpoint for offline inspection or archival.

# Hidden from --help; not a supported public CLI surface
rensei audit chain export \
  [--format json|jsonl] \
  [--project <slug>] \
  [--since <RFC3339>] \
  [--until <RFC3339>]

Audit architecture

The Rensei audit system has three layers:

Public keys used for verification are published at:

https://rensei.ai/.well-known/audit-keys.json

This endpoint returns the discovery and verification protocol. Per-workspace JWKS documents are served from https://app.rensei.ai/.well-known/audit-keys/{workspace_id}.json. See Audit keys JWKS for the schema and explicit verifier steps.

For a conceptual overview of the full audit trail design, see Security - audit trail.

Related pages

• Security - audit trail - hash-chain design, proof limits, retention, and optional anchoring
• Audit keys JWKS - /.well-known/audit-keys.json schema
• Observability - events - Layer 6 daemon hook events (separate from the audit chain)
• BFSI compliance overview - SR 11-7, approval gates, audit requirements