El mecanismo completo detrás del Tablón: qué vigilamos, cómo lo detectamos, y qué no hacemos nunca. Sin cajas negras — esta página explica el mismo código que corre en producción, no una versión simplificada para marketing. Si buscas la referencia de la API para integrar Centinela en tu propio sistema, esa vive en Documentación de la API.
Un servidor MCP le ofrece a un agente de IA una lista de herramientas — cada una con un nombre, una descripción en texto libre, y un esquema de qué parámetros acepta. El agente lee esa descripción y decide, él solo, cuándo usar la herramienta y con qué datos. Ahí está el problema: el agente confía en ese texto de la misma forma que confiaría en la instrucción de un humano, y ese texto lo escribe quien sea que opere el servidor — no hay ninguna revisión entre medias.
Eso abre vectores que no existían con una API tradicional: una descripción puede llevar una instrucción escondida para manipular al agente, un esquema puede pedir mucho más acceso del que la descripción deja ver, un servidor puede cambiar el comportamiento de una herramienta después de que ya te fías de ella (un rug pull), o hacerse pasar por una herramienta de confianza con un nombre casi idéntico. Ninguno de estos ataques necesita una vulnerabilidad de software clásica — les basta con el texto que el propio servidor ya publica.
Centinela nunca invoca una herramienta de tu servidor, nunca ejecuta código, y nunca toca tus datos. Todo lo que ves en el Tablón sale de leer tools/list (la lista de herramientas que el propio servidor ya publica) y de cruzarlo contra metadatos públicos — el mismo tipo de información a la que cualquiera tiene acceso, solo que nosotros lo miramos de forma sistemática y constante.
Las únicas peticiones de red que hacemos a un servidor son las mínimas para pedirle su lista de herramientas y comprobar cómo responde sin credenciales — nada más se envía ni se recibe.
22 categorías, agrupadas por de dónde sale la señal. Cada una tiene una severidad por defecto (Alta/Media/Baja) — la que ves en un hallazgo concreto puede variar según el caso, mira cómo leer el Tablón para lo que significa cada franja.
Caracteres invisibles o de control (ancho cero, overrides de dirección, el bloque Unicode "tag") escondidos dentro de la descripción — una forma conocida de esconder texto que un humano no ve pero el agente sí procesa.
Frases literales del tipo "ignora las instrucciones anteriores" en la descripción — el mismo ataque que el de arriba, pero en texto visible en vez de escondido.
El esquema pide algo sensible (archivos, ejecutar comandos, credenciales) que la descripción nunca menciona. Con IA activada, un modelo entiende matices (un token de paginación no es una credencial); sin ella, cae a un heurístico de palabras clave.
Una dirección IP literal o un acortador de URL (bit.ly y similares) en la descripción — un servicio legítimo se referencia por su dominio, no escondido tras un acortador ni por su IP.
Un bloque largo de texto con pinta de base64 dentro de la descripción, sin motivo para estar ahí en un texto pensado para que lo lea un humano o un agente.
El nombre se parece — con homóglifos (una letra cirílica que se ve igual que la latina) o casi-typo — al de una herramienta extremadamente común (leer un archivo, ejecutar un comando). Conocido como tool shadowing: la forma de que el agente confunda la herramienta maliciosa con la de confianza.
Decenas de saltos de línea o espacios seguidos antes del contenido real — empuja el texto fuera de lo que muestra la interfaz de aprobación de un cliente, que sigue leyendo la descripción completa aunque solo enseñe las primeras líneas.
El esquema declara additionalProperties: true a propósito sin definir ninguna propiedad propia — acepta JSON arbitrario del agente, una forma de colar campos que nunca se anunciaron.
Un parámetro de seguridad booleano (confirmar, forzar, omitir verificación) cuyo valor por defecto deja la protección desactivada sin que el agente tenga que pedirlo explícitamente.
El paquete (npm, PyPI o NuGet) del que se distribuye el servidor tiene una entrada confirmada en OSV.dev — vulnerabilidad real o paquete ya identificado como malicioso, no una sospecha.
Menos de 7 días desde su primera publicación en el registro — nadie ha tenido tiempo de auditarlo todavía, un riesgo real de cadena de suministro.
El repositorio de GitHub tiene menos de 30 días y menos de 20 estrellas — no implica nada malicioso por sí solo, pero merece una mirada antes de confiar del todo.
El dominio del servidor está a una o dos letras de distancia de un dominio real y famoso — typosquatting clásico, aplicado al propio MCP en vez de a un sitio web.
El dominio real que sirve el MCP (no el repositorio de su código, que puede ser distinto) se registró hace menos de 30 días, según RDAP — el sucesor estándar de WHOIS.
El dominio aparece en URLhaus como infraestructura ya confirmada de phishing, malware o C2 (mando y control) — cruce directo contra una lista pública, no una heurística.
El servidor deja listar y usar sus herramientas sin ninguna credencial. Informativo, no un peligro por sí solo — habitual y legítimo en muchas APIs públicas de consulta.
Exige algo antes de dejar entrar, pero sin seguir el estándar OAuth 2.1 que define MCP (sin la cabecera WWW-Authenticate con resource_metadata) — puede ser una clave estática u otro mecanismo a medida.
El servidor de autorización sí sigue el estándar, pero no anuncia soporte de PKCE con S256 — obligatorio en OAuth 2.1, la base del estándar de MCP.
Apareció una herramienta que no estaba en el escaneo anterior. Con IA activada, se juzga si su propio contenido parece sospechoso y la severidad sube si es así.
La descripción de una herramienta ya conocida cambió respecto al escaneo anterior — el indicio central de un rug pull: una herramienta que empezó siendo confiable cambia su comportamiento después de que ya la usas.
Una herramienta que existía ya no está — informativo, para llevar la cuenta de qué ha cambiado en el catálogo.
El mismo hallazgo, palabra por palabra, aparece también en otro servidor sin relación aparente — indicio de una plantilla clonada o un ataque dirigido a varios servidores a la vez, no un caso aislado. Hereda la severidad del hallazgo que se repite.
Cada servidor se reparte en una de tres franjas según la severidad MÁS ALTA de su último escaneo — el mismo lenguaje en todas partes:
"No podemos verificarlo" (exige autenticación, o no responde) nunca se presenta como "es seguro" — es justo lo contrario: no tenemos ninguna visibilidad sobre ese servidor, así que no sabemos si lo es o no.
En la sección de Vulnerabilidades, cada fila cuenta hallazgos, no necesariamente servidores: un mismo servidor puede aportar varios (una herramienta distinta cada vez, por ejemplo). Cuando el número de servidores afectados es distinto del número de hallazgos, se muestra debajo — así 2.500 hallazgos de "pide más acceso del que anuncia" no se leen como 2.500 servidores distintos si en realidad son 800.
Cada servidor del catálogo se re-escanea cada 24 horas — un ciclo horario va recorriendo el catálogo entero de forma continua, sin esperar a que alguien lo pida. Los datos del Tablón se refrescan a su vez cada pocos minutos a partir de esos escaneos, así que lo que ves nunca tiene más de un día de retraso respecto al último escaneo real de cada servidor, y normalmente mucho menos.
Depende de la categoría — la descripción del hallazgo en la ficha de tu servidor explica exactamente qué se detectó y por qué. Muchos hallazgos de severidad baja (sin autenticación, repositorio nuevo) son informativos, no un fallo que corregir.
No. Reclamar un servidor (verificando que controlas su dominio) te permite asociarle una credencial de escaneo para que vigilemos también las herramientas que exigen autenticación — nunca oculta ni modifica ningún hallazgo ya detectado.
Esta misma página describe exactamente el mecanismo que corre en producción — no hay ninguna comprobación adicional escondida que no esté documentada aquí.