MCP: how to expose a regulatory API to AI agents in a controlled way

AI agents no longer just draft text: more and more often they query systems, fill out forms and prepare client files. In regulatory compliance this raises a concrete question: if an agent is going to review a client or a supplier, how do we give it access to a reliable source of sanctions lists without handing it more than it needs? In this article we explain what the Model Context Protocol (MCP) is, why a compliance check fits well as a tool for an agent, and which controls we consider essential.

What MCP is

MCP is an open protocol that standardizes how an AI application connects to external systems. Instead of every assistant, code editor or agent platform building its own integration for every service, the service publishes an MCP server and any compatible client can use it.

An MCP server mainly exposes three kinds of elements:

• Tools: actions the model can invoke, each with a name, a description and a schema for its input parameters.
• Resources: context information the application can read.
• Prompts: predefined instruction templates.

For a regulatory API, tools are what matter. The model reads the description, decides when it makes sense to use it, builds the parameters and receives a structured response. The call itself is executed by the host application, which can also ask the user for confirmation before doing so.

Why a compliance check is a good tool

Not every API should be exposed to an agent. A sanctions-list search has characteristics that make it particularly suitable:

• It is read-only. Looking up a name or an RFC (Mexican tax ID) in OFAC, the UN consolidated list or the SAT lists (69, 69-B and 69-B Bis) changes nothing. If the agent gets the parameters wrong, the cost is one extra query, not an altered record.
• Its inputs are narrow. A name or an RFC and, optionally, the lists to check. It is easy to describe in a schema and to validate what comes in.
• It returns structured data. Matches with their source list, a similarity score and the data of the listed entity. The model does not have to interpret web pages or free text.
• It covers a step that is easy to skip. In client onboarding, the list check is the step that gets forgotten when it depends on opening several portals.

What the agent must not do is decide. A phonetic match against a list is not a risk determination: it may be a namesake, a record that has since changed or a false positive. The agent can find, sort and document; the assessment and the decision remain with a person.

The controls that are not negotiable

Connecting an agent to a regulatory source changes who runs the query, but it should not change the rules. These are the controls we apply in our API and carry over, without exception, to the MCP channel:

1. Per-account key authentication. The agent uses the same API key as any other integration: issued to a specific account and revocable from the panel. A revoked key gets the same response as one that never existed, so the service cannot be used to find out which keys are valid.
2. Separation of credentials. The API key only allows queries; it gives no access to billing or account administration. Conversely, a panel session cannot be used to run queries.
3. Usage limits. Per-route rate limits protect the service and the client alike. An agent stuck in a badly designed loop can generate hundreds of calls in minutes; the limit turns that mistake into a rejected response rather than runaway consumption.
4. A log of every query. Each search is recorded in the account history: which parameters were sent, what was returned, when and with which key. If it later becomes necessary to show an auditor that a client was screened against lists, the evidence does not depend on what the agent kept in its conversation.
5. Minimal surface. Only public query operations are exposed to the agent. Internal, administrative or data-modifying functions stay out of its toolset.

An agent with access to a regulatory source should have exactly the same permissions, limits and logs that a traditional integration would have. Not one more.

The person still decides

The design we propose clearly separates three moments:

• The agent queries. It runs the search, gathers the matches and presents them with their source list.
• The person assesses. They check whether the match really corresponds to the client, based on other data in the file: full RFC, date of birth, address, nationality.
• The system records. Both the query and the decision are documented, together with who made it.

This is not a technical limitation but a consequence of the regulatory framework itself: the obligation to identify the client and assess their risk falls on whoever is subject to the regulation, not on a tool. A well-designed agent speeds up the work and reduces omissions, but it does not replace that judgment.

How we are building it at AmigoApi

At AmigoApi we are building an MCP server on top of the same REST API our clients already use. The principle is simple: same key, same data, same history, a different way of consuming it. The lists queried through MCP are the same ones queried through REST, they are synchronized against the official sources, and every query lands in the account log. Internal operations are not part of the toolset.

Until the MCP server becomes available, any agent able to make an HTTP call can use the REST API directly, with the same controls described above.

If you are designing a compliance workflow with AI agents and want to review how to scope their permissions, Write to us.