Segurança e limites

O servidor MCP entrega dados de conformidade a um modelo cujo contexto também contém texto escrito por um solicitante. Tudo o que está abaixo decorre de levar isso a sério.

Níveis de tratamento de PII

As respostas padrão têm formato de veredito: um status, uma decisão, uma pontuação, quais verificações passaram. Elas não são o arquivo do solicitante.

• Descartados por completo — valores sem uso analítico em um veredito: OCR bruto (parsedData, texto extraído), dados de MRZ e código de barras, embeddings faciais e qualquer blob de imagem. list_verification_documents exclui o blob de OCR de forma estrutural, então ele não pode ser extraído em nenhuma configuração.
• Mascarados — valores em que o agente precisa saber que algo existe sem vê-lo: data e local de nascimento, números de documento, de passaporte ou de carteira, e endereços de e-mail dos destinatários nas listagens de envio.
• Opt-in — include_pii: true em get_verification_result e list_form_deliveries amplia a resposta. Exige o escopo no lado da REST e é registrado. Use-o quando a pessoa que pergunta tiver solicitado explicitamente os dados de identidade e tiver direito a eles, e não como padrão.

A redação é estrutural, não regex sobre texto corrido: o grafo de objetos é percorrido e as chaves são tratadas pelo nome, porque os payloads da REST são nossos e os nomes dos campos são estáveis.

O envelope não confiável

Nomes de solicitantes, notas em texto livre e, acima de tudo, o texto de OCR extraído de um documento enviado são controlados por um atacante. Eles chegam envolvidos em um envelope rotulado, com um nonce por chamada, de modo que um payload não consegue forjar o delimitador de fechamento e escapar para o canal de instruções. As próprias instruções do servidor dizem ao modelo, de forma clara, que o texto dentro de um envelope UNTRUSTED é dado sobre o qual deve relatar, nunca instruções a seguir.

Junto com o envelope, os payloads são analisados por padrões, e textos com cara de instrução são exibidos ao agente como um aviso explícito — tentativas de substituir instruções anteriores, de direcionar uma decisão de verificação, enquadramento imperativo voltado ao modelo, reatribuição de papel. O detector sinaliza, não higieniza: um falso positivo custa uma linha de aviso, enquanto um falso negativo custa um solicitante aprovado indevidamente.

Envio é um efeito colateral no mundo real

Três ferramentas enviam e-mails a clientes reais: send_form_to_customer, send_verification_reminder e renew_verification. As três são anotadas com readOnlyHint: false e idempotentHint: false, para que um host possa pedir confirmação antes de executá-las. Envios em lote são limitados a 50 registros por chamada.

Controle de velocidade dos lembretes

send_verification_reminder tem controle de velocidade no servidor. Um segundo lembrete dentro do intervalo mínimo — 24 horas por padrão, configurável por implantação — é recusado.

O relógio do controle de velocidade abrange tanto o evento de auditoria quanto a linha de envio, então alternar entre o painel e a API não pode zerar o controle.

Limites de requisições

O servidor MCP não introduz nova cota — herda a da API REST. Os endpoints KYC v1 que ele chama são limitados a 120 requisições por minuto, por locatário, compartilhadas entre todas as chaves e todos os clientes que a sua organização usa.

É por isso que o catálogo de ferramentas tem formato de fila, e não de registro: uma chamada a get_todays_queue responde o que quarenta chamadas a get_verification_status responderiam, e um laço sobre find_verification esgota a janela antes de terminar. Os prompts incluídos dizem isso explicitamente.

Por que apenas 26 ferramentas

O catálogo é limitado a aproximadamente esse tamanho de propósito. A precisão de seleção de ferramentas cai de forma mensurável quando um modelo escolhe entre opções muito parecidas, por isso uma nova capacidade substitui ou consolida em vez de acrescentar — um grupo que cresce se reduz a uma única ferramenta orientada à tarefa, com um argumento de modo, em vez de trazer ferramentas irmãs. list_expiring_documents é o exemplo trabalhado: documents e renewals são duas perguntas, uma ferramenta. As ferramentas de verificação de identidade ao vivo seguem a mesma regra: listagem e detalhe são uma ferramenta, e reagendar / cancelar / reconvidar são uma única manage_live_verification com uma action.

Anotações honestas

Cada ferramenta declara o que realmente faz, para que o seu host controle o acesso corretamente, em vez de confiar no texto descritivo:

Lacunas conhecidas

Ações de agentes ESTÃO no registro de auditoria de KYC, à prova de adulteração: cada chamada de ferramenta é gravada em kyc_audit_log por meio de POST /api/v1/kyc/audit, com a própria chave do chamador, no mesmo registro encadeado por hash das ações humanas. A lacuna abaixo é do tipo que você descobriria de outra forma, em produção.

E uma limitação herdada da referência de ferramentas: check_company_registry atualmente falha no registro em produção com 401, porque a chave do OpenCorporates não é repassada, então o seu diff de correspondência de diretores não foi comprovado de ponta a ponta. Veja KYB.