Sanctions Screening From Your AI Assistant: Compliance Over MCP
DeRisk Hub's MCP server gives AI assistants 22 sanctions screening tools, with confirm gates that stop an agent clearing a match on its own.
An MCP server lets an AI assistant call your sanctions screening platform directly, as tools rather than as a chat window bolted onto a dashboard. DeRisk Hub runs one at https://api.deriskhub.com/mcp. It exposes 22 tools covering screening, entity lookup, case triage, monitoring, and match decisions, and works with Claude, ChatGPT, Cursor, Gemini, and Slack.
The interesting question is not whether an assistant can screen a name. It obviously can. The question is what stops it from clearing a sanctions match on its own. That is the part this post is actually about.
This describes the server as of August 2026.
What is MCP, and why does it matter for a compliance team?
MCP (Model Context Protocol) is an open standard for connecting AI assistants to external systems. It defines how a host (Claude, ChatGPT, Cursor) discovers and calls tools exposed by a server, in this case DeRisk Hub. It uses JSON-RPC 2.0 messages, and the current protocol revision is dated 2026-07-28 [Model Context Protocol Specification].
The practical consequence for a compliance team is narrow but real. Getting an assistant to check whether a customer was sanctioned used to mean building a custom integration against your vendor's API. With MCP it is a settings-screen task, and the assistant discovers what it is allowed to do by asking the server.
That convenience is also the risk. An assistant that can screen an entity is useful. An assistant that can decide a sanctions match is a control failure waiting for an examiner to find it. The specification is explicit that it does not solve this for you: "While MCP itself cannot enforce these security principles at the protocol level, implementors SHOULD" build consent and authorization flows themselves [Model Context Protocol Specification]. Governance is the server author's job, not the protocol's.
What can an AI assistant actually do with a sanctions screening MCP server?
It can screen entities, read screening history, triage open cases, toggle ongoing monitoring, and record match decisions under an explicit confirmation step. Every tool maps to a real REST API endpoint, so the assistant can do what your own integration could do, and nothing beyond it.
| Capability | Tools | A realistic ask |
|---|---|---|
| Screen and re-screen | screen_entity, start_batch_screening, get_job, list_screenings, get_screening | "Screen Acme Trading Ltd, an organization registered in Cyprus, and tell me whether it opens a case." |
| Entity lookup and history | create_entity, update_entity, get_entity, list_entities, get_entity_screenings | "Which entities we onboarded last month are still pending review?" |
| Case triage | list_cases, get_case, get_case_matches, list_users, add_case_note | "Summarise the open cases assigned to nobody, highest risk first." |
| Match decisions (confirm-gated) | record_match_decision, reverse_match_decision, close_case | "This match is a different person, born 1987, not 1962. Record it as a false positive." |
| Monitoring | set_monitoring, get_blocking_cases | "Turn on ongoing monitoring for every entity we onboarded this quarter." |
| Account context | get_usage, get_lists | "How many screenings have we used this billing period?" |
All tool names carry a deriskhub_ prefix. Three built-in prompts (onboard_entity, triage_case, explain_match) steer the assistant through the common sequences, so a user does not have to know which tool comes next. The main flow runs screen, then check blocking cases, then read the matches, then decide.
One detail matters more than it sounds. Screening an entity and finding zero matches does not mean the entity is safe to onboard. A prior case may still be open against it. The onboard_entity prompt forces the blocking-cases check for exactly this reason.
What stops an AI assistant from clearing a sanctions match on its own?
Seven controls, each enforced server-side rather than requested politely in a tool description. A model that ignores an instruction still cannot get past a handler that refuses to run.
| Control | What it prevents | Where it is enforced |
|---|---|---|
| Confirm gate on 4 tools | Recording or reversing a match decision, closing a case, or submitting a batch, without a human agreeing to that specific action | In the tool handler, before any API call is made |
Scope-filtered tools/list | The assistant seeing, or attempting, tools its credential does not permit | At connect time, from the key's scopes |
| Role ceiling on consent | Someone granting an assistant more authority than their own role holds | Server-side when the connection is approved |
| Self-proxying architecture | MCP becoming a side door around REST guardrails | Every tool call is one ordinary REST call |
| Actor pinning (OAuth) | The model inventing or choosing who cleared a match | The field is absent from the tool schema entirely |
| Decision rate limit | A runaway loop deciding hundreds of matches | 30 per minute, shared across all of a tenant's keys |
| Exclusion by omission | Entity deletion and webhook reconfiguration by chat | Those tools are never registered |
Three of these deserve unpacking.
The confirm gate is a refusal, not a request
Four tools refuse to execute unless called with confirm: true (or review_confirmed: true for batch screening). Called without it, the tool returns an error without making any API call, and instructs the model to summarise the proposed action in plain language, ask the user to confirm, and only then call again.
The property that matters is that this lives in the handler, not merely in documentation. A model that tries to skip ahead by passing confirm: true on the first call still only succeeds on the retry. The two-step shape (refuse, explain, confirm, succeed) is visible in the conversation transcript, which is what makes it reviewable after the fact.
Every tool call is an ordinary API call
Tools do not query the database. Each one makes a single HTTP call back into the same public REST API, using the caller's own credential. One tool call equals one REST call, always.
That sounds like an implementation detail. It is the whole governance argument. Because the call takes the normal REST path, every control that already applies there applies identically here: scope checks, per-tenant rate limits, plan limits, usage metering, and the audit trail. There is no separate MCP permission model to keep in sync, and so no gap between the two to be discovered later.
The audit trail records a person, not a robot
Every write that needs attribution records an actor. On OAuth connections, the recommended setup, the actor is derived server-side from the person who approved the connector and pinned onto every write. The model is never asked for one and cannot override it, because the field does not appear in the tool's schema at all.
A shared static API key does not identify an individual, so there the tool requires an explicit actor instead. Either way, decisions land in the case audit log with the connector's key ID alongside that actor, so "which assistant, acting for whom, cleared this match" is answerable two years later. Audit obligations do not soften because the request came from a chat window. OFAC's compliance framework treats documented escalation and internal controls as core components of a sanctions compliance programme, and testing that reviewer determinations followed procedure as another [OFAC Framework 2019].
Sanctions list data is treated as adversarial
Names, aliases, and remarks on sanctions lists are free text written by external providers. Tool results place that data inside structured JSON fields, never concatenated into instruction-shaped prose a host model might read as a command. That reduces prompt-injection risk without eliminating it, which is why the confirm gate remains the real defence.
How do you connect an assistant to it?
Through your host's connector settings, using either OAuth or a static API key. OAuth is the better default: it needs no key handling, and it attributes every write to the person who approved it.
| Host | Authentication | Where you set it up |
|---|---|---|
| Claude.ai, Desktop, mobile | OAuth (recommended), or static headers on some plans | Settings, then Connectors, then Add custom connector |
| Claude Code | Header or OAuth | claude mcp add --transport http deriskhub https://api.deriskhub.com/mcp |
| Cursor | Header | ~/.cursor/mcp.json, or a project-scoped .cursor/mcp.json |
| ChatGPT | OAuth only | Connector settings |
| Slack, Gemini Enterprise | OAuth, workspace-wide | An administrator configures it once for everyone |
Scopes are where you decide what the assistant can do, and they are worth a deliberate minute. A read-only set answers questions about entities, cases, and usage. Adding entities:write and screening:write lets it screen new customers. Adding cases:write lets it record decisions that clear or confirm sanctions and PEP hits, which is the one to grant on purpose rather than by accident.
Because tools/list is filtered by scope, the set of tools visible to the model is itself a control. A key without cases:write does not see the decision tools at all, so there is no scope error to hit mid-conversation. Revoking a key or a connector grant takes effect within about 60 seconds.
What should stay human-decided?
Match adjudication, case closure, and anything that leaves your organisation. An assistant is good at assembling context and bad at carrying accountability, and only one of those two is what a decision is.
Keep these human:
- Match adjudication. Deciding a hit is a different person is a judgement about identity evidence, and it is the decision an examiner will reconstruct. Let the assistant lay out the comparison. Let a person conclude it.
- Case closure. Same reasoning, wider blast radius.
- Suspicious activity reporting. Regulatory filings are not a tool call.
- Threshold changes. Tuning thresholds to reduce workload rather than to improve precision is a finding waiting to happen, whoever proposes it.
Where an assistant earns its place is the work around those decisions: summarising why a match scored the way it did, pulling an entity's screening history, drafting justification text a reviewer then edits and owns, and finding the six cases nobody has touched in two weeks.
One honest note on the competitive picture. DeRisk Hub is not the only compliance vendor with an MCP server, and any post claiming otherwise is out of date. Encompass exposes KYC and screening capabilities over MCP through its EC360 platform [Encompass EC360 MCP], and open-source sanctions MCP servers exist too. What differs is not the protocol. It is whether the confirm gates, scope ceilings, and audit attribution are enforced in the server, or left to the model's good judgement.
Frequently asked questions
Can an AI assistant clear a sanctions match by itself? Not on DeRisk Hub. The three decision tools and the batch screening tool refuse to execute without an explicit confirmation flag, and the refusal happens in the tool handler before any API call. The assistant must summarise the action, get a human to confirm it, and call again. Whether other vendors' MCP servers enforce this in the server or only describe it in the tool documentation is worth asking directly.
Does using MCP change what gets written to the audit trail? No. Every tool call is a normal REST API call underneath, so it produces the same audit records as any other API activity. MCP-originated traffic is tagged with an internal source header so you can tell it apart in usage reporting, but it is not audited differently or billed differently.
Do MCP tool calls cost extra? They consume the same screening credits as REST API calls. There is no separate MCP meter and no separate SKU. Your AI host bills you for its own tokens separately.
What if the assistant is fed a malicious sanctions list entry? List data is returned inside structured JSON fields rather than as prose, and tool descriptions instruct hosts to treat it as data. That lowers the risk but does not remove it. The confirm gate is the control that matters, because a manipulated agent still cannot record a decision without a human confirming it.
Can I give an assistant read-only access? Yes, and it is the sensible starting point. Grant only the read scopes, and the write and decision tools never appear in the tool list for that connection.
Citations
- Model Context Protocol, Specification (revision 2026-07-28), including the Security and Trust & Safety principles: https://modelcontextprotocol.io/specification/2026-07-28
- OFAC, A Framework for OFAC Compliance Commitments, published 2 May 2019: https://ofac.treasury.gov/recent-actions/20190502_33
- Encompass Corporation, EC360 MCP, accessed 19 August 2026: https://www.encompasscorporation.com/ec360-mcp/
Screening your assistant can reach, under controls it cannot talk its way past
The reason to put screening behind an MCP server is not that chatting with a compliance platform is pleasant. It is that the alternative, an analyst copying names between a dashboard and a spreadsheet, is slower and no more auditable.
DeRisk Hub's MCP server is live, exposes 22 scope-filtered tools, and routes every one of them through the same REST API, rate limits, and audit trail as any other integration. Match decisions stay behind a confirm gate the model cannot skip. See the developer documentation, the platform overview, or start with what sanctions screening actually involves and how fuzzy name matching works. Start your free trial, or go to DeRiskHub.com.