Seguridad y tratamiento de datos

SecCheck es una herramienta de seguridad, así que se le exige el estándar de una herramienta de seguridad. Esta página expone con claridad cómo le autentica, qué registra y qué sale — y qué no — del perímetro de Cert-IX.

Autenticación y habilitaciones

• Toda petición a https://mcp.cert-ix.com/seccheck debe llevar una clave API válida como Authorization: Bearer <key>. Las peticiones sin ella reciben 401; el backend nunca ve tráfico no autenticado.
• Las claves son gratuitas y de autoservicio: solicite una en cert-ix.com/tools/seccheck-mcp, confirme su dirección de correo electrónico y la clave le llegará por correo. Una clave de autoservicio corresponde a la edición Community, dura 90 días y se puede renovar desde el correo de recordatorio que se envía antes de que caduque. Trate una clave como una contraseña: guárdela en la configuración de su cliente MCP o en un gestor de secretos, nunca en el control de versiones, y rótela si pudiera haberse filtrado.
• Todo el tráfico va por TLS. No envíe claves por HTTP sin cifrar.

Su edición viaja con su clave, y esta es la parte que conviene entender:

Las habilitaciones se resuelven en el borde, en cada petición

El borde de Cert-IX autentica su clave y luego fija sus habilitaciones en la petición reenviada — incondicionalmente, en cada petición, incluso cuando están vacías. Por tanto, un llamante no puede declarar su propio nivel enviando él mismo información de habilitaciones: lo que usted envíe se sobrescribe antes de que el backend lo vea.

El servidor se niega a arrancar en modo alojado si se configura un archivo de licencia global del proceso, porque una sola variable de entorno promocionaría a todos los llamantes de golpe. Las habilitaciones vienen de su clave, una petición cada vez, o no vienen.

Si una herramienta devuelve un error de restricción inesperado, llame a license_status — informa exactamente de qué desbloquea su credencial.

Límites de tasa y protección frente a abusos

El punto de acceso alojado aplica límites en el borde (nginx del host), antes de realizar trabajo alguno:

Ámbito	Límite
Por clave API	20 peticiones/segundo (ráfaga corta hasta 40), 20 conexiones simultáneas
Por IP de origen	40 peticiones/segundo (ráfaga 80), 40 conexiones simultáneas

Los límites por IP se aplican antes de la autenticación, de modo que las avalanchas no autenticadas también quedan acotadas.

Superar un límite devuelve 429 Too Many Requests con una cabecera Retry-After. Respétela y aplique retroceso exponencial; un cliente correcto debería mantenerse holgadamente por debajo de 10 peticiones/segundo por clave. Estos topes están muy por encima del uso normal de un agente — unas cuantas búsquedas y una o dos cargas por tarea — y existen para frenar avalanchas, no para estrangular el trabajo real.

Los fallos de autenticación repetidos se tratan como abuso: una IP que produce muchos 401 en poco tiempo queda bloqueada temporalmente (fail2ban). Un titular de clave válida nunca llega a esto, porque una clave correcta nunca da 401.

Qué envía usted y qué ocurre con ello

Las herramientas de SecCheck son consultas de solo lectura contra un corpus fijo. Esto es exactamente para qué se usa cada tipo de entrada:

Usted envía	Qué hace SecCheck con ello
Una consulta de búsqueda y filtros	Los puntúa contra el catálogo en memoria y devuelve los resúmenes de playbooks coincidentes.
Un id de skill	Devuelve el SKILL.md de ese playbook.
Un id de skill + una ruta de recurso	Devuelve ese archivo incluido, resuelto estrictamente dentro del propio directorio del skill.

Nunca envía a SecCheck su código, sus registros, sus hallazgos ni nada sobre su entorno — las herramientas reciben una cadena de búsqueda e identificadores, y nada más. El servidor alojado no tiene acceso a su sistema de archivos ni capacidad alguna de alcanzar sus sistemas.

Qué datos operativos se conservan

Existen dos registros, ambos deliberadamente estrechos:

• Medición de uso — recuentos de llamadas agregados por herramienta y por cliente, para capacidad y supervisión. Un indicador vivo, no un libro de facturación.
• Un registro de auditoría por llamada a herramienta, con el nombre de la herramienta, solo los nombres de los argumentos, su etiqueta de cliente, su nivel y si la llamada dio error.

Las consultas de búsqueda nunca se registran

El registro de auditoría anota que usted llamó a search_skills con un argumento query — no qué decía la consulta. Una consulta de búsqueda es entrada de usuario y puede describir un incidente en curso; registrar la clave sin el valor es lo que convierte el registro en evidencia de revisión de accesos en lugar de un volcado de depuración de su postura de seguridad.

Ambos se exponen únicamente en un endpoint /metrics interno protegido por token, nunca alcanzable desde la internet pública, y que falla en cerrado — sin token configurado se niega directamente a servir.

Residencia de datos — dónde vive el contenido

Para SecCheck, la respuesta es sencilla:

• Todo el corpus de 857 playbooks está incorporado en el servidor de SecCheck y se sirve desde memoria. La búsqueda, la carga y la lectura de recursos las resuelve el mismo servidor que recibió la petición.
• SecCheck no realiza llamadas salientes a servicios de terceros en el momento de la petición. No hay API de origen, ni consulta de respaldo, ni telemetría a un proveedor externo — ese mismo servidor responde aunque la red esté completamente desactivada. Su consulta se responde en la infraestructura de Cert-IX y no se reenvía a ningún otro sitio.
• Su cliente MCP, y el modelo de IA que hay detrás, también ven todo lo que su agente envía y recibe. Esa parte se rige por su cliente y su proveedor del modelo, no por Cert-IX.

¿Quiere un despliegue totalmente sin conexión?

Ejecute SecCheck localmente por stdio — el binario lleva el corpus y no necesita red alguna, lo que encaja con entornos aislados y de alta garantía. Véase Primeros pasos → Opción 2. El binario local aún no es una descarga pública: hable con su equipo de cuenta de Cert-IX.

Postura de red (alojado)

• El punto de acceso está tras nginx del host, que es la única entrada y se encarga de la autenticación, la limitación de tasa, la resolución de habilitaciones y la terminación TLS.
• El contenedor de SecCheck se publica solo en el loopback del host, de modo que no se puede alcanzar desde internet salvo a través de ese nginx.
• El servidor Go rechaza escuchar fuera del loopback salvo excepción explícita, porque la capa de aplicación no tiene autenticación propia — autenticar es tarea del borde, y escuchar en todas las interfaces publicaría un servidor MCP sin autenticar.
• /seccheck es la única ruta expuesta públicamente para este servidor. Las rutas operativas (/metrics) son solo internas.

Integridad del contenido

Un corpus vacío o parcial sería la versión de «falso veredicto limpio» de este producto: search_skills devolvería «sin resultados» y un modelo lo leería como «ese trabajo de seguridad no existe». Por eso el servidor se niega a arrancar en modo alojado con un catálogo vacío, y su comprobación de salud se declara no sana en lugar de servirlo — una imagen sin corpus no puede pasar el despliegue.

Obligaciones de licencia y atribución

Los playbooks son contenido de terceros redistribuido bajo licencias permisivas (Apache-2.0 y MIT), conservando todos los derechos de sus autores originales.

• get_attribution devuelve el origen, el autor, el identificador de licencia, la página del proyecto y el texto completo de la licencia de cada biblioteca.
• Si redistribuye contenido de los playbooks — internamente a gran escala, en un producto o en un entregable a un cliente — reproduzca esos avisos. Acceder a través de SecCheck no cambia los términos de licencia subyacentes.

Notas de cumplimiento

• SecCheck procesa consultas de búsqueda e identificadores de documento — entrada técnica, no datos personales. Los valores de las consultas no se conservan.
• Las claves API identifican a un cliente/organización, para control de acceso, resolución de habilitaciones y contabilidad agregada de tasa — no para elaborar perfiles.
• El diseño con corpus incorporado responde a todas las consultas en la infraestructura de Cert-IX: el propio SecCheck no tiene ninguna vía de consulta a terceros de la que haya que salirse.

Si necesita un anexo de tratamiento de datos o una garantía de residencia para una carga regulada, hable con su equipo de cuenta de Cert-IX sobre un despliegue dedicado o totalmente sin conexión.

Uso aceptable

La biblioteca incluye material ofensivo — explotación, ataques a credenciales, post-explotación, metodología de ataque web. Se publica para trabajo de seguridad autorizado: sistemas de su propiedad, encargos para los que tenga permiso por escrito, CTF, entornos de formación e investigación defensiva.

Usarlo para atacar sistemas que no está autorizado a probar es un uso indebido del servicio y su responsabilidad. Cert-IX puede revocar una clave utilizada así.

Lista de buenas prácticas

• ✅ Guarde la clave API en la configuración segura de su cliente MCP, no en el repositorio.
• ✅ Rote la clave ante cambios de personal o sospecha de exposición.
• ✅ Haga que el agente indique con claridad un NO MATCH en lugar de improvisar un procedimiento (véase Flujos de trabajo de agentes).
• ✅ Lea un playbook antes de ejecutar sus comandos — es orientación de terceros escrita para el stack de otra persona.
• ✅ Si el playbook tiene una sección de verificación o validación, ejecútela antes de dar el trabajo por terminado.
• ✅ Reproduzca los avisos de atribución si redistribuye contenido.
• ✅ Mantenga SecCheck como una capa más — combínelo con revisión, pruebas y sus controles existentes.