Sessions
Every sequence of AI interactions is grouped into a session. Sessions provide the full context for enforcement decisions — what an agent has accessed, what data classifications it has touched, and how its behavior has evolved across a conversation.
Where to find it in the app
Dashboard → Actions & Evidence → Activity Timeline.
The Activity Timeline view lists every session with the actor, agent, start time, duration, total cost, detection count, and severity. Filter by agent, status (Open / Closed / Escalated), date range, or severity.
Click a session to open its detail page — the full event timeline with timestamps, every detection, the enforcement actions taken, tool calls, RAG fetches, and the original request.
A per-agent session view is also available from Dashboard → Agent Registry → click agent → Activity tab, scoped to that single agent.
What is a session?
A session is a continuous thread of interactions between an actor (user or agent) and one or more AI providers. Rivaro groups requests into sessions automatically using several signals:
- An explicit
x-session-idheader in your request - A W3C
traceparentheader (OpenTelemetry compatible) - The adapter's own session/thread/run identifier
- Smart detection — requests from the same actor within a 30-minute window are grouped automatically
Sessions are important for enforcement because Rivaro maintains a security context that accumulates across the session. If an agent accesses credentials in turn 3, that context is considered in the risk assessment for turn 7.
Session Fields
| Field | Description |
|---|---|
sessionId | Unique session identifier (UUID) |
actorId | User or service identifier making the requests |
agentId | Agent identity (ag_xxx) responsible for the session |
status | OPEN, CLOSED, or ESCALATED |
createdAt | When the session started |
lastActivityAt | Most recent request timestamp (updated every 60 seconds) |
traceId | W3C Trace Context trace ID (for OTel integration) |
spanId | W3C Trace Context span ID |
interactionId | Framework thread/run ID (LangChain, AutoGen, etc.) |
Aggregated metrics
These are computed asynchronously (accurate within ~60 seconds) and denormalized on the session for fast querying:
| Field | Description |
|---|---|
totalCostUsd | Sum of token costs across all requests in the session |
totalTokens | Total tokens used |
detectionCount | Number of policy violations detected |
incidentSeverity | Highest severity score seen in the session (0–100) |
eventCount | Total events recorded |
Security context
Rivaro maintains a security context that accumulates over the session's lifetime:
| Field | Description |
|---|---|
originalRequest | Truncated first user message — immutable once set, used to detect goal drift |
dataClassificationsAccessed | High-water mark of data classifications seen in this session (e.g. PII,PHI,CREDENTIALS) |
The session context directly feeds the risk assessment. An agent that accessed credentials earlier in the session carries elevated session risk for subsequent enforcement decisions — even if the current request looks benign.
Session Events
Events are the append-only record of everything that happened inside a session. Each event references an entity (a detection, a telemetry record, a content record) and records when it happened and which agent produced it.
Event types
| Event type | What it records |
|---|---|
TELEMETRY | Token counts, latency, cost for a request |
CONTENT | The request/response content (subject to retention policy) |
DETECTION | A policy violation found during ingress or egress scanning |
POLICY_ACTION | The enforcement action taken (BLOCK, REDACT, LOG, etc.) |
ALERT | An elevated alert triggered by a detection |
RAG_FETCH | A retrieval-augmented generation fetch — what data was pulled |
MCP_TOOL | An MCP tool invocation — which tool, with what arguments |
SESSION_CLOSED | Session closure event with summary metadata |
Event fields
| Field | Description |
|---|---|
eventType | One of the event types above |
entityType | Type of the referenced entity (Detection, TelemetryMetric, etc.) |
entityId | ID of the referenced entity for cross-referencing |
timestamp | When this event occurred |
agentId | Which agent produced this event |
adapter | Which provider adapter was used |
resource | App, page, or tool where this happened |
traceId / spanId | OpenTelemetry trace context |
Session Lifecycle
Opening a session
Sessions are created automatically when a request arrives with no matching open session. No SDK changes are needed — Rivaro handles session management transparently.
To correlate requests into a session explicitly, pass an x-session-id header or use the W3C traceparent header from your tracing system.
Session status
| Status | Meaning |
|---|---|
OPEN | Active — requests are being grouped into this session |
CLOSED | Session ended normally (explicit close or inactivity timeout) |
ESCALATED | Session flagged for admin review due to governance escalation |
Closing a session
Sessions close in three ways:
- Explicit close — your application sends a close signal
- Inactivity timeout — no new requests for the session timeout window (30 minutes by default)
- Governance action — quarantine or termination of the actor automatically closes open sessions
Session Risk & Enforcement
Session context contributes to the risk score of every enforcement decision made within it:
| Context signal | Risk impact |
|---|---|
| Credentials accessed in session | +30 to risk score |
| Sensitive data + outbound tool call in session | +20 to risk score |
| High event volume (>20 events) | +10 to risk score |
This means a single session where an agent accessed a secret early on will trigger stricter enforcement on subsequent requests — even if later requests look clean in isolation. See Actor Governance for the full risk score formula.
Next steps
- Actor Governance — How session context feeds into risk scoring and enforcement
- Enforcement & Policies — Policy actions that create session events
- Understanding Detections — What Rivaro scans for in each request