Audit Agent Router activity

Enterprise Tier

Two questions land on a platform operator's desk more reliably than any other: who did this?, usually after a configuration changes unexpectedly, a key disappears, or a model behaves differently than it did yesterday; and what is Agent Router actually doing?, usually before a quarterly review, a cost forecast, or a compliance attestation. Both are answered from the same place: Agent Router's record of activity, surfaced through two complementary screens in the Admin Dashboard. Audit Logs is the immutable per-event record of every administrative action, and Usage Analytics is the aggregated traffic view. This guide covers both, the investigation patterns that combine them, and the compliance posture the audit surface supports.

---

Audit Logs is the per-event record. Every administrative action (secret rotation, guardrail change, project membership edit, API key lifecycle event, data-plane change, and similar mutations) is captured with a timestamp, an actor, an actionType, the affected resource, and structured context. The log is immutable; nothing in Agent Router can edit or delete an entry once it has been written. Usage Analytics is the aggregated traffic view: organization-wide request counts, token totals, costs, and breakdowns by user, model, provider, and API key, with time-range filtering and export. Together they answer the two questions: Audit Logs for "who did what", Usage Analytics for "what is happening". For the full wire schema, see Audit log events.

Persona: Platform operator working in the Admin Dashboard, often under time pressure during an incident or a compliance review.

Estimated time: 10 to 15 minutes for an initial tour; ongoing thereafter.

When this guide applies

This guide is the right surface in any of these situations:

Situation	Surface that helps most
Investigating a configuration that has changed unexpectedly	Audit Logs, filtered by resource and time range
Identifying who revoked an API key, or when	Audit Logs, filtered by action type
Producing a SOC 2, ISO 27001, or other compliance attestation	Audit Logs export, filtered by the relevant time window
Forecasting cost across the rest of the quarter	Usage Analytics with a long time range
Identifying the heaviest-consuming user or team	Usage Analytics with the By User breakdown
Detecting an unexpected spike in spend	Usage Analytics with anomaly inspection, then Audit Logs to correlate to a recent change

For the developer-side equivalents of the same data (per-request investigation and per-key usage), the Monitor Traffic and Usage developer guide is the corresponding surface.

Outcomes

By the end of this guide:

• The Audit Logs surface has been opened, exercised, and at least one audit entry has been located with the filters.
• The Usage Analytics surface has been opened and the user, model, provider, and API key breakdowns reviewed.
• A combined investigation pattern ("use Usage Analytics to spot the anomaly, then Audit Logs to find the cause") has been walked through at least once.
• The compliance and retention model is understood, including the immutability guarantee on the log.

Prerequisites

• Administrator access to the Admin Dashboard, typically the super_admin or billing_admin role for Usage Analytics, and super_admin for the full Audit Logs surface.
• Some recent activity in Agent Router. A freshly-installed Agent Router with no traffic and no administrative changes will surface empty screens that are technically working but uninformative.

Step 1: open audit logs and orient

The Audit Logs surface is the closest Agent Router comes to a single source of truth for what has been changed and by whom. Every administrative action surfaces here, with no editing or deletion possible after the fact.

1. Sign in to the Admin Dashboard.
2. Open Audit Logs from the sidebar.

1. Review the columns surfaced for each entry:

   Field	What it carries
   Timestamp	Exact date and time in UTC
   User / Actor	The acting user id (and email when available)
   Action	Wire actionType such as CREATE_SECRET, SET_GUARDRAIL_STATUS, or DELETE
   Resource	resourceType plus resourceId, often with a human-readable label in the UI
   Source	Origin of the request when known
   Result	Success or failure, with HTTP status when available

2. Note that entries appear in reverse chronological order. The most recent action is at the top of the list.

Action names are stable uppercase strings on the wire (CREATE_SECRET, UPDATE_GUARDRAIL, ADD_PROJECT_MODEL), not dotted <resource>.<verb> labels. Common examples:

Action type	Generated when
CREATE_SECRET / DELETE_SECRET / ROTATE_SECRET	Secret lifecycle
SET_GUARDRAIL_STATUS / CREATE_GUARDRAIL / UPDATE_GUARDRAIL	Guardrail enablement and edits
ADD_PROJECT_MODEL / REMOVE_PROJECT_MODEL	Project model catalogue changes
ADD_PROJECT_PROVIDER / REMOVE_PROJECT_PROVIDER	Project provider attachment
CREATE_CLIENT_KEY / DISABLE_CLIENT_KEY / DESTROY_CLIENT_KEY	API key lifecycle
ADD_PROJECT_MEMBER / UPDATE_PROJECT_MEMBER / REMOVE_PROJECT_MEMBER	Project membership
CREATE_DATAPLANE / UPDATE_DATAPLANE / DELETE_DATAPLANE	Data plane lifecycle
CREATE_TELEMETRY_CONFIG / UPDATE_TELEMETRY_CONFIG	Telemetry / SIEM forward configuration

See Audit log events for the full field list and a broader vocabulary sample.

Step 2: investigate a specific change

Most investigations into the Audit Logs surface come down to a sequence of filter applications. The available filters can be combined; the more specific the combination, the smaller and more useful the result set.

1. Set the time range to the window around the moment of interest. A narrower window is almost always more useful than a wider one.
2. Apply the Actor filter to a specific user if there is reason to suspect a particular operator's actions.
3. Apply the Action filter if the type of change is known, for example REMOVE_PROJECT_PROVIDER if a provider detachment is suspected.
4. Apply the Resource filter to a specific resource if the affected object is known: a model id, a provider id, a secret name, or an API key id.
5. Open View on the resulting entries. metadata, request context, and result fields usually identify what changed.

A worked example. A developer reports that requests targeting gpt-4o started failing yesterday afternoon. To investigate:

1. Set the time range to yesterday afternoon, plus a couple of hours of buffer on either side.
2. Filter on the model or provider resource associated with gpt-4o.
3. Review the resulting entries. An REMOVE_PROJECT_MODEL or REMOVE_PROJECT_PROVIDER action in that window would explain the symptom immediately.
4. If no model-level change shows up, broaden the search by removing the resource filter and looking for related actionType values on the same provider in the same window.

The same pattern applies to almost every "what changed" investigation: narrow on time first, then on resource or action, then read the entry detail.

Step 3: open usage analytics and orient

Where Audit Logs answers "what changed", Usage Analytics answers "what happened". The two are designed to be used together, and they share the same time-range model.

1. Open Usage → Analytics from the sidebar.

1. Review the top-level metrics:

   Metric	What it captures
   Total Requests	All API requests in the selected time range
   Total Tokens	Combined input and output token totals
   Total Cost	Estimated cost from model pricing tiers and token totals
   Unique Users	Number of distinct users who issued requests
   Unique Models	Number of distinct models that received requests

2. Apply a time range at the top of the page. Presets cover last 24 hours, last 7 days, and last 30 days; a custom range covers anything longer or more specific.

3. Switch between the available breakdowns:

   Breakdown	What it reveals
   By User	Ranked list of users by requests, tokens, or cost; useful for identifying heavy consumers or unusual patterns
   By Model	Which models the workload actually leans on; useful for retiring rarely-used models and for negotiating with providers
   By Provider	Cost and volume across providers; useful for contract negotiation and capacity planning
   By API Key	Per-key request and cost picture; useful for spotting integrations that might need rate limiting

The By User breakdown supports drill-down: clicking a user's bar or table row focuses on that person. To select several users or teams at once and compare them side by side, see Compare user and team spend in Analytics.

The distinction between this surface and the developer-side Usage page in the Console is worth keeping clear:

Feature	Admin Usage Analytics	Console Usage
Scope	All users and API keys	The signed-in user's own data
Breakdowns	User, model, provider, API key	Model, API key
Cost analysis	Organization-wide cost totals and per-user costs	Individual user costs
Export	Full Agent Router data export	Personal data export
Audience	Agent Router administrators	Individual developers

Step 4: combine the two surfaces in an investigation

The interesting investigations almost always cross both surfaces. The pattern that works most reliably:

1. Spot the anomaly on Usage Analytics. An unexpected cost spike on the cost-by-provider chart, an unfamiliar model in the by-model breakdown, an outlier in the by-user list.
2. Identify the resource. Filter Usage Analytics down to the specific user, model, provider, or key the anomaly points at.
3. Switch to Audit Logs. Apply the same time window plus the resource filter.
4. Look for an administrative event. Most surprising traffic patterns are explained by a recent configuration change: a new model enabled, a routing change, a user role modified, or an API key reissued.
5. Reconstruct the timeline. The combination of the audit entry and the usage chart shows what changed, who changed it, and the resulting traffic shift.

The reverse direction (starting from an audit event and looking for its traffic consequences) is equally common. A recent ADD_PROJECT_PROVIDER event makes a new provider show up in the by-provider breakdown; a recent ADD_PROJECT_MODEL makes a model appear in the by-model breakdown; these correlations are how the "did the change have the intended effect" question gets answered.

Step 5: export for compliance and reporting

Usage Analytics supports export of the filtered data:

1. Apply the time range and breakdown filters that match the report being produced.
2. Click Export.
3. Select the format (typically CSV).
4. The downloaded file contains the metrics for the selected filters and time range.

Audit Logs export, where supported by the deployment, follows the same shape. The exported records are the same immutable rows that the screen displays, with all of the audit fields included.

Compliance posture

The audit surface is deliberately built to satisfy the audit and integrity requirements of SOC 2, ISO 27001, and similar frameworks. Three properties are worth being able to assert:

• Immutability. Audit entries cannot be edited or deleted by any user, regardless of role. There is no "delete from the log" operation anywhere in the Admin Dashboard.
• Coverage. Every state-modifying administrative action generates an entry. There is no path through the Admin Dashboard that changes Agent Router state without leaving a record.
• Retention. The retention period for audit data is set by the deployment configuration. Long-horizon retention, including compliance-archival use cases, is supported through export to an external system; the in-Console window is intended for active investigation rather than indefinite storage.

What to do next

• Configure single sign-on: the SSO and role-mapping surface generates audit events that this guide makes visible. See Configure Single Sign-On.
• Working with budgets: budgets track spend and raise alerts, and are visible in Usage Analytics. See Choose the right cost control for each workload.
• Run multiple Agent Router instances: multi-instance deployments need to be audited per instance; the audit surface helps confirm that boundary. See Run Multiple Agent Router Instances.

The audit and usage surfaces remain available across every subsequent operational activity.

---

Where to go next

Configure single sign-on

The SSO surface generates audit events this guide makes visible.

Working with budgets

Budgets track spend and raise alerts, and are visible in Usage Analytics.