Methodology
- 1 Screen the primary name (and any known-by names) against the OFAC SDN list.
- 2 Below the 'possible' band with nothing else: clear, documenting no match above threshold.
- 3 For each 'possible' or 'strong' candidate, compare secondary identifiers: date of birth, nationality, address, party type, and program plausibility.
- 4 Block a genuine match (a strong name match whose identifiers are consistent, or unavailable so you cannot rule it out). Clear only a documented false positive, naming the specific identifier that contradicts the listing.
- 5 Escalate whatever can be neither confirmed nor exculpated. Insufficient data resolves to escalate, never to clear.
- 6 Apply the OFAC 50% rule (screen a disclosed owner / parent) and treat identifier-less vessel or aircraft listings as non-exculpatory.
Sandboxed tools
In-process MCP tools only. Built-in tools disabled, settingSources [], permissionMode bypassPermissions. The only ground truth is the tools.
screen_name read OFAC SDN list Ranked candidate matches with similarity score, strength band, and each entry's secondary identifiers.
get_sdn read OFAC SDN list Pulls a full SDN entry by ent_num for deeper review.
record_disposition commit Commits the disposition: clear, block, or escalate. Called exactly once.
Outcome contract
A committed disposition with the closest candidate considered (even on a clear) and exactly how the secondary identifiers compared.
▸ the validated schema (Disposition)
type Disposition = {
disposition: "clear" | "block" | "escalate"
confidence: number // 0..1, calibrated
matchId: string | null // closest candidate, even when you clear
matchedName: string | null
matchScore: number | null
secondaryIdCheck: string // exactly what matched / what differed
rationale: string // references the SDN id and program
recommendedAction: string // the concrete next step
} Grounding
Governance seams
The three trust boundaries a runtime governance layer clamps onto. Shown here ungoverned, so you can see exactly what would be inspected, redacted, or blocked.
The Cerberus system prompt (the methodology + risk posture) and the screening case (subject, identifiers, payment).
governor → Inspect or constrain what context the model is allowed to see.
Each screen_name and get_sdn call's full input and output: the candidates, scores, and SDN identifiers.
governor → See exactly which lists were queried; redact or block a tool that reaches a disallowed source.
The recorded disposition written to the case journal (a gated mock; no real payment is stopped).
governor → Hold or require a second sign-off on a block / clear before it commits.
A recorded block does not itself stop the payment. The disposition is gated: the oversight judge (reviewBlock) independently confirms a block is genuinely supported, not an unresolved false positive that should have escalated, before the control plane acts.
Evals & guardrails
- OFAC 50% rule. Screens a disclosed SDN owner even when the entity's own name is clean.
- Vessel listing, no identifiers. Treats absence of secondary identifiers as non-exculpatory; escalates rather than clearing.
- Confirmed possible match. Blocks a lower-name-score hit when DOB or passport positively confirm the listing.
- Multiple distinct candidates. Escalates rather than guessing a single attribution.
Orchestration
- ⇢Called via A2A by Bloodhound to screen material parties
- ⇢A block is gated by the oversight judge (reviewBlock)