The audit log

Every mutation, every decryption, and every denial is recorded. A system that records only what succeeded cannot detect an attack in progress.

Owners and admins can read the log. It is append-only, enforced by database grants rather than by convention — the application's own credentials cannot alter it.

What a record contains

There is no field that could hold a secret value. The type describing the metadata is a fixed allowlist of field names with no catch-all, so a value cannot be placed in a record: the compiler rejects it rather than a reviewer having to spot it.

Attribution is precise

A write made by CI is recorded as the act of that service token, by name — never as the act of whoever minted it. Two separate columns hold the two kinds of actor, with a database constraint requiring exactly one of them to be set.

This matters in the one log a company reaches for during an incident: putting a person's name on a write they did not make is worse than useless.

The events

Authentication

Vault reset and recovery

See Resetting your vault for what each of these means.

The sign-in events — auth.login, auth.signup and auth.identity_linked — carry signInMethod: how the person authenticated, as one of a closed set: password, oauth, sso, magic_auth (a code sent by email), passkey, or other for a method the identity provider named that this list does not know. It is coarser than the provider's own vocabulary on purpose: a review asks whether this was a password, a Google account or the company's single sign-on, not which of many OAuth providers.

Secrets

secret.read and secret.revealed are the two rows that mean a plaintext left the server, and the distinction is deliberate. A 200-secret pull writes one secret.read row with a count, not 200 rows — otherwise the audit table becomes a denial-of-service surface against itself.

secret.revealed is the one to watch. It means a person or token asked for one specific value, which is what curiosity and exfiltration both look like.

A pull that reads beyond its own environment — values it inherits, or a template refers to — writes a secret.read against each environment it read, naming the environment being pulled as context and, for a referenced secret, the secret that referred to it. Production's own log therefore shows a read of production that a template in staging caused.

Organisations, projects, environments

org.created · org.updated · org.deleted · project.created · project.updated · project.deleted · environment.created · environment.updated · environment.deleted

A refusal by one of your own policies is an error with reason policyRefused and the policy's name; a refusal by the plan is quotaExceeded with the feature or limit that refused it.

Single sign-on

A refused attempt at any of these is recorded too: denied for somebody without the role (an admin, for anything that switches something on), error for a missing add-on, a precondition (no active connection or verified domain, SSO not on yet, a link made in another WorkOS environment, a deployment whose WorkOS environment the database does not belong to, no recent sign-in before the setup portal) or WorkOS being unreachable.

People and access

Suspension and removal are separate events because the histories imply different things. During a review, "could this person still act during the window?" has a different answer for each — a suspended member resolves to none everywhere while keeping their grants.

Plans and billing

Written by the system for what the payment provider, the seat sync and the billing jobs did, and by an owner for what they asked for. The actor of a system row says which: Dodo webhook, seat sync, billing job or billing reconciler. No row carries an amount, a card detail, or any identifier of the payment provider's — only plans, statuses, counts and the name of the event that caused it.

Credentials

Denials

Plus: any of the actions above can carry outcome: denied. Filtering on outcome rather than on this single action is usually what you want.

Reading it

Audit in the dashboard, or GET /api/orgs/{orgSlug}/audit.

Filters: actor, action, project (and environment within it), outcome, and a date range. Results are paginated with an opaque cursor.

The range is clamped to 90 days, and the response states the window it actually scanned — a view showing less than it was asked for must say so rather than quietly returning a shorter answer.

curl "https://xecret.playxoft.com/api/orgs/acme/audit?action=secret.revealed&from=2026-08-01" \
  -H "Authorization: Bearer $XCT_TOKEN"

Using it during an incident

A laptop is stolen, or a CI token leaks. The sequence:

1. Revoke first. The device under Tokens → Your devices, or the service token under Tokens → Service tokens. Revocation is immediate, and is never softened by the CLI's offline cache — a rejection is a decision, and decisions are not overridden by a local file.

2. Find what it did. Filter the log by that actor. secret.read rows tell you which environments were pulled and when; secret.revealed rows name individual secrets.

3. Rotate what it touched, at the source. Change the database password at the database, the API key at the provider, then write the new value into xecret. Revoking the token does not un-leak a value it already read — this is the step people skip.

4. Check for denials. A run of outcome: denied around the same time is somebody probing for what else the credential could reach.

5. Write down what you found. Filter by date range and export before the 90-day window moves.

What to review routinely

Worth a look once a month, or after anyone leaves:

• access.granted on production environments — is each still needed?
• token.created — is every standing service token still in use?
• secret.revealed — is anybody reading production values by hand who should be using xecret run?
• member.role_changed — did every promotion have a reason?
• role.updated and member.custom_role_changed — did a custom role widen, or come off somebody, and was that meant?

Next

• Trust model — what the log is protecting.
• Tokens — revocation and rotation.
• Teams and access — the grants these events describe.