Audit log

Every action that touches a credential, every permission change, and every administrative decision writes an entry before the response is returned.

• Secret values, in any form.

• SSH keys, database passwords, AWS secret keys, kubeconfigs.

• Proxy tokens and API token plaintext.

• Anything injected into a process, and anything a wrapped process printed.

• The contents of an SSH session.

The audit log records that a credential was released, never which credential it was. A log that contained the values would be a second copy of the secret store with weaker access controls - the exact thing worth not building.

Audit in the console, filterable by actor, action, resource, project, and date range. Requires the admin role and the Team plan.

Through the API with the audit:read ability:

curl -H "Authorization: Bearer $SHORTSPAN_TOKEN" \
  "https://shortspan.dev/api/v1/organizations/acme/audit-logs?action=secret.reveal"

Who read that secret, and when?

Filter by resource. Reveals and injections are separate actions, so "who could have seen the value" and "what used it" are distinguishable.

What did this person touch before they left?

Filter by actor across the whole date range. Entries survive their removal from the workspace.

Is this token behaving normally?

Filter by actor and look at the source addresses and the rate. A CI token that suddenly reveals secrets from a residential IP is the signal you are looking for.

Who had access to production last quarter?

Grant creation and expiry are recorded, so the set of people with elevated access at any past moment is reconstructable.

Separately from the audit log, the CLI reports the start and completion of each command it runs. That is what makes "opened a session" and "actually connected" distinguishable, and it is where a session's duration comes from.

A command whose CLI stopped reporting - the laptop closed, the process was killed - is reconciled after an hour and marked interrupted rather than left running indefinitely.

Audit entries are append-only. Nothing in the product edits or deletes one - not an admin, not an owner, not the platform control plane.

They outlive what they describe. Deleting a secret does not delete the record of who read it; removing a member does not delete the record of what they did.

On a self-hosted deployment, retention is whatever your database retention is. Back the audit tables up with the same care as the secrets - they are frequently the more legally significant of the two.