Administrative audit log.

Who changed what in your workspace, when, from where and how it ended. Append-only: nobody edits or deletes an entry.

Overview

The administrative audit log records who changed what in your workspace, when, from where and how it ended: an API key created, a role changed, an enforcement policy edited, a column tagged as sensitive. Each change and its entry are saved in the same transaction: if the entry cannot be written, the change is not applied.

It is not the query audit trail. The audit trail records every engine decision about a query; this log records the configuration and access changes made by people, API keys, Vericto processes and the Vericto team.

What is recorded

Each of these changes leaves an entry:

  • API keys: creation, revocation and rotation.
  • Members and invitations: invitation sent, accepted or revoked, role change and member removal.
  • SSO and OIDC: the SSO connection (including enforced SSO sign-in) and its domains; the OIDC trust policies for CI and every credential an OIDC exchange issues.
  • CLI login: every approval, which issues a key for the workspace.
  • Rules: severity change, enabling or disabling (workspace-wide or for one database), reset to the catalogue default, and custom rules created, edited or deleted.
  • Databases and workspace: adding a database, changing its proxy settings and deleting it; renaming the workspace.
  • Enforcement policy: per-severity actions, monitor mode, observe mode window, the action for unparseable queries (parse_error_action) and telemetry mode.
  • Sensitive columns: tagging a column, changing its policy or mask style, and untagging it.
  • Alert destinations and webhooks: creation, change, turning off, turning on and deletion. Turning a destination off is an action of its own, because it silences alerts.
  • Billing: plan or cycle changes a user requests, scheduled downgrades and their cancellation, and the plan change the payment provider confirms.
  • Contracts and retention: start and end of an Enterprise contract, and changes to contractual retention terms.
  • Audit trail: every export requested, and every deletion of events before their retention period ends, which Vericto does only at the customer's request.

Some rejected attempts are recorded too, with outcome denied: for example, a member without permission who tries to create an API key or change a role. Only attempts by workspace members are recorded; a request that changes nothing leaves no entry.

What each entry holds

  • Actor and actor type: a user, an API key, Vericto (system, for example the payment provider webhook or an OIDC exchange) or a Vericto operator running a procedure, with the reference that authorizes it (operator).
  • IP, user agent and request id of the request that made the change, when there is one.
  • Action and entity: what was done and to what (a key, a member, a database, a policy).
  • Outcome: success, denied or failure.
  • Before and after of only the fields that changed. On a creation, the new state; on a deletion, the last state. Secrets are replaced with [REDACTED]: a secret that changed shows as changed, without its value.
  • Time from the database server.

What is never stored

The log does not store API key values or their hashes, tokens, passwords, connection strings, SSO client secrets, webhook URLs (they carry their credential in the path), or the email of invitees or of whoever acts. Every field named like a secret is redacted on write, even when the code sending it does not ask, and so is every value shaped like a secret: a URL with credentials, an API key or a private key.

People appear by their user id. The dashboard shows their name or email when reading, without storing it in the log.

Append-only

The database rejects any UPDATE, DELETE or TRUNCATE on the log with a trigger, whatever role attempts it. No cascading delete removes entries underneath it, and the daily retention purge does not touch it.

The only path is deliberate and narrow, inside a single transaction: when a person's account is erased (right to erasure), their entries are kept and only lose the link to them, which shows as erased user; when a whole workspace is removed, that workspace's entries are deleted.

The trigger protects the log against application bugs and accidental writes. It is not a control against someone with full database access as the table owner.

Viewing it

The owner and admins see it in the dashboard under Settings → Audit log, on every plan. Members and viewers have no access: entries carry the IP and user agent of other members.

Entries go from newest to oldest. You can filter by dates, domain (API keys, members, SSO, billing…), outcome and actor, and load more pages with a cursor. Expanding an entry shows the before/after table of the fields that changed, the IP, the user agent and the request id.

Reading the log does not leave an entry: it changes nothing, and an entry per page view would bury the changes the log exists to show.

Export

Exporting this log is not available yet. The dashboard's signed export covers the query audit trail. In the meantime, the log is viewed in the dashboard.

SOC 2 evidence

The log shows who granted, changed or removed access and who changed the configuration, with date and origin:

  • CC6.1 to CC6.3, logical access: API keys created, rotated and revoked; members invited, their roles and removals; SSO connection, OIDC policies and issued credentials.
  • CC8.1, change management: changes to rules, enforcement policy, sensitive columns, databases and alert destinations, with the before and after.

Vericto provides the evidence; whether a control is met is for your auditor to decide.