Audit Log
The Audit Log page
(/audit) is a read-only, newest-first record of administrative actions taken
on your organization. It changes nothing itself — every control on it is a
filter over history, scoped server-side to your organization the same way as
every other CPS-backed page.
What gets logged
Section titled “What gets logged”This is a unified, cross-service feed: every first-party service that mutates a tenant-scoped resource fans its events into the same underlying log, regardless of which service owns the data. An entry is recorded whenever an operator (or the system, or an AI agent acting through the MCP server) changes one of these resources:
| Action | Where it happens |
|---|---|
| API key created / updated / rotated / revoked | API Keys |
| Certificate issued / renamed / revoked | Certificates page |
| KMS key generated / imported / rotated / retired / rotation-due notice | Keys (KMS) page |
| Behaviour created / updated / patched / imported / deleted | Behaviours |
| Engine tenant config created / updated | Engine configuration |
| Routing rule created / updated | Routing rules |
| Connected app created / scopes updated / revoked | Connected Apps |
| Product trial started; product activated, suspended, cancelled, or plan changed | Products and trials |
| Billing change requested, scheduled for removal, or undone | Products and trials |
An AI agent acting through the MCP server generates its own, separately-tagged entries for the same underlying resources (API keys, certificates, behaviours, engine config, and routing rules) whenever it makes a change on your behalf, so you can tell an agent-driven change apart from one made directly in the dashboard.
The audit log only captures resource lifecycle events and operational audit signals like these — not every action is a mutation (the KMS rotation-due notice above fires without changing the key), but it is still not a general request log. Read-only browsing (viewing a list, running a report) never produces an entry.
Filters
Section titled “Filters”- From / To — restrict the log to entries whose timestamp falls in the selected date range, inclusive of both endpoints. Leave either blank for an open-ended range.
- Action — narrow to one of the action names in the dropdown. The dropdown lists the API key, certificate (issue, rename, and revoke), engine config, routing rule, KMS key, behaviour, and connected app revoke actions, plus legacy agent-credential actions that only exist in old rows. Product, billing, connected app create or scope-change, and MCP agent actions are not in the dropdown, but they still appear in the feed. Leave the filter on All actions and use From/To plus the row detail to find them.
Click Apply to run the filters, or Reset to clear them and return to the full unfiltered log. Changing filters always returns you to the newest page.
Reading a row
Section titled “Reading a row”Each row shows the event’s time, action, actor, and source IP:
- Actor shows “System” only for CPS-native events with no user attached.
Cross-service events (KMS, BCS, agent connections, MCP) always carry an
identity — including automated actors like the KMS rotation reminder — so
they show as a resolved
User #<id>rather than “System”. - IP is only ever populated for actions taken directly against CPS from an authenticated request (for example, creating an API key from the dashboard). Cross-service events carry no source IP and always show an em dash.
Click View to expand a row and see its full detail:
- Target — which resource was acted on (for example the API key’s id and prefix, or the certificate’s serial number).
- Metadata — supplementary detail about the change itself (for example an API key’s scopes and rate limit at creation, or a routing rule’s new configuration). Metadata never includes secrets — a key’s plaintext value or a certificate’s private key never appear here.
Why it matters
Section titled “Why it matters”For a regulated fintech operator, the audit log is often the first place to look during an incident or a compliance review: it answers who changed what, and when. If you revoked a certificate or rotated an API key and need to confirm it happened — and who did it — this is where to check. Because entries are permanent and cannot be edited or deleted from the dashboard, it is also the authoritative record when reconciling what a teammate or an automated process changed.