Docs

Console

Sessions

Drill into individual agent runs in the RenLayer Console, request bodies, responses, latencies, DLP findings, and the policies that fired.

A session is the unit of investigation in RenLayer. It groups one or more traces from the same logical agent run (typically tied together by the X-RenLayer-Session header) so you can answer questions like “what did this agent do over the last five minutes for this user?”.

The session list

The Sessions page opens with a paginated list of recent sessions. Each row shows:

  • Agent name.
  • User identifier (if the agent forwards X-RenLayer-User).
  • Started at and duration.
  • Action count and a badge of any non-ALLOWED outcomes.

Filters at the top: agent, user, status, time window, free-text search across prompt content (subject to your role’s permissions).

The session detail

Click any session to open its detail view. The view has three panes:

  • Timeline on the left, every trace in chronological order, with a colored badge for its action status.
  • Trace detail in the center, full request and response bodies (redacted by default; reveal requires permission), latency, token counts, model, and the upstream URL.
  • Side panel on the right, DLP findings on this trace, the policies that matched, and the rate-limit state at request time.

Body redaction

By default, the console renders bodies with all DLP-matched spans redacted (e.g. [REDACTED:secret.aws_access_key]). Operators with the unmask permission can reveal the original value; every reveal is recorded in the audit log.

Joining to your own logs

The proxy returns X-RenLayer-Trace-Id on every response. If your agent code logs that header, you can paste a trace ID into the session search and jump straight to the matching trace, useful for incident response when you have an application log line and need the governance context.

Exporting

Sessions can be exported as JSON for offline analysis. Exports respect role permissions (redacted spans stay redacted unless the exporter has unmask).

Common workflows

  • Triage a denied request. Filter to DENIED in the last hour; the side panel shows which policy fired and why.
  • Investigate a DLP block. Filter to DLP_BLOCKED; the side panel shows the detector that matched and the byte range in the body.
  • Reproduce a customer issue. Filter by X-RenLayer-User to see exactly what one user’s session looked like.

Where to go next

Last updated: