AgentWarden, un escáner estático para skills de agentes y configs MCP
El proyecto pone una puerta de seguridad en CI delante de los Markdown y configuraciones MCP que consumen los agentes, con lockfile, digest y verificación de publicador.
Un agente de IA con acceso a shell, ficheros y APIs rara vez se instala como se instala una dependencia. Muchas veces llega como un Markdown copiado en una carpeta o referenciado por URL, y dentro puede haber scripts ejecutables, patrones de acceso a credenciales, peticiones de red e instrucciones pensadas para saltarse al propio agente. AgentWarden es un CLI de análisis estático que quiere poner puerta a esas skills, herramientas y configuraciones MCP antes de que el agente las lea. Va por la versión 0.3.2 y se distribuye desde el repositorio en GitHub y el paquete en npm.
El argumento del proyecto es sencillo: las skills y los ficheros de configuración MCP ya son dependencias de facto, pero no reciben nada de lo que se da por hecho en cualquier dependencia. No hay lockfile que registre lo instalado exactamente, ni digest estable para detectar cambios posteriores, ni verificación del publicador, ni puerta en CI que frene una configuración de riesgo antes del merge.
Qué mira
Las reglas actuales cubren exposición de credenciales y secretos (rutas locales sensibles, variables de entorno privilegiadas, tokens de API, claves privadas embebidas), comandos peligrosos (operaciones destructivas, patrones de descargar y ejecutar, eval, cadenas de ejecución codificadas), prompt injection y jailbreaks, exfiltración de datos e intentos de conexión inversa, configuraciones MCP arriesgadas (ejecución de shell en crudo, paquetes de servidor sin fijar versión, secretos en claro dentro de env) y patrones de cadena de suministro, como ejecutar un script remoto sin digest o usar un dominio de descarga que imita a otro.
El escaneo de directorios descubre skills en Markdown y los formatos habituales de configuración MCP. El alcance se acota con globs de inclusión y exclusión. Los informes salen redactados por defecto, para que el propio análisis no filtre las credenciales que estaba buscando.
Lockfile, firmas y CI
AgentWarden guarda lo revisado en skills.lock con el digest SHA-256, el manifiesto del paquete, el origen remoto y la procedencia del publicador. verify compara lo instalado con ese lockfile, audit comprueba integridad y aplica la política vigente, y sbom exporta todo como documento CycloneDX 1.5. La instalación remota exige un SHA-256 que aporte el publicador; si el digest no cuadra o el contenido falla la política, el comando termina con código distinto de cero y no registra el artefacto en silencio.
Además admite firma desprendida Ed25519 con clave pública propia. Son dos preguntas distintas: el SHA-256 responde si los bytes cambiaron, la firma responde quién los publicó.
Para meterlo en CI, init --profile strict genera el fichero de política y un workflow de GitHub Actions. La Action también está en el Marketplace, emite SARIF para Code Scanning y soporta escaneo solo de ficheros cambiados en pull requests. Los hallazgos existentes se pueden aceptar mediante una baseline de fingerprints con responsable y fecha de caducidad, para que una excepción temporal no se quede para siempre.
Requiere Node.js 22.6 o superior y no tiene dependencias en runtime, así que se puede probar con npx sin instalar nada globalmente.
El propio proyecto marca los límites: es una puerta estática, no un sandbox, ni un antivirus, ni un motor de políticas en ejecución. Se le pueden escapar patrones de ataque nuevos y puede dar falsos positivos. No sustituye al mínimo privilegio, al aislamiento, a los controles de red ni a la revisión humana. La pregunta que deja abierta es si este tipo de comprobación acaba siendo rutina en los repositorios que despliegan agentes o se queda en una utilidad que cada equipo instala por su cuenta cuando ya ha tenido un susto.
