Group Envelopes

How new agents inherit behavioral baselines from their group to eliminate cold-start noise

Status: shipped — Stage 1 in shadow mode. Group inheritance is wired in; effective once Stage 1 enforcement turns on.

Group Envelopes

New agents have empty fingerprints. Every action looks novel, every tool is a first-time event, and the capability distribution is undefined. Without a baseline, the behavioral engine would flag everything — generating noise for days until the agent builds its own history.

Group envelopes solve this: new agents inherit a group baseline from day one.

How It Works

Group Assignment

In v1, agents are grouped by agent type — the platform they run on (e.g., claude-code, cursor, aider). This is automatically detected by the proxy’s agent detection system.

All Claude Code instances share one group envelope. All Cursor instances share another. This works because agents of the same type tend to use similar tools and capability patterns.

Future versions will support custom groups via security profiles, allowing finer-grained grouping (e.g., “healthcare-agents”, “devops-agents”).

Fingerprint Merging

A group envelope is computed by merging the fingerprints of all agents in the group. Each sub-structure has a merge strategy:

Component	Merge Strategy
Capability distribution	Weighted average by TotalActions
Count-Min Sketch	Element-wise addition (capped at uint16 max)
Bloom filters	Bitwise union (tools seen by ANY agent)
HyperLogLog	Cardinality union
Welford stats	Parallel combination algorithm
Markov chain	Transition count merge with eviction
Hourly activity	Weighted average by TotalActions

Performance: Merging 10 fingerprints takes ~6.7 microseconds.

Caching

Group envelopes are cached with a configurable TTL (default 5 minutes). The cache avoids recomputing the merge on every action:

• Cache hit: 20ns (zero allocations)
• Cache miss / stale: Recompute by iterating the BehaviorCache, merge matching fingerprints, cache result
• Thread-safe via sync.RWMutex

Gate 3 Integration

The group envelope check is the last layer in Gate 3’s 5-layer evaluation, applied only when:

1. The action has already been classified as ANOMALOUS by corroboration
2. The agent has fewer than 100 actions (still in cold-start phase)
3. A group envelope is available

If the action passes the group check:

• The tool is known to the group (Bloom filter)
• The capability JSD against the group distribution is below 0.2

Then the classification is downgraded from ANOMALOUS to UNCERTAIN with a group:envelope_match signal. This prevents false positives during the learning period.

Once an agent accumulates 100+ actions, its own fingerprint is mature enough and the group envelope is no longer consulted.

Cold Start Timeline

Actions	Source of Truth	Behavior
0-10	Group envelope only	Very permissive — baseline not established, MinActions guard in Gates 1-2
10-100	Agent fingerprint + group fallback	Gates fire signals, but group envelope catches false positives
100+	Agent fingerprint only	Group envelope skipped — agent has its own baseline

Limitations (v1)

• In-memory only — group envelopes are computed per proxy instance. Multi-proxy consistency requires Redis (P4).
• Agent type grouping only — no custom groups yet. Security profile-based groups planned for P4.
• No group eviction — stale groups accumulate. Addressed when session TTL management is implemented.