Skip to content
TapPass

Sessions & path-aware policy

Most governance tools evaluate each call in isolation. TapPass also evaluates the path: the ordered history of what this agent has already done in this session. The same action can be allowed at minute one and blocked at minute ten, because of what came before it.

What a session accumulates

Section titled “What a session accumulates”

Every governed call, including blocked attempts, is appended to the session’s path after the decision. The tracker keeps, per session:

  • the ordered event list (behavior type, resource, timestamp), and
  • aggregates: count_by_type, unique_resources, total_events, first/last timestamps.

A session is identified by session_id; when the caller doesn’t supply one, the server pins one per (org, agent).

What policy sees

Section titled “What policy sees”

Three projections land in the policy input:

{
  "state": {
    "session": { "event_count": 17, "unique_resources": 4 },
    "path":    { "tools": ["read_file", "query_db", "read_file"],
                 "last":  { "type": "TOOL_CALL", "resource": "read_file" } }
  },
  "path": {                         // opt-in: full projection
    "session_id": "ses_…",
    "events": [ /* capped at a fixed window */ ],
    "aggregates": { /* counts, uniques, timestamps */ }
  }
}
  • state.session, always available.
  • state.path.tools, the ordered prior tool trajectory; read by sequence and rate rules.
  • state.path.last, the immediate predecessor event (type + resource), regardless of type. Freshness rules key on it: “the gate must be the step directly before this one,” not “a gate exists somewhere in history.”
  • path, the full event projection, available when opt-in path projection is enabled for your org. Rules that read it (e.g. the rate_limit_tool_per_session template) require it.

If the path store is unavailable, state.session becomes {"unavailable": true} and path facts are absent, policy can treat “history unknown” as a reason to refuse, keeping the system fail-closed.

What path-aware rules look like

Section titled “What path-aware rules look like”

Concrete rules you can express today with built-in kinds:

Intent Rule kind Reads
No more than N calls to tool T per minute PerToolRateLimit state.tool_rate
Cap session spend at $X MaxSpend state.spend
Cap tokens per day MaxTokensPerDay state.tokens_used_today
Forbid tool B after tool A ran BlockToolSequence state.path.tools
Max calls per session overall SessionRateLimit state.session
Flag anomalous tool args vs learned baseline ToolArgOutlier findings.tool_baseline

BlockToolSequence is the taint primitive: “once read_secrets appears in the trajectory, block http_post for the rest of the session.” Taint is permanent within the session because the trajectory only grows.

Why it matters

Section titled “Why it matters”

Single-call rules can’t express the attacks and failures that actually hurt agents:

  • Data-leak chains, read a secret file, then exfiltrate. Neither call is bad alone.
  • Runaway loops, the 40th identical query_db call in a session.
  • Scope creep, an agent that touches one customer record is fine; one that touches thirty in a session needs approval.

Path-aware policy is what turns an audit trail into a control plane.

Next steps

Section titled “Next steps”