Audita agentes de IA locales con Geiger

Inventaría los agentes antes de confiar en ellos

Tu portátil puede estar ejecutando más asistentes de agentes de los que recuerdas, y cada uno puede acceder a archivos, red o secretos de una manera diferente. Antes de pegar un prompt en uno, necesitas una lista de lo que puede tocar.

La escala es difícil de ignorar: un arnés de agentes de código abierto recopiló más de 200,000 estrellas de GitHub durante tres semanas en agosto de 2026, mientras que el ecosistema de plugins superó los 13,000 repositorios en ese mismo período.

Geiger se ejecuta como un comando de solo lectura. Enumera los agentes de IA locales, además de arneses, servidores MCP, plugins y extensiones de IA en la máquina, y luego indica lo que cada uno puede tocar.

Úsalo sin instalación, cuenta ni telemetría, y no escriba nada a menos que especifiques explícitamente un archivo de salida JSON.

Confirma que el escaneo alcanza los servidores MCP globales y por proyecto de Claude Code, además de sus hooks, plugins, skills, subagents y apiKeyHelper, y los hosts MCP: Claude Desktop, Cursor, Windsurf, además de VS Code, Cline, Roo Code, además de Continue y Zed.

Si la salida es demasiado larga, divídela por host. Mantén una columna para el elemento, otra para su origen y otra para lo que puede hacer.

Guarda la salida cruda en un lugar donde puedas hacer un diff más tarde. Un registro antes y después es la forma de detectar un nuevo asistente tras una actualización rutinaria.

Haz que el inventario sea repetible. Guarda el comando, la fecha y el nombre de la máquina en una nota, para que la siguiente persona pueda reproducir la misma vista. Esa línea base es a lo que vuelves. Si no puedes volver a ejecutar el mismo escaneo, no puedes comparar una semana normal con una semana cambiada.

Lo hecho se parece a una lista de capacidades nombradas que puedes leer en un solo vistazo.

Verifica la ruta de evidencia detrás de cada etiqueta

Cada hallazgo lleva su origen, etiquetas de capacidad como EXECUTES y HOLDS-SECRETS, además de BROAD-FILESYSTEM, BROAD-WEB y NETWORK, y una ruta de evidencia que puedes abrir.

Abre la ruta de evidencia y confirma que la configuración, el script o la entrada del servidor realmente existe.

Compara la etiqueta de capacidad con el alcance real: una etiqueta NETWORK significa llamadas salientes, BROAD-FILESYSTEM significa acceso amplio a archivos y HOLDS-SECRETS significa que las credenciales pueden ser accesibles.

Marca como no confiables las entradas cuyo origen sea desconocido hasta que puedas rastrearlas.

El campo de origen es aburrido pero útil: indica si el elemento proviene de un registro, una tienda, una fuente git, un script local, un servidor remoto o un lugar desconocido.

El error ocurre cuando un inventario limpio se interpreta como un certificado de buena salud. Trata a Geiger como un inventario con etiquetas de exposición honestas, no como una auditoría de seguridad.

Convierte la etiqueta en una decisión. Abre el script cuando una ruta apunte a un script de shell, y anota el endpoint y el transporte cuando apunte a un servidor remoto.

Estás listo cuando tienes una tabla breve: elemento, origen, etiqueta, ruta y tu veredicto.

Prueba los límites de tiempo de ejecución que el inventario no puede demostrar

Ejecuta el agente en un sandbox o directorio desechable con archivos de muestra, y luego observa lo que lee, escribe y envía.

Pide al agente que resuma un archivo y luego verifica si tocó algo fuera de la carpeta permitida.

Solicita una llamada a un endpoint falso y luego confirma si el tráfico de red se bloquea o se registra.

Dale una cadena que parezca un secreto y observa si la almacena, la repite o la envía.

No dejes que una señal estática reemplace una prueba de comportamiento; AI-SLOP-Detector mide señales estáticas de código y documentación, pero no demuestra la corrección en tiempo de ejecución.

Registra la prueba en lenguaje claro: qué pediste, qué tocó y si el límite se mantuvo. Una nota breve es suficiente si te permite repetir la prueba más tarde.

Vigila los efectos secundarios que no parecen fallos: un nuevo archivo temporal, una configuración cambiada, una solicitud a un dominio que no esperabas.

Repite la prueba tras cada actualización que cambie un plugin, hook o servidor, y guarda la nota junto al inventario antes de conceder más acceso.