Skip to main content

Audit Log: Complete Administrative Action History

Administrative history is only useful if people can query it quickly, trust that it has not been rewritten, and move from the history record into the rest of the operating workflow. In Keeptrusts, that capability lives in the immutable Trail explorer, which the product and docs also describe as the audit log. The Trail view gives you searchable event history, linked records from runtime events, filterable investigation windows, JSON export, chain verification, and SIEM subscriptions for forwarding the same evidence stream outward.

Use this page when​

  • You need a complete history of who changed what, when, and with what result.
  • You are preparing an internal review, audit response, or incident timeline.
  • You want to distinguish administrative history from request-level policy logging and use both correctly.

Primary audience​

  • Primary: Technical Engineers
  • Secondary: Security teams, compliance reviewers, technical leaders

The problem​

“Audit log” often becomes a vague promise. A product says it has one, but the history is incomplete, hard to filter, or impossible to validate. Sometimes it captures request traffic but not administrative changes. Sometimes it captures settings changes but not who triggered them. Sometimes it can be exported, but not in a way that external security tooling can consume.

That is a serious weakness in an AI governance platform. Identity changes, policy rollouts, token creation, escalation resolutions, and security actions all need to be reconstructable after the fact. During an incident or audit, you are not just looking for a single event. You are looking for a sequence:

  • who signed in,
  • who changed a configuration,
  • who rotated or created a token,
  • who reviewed or resolved a queue item,
  • whether the action succeeded or failed,
  • and what else happened around the same time.

Keeptrusts addresses that with an immutable administrative trail rather than a loose activity feed.

What the feature does​

In the console, the administrative history surface is exposed as Trail. The page headline is Trail Events and its purpose is explicit: an immutable audit trail of all organization activities.

The page gives you several practical controls.

  • Filters for investigation windows and targeted searches.
  • Auto-refresh for active investigations.
  • A detail view for examining individual records.
  • A Verify Chain action to validate trail integrity.
  • Export JSON for immediate evidence extraction.
  • SIEM Subscriptions so the same trail can be forwarded to external systems.

The Trail explorer also supports linked context. If you arrive from an event record, the page can show you trail entries associated with that event and let you move back into the originating runtime surface.

That connected workflow matters. Good history tools do not force people to manually stitch together context from unrelated pages.

Trail versus request-level audit logging​

There is an important distinction worth making clearly.

The administrative Trail is not the same thing as the audit-logger policy used in configurations for proxied AI requests. Both matter, but they answer different questions.

  • Trail answers: who logged in, who changed settings, who created a token, who resolved an escalation, who changed policy state, and what happened administratively.
  • Request audit logging answers: what AI traffic passed through the gateway, what policy chain ran, and what the runtime decision was.

In other words, Trail is about administrative accountability. Request-level audit logging is about governed AI activity. Mature operations need both.

Practical workflow​

The most useful way to work with Trail is to start from a specific question.

Imagine your team observes an unexpected spike in escalations after a configuration rollout. You want to know whether the spike aligns with a policy change, who made it, and whether any follow-up administrative action happened afterward.

Use this workflow:

  1. Open Trail from the settings navigation.
  2. Set a start and end window around the suspected rollout period.
  3. Filter down to the relevant actor, action, or resource if you already know part of the story.
  4. Inspect the matching records for the configuration change, sign-in activity, and any subsequent token or review actions.
  5. Open the detail view for the change record and read the structured details.
  6. If the issue is tied to a runtime event, follow the linked context between Trail and the originating event.
  7. Run Verify Chain if you need explicit integrity confirmation during the investigation.
  8. Export JSON if the incident timeline must be shared outside the console.
  9. If your security team uses a SIEM, confirm the relevant subscription is already forwarding trail events or create one for ongoing monitoring.

That entire loop is much faster than trying to reconstruct the same story from separate spreadsheets, chat messages, and partial screenshots.

A concrete example​

Suppose an organization admin saves and deploys a configuration version late Friday, and by Monday morning reviewers are reporting more queued work than expected. In Trail, you can narrow the window to the deployment period, inspect the change record, identify the actor, review the action metadata, and confirm whether the configuration change succeeded.

From there, you can correlate outward:

  • check runtime Events for the new decision mix,
  • inspect the inbox for resulting escalations,
  • and determine whether a follow-up administrative response occurred, such as a rollback or token change.

If the incident escalates into a formal review, export the relevant JSON immediately or use SIEM subscriptions to hand the same evidence into your broader security workflow.

That is the value of complete action history. It turns “something changed” into a defensible chronology.

Evidence and external delivery​

Trail is not only a viewer. It is also an evidence surface.

The page supports immediate JSON export, which is useful for narrow investigations. For broader operational integration, Trail subscriptions can forward events to external SIEM destinations. The implementation supports delivery formats including json, jsonl, and cloudtrail, which makes the history easier to fit into existing security pipelines rather than forcing a separate manual export process for each review.

That matters because the most important audit record is often the one you need outside the console. Security teams may want continuous ingestion. Compliance teams may want targeted snapshots. Engineers may want a quick export attached to an incident ticket. Trail supports all three patterns without changing the underlying source of truth.

Why integrity matters​

History without integrity is just activity data. The presence of a Verify Chain action is important because it acknowledges a real audit requirement: evidence should be checkable, not merely visible.

For day-to-day operations, you may not verify the chain every time you inspect a record. During an incident, an external review, or a compliance handoff, that capability becomes much more important. It strengthens confidence that the trail you are exporting or reviewing has remained intact.

Combined with request-level audit logging, this creates a stronger overall story. Administrative actions are traceable. Runtime AI activity is traceable. And the boundary between those two histories remains clear enough to investigate both properly.

Results and impact​

Teams that rely on Trail as the administrative source of truth respond faster and argue less about provenance. Security reviewers can reconstruct timelines without guessing which page was authoritative. Engineers can connect a suspicious runtime change to the exact administrative action that preceded it. Leaders get a more defensible evidence chain for audits and retrospectives.

Trail gives you the administrative half of that picture in a way that is queryable, exportable, and externally consumable.

Key takeaways​

  • Keeptrusts exposes administrative history in the immutable Trail explorer.
  • Trail is the audit log for organizational actions, not a substitute for request-level audit-logger policy records.
  • Use filters, linked context, and auto-refresh during investigations.
  • Use Verify Chain when integrity itself is part of the question.
  • Export JSON or forward the stream to a SIEM when the evidence needs to leave the console.

Next steps​