<0.1%
false-positive rate, 30-day rolling SLA
7 day
per-agent behavioral baseline
ms
Kill Switch isolation latency
SR 26-2
principles examiners apply, answered day one
The core invariant

The enforcement plane is deterministic. The LLM only narrates.

Every Overseer component is one of: a rule engine, a statistical scorer, or a single narrowly-scoped classifier. Generative LLMs do not block agents. They do not isolate sessions. They do not score risk. They write the post-incident narrative, which is exactly the thing humans need but never the thing that fires the action.

ComponentRoleMechanismEnforcement
Behavioral Rule Engine Per-agent z-score and n-gram math against a 7-day baseline of tool calls, prompt structure, and timing. DETERMINISTIC YES, fires Kill Switch
Kill Switch Redis pub/sub isolation of an agent session in milliseconds. Subsequent tool calls rejected at the SDK boundary. DETERMINISTIC YES, the mechanism
Fleet Correlator Kafka + CUSUM across the agent fleet. Detects coordinated attacks where no single agent crosses threshold but the cluster does. DETERMINISTIC YES, can fire Kill Switch
Drift Detector Weekly Jensen-Shannon divergence vs. prior windows. Flags when an agent's baseline is drifting in a way that warrants human review. STATISTICAL NO, alerts humans only
SOC Analyst Helper Small autoregressive LLM that writes the human-readable narrative for a decision the deterministic plane already made. GENERATIVE LLM NO, zero authority

Deterministic controls are the guarantee. The single narrowly-scoped classifier is best-effort content detection, and the table marks which is which.

How detection works

Behavioral call-shape analysis, not content scanning.

The same approach that detected device fraud at InAuth, applied to AI agents. We do not pattern-match prompt content; we model what each agent's tool-call shape looks like under normal operation, and we score deviation. There is no signature database to evade.

CLEAN AGENT · NORMAL BASELINE

Anomaly score: 0.04

Instruction originhuman session → system prompt → task
Tool-call sequenceread_account → summarize → respond
Payment tools usednone, outside baseline scope
External endpointapproved MCP, hash match
Timing distributionmatches 7-day p50/p99 envelope
INJECTED AGENT · ANOMALY DETECTED

Anomaly score: 0.91 → ISOLATED

Instruction originexternal_web · third-party document
Tool-call sequenceread_account → initiate_payment → call_external_api · 3 anomalous calls in 4s
Payment tools usedinitiate_wire($2.3M), out of profile
External endpointunregistered MCP, 1-char typosquat
Timing distributionburst: 8x p99 inter-call spacing

Detection is structural and origin-tagged. There is no prompt-content signature. The same indirect-injection attack with paraphrased text produces the same anomaly score, because the structural features and the origin tag have not changed.

Baseline maturation

Shadow → alert-only → enforcement, with SOC sign-off at every stage.

Overseer does not start blocking on day one. The baseline matures through three stages with explicit human sign-off before each transition. The path is auditable, recorded in Time Machine, and the standard pattern your model-risk-management team will recognize.

DAYS 1 to 3

Shadow mode

Overseer observes. No alerts emitted. No actions taken. Baseline begins to populate from real agent traffic.

DAYS 4 to 7

Alert-only

Anomaly scoring active; alerts flow to SOC. No automatic isolation. Human reviewers tune thresholds against your traffic.

DAY 8+

Full enforcement

Kill Switch armed after explicit SOC sign-off. Threshold auto-dampens on any FP-rate breach against the <0.1% SLA.

The attack no single-agent tool catches

Fleet correlation: the supply-chain compromise scenario.

A compromised shared library appends an extra parameter to every outbound call across 47 agents in 6 different agent types. No single agent crosses its per-agent threshold. The Fleet Correlator catches the cluster anyway, and the Kill Switch isolates all 47 simultaneously.

T+0Threat

Attacker compromises a shared Python library in the agent build

Poisoned version appends an extra parameter to every outbound call, &telemetry_id=<exfil_hash>.

T+0 → 30mPropagating

47 agents across 6 agent types begin emitting the new parameter

Each individual anomaly score lands around 0.4, below the per-agent 0.75 threshold. No single agent is blocked.

T+15mDetected

Fleet Correlator fires

Kafka consumer observes a novel parameter pattern telemetry_id=* across multiple agent types within a short correlation window. Rule fires, cross-type anomaly cluster. Deployment-event topic shows no matching rollout.

→ This is coordinated, not benign. Fleet-level anomaly confirmed.
T+15mContained

Every affected agent isolated simultaneously

SOC Analyst Helper produces a fleet-level narrative naming the 47 affected agents and the shared library, after the Kill Switch has already fired.

→ 47 agents isolated. Audit recommended on recent pip install events.
T+30mResolved

Time Machine reveals the poisoned dependency and the build event that introduced it

Affected containers redeployed with the clean manifest. Federation signal hash sent to the network, every other member bank's detection hardens against this pattern.

Why examiners can follow it

Three architectural choices, each individually defensible.

There is no safe harbor for agents. SR 26-2 leaves them out of scope. But examiners still apply model-risk and safety-and-soundness principles to the agents you run, and each of these choices is built to answer them.

Choice 01

Separation of decision and narration

The LLM that explains decisions is structurally separated from the components that make them. The "ongoing performance testing" that model-risk guidance expects applies cleanly to deterministic scorers, which actually have a defined performance metric.

Choice 02

FP-rate SLA as an operational commitment

<0.1% over a 30-day rolling window. Threshold auto-dampens on breach. This is not a marketing claim. It is the operating contract Overseer runs against and the metric your SOC reviews weekly.

Choice 03

Continuous Drift Detection

Weekly Jensen-Shannon divergence on every agent's baseline. When drift exceeds threshold, Drift Detector alerts humans. It does not silently retrain. That is exactly the ongoing-monitoring-with-human-governance principle examiners still apply.

Compliance mapping

Overseer answers the principles examiners apply.

SR 26-2 does not mandate agent controls. It leaves agents out of scope, and there is no examiner sign-off to claim. What examiners do carry over is the model-risk and safety-and-soundness thinking below. Overseer maps to each principle directly.

OCC SR 26-2
Model-risk governance principles, validation, monitoring, and ongoing performance testing, that examiners apply to AI models.
Deterministic plane + drift
FFIEC AI Guidance
Explainability for every AI decision affecting a customer or financial transaction.
SOC Analyst Helper narrative
EU AI Act · Article 9
Risk management system covering identification, evaluation, and mitigation of high-risk AI risks.
Maturation flow + drift
EU AI Act · Article 14
Human oversight measures for high-risk AI systems.
SOC sign-off · alert-only mode
Works with

Overseer is one of four platform components.

Common questions

What model-risk-management teams ask first.

Is the Behavioral Rule Engine itself a model under SR 26-2?
It is statistical infrastructure with documented inputs, fixed transformations, and an FP-rate SLA, closer to a credit-scoring monitor than to a generative model. Your MRM team can validate it the same way they validate any deterministic scorer: input documentation, baseline establishment process, performance testing against held-out anomaly data, and ongoing drift monitoring. We provide the validation pack.
How is the <0.1% FP-rate measured?
30-day rolling window of automatic isolation events with human SOC review labels. Any week the FP rate trends above 0.1%, Overseer auto-dampens isolation thresholds and surfaces the trend to the SOC dashboard. The metric and the dampening behavior are part of the operating contract, not a marketing claim.
What's the SOC Analyst Helper actually doing?
A small autoregressive LLM (under 8B parameters, fine-tuned on incident narratives) that takes the structured detection event from the deterministic plane and writes a one-paragraph human-readable explanation: which agent, which baseline deviation, which fleet pattern matched, what the SOC should look at next. It runs after the Kill Switch has fired. It cannot fire the Kill Switch. It cannot modify a detection.
How does Overseer handle drift in agent behavior over time?
Drift Detector computes Jensen-Shannon divergence weekly on every agent's baseline distribution against prior baseline windows. Significant drift triggers a human review event, not an automatic baseline replacement. Your MRM team explicitly approves each baseline reset, and the decision is logged to Time Machine. We do not silently retrain.
Can we tune thresholds per agent type?
Yes, and most banks do. A high-stakes payment-orchestration agent runs a tighter threshold than an internal knowledge-retrieval agent. Threshold profiles are scoped per agent type, version-controlled, and require change-management approval to modify. Profile-change history is part of the Time Machine record.
Does Overseer require Federation participation?
No. Overseer ships with the BladeRun Threat Research-derived baseline and rule corpus on day one. Federation participation is opt-in and adds cross-bank correlation signal, but local detection is fully functional without it. Air-gapped deployments run Overseer locally with periodic offline rule updates.
Validate Overseer in your environment

Run it in shadow mode.
See the deviations before you decide.

The first week is observation only, no enforcement. We show you what your agent baseline looks like, where the deviations are, and what Overseer would have done. Then your SOC turns on enforcement.