Scoring Pipeline

The 4-gate fast-rejection architecture that evaluates every agent action

Status: Stage 1 — shadow mode. The 4-gate pipeline is implemented and tested; enforcement is gated on shadow-mode calibration per the ML Roadmap.

Scoring Pipeline

The behavioral scoring pipeline is a fast-rejection architecture — each gate is cheaper than the next, and most actions exit early. The system optimizes for the common case: 95% of actions are normal and should produce zero output.

Gate 0: Deny List + Rate Limit (~200ns)

Before any behavioral analysis. Pure lookup — no state, no history.

• Static deny list (hash table lookup)
• Capability policy from security profile
• Per-agent rate limiting (token bucket)

Catches: Known-bad tools, capability violations, brute-force attacks. Exit rate: ~0.1% blocked.

Gate 1: Envelope Membership (~114ns, 0 allocs)

The noise killer. Three O(1) checks determine if the action is inside the agent’s established envelope:

1. Tool novelty (Bloom filter) — has this agent ever used this exact tool? Zero false negatives.
2. Frequency sanity (Count-Min Sketch) — is the tool’s usage rate within normal range?
3. Capability drift (Jensen-Shannon Divergence) — has the agent’s capability mix shifted? JSD < 0.1 = stable.

All three pass -> KNOWN_SAFE. Update the fingerprint (learn this action), return. Zero output. No score computed. No log entry.

Exit rate: ~95% of actions stop here.

Why this works

The Bloom filter has zero false negatives. If it says “not seen,” the tool is genuinely novel. Combined with a quick frequency and JSD check, this accurately classifies ~95% of actions as normal in ~114ns.

What doesn’t reach Gate 2:

• Code assistant using fs:read for the 500th time today
• Data pipeline running its hourly data:read -> net:outbound batch
• DevOps agent using the same 15 tools it always uses

Gate 2: Deviation Scoring (~433ns)

The action is outside the inner envelope. Compute all 6 independent deviation signals:

Signal	Structure	Weight	Detects
bloom:novel_domain	3-level Bloom	0.9	First-time domain usage
bloom:novel_server	3-level Bloom	0.7	First-time server usage
bloom:novel_tool	3-level Bloom	0.5	First-time tool usage
cms:frequency_spike	Count-Min Sketch	0.4	Usage rate exceeds historical norm
jsd:capability_shift	Capability dist	0.5	Agent’s capability mix changed
ewma:temporal_anomaly	EWMA + Welford	0.3	Unusual timing (z-score > 2.5)
markov:unusual_sequence	Markov chain	0.4	Rare action transition
hll:exploration_spike	HyperLogLog	0.3	Sudden tool diversity growth

Single signal fired? -> UNCERTAIN. The agent is doing something mildly new — a user asked it to try a different tool. Normal.

Exit rate: ~4% of actions classified UNCERTAIN (telemetry only).

Gate 3: Corroboration + Session Analysis (~293ns)

Multiple signals fired. Now check if they corroborate and whether the session trajectory is concerning.

5 layers of filtering before ANOMALOUS:

1. Corroboration count — did 3+ independent signals fire? If not, stay UNCERTAIN.
2. Session trajectory — has this session accumulated 4+ uncertain actions? If not, stay UNCERTAIN.
3. Structural evidence — resource sharing with dangerous capability pair? Privilege escalation? Depth > 3?
4. Risk z-score — is this action’s risk score 2+ std devs from the agent’s baseline?
5. Group envelope fallback — is this normal for agents like this one? (cold start solution)

Exit rate: <0.5% reach ANOMALOUS.

Why corroboration works

Individual signals have known error rates (Bloom: ~1.5% FPR, CMS: ~1%, EWMA: ~5%). Any single signal alone has a 1-5% false positive rate.

Three signals corroborating independently:

P(3 false positives) = 0.03 x 0.01 x 0.05 = 0.000015 = 0.0015%

The signals are independently wrong in different ways. When they all agree, the probability of all three being wrong simultaneously is vanishingly small.

Enforcement

After band classification, enforcement depends on the security profile mode:

Band	Strict Mode	Balanced Mode	Permissive Mode
KNOWN_SAFE	Allow	Allow	Allow
UNCERTAIN	Allow + log	Allow + log	Allow
ANOMALOUS	Block	Alert + escalate session	Log only

Async Tier 2

Every action — regardless of band — is published asynchronously to the Behavioral Intelligence Service (NATS-backed internal bus). The BI service runs full GNN structural analysis on its own timeline and can retroactively:

• Confirm the proxy’s decision
• Upgrade an ALLOW to ALERT (pushed back within 10-50ms)
• Downgrade a false positive (update baselines)