Mid-session policy changes

You edit a rule while agents are in the middle of long-running conversations. When does the change take effect, and against what? This page is the mental model — and it explains a surprise that bites most people once: a rule you add now can match on content from hours ago.

LLM calls carry the whole transcript, every time

LLM APIs (Anthropic, OpenAI, …) are stateless. The model keeps no memory between calls, so to continue a conversation the client re-sends the entire context on every request — the system prompt, every prior turn, and every tool output — then appends the new turn.

turn 5 request  =  [ system prompt ]
                   [ turn 1 ] [ turn 2 ] [ turn 3 ] [ turn 4 ]   ← re-sent, unchanged
                   [ turn 5 ]                                     ← the only new part

A session running since yesterday ships all of yesterday and today on each call. This isn't a Kilasec behaviour — it's how the protocol works. (Providers soften the cost with prompt caching, but the bytes still cross the wire, and the collector still sees the full body.)

Two consequences follow directly:

• Once a sensitive string appears once — a secret, an SSN, a destructive command — it rides along in every subsequent request until the client compacts it out. That's why "every call is hitting the redact rule": the value is in the re-sent prefix, not just the latest turn.
• The collector re-inspects the full body each request. It does this cheaply — per-leaf scans are memoized by exact content, so the unchanged prefix is a near-free cache hit — but the policy is still applied to the whole transcript.

A policy change applies on the very next request

There's no session pinning. The engine re-reads the current policy on every POST /evaluate (no restart), and evaluates it against whatever that request contains — which is the full re-sent transcript. So a rule you save mid-session takes effect on the next call, judged against the entire history, not just new activity.

That is the surprise: add a rule that matches something already in the transcript, and the running session is affected retroactively — even though the thing it matched happened before the rule existed.

What that means, per action

Action	Behaviour on a mid-session change	Why
redact	Benign. From the next call on, matching PII/secrets in the re-sent transcript are masked before egress. The model is stateless, so it simply sees masked history going forward.	Values already sent in earlier turns are already out — a rule can't un-send them — but everything from here is protected.
dangerous-action	Enforces only on the request's own action payload (a tool/command/SQL field), not on commands mentioned in the transcript. So adding a destructive-action rule does not retroactively block a running coding session just because its history discusses rm -rf.	An LLM call executes nothing; a command in the transcript is history/discussion. See Decisions & verdicts.
deny (destination, model, agent)	The next call is blocked, as intended — the block is about this request reaching that destination, independent of history.	The condition is a property of the current request, not the transcript's past.
require_approval	Same as deny for timing — the next matching call is held for a human.	—

The dangerous-action row is the important one, and it's deliberate. Earlier, a broad "block destructive actions" rule added mid-session would immediately 403 a legitimate coding session whose transcript merely mentioned a destructive command — stranding it. Enforcement now targets the action the request actually takes, so a mid-session rule can't nuke a session for old discussion.

The principle: judge the new action, not the whole history

The through-line: policy should act on what an agent is doing now, not re-litigate its entire transcript every turn. Redaction is the one exception, and only because the whole body genuinely egresses each call, so the whole body must stay clean.

Practical notes:

• Reorder freely. Rules are an ordered list re-read per request; a change is live on the next call. Ship a new rule as log first and watch Live Traffic — it shows which calls the rule actually matches, including running sessions it would retroactively hit.
• Expect "every call" fan-out on transcript-resident matches. If a rule keys on something in the re-sent prefix (an SSN in a file the agent read, an email in a git output), it will match on every subsequent call in that session — that's the transcript, not a bug.
• To stop affecting a running session, narrow the rule (scope by agent/destination) or disable it — the change lands on that session's next request.

→ See Policy & rules for rule structure and ordering, and Decisions & verdicts for exactly what each action does to a request.