Skip to main content

​
Audit Logs

Audit logs are the tenant security trail for who changed what in NeuralTrust — sign-ins, membership and role changes, SSO and SCIM, and configuration of TrustGate and TrustGuard resources. In the console they live under Telemetry → Logs (platform stream). Use them for compliance evidence, security monitoring, and incident investigation.
Logs is not the same as product Activity (Gateway or Runtime request explorers) or Alerts (detection findings from TrustGuard / TrustGate telemetry). Those surfaces show runtime traffic and raised detections; Logs shows console and configuration audit events.

​
Open Logs

  1. Sign in to NeuralTrust with access to the Telemetry product (at least Read only).
  2. Open Telemetry from the top bar (or go to /{teamId}/telemetry).
  3. Select the Logs tab.
Telemetry has three tabs: Alerts, Logs, and Integrations.

​
What you see

Each row is one audit event: Row menu:
  • Copy details — copies the full row as JSON to the clipboard (for tickets or SIEM correlation).
Toolbar:
  • Search action — filters the currently loaded rows by action text
  • Filter — Author email, Trace ID, Event type (applied when loading from the server)
  • Date range — optional bounds on when events occurred
  • Export — downloads a CSV of the visible (loaded + filtered) rows
  • Refresh — reloads the list
  • Scroll / load more — pages of up to 100 events

​
Filters

Sort any column in the table (default: newest first).

​
Categories

Events are grouped into categories. Platform Logs include identity, admin, and product-configuration categories: A separate Activity stream is reserved for runtime product operations (e.g. runtime security and posture). The Logs table today focuses on the platform audit trail above.

​
Representative event types

Exact type strings appear in filters and in Copy details. Common examples:

​
Authentication

​
User management & platform IAM

​
SSO, SCIM, OIDC

​
TrustGate & TrustGuard configuration

Sensitive values (passwords, tokens, secrets, cookies, session material) are redacted from stored metadata.

​
Login failures

When investigating auth.login.failure (or related auth events), common failure reasons include:

​
Suspicious patterns worth reviewing

  1. Many failures from one IP across different accounts
  2. Success immediately after a burst of failures
  3. Break-glass or off-hours admin activity
  4. Rapid role or ownership changes
  5. Unexpected SSO config or SCIM deprovision events

​
Export and retention

  • CSV export includes Date, Category, Actor, Action, and Resource for the rows currently visible after filters and search. Load more pages before export if you need a wider window.
  • Copy details is the full JSON for a single event.
  • Audit events are retained for 365 days (SOC2 minimum). Forward critical streams to your own SIEM if you need longer retention.

​
Access

Platform IAM admins and Global Admins typically already have Telemetry access; grant Telemetry Read only when a compliance reviewer needs the trail without product admin rights.

​
Forwarding to a SIEM

Telemetry → Integrations forwards alert findings (detections), not every audit row, as OCSF Detection Findings. See Integrations. For the audit trail itself:
  • Use Export / Copy details for investigations and evidence packs, or
  • Ingest exported CSV/JSON into your SIEM on a schedule if you need the full console audit stream outside NeuralTrust.

​
Troubleshooting

​
Best practices

  1. Review authentication and SSO categories regularly, especially after IdP changes.
  2. After offboarding, filter by the user’s email and confirm role removals and SCIM deprovision events.
  3. Prefer Event type + Author over free-text search for forensic queries.
  4. Export or copy JSON when opening an incident ticket so the evidence is immutable.
  5. Do not confuse Logs with Gateway/Runtime Activity when answering “what did this API call do?”