Envelope Lifecycle

How a behavioral envelope is born, learns, matures, evolves, and syncs across proxy instances

Status: shipped — Stage 1 in shadow mode. Envelope lifecycle runs in production; multi-proxy sync is built.

Envelope Lifecycle

Every agent builds a behavioral envelope — a fixed-size probabilistic fingerprint of what it normally does. This page traces the complete lifecycle from first action to mature baseline to multi-proxy sync.

Phase 1: Cold Start (Actions 0-10)

An agent connects for the first time. The proxy has never seen it.

1. BehaviorCache.GetOrCreate() — local cache miss
2. HydrateFunc — Redis miss (new agent, nothing stored)
3. NewFingerprint() — all zeros (CapDist, FlowMatrix, Bloom, CMS, HLL, Welford)

Gate behavior: Gates 1 and 2 have a MinActions guard (default 10). Below this threshold, the fingerprint is not trusted — gates pass through without scoring. The agent operates freely.

Group envelope fallback: If other agents of the same type (e.g., “claude-code”) have established baselines, the group envelope provides a borrowed baseline. Actions normal for the group won’t trigger false positives.

Phase 2: Learning (Actions 10-100)

Every action updates the fingerprint in O(1), ~212ns:

Step	What Updates	Structure
1	Total action count	Counter
2	Capability distribution (running average)	[12]float32
3	Tool frequency	Count-Min Sketch
4	Tool/server/domain novelty	3 Bloom filters
5	Hour-of-day activity	[24]float32 EWMA
6	Inter-action interval	EWMA + Welford variance
7	Risk score baseline	Welford (mean, m2)
8	Action sequence model	Markov chain (32 slots)
9	Tool/server/IP cardinality	3 HyperLogLog sketches
10a	Capability flow transitions	[12][12]float32 EWMA
10b	Resource boundary crossings	CMS64
10c	Depth-capability profile	[12][8]float32 EWMA
10d	Per-transition timing	[12][12]float32 EWMA + variance

Gate behavior: Gates are active. Gate 1 starts short-circuiting for known tools (Bloom says “seen” + CMS frequency normal + JSD low → KNOWN_SAFE in 114ns). Novel tools pass through to Gate 2.

Gate 3’s group envelope fallback catches false positives: agent does something novel for itself but normal for its group → downgraded from ANOMALOUS to UNCERTAIN.

Phase 3: Mature Envelope (Actions 100+)

The fingerprint is trusted. The group envelope fallback is disabled. The agent operates on its own baseline.

The 95% Fast Path (~526ns total)

Action: mcp:github:list_repos.list
  → Gate 0: not on deny list                    ~200ns
  → Gate 1: Bloom YES + CMS normal + JSD 0.02   ~114ns
  → KNOWN_SAFE. Zero output.
  → Update fingerprint                           ~212ns

The 5% Novel Action Path (~1.2μs total)

Action: mcp:slack:send_message.send (novel server!)
  → Gate 0: PASS
  → Gate 1: Bloom says "slack" never seen → PASS THROUGH
  → Gate 2: bloom:novel_server + jsd:capability_shift + markov:unusual_sequence
  → Gate 3: 3 signals but band2Count < 4 → UNCERTAIN
  → Log telemetry. No alert. Fingerprint learns "slack".
  → Next time → Gate 1: KNOWN_SAFE

The Attack Path (<0.5%)

Session: agent reads credentials, then exfiltrates

Actions 1-190: normal reads → Gate 1 KNOWN_SAFE
Action 191: vault:read_secret → Gate 2: novel_tool → UNCERTAIN (band2=1)
Actions 192-195: mixed → band2 accumulates to 4
Action 196: slack:send_message → Gate 2: 3 signals
  → Gate 3:
    ├── 3 signals ≥ 3 (corroboration) ✓
    ├── band2Count 4 ≥ 4 (trajectory) ✓
    ├── FlowMatrix JSD 0.47 > 0.3 (structural) ✓
    └── ANOMALOUS → enforce per security profile

Phase 4: Ongoing Evolution

The envelope is alive — it evolves as the agent’s behavior changes.

EWMA Decay

Old patterns naturally fade. The FlowMatrix EWMA (α=0.05) means a transition that stops occurring decays to near-zero over ~140 actions. The CapDist shifts as new capabilities are used.

Week 1: CapDist ≈ [0.80, 0.20, 0, ..., 0, ...]     (80% reads, 20% writes)
Week 2: CapDist ≈ [0.75, 0.22, 0, ..., 0.03, ...]   (starting to send)
Week 4: CapDist ≈ [0.55, 0.28, 0, ..., 0.17, ...]   (new behavior established)

What was once anomalous (sending) becomes part of the baseline. This prevents false positives from legitimate behavioral evolution.

Drift Detection

The DriftDetector runs hourly, comparing a frozen 7-day snapshot against the live envelope across three JSD dimensions:

Dimension	Threshold	Catches
CapDist JSD	0.15	Gradual capability shift
FlowMatrix JSD	0.20	Structural flow change
DepthProfile JSD	0.20	Nesting depth change

If drift exceeds any threshold, a detection is emitted even though no single action was ever anomalous — the “boiling frog” detector.

After detection, the snapshot is refreshed (alert on change, not state). The next comparison starts from the new baseline.

Phase 5: Multi-Proxy Sync

The fingerprint doesn’t live on just one proxy.

Delta Flush (every 30s)

Dirty fingerprints are serialized (MarshalBinary, 2.6μs) and merged into Redis (Merge, 9.6μs). Redis holds the authoritative merged fingerprint — the union of all proxy instances’ observations.

Cache Miss Hydration (~2-5ms)

When a proxy doesn’t have an agent locally (LRU evicted or new instance), GetOrCreate calls the HydrateFunc which fetches from Redis. The agent’s full behavioral history is restored.

Cold Start Bootstrap

On proxy startup, BootstrapFromRedis bulk-loads fingerprints for recently active agents in batches of 100. 10K agents bootstrap in ~1ms CPU + ~200ms Redis.

Session Export (every 60s or session end)

The SessionBuffer’s flow matrices + action chain are serialized to JSON (~152μs, ~29KB) and published to NATS (quint.sessions.{org}). The Behavioral Intelligence Service materializes these as subgraphs in Memgraph.

Complete Architecture