Seguridad y límites
Cómo el servidor MCP de Certivant clasifica los datos personales, envuelve el texto controlado por el solicitante en un sobre no confiable, limita los recordatorios a 24 horas y comparte su límite de 120 solicitudes por minuto por inquilino; además, el hueco de auditoría que no debe ocultarse.
El servidor MCP entrega datos de cumplimiento a un modelo cuyo contexto también contiene texto que escribió un solicitante. Todo lo siguiente se deriva de tomar esto en serio.
Clasificación de datos personales
Las respuestas por defecto son de tipo veredicto: un estado, una decisión, una puntuación, qué comprobaciones se superaron. No son el expediente del solicitante.
- Eliminados por completo: valores sin utilidad analítica para un veredicto: el OCR sin procesar (
parsedData, texto extraído), los datos de MRZ y de código de barras, los embeddings faciales y cualquier blob de imagen.list_verification_documentsexcluye estructuralmente el blob de OCR, así que no puede obtenerse con ningún ajuste. - Enmascarados: valores en los que el agente necesita saber que existen sin verlos: fecha y lugar de nacimiento, números de documento, pasaporte o permiso de conducir, y direcciones de correo de los destinatarios en los listados de entregas.
- Opcionales:
include_pii: trueenget_verification_resultylist_form_deliveriesamplía la respuesta. Requiere el ámbito en el lado de la API REST y queda registrado. Úselo cuando quien pregunta haya pedido explícitamente datos de identidad y tenga derecho a ellos, nunca como valor por defecto.
La redacción es estructural, no una expresión regular sobre el texto: se recorre el grafo de objetos y las claves se tratan por nombre, porque los payloads de la API REST son propios y sus nombres de campo son estables.
El sobre no confiable
Los nombres de los solicitantes, las notas de texto libre y, sobre todo, el texto OCR extraído de un documento subido
están controlados por un atacante. Llegan envueltos en un sobre etiquetado con un nonce por llamada, de modo que una carga
útil no puede falsificar el delimitador de cierre y escapar al canal de instrucciones. Las instrucciones del propio servidor
indican al modelo, de forma explícita, que el texto dentro de un sobre UNTRUSTED son datos sobre los que informar,
nunca instrucciones que seguir.
Junto al sobre, las cargas útiles se analizan con patrones y el texto con apariencia de instrucción se muestra al agente como una advertencia explícita: intentos de anular instrucciones previas, de dirigir una decisión de verificación, formulaciones imperativas dirigidas al modelo o reasignación de roles. El detector marca, no sanea: un falso positivo cuesta una línea de advertencia, un falso negativo cuesta aprobar por error a un solicitante.
Si al revisar un caso ve una advertencia de que un documento contiene texto con apariencia de instrucción, eso es en sí mismo un hallazgo que merece lectura. Los pasaportes legítimos no piden que se les apruebe.
Enviar es un efecto real en el mundo
Tres herramientas envían correos a clientes reales: send_form_to_customer, send_verification_reminder y renew_verification.
Las tres están anotadas con readOnlyHint: false e idempotentHint: false, para que un host pueda pedir confirmación antes de
ejecutarlas. Los envíos por lotes están limitados a 50 filas por llamada.
El límite de recordatorios
send_verification_reminder tiene un límite aplicado en el servidor. Un segundo recordatorio dentro del intervalo mínimo
—24 horas por defecto, configurable por despliegue— se rechaza.
Un rechazo llega como HTTP 429, y significa que no se envió nada. Es una decisión de política, no una contrapresión:
no reintente, no espere y vuelva a intentarlo, y no recurra a send_form_to_customer (lo que crearía un segundo solicitante
y una segunda solicitud para la misma persona). La respuesta indica cuándo se permitirá el siguiente recordatorio. Espere a ese momento.
El reloj del límite abarca tanto el evento de auditoría como la fila de entrega, de modo que alternar entre el panel y la API no puede reiniciarlo.
Límites de solicitudes
El servidor MCP no introduce ninguna cuota nueva: hereda la de la API REST. Los endpoints KYC v1 que llama están limitados a 120 solicitudes por minuto, por inquilino, compartidas entre todas las claves y todos los clientes que ejecute su organización.
Por eso el catálogo de herramientas tiene forma de cola y no de registro: una sola llamada a get_todays_queue responde lo que
harían cuarenta llamadas a get_verification_status, y un bucle sobre find_verification agotará la ventana antes de terminar.
Los prompts incluidos lo indican explícitamente.
Por qué solo 26 herramientas
El catálogo está limitado a aproximadamente este tamaño a propósito. La precisión al seleccionar herramientas se degrada de forma
medible cuando un modelo elige entre demasiadas opciones similares, así que una nueva capacidad reemplaza o consolida en lugar
de añadir: un grupo que crece se agrupa en una única herramienta orientada a la tarea con un argumento de modo, en lugar de añadir
hermanas. list_expiring_documents es el ejemplo trabajado: documents y renewals son dos preguntas, una herramienta. Las herramientas
de Live ID siguen la misma regla: listar y detallar son una herramienta, y reprogramar / cancelar / reinvitar son una sola herramienta
manage_live_verification con un action.
Anotaciones honestas
Cada herramienta declara lo que hace realmente, para que su host controle el acceso correctamente en lugar de confiar en la prosa:
| Anotación | Se aplica a |
|---|---|
readOnlyHint: true | Las herramientas de cola, búsqueda, estancados, cambios, estado, resultado, explicación, registro de empresa, métricas, caducidad, metadatos de documentos, enlace de documentos y list_live_verifications. |
readOnlyHint: false | Las tres herramientas de envío de correo, además de start_verification, start_verifications_batch, submit_business_details, check_company_registry (hace una llamada externa facturable y puede marcar un registro como verificado), resubmit_verification, schedule_live_verification y manage_live_verification (ambas pueden enviar correo o SMS al solicitante). |
destructiveHint: true | resubmit_verification (elimina las comprobaciones y la puntuación de riesgo de la solicitud, así que el rechazo ya no podrá explicarse después) y manage_live_verification (su acción cancel es irreversible). |
Limitaciones conocidas
Las acciones de los agentes SÍ están en el registro de auditoría de KYC a prueba de manipulaciones: cada llamada a una herramienta
se escribe en kyc_audit_log a través de POST /api/v1/kyc/audit con la propia clave del llamador, en el mismo registro encadenado
por hash que las acciones humanas. El hueco que se describe a continuación es del tipo que, de otro modo, descubriría en producción.
El razonamiento estructurado de las decisiones falta en la mayoría de las verificaciones antiguas.
explain_verification_decision devuelve reasoningAvailable: false cuando no se registró ningún verdictMeta, lo que cubre
la mayor parte de las solicitudes históricas. La herramienta es honesta al respecto; su flujo de trabajo también debe serlo.
Y una limitación heredada de la referencia de herramientas: check_company_registry falla actualmente contra el registro en vivo
con un 401, porque la clave de OpenCorporates no se transmite, así que su comparación de directores no está probada de extremo
a extremo. Consulte KYB.
Recursos y prompts
Los cuatro recursos MCP que el modelo puede consultar como contexto sin coste, y los cinco flujos de trabajo empaquetados como prompts: triaje matinal, enviar y seguir, reclamar a los estancados, informe mensual de cumplimiento e investigar un caso.
Referencia de la API (OpenAPI)
La API REST completa de Certivant como documento OpenAPI 3.1: una especificación JSON pública que puede importar en Postman o usar en un generador de código, además de una referencia interactiva con cada endpoint, esquema, ámbito y evento de webhook.