Skip to main content
Operations is a remote-execution surface running inside your customer’s own cloud account. This page documents the cryptography that makes it auditable: which keys exist, where they live, which transitions get signed, where signed evidence is preserved, and how anyone (you, your customer, an auditor) can verify the chain after the fact.

​
The trust chain at a glance

Two Ed25519 keypairs have different roles:
  • Your customer’s signing key signs command-approval and output-release manifests, or a standing pre-approval grant. Your customer generates it on their workstation and stores it in their own secret store. The matching public key is pinned where the appliance controller reads it before accepting those decisions.
  • The appliance controller’s signing key signs output integrity on the normal process-result path, before encryption. Its private key is read from the appliance controller’s secret store under your customer’s AWS IAM, Google Cloud IAM or Kubernetes RBAC, as appropriate. The matching public key is on the install record in your control plane.
These signatures cover specific records, not every lifecycle transition. Customer-signed decisions authorize work or release; controller-signed output integrity binds the result to the controller’s signing key. The command record preserves available signatures and manifests for later verification.

​
What the three signatures prove

The per-command signed flow has three distinct signature checks. The customer signs approval and release; the controller signs output integrity. A verified standing pre-approval can cover the corresponding customer decision without a separate per-command manifest. The output digest includes the result type and its metadata. For inline output, it binds the content; for a blob, it binds the size, checksum and URL. After mirroring, verification uses the original blob metadata to preserve signature continuity. Fetching a blob and checking its checksum is a separate step from verifying the signature over its metadata. The normal process-result path signs before encrypting the result and preserves the signature through encryption and release. Some legacy or failure records have no output-integrity signature; a missing signing key or signing error can also leave it absent. Inspect each audit check rather than assuming every command has all three signatures. Runtime verification and later audit verification use different sources of trust. The appliance controller checks customer signatures against the public key pinned in the customer’s secret store. The audit CLI checks a customer manifest against its embedded public key and reports its fingerprint for comparison with the customer-pinned key. A valid signature identifies the signing key; the fingerprint comparison ties that key back to the customer’s configured authorization.

​
Where keys live

​
Your customer’s signing key

Your customer owns and stores their own private signing key. The support-portal approval UI handles the setup on first approval (the Set up your signing keypair step) and renders the bash snippets your customer pastes into their own terminal. The approval UI supports three storage backends, matched to the appliance environment:
  • AWS appliances: private key in your customer’s AWS SSM Parameter Store as a SecureString (KMS-encrypted at rest).
  • GCP appliances: private key in Google Cloud Secret Manager in the appliance’s Google Cloud project.
  • Kubernetes appliances: private key as a Kubernetes Secret in the cluster namespace.
The UI supplies the matching setup and signing snippets. GCP setup needs the appliance’s project to be reported to the UI. Reads and writes use your customer’s AWS IAM, Google Cloud IAM or Kubernetes RBAC permissions for the selected backend.

​
The appliance controller’s signing key

The customer signature records a decision under the customer’s signing key. The controller signature binds result bytes and execution metadata to its signing key. They answer different questions: authorization and result integrity. Neither signature replaces the other, and neither turns every lifecycle event into a signed record.

​
How non-repudiation survives revocation

Pre-approval involves two distinct artifacts stored in two distinct places. They serve different purposes and have different deletion properties. An observed, valid revocation record stops use of that grant without erasing its historical signature. Verify that the controller recognizes the record. Its reader treats a missing, unreadable, blank or malformed record as not revoked; malformed records produce a warning. Removing or invalidating the record can make a still-valid grant eligible again, but it must still pass the current pinned-key and other grant checks. The preserved manifest can still be checked against its embedded signer public key. Compare its recorded fingerprint with the customer-authorized signing key when establishing which key signed the grant. The non-repudiation property holds because the manifest lives where the customer can’t unilaterally erase it: vendor-side infrastructure. If the manifest lived on the appliance controller vault instead, customer-side deletion would be both revocation AND history-rewrite, and a customer could plausibly claim they never signed anything that the appliance controller briefly acted on.

​
Key rotation

Customers rotate their signing key for a few reasons: retiring a workstation, suspected compromise of the laptop holding the key, an employee with access leaving, or routine rotation per their own security policy. The mechanics:
  1. Generate a fresh keypair and store its private key using your customer’s existing signing-key setup flow.
  2. Replace the pinned public key in the appliance controller’s secret store with the new key. The current verifier reads one pinned customer key; it does not accept several keys pinned alongside one another.
  3. Review existing grants. A pre-approval signed by a different key from the one currently pinned stops qualifying for automatic approval. New approval and release decisions must match the current pinned key.
Customer manifests preserve their embedded public key and fingerprint, so the signature can still be checked after rotation. The audit CLI reports that fingerprint; it does not fetch a historical customer pin. Controller output-integrity signatures use the current install public key fetched by the CLI, so changing that key affects automatic verification of older controller signatures.

​
What revocation does and doesn’t do

Three distinct operations get called “revocation” loosely. They have different effects. Recognized revocation changes which authorization can be used going forward. It does not erase recorded signatures or roll back a command’s effects. Deleting or invalidating the record does not revoke a grant; a grant can qualify again only if its signature, current pinned key and other grant checks still pass.

​
Independent verification

Both you and your customer can inspect the available audit checks for a specific ops command:
The action:
  1. Pulls the command record and the install’s current controller public key from your control plane.
  2. Checks customer approval and release manifests against their embedded public keys, including the recorded fingerprint. Compare those fingerprints with the customer’s pinned key separately; the CLI does not read the customer’s secret store.
  3. Checks available controller output-integrity signatures, and legacy controller approval signatures, against the current install key. Output still encrypted cannot yet be checked from plaintext and is reported as skipped.
  4. Reports each check’s status and available signer evidence.
A zero exit code alone does not mean that all three checks ran and passed. Missing stages, rejected decisions and encrypted output can be reported without a failure. By default, only a failed signature check causes a non-zero exit; --strict also fails unsigned legacy records. It does not make skipped or absent stages into failures. Healthy checks appear as [OK]; verification failures appear as [FAIL] with a reason. Inspect every per-check status and its trust anchor. For programmatic use, pass --output json to archive the reported checks, fingerprints and available signature evidence alongside the command and relevant public keys. The CLI verifies recorded cryptographic evidence. It does not certify that every lifecycle transition was signed or independently prove the customer’s historical key pin.