Wardengate

Operate

Audit & reporting

Audit is a product surface in Wardengate, not a log pipe. Every privileged action — a policy decision, an approval, a session open, a recording played back, an IdP sync, a config change — becomes a first-class event. Those events feed a set of built-in reports that answer the questions auditors and compliance owners actually ask, and they are persisted in a tamper-evident store you can prove intact at review time.

Built-in reports

The console ships five reports out of the box. Each one is a live query against the audit store with sensible filters and sensible defaults; all of them can be scheduled, exported, and deep-linked.

Access review

A pivot of who has effective access to what, derived from the current policy graph intersected with current identity state. Filters let you select a group, a tag, or a single target and see every principal that could reach it, with the policies that admit them. Export to CSV for a signed-off quarterly review.

Privileged activity

A session-centric timeline with one row per brokered session, plus the drill-in metadata: target, account, MFA method, approvals fired, command-filter hits, recording bytes written. The default view is the last 30 days; the filter chips are user, target tag, policy, and outcome.

Policy violations

Every policy.denied and every alert-classed command-filter hit, deduped by principal and day so one aggressive CI runner does not drown out the signal. Includes a “what changed?” panel that correlates spikes with recent policy edits.

Recording access log

Who watched which recording, when, and for how long; which frames they scrubbed to; which exports they produced. This is the report regulators will ask for when they want to see that the people watching the watchers are themselves being watched.

IdP event log

SSO sign-ins, SCIM creates/updates/disables, LDAP sync outcomes, MFA enrolments and resets, step-up challenges. Grouped by IdP and by result. Failing SCIM calls land here with their full error text so you can stop guessing which group mapping broke.

Filter and search UI

Every report shares one filter bar. Filters are additive — the URL is the query — so you can drop a filtered report into a ticket and the next person lands on exactly what you saw. The supported operators are =, !=, in, like, and time windows like last 24h, this week, 2026-04-01..2026-04-20.

wgctl audit query \
  --report privileged-activity \
  --where 'target_tag=env:prod AND outcome=denied' \
  --since 'last 30d' \
  -o csv > prod-denies.csv

Scheduled reports

Any filtered report can be saved and put on a cron. The scheduler runs the query, renders the output, and delivers it — email, Slack, SFTP, or S3 with a signed object. Scheduled runs re-use the saved-filter permissions of the creator, so a report emailed to a director only contains what that director was entitled to see at creation time.

apiVersion: wardengate/v1
kind: ScheduledReport
metadata:
  name: monthly-prod-access-review
spec:
  report: access-review
  where: "target_tag=env:prod"
  schedule: "0 6 1 * *"          # first of every month, 06:00 UTC
  format: pdf
  deliver:
    - kind: email
      to: ["security@example.com", "cfo@example.com"]
      subject: "Prod access review - {{.period}}"
    - kind: s3
      bucket: "s3://corp-audit-archive/wardengate/"
      signObject: true

Export formats

  • CSV — the default for spreadsheets. UTF-8, RFC 4180 quoted, one row per record.
  • JSON / JSONL — JSONL for pipeline consumers; the same schema as the SIEM stream so you can feed the export into the same indexer.
  • PDF — themed for human delivery, with a header page carrying the query, the period, the generator identity, the row count, and the audit-store hash-chain head at generation time.

Every export writes its own audit.export event containing the report name, the filter, the generator, the recipient, and the SHA-256 of the generated artefact. Exports are themselves auditable — there is no “silent download.”

Hash-chain integrity

Events are written to the audit store in order and each event carries the SHA-256 hash of the previous event in its envelope. That turns the stream into a hash chain: any tamper — insertion, deletion, edit — breaks the chain from that point forward. The control plane publishes the current chain head every minute to the public log endpoint /api/v1/audit/head and signs it with the cluster key.

{
  "ts": "2026-04-20T18:59:00Z",
  "chain_head": "5f8ab4ce09...c411",
  "sequence": 48210411,
  "signature": "ed25519:9de0a8...",
  "signer": "cluster-key/2026-q2"
}

To verify at any time, run wgctl audit verify --since <ts>; the CLI walks the range, recomputes each link, and confirms the head against the last signed publish. Publishing the chain head to an external witness (your own S3 bucket, a ledger, a second account) gives you a cheap external anchor.

WORM and immutable storage

For regulated environments the audit store can be backed by write-once-read-many object storage — S3 Object Lock, Azure Blob immutable policies, or GCS bucket retention. Once enabled, audit batches land in storage and cannot be deleted or edited until the configured retention period elapses, even by a cluster admin. The Postgres index remains mutable (you still need to vacuum it); the store of record is the signed batches on object storage.

audit:
  store:
    kind: s3
    bucket: s3://corp-audit-worm/
    mode: worm                     # compliance, not governance
    retentionYears: 7
    batchSeconds: 60
    signer: cluster-key/2026-q2

Auditor read-only mode

The built-in auditor role grants read-only access to every report, every recording, and every policy state — with no ability to open a session, edit a policy, or mask their own activity. Actions taken by auditors land in the same audit stream as everyone else’s, so there is no “audit the auditors” gap. Pair the role with an IdP group dedicated to external reviewers and give them a time-bound membership for the length of the engagement.

Chain-of-custody attestations

When an auditor leaves with artefacts — recordings, exports, reports — they should be able to prove those artefacts are the genuine output of the system and have not been tampered with since generation. Wardengate produces an attestation bundle on demand that contains the artefact hashes, the audit-store chain head at the time of generation, the generating principal, the filter used, and a detached signature with the cluster key.

wgctl audit attest \
  --artifact /tmp/prod-denies.csv \
  --out /tmp/prod-denies.attest.json

wrote /tmp/prod-denies.attest.json
  artifact_sha256: 7b4e...c910
  chain_head:      5f8ab4ce09...c411
  generator:       carol@corp
  signed_at:       2026-04-20T19:02:14Z
  signature:       ed25519:3c17a0...

Third parties can verify an attestation with wgctl audit verify-attest and the published cluster public key — no Wardengate instance required. This is the piece that lets a recording travel out of your environment into a courtroom without the defence picking it apart on provenance grounds.

Retention and archival

Audit events are cheap and small; retention is usually measured in years rather than days. The default hot retention is 400 days in Postgres (for fast report queries) with cold batches on object storage for the full retention period. Queries that span cold batches transparently page them in, with a banner telling the operator the run may take a few extra seconds.

Related