Skip to main content

User Activity Reporting: Who Uses AI and How Within Your Org

Keeptrusts answers "who uses AI and how within your org" through the activity view on /history?view=activity, where you can filter by actor, gateway, tool server, source type, and time range, then export the resulting activity facts instead of relying on anecdote, screenshots, or manually sampled event logs.

Use this page when​

  • You need to understand which users or services are driving governed AI activity.
  • You want a report that reflects behavior patterns, not just raw transcripts.
  • You need an exportable activity trail for governance, incident review, or operational planning.

Primary audience​

  • Primary: Technical Engineers, Platform Operators, and audit-minded reviewers
  • Secondary: Technical Leaders tracking adoption and operational load

The problem​

Usage reporting often swings between two unhelpful extremes.

At one end, you have aggregate metrics that tell you total requests or total cost but say very little about behavior. At the other, you have raw conversation or event logs that are too detailed to summarize quickly.

Neither one is enough when you want to answer practical questions such as:

  • Which users are actually using the platform?
  • Is the traffic coming from prompt workflows, approvals, audit events, or gateway actions?
  • Which gateway or tool server is responsible for most of the activity?
  • Are users interacting directly, or is a service account driving the load?

Without a dedicated reporting view, teams end up manually stitching answers together from event samples, chat history, exports, and operations memory. That is slow, inconsistent, and poor for auditability.

The solution​

The Keeptrusts activity page solves this by focusing on activity facts rather than only on content.

On /history?view=activity, the console can filter and summarize across several source types, including prompts, gateway actions, MCP receipts, audit events, approvals, and lifecycle signals. That matters because usage is not just about who typed a prompt. It also includes surrounding governed behavior.

The page is built for both filtering and reporting:

  • source-type filters let you separate prompt activity from approval or lifecycle traffic
  • actor, gateway, and tool-server filters help you isolate a user, integration, or runtime path
  • time-window filters help you turn the page into a weekly or incident-specific report
  • export lets you move from interactive exploration into a durable artifact

It also supports drill-through. Some entries deep-link into /events/{id}, /trail, or /approvals/{id}, so the report page is not a dead end. You can move from summary to evidence quickly.

Implementation​

The most reliable way to use the page is to run a simple reporting workflow every time.

  1. Open /history?view=activity.
  2. Start with the time range that matches the question you are answering.
  3. If you are investigating a user or team, add actor or gateway filters early.
  4. Narrow by source type only after you understand the overall mix.
  5. Use the on-page summary counts to confirm whether the view is representative.
  6. Open a few linked records for validation before you export.
  7. Export once the filter set reflects the report you actually want to keep.

This page is especially useful for operational questions, not just formal audit work.

For example, if leadership asks why AI adoption rose last week, do not start in chat history. Start here.

  1. Filter the page to the last seven days.
  2. Compare prompts versus gateway actions and approvals.
  3. Filter by actor or gateway when one integration looks unusually active.
  4. Open representative deep links to confirm the increase is real usage rather than background workflow noise.

Another common workflow is incident analysis.

  1. A gateway or escalation issue appears.
  2. Open /history?view=activity for the relevant incident window.
  3. Filter to the affected gateway ID.
  4. Review whether the issue was concentrated in prompt traffic, approval traffic, or another activity type.
  5. Export the filtered set for evidence and follow-up.

The point is that the activity page lets you report on platform use without pretending that every meaningful fact lives inside message content.

If you need a narrower command-line comparison against recent governed traffic, pair the page with a short event pull:

kt events tail --since 24h --json

That command is not a replacement for the activity page. It is a useful cross-check when you want raw event samples next to the higher-level activity report.

One subtle strength of the page is that it respects redaction and reporting boundaries. You still get a usable activity record even when underlying content is summarized or redacted. That keeps the reporting surface useful in regulated environments where raw content should not be exposed casually.

Results and impact​

Good activity reporting changes two things.

First, it makes adoption measurable in a form that operations teams can trust. You can distinguish real prompt usage from platform lifecycle noise. You can see whether activity is distributed or concentrated. You can connect usage patterns to gateways, actors, and workflow types.

Second, it reduces the time needed to answer governance questions. Instead of assembling evidence from several disconnected pages, operators can filter once, validate a few linked records, and export the result. That speeds up internal reviews and lowers the cost of recurring reporting.

This matters because AI governance questions often arrive suddenly. Leadership wants a weekly snapshot. Security wants an incident window. Finance wants to understand whether higher spend came from more users or more expensive behavior. The activity page is useful precisely because it turns those into filter-and-export tasks instead of custom analysis projects.

Key takeaways​

  • Use /history?view=activity when you need behavior reporting, not just transcripts or raw events.
  • Filter by actor, gateway, tool server, source type, and time range before exporting.
  • Validate a filtered report by opening a few linked records before you treat it as final evidence.
  • Pair the page with event samples when you need raw context next to the report.
  • Activity reporting is most useful when you treat it as an operating surface, not a once-a-quarter audit page.

Next steps​