Key management

1. The keys at a glance#

In plain language: each region has one signing key, kept as an encrypted secret that only our receipt service uses. No part of the API hands it out.

2. Which key signs which receipt#

A workspace's receipts are signed by the key of the data region chosen when the workspace was created:

There is no fallback between regions. If a region's key is not configured, calls fail with 503 signing_unprovisioned; if the key cannot be used, with 503 signer_unavailable. No receipt is ever signed by another region's key or returned unsigned.

3. Key ids#

A key id (kid) is derived from the public key itself: the first 16 bytes of the SHA-256 hash of the raw 32-byte public key, encoded as base64url without padding, 22 characters. You can recompute it from the published key, so nobody can attach a different id to a key without it showing.

Every receipt names its key in signatureKeyId, inside the signed bytes.

4. Where the public keys are published#

Each key in the set has kty: "OKP", crv: "Ed25519", alg: "EdDSA", use: "sig", its kid, the public key x in base64url, its jurisdiction (the region) and the signer's DID, did:web:agined.com:agents:tools-signer.

5. Pinning a key#

A signature proves who holds a key, not whose key it is. For the strongest position, fetch the key set once through a channel you trust, store the kid and x of the key you rely on in your own repository or records, and verify against that copy. Keep the key set you verified against next to any receipt you keep as evidence: the two together verify on their own, years later and without us.

6. Rotation#

A key changes only through a manual key ceremony run by Agined. There is no automatic rotation and no schedule. No production signing key has been rotated so far.

When a key is retired, its public half stays in the published key set for as long as receipts it signed can be relied on, and a key change never changes the receipt format. This is our policy; the key endpoint does not enforce it on its own, which is one more reason to pin the keys you rely on.

Workspace owners and admins can ask for a rotation with POST /api/v1/tools/signing-key/rotate-request and follow it with GET /api/v1/tools/signing-key/rotation-status. A request records the wish; it does not rotate anything by itself. See Signing keys and rotation.

7. If a key is compromised#

There is no automated compromise response, no revocation list and no revocation of single receipts. A leaked key would let its holder create receipts that verify, and a signature check alone could not tell them from genuine ones.

We would handle a suspected compromise as a security incident. Where a key has been, or may have been, misused, we would:

1. stop signing with it and move the region to a new key;
2. publish a notice on this page and in the changelog naming the key id and, as far as we can establish it, the period in which it may have been misused;
3. tell the owners of the affected workspaces by email; and
4. decide, and say in the notice, whether the key stays in the published set. Withdrawing it makes every receipt under it fail with unknown_key, genuine ones included, so we would weigh that against the risk of forgeries.

Your best protection does not depend on us: pin the key set you verified against, and record each receipt in a system you control, with its own clock, when you receive it. A receipt you stored before a compromise keeps its value, because you can show you held it before the forgery became possible.

Report a suspected compromise to security@agined.com.

8. What custody does not protect against#

Keeping keys as encrypted secrets limits who can read them. It does not stop whoever can deploy the receipt service from causing it to sign. That is why the Receipt Practice Statement keeps observed and reported facts apart, and why the trust you place in us is limited to the short list in its section 9.

9. Key events#

No key has been rotated or compromised. Notices of rotations and compromises will be added here, with their dates. Questions: security@agined.com.