Session

Session

A Session is one continuous run of an Agent.

Has a session_id (UUID). Lasts from when the Agent starts a conversation/task to when it ends or is killed. The unit at which loop_guard, drift detection, and audit chains track state.

At a glance

Has	a session_id (UUID); a started_at; an ended_at (or killed_at)
Happens within	one Sandbox
Belongs to	one Agent (the Sandbox's Agent)
Tracked for	loop_guard (sliding-window destructive-op detection), drift baseline, audit chain integrity

What it is, concretely

When an Agent starts working — answering a chat, processing a task, running a tool sequence — that's a Session. It might last seconds (a single tool call) or hours (a long agentic loop).

A Session ends when:

• The Agent finishes the task naturally
• The Agent is idle past a timeout
• A pipeline step kills it (loop_guard trips, capability-token revoked)
• The operator revokes the Sandbox

Every governed event in a Session shares the same session_id and trace_id, so reconstructing what happened is trivial.

Why Sessions are the right unit for tracking

Several pipeline behaviors operate per-Session, not per-call:

Behavior	Why it's per-Session
loop_guard (sliding-window detection)	"3 deletions in 60s" only makes sense within a single Session. Otherwise an Agent would trip after 3 cumulative deletes over its entire lifetime.
Drift baseline matching	The pre-deployment baseline characterizes typical Sessions. Drift is detected when current Session tool-call distribution diverges from baseline.
Audit chain integrity	Each Session's audit forms a sub-chain inside the global hash chain — verifiable independently.
Capability token scoping	Tokens are issued per-Session, expire when the Session ends.

Where Sessions sit in the picture

       Project (e.g. "Customer support")
         │
         ▼
       Agent (e.g. "support-emailer-bot")
         │
         ▼
       Sandbox (one per host)
         │
         │ over time
         ▼
       Session 1 (10:00–10:15)  ─┐
       Session 2 (10:30–11:00)   ├─ each = one continuous run
       Session 3 (14:20–…)       │  with its own session_id,
       …                         ┘  trace_id, audit sub-chain

What gets recorded per Session

Every governed call within a Session produces an Audit log row carrying:

• The session_id (this Session)
• The trace_id (this specific call within the Session — multiple per Session)
• The policy_version enforced
• The Pipeline step decisions (allow / deny / redact, with reasons)
• The signed mandate (Ed25519) for any allow

So reconstruction of a Session = filter the audit log by session_id, walk in time order. Every decision, every reason, every signature, every input/output (PII-redacted).

Surfaces

Persona	Surface	What you do
Operator	Dashboard sessions tab	Browse active + historical Sessions per Sandbox
Operator	tappass session kill <session_id>	Force-kill a runaway Session
Auditor	Dashboard audit views	Filter audit by session_id for incident response / compliance

Related concepts

• Happens within → Sandbox
• Belongs to → Agent
• Tracked by → loop_guard and drift detection
• Recorded in → Audit log