Audit trail

Every write ISE performs travels the same pipeline, and every step is recorded. The audit trail is append-only: entries are added, never edited or removed.

What gets recorded

• Sign-ins, including every break-glass login — highlighted, because it should be conspicuous.
• Every proposed-change transition: proposed, approved, rejected, executed, failed — each with its actor, the exact parameters, the target system, and links to the evidence behind it.
• Role-relevant changes, and changes to integrations, credentials, risk policy, and model configuration.
• AI runs — the full trace of what a model was asked, which tools it called, what came back, and what it produced.
• Manual triggers: syncs and analyses someone kicked off by hand.
• Estate enrichment — the internal metadata writes ISE makes to its own knowledge base, audited separately from infrastructure actions because they are a different class of change.

Two things worth knowing about how it reads back:

A playbook run’s transcript is its audit artefact. Because execution is AI-interpreted, the record is a replayable narrative of what happened — not a replayable execution. Auto-approved in-envelope changes carry provenance: which playbook, published by whom, when.

Self-approvals are flagged. Where an admin approves their own change, it is audited distinctly rather than blending into ordinary approvals.

Where to look

The Audit log screen is a filterable stream by actor, system, event type, and time range, with export. The Agent runs screen renders any AI run in full — task type, model and settings, every tool call with its inputs and outputs, token spend, outcome, and the artefacts produced. It is deliberately a first-class screen rather than a debug page: it is how you answer “why did the AI say that?”

Incident timelines merge the same records into one chronological view, so the audit story of an incident reads in place rather than requiring a separate hunt.

How credentials are handled

Delivery. Secrets reach the application only through environment variables or mounted files sourced from Kubernetes Secrets. No secret value appears in git, Helm values files, images, or CI logs — and CI runs a secret-scanning check on every pull request, so committing one is a build failure rather than an incident.

Storage. Integration credentials configured through the UI are stored in PostgreSQL encrypted at rest with application-level envelope encryption. The key-encryption key is itself delivered as a deployment secret and is never stored in the database — which is the defence-in-depth point, and also why your backups must include it. Losing it means re-entering every connector credential. The break-glass credential is stored only as a strong hash.

Exposure. The API never returns secret values: credential fields are write-only and masked on read. The logging redaction list covers every credential field and known token shape, and adding an integration means adding its credential shapes to that list.

Least privilege and the read/write split. Each connector requests the minimum scopes for its declared capabilities, and read-only integrations get genuinely read-only credentials. Enabling actions grants a separate write identity; the two never share a credential. Credentials rotate without downtime — connectors re-read configuration, no restart required.

Streamed output is redacted as it flows. A streamed answer reaches the browser before anything is persisted, so redaction cannot wait for persist time. Text is accumulated, scrubbed as a whole, and released only once no later token could change the result — so a secret split across two fragments cannot slip through.

Next

• Roles & access — who can do the things being audited.
• Actions & approvals — the pipeline these records track.
• Upgrading — backing up the database and the key.