La idea de que un agente de código haga una revisión de seguridad no es nueva. Lo nuevo es describir ese trabajo no como una sola petición sino como una cadena de etapas enlazadas.
Google ha liberado justo esa cadena con el nombre de Mantis. La herramienta es agnóstica respecto a la pila: un conjunto de habilidades que cargas en tu agente y un conjunto estricto de reglas sobre dónde puede ejecutar código.
Esta guía explica qué hace Mantis, cómo puede probarlo con seguridad un equipo pequeño y dónde debe detenerse. Se centra menos en comandos de instalación que en las decisiones previas: dónde se ejecuta, qué etapa no se puede saltar y cuánto se puede confiar en el informe. Si eso se decide mal, la herramienta no hace daño, pero hace perder tiempo.
Qué es Mantis y qué no
Mantis no es un escáner que apuntas a un repositorio y dejas solo. Cada etapa se publica como un directorio de habilidad separado y se invoca como un comando con barra. Las etapas se encadenan; si lo prefieres, una habilidad supervisora, el meta agente, conduce todo el ciclo en una sesión larga.
Hoy puedes clonarlo y ejecutarlo con Gemini CLI, Antigravity CLI, el Google ADK o un marco de agentes equivalente. Google lo publica bajo Apache 2.0, pero su documentación dice con claridad que es solo demostrativo y no recomendado para producción.
- Es una implementación de referencia, no un producto ni un servicio con soporte de Google.
- No es agnóstico respecto al modelo, pero sí a la pila: no impone lenguaje ni marco.
- Los contratos entre etapas están publicados, así que las habilidades pueden envolverse en un arnés determinista.
- Sirve para evaluación local e interna, no para ejecuciones automáticas sobre código de clientes.
La cadena: aprender, encontrar, probar
Las etapas se agrupan en tres bloques. El primero aprende el objetivo, el segundo genera candidatos y los filtra, el tercero prueba el hallazgo y lo parchea. Esa división es también el esqueleto del resto de la guía.
| Bloque | Qué hace | Habilidades destacadas |
|---|---|---|
| Aprendizaje | Mapea el repositorio y la superficie de amenaza | Barrido del historial, mapa de directorios, nota de arquitectura, modelo de amenaza, plan |
| Búsqueda y filtrado | Genera candidatos y descarta falsos positivos | Investigador, deduplicación, revisión, crítico |
| Prueba y corrección | Reproduce el fallo, lo parchea y puntúa el riesgo | Reproducción, encadenado, parche, calibración, informe |
El paso más interesante del bloque de aprendizaje es el barrido del historial de versiones. Los fallos de seguridad ya cerrados son la mejor pista sobre dónde reaparecerá la misma clase de error. Mantis lee ese historial y estrecha el plan de las etapas siguientes.
Publicar las etapas como directorios separados parece un detalle, pero es la propiedad más útil en la práctica. Puedes quitar una etapa que no necesitas e insertar otra con tus propias reglas. Si ya tienes una lista de comprobación interna, se puede enganchar como habilidad en el paso de filtrado.
Tres límites antes de empezar
Pedir a un agente que busque vulnerabilidades es darle permiso para ejecutar código. La etapa de prueba ejecuta cargas reales; montar esto sin tomárselo en serio significa convertir tu propia máquina en objetivo mientras auditas otra cosa.
- La ejecución solo cabe dentro de gVisor o de una máquina virtual con la red desactivada. Las reglas de Mantis lo exigen.
- Monta la copia del repositorio en solo lectura; los parches van a una rama aparte y no se fusionan sin aprobación humana.
- Los secretos y credenciales de producción no deben existir en ese entorno. Una clave filtrada sale más cara que el fallo hallado.
Esos tres límites no son una preferencia técnica sino el supuesto de funcionamiento de la herramienta. La documentación define dónde puede ocurrir la ejecución a nivel de habilidad; relajar esa definición elimina su modelo de seguridad.
La primera pasada, paso a paso
Empieza con un repositorio pequeño. El primer objetivo no es hallar una vulnerabilidad sino ver la cadena funcionar de principio a fin en tu pila.
- Clona el repositorio y enlaza las habilidades al directorio de comandos de tu marco de agentes.
- Ejecuta primero solo las etapas de aprendizaje y lee tú la nota de arquitectura y el modelo de amenaza.
- Si esa nota entiende mal un componente, corrígelo y regenérala; todas las etapas posteriores se apoyan en ese texto.
- Limita la etapa de investigación a un directorio estrecho en vez de soltarla sobre todo el repositorio.
- No te saltes las etapas de filtrado; la lista bruta de hallazgos llega casi siempre inservible.
- Activa la reproducción solo con el aislado listo y prueba con un único hallazgo en la primera vuelta.
Romper ese orden cuesta tiempo. Si el aprendizaje queda flojo, el investigador mira archivos irrelevantes, el filtrado debe descartar más falsos positivos y el coste en tokens sube rápido.
La diferencia real: reatacar el parche
Casi todas las herramientas de seguridad con agentes se detienen al generar hallazgos. Lo que distingue a Mantis es tratar la reproducción y el reataque al parche como frontera de confianza. Un hallazgo solo cuenta cuando puede ejecutarse y mostrarse en el aislado.
La misma lógica opera en la corrección. Tras aplicar el parche, la cadena vuelve a lanzar la misma carga; si pasa, el parche se rechaza. Es un criterio anclado en un resultado observable y no en la confianza del modelo, y en la práctica es la parte que más tiempo ahorra.
Tiene un precio: los hallazgos que no se pueden probar caen de la lista, y entre ellos puede haber reales. A cambio, la lista que recibes es corta y cada punto es demostrable. Como una revisión se mide por cuántos puntos se atendieron y no por cuántos produjo, ese intercambio suele compensar.
Las dos cifras que da Google
Google describe el problema que ataca con una sola cifra: en el escaneo ingenuo de código con IA, la tasa de positivos reales queda por debajo del 7 por ciento. Es decir, la gran mayoría de los hallazgos no merece revisión, y el coste real no es el escaneo sino las horas humanas de filtrado.
La segunda cifra está en el coste. Según la empresa, el árbol jerárquico de resúmenes recorta más del 85 por ciento del gasto de tokens que el agente dedica a entender un repositorio. Esa cifra decide si la cadena sigue siendo ejecutable en repositorios grandes.
Puntuar el riesgo y leer el informe
La etapa de calibración asigna a cada hallazgo una puntuación de riesgo de 1 a 10. No es una medida absoluta; existe para ordenar hallazgos dentro del mismo repositorio y decirle al lector por dónde empezar.
- Un hallazgo con puntuación alta pero sin reproducción va al final de la lista, no al principio.
- Los hallazgos que une la etapa de encadenado pueden parecer bajos por separado; evalúalos juntos.
- La etapa de reflexión escribe sus lecciones para la pasada siguiente, así que conviene guardar el primer informe.
- El informe se genera para lectura humana; simplifica tú sus títulos antes de volcarlo a un sistema de tickets.
Una habilidad más reciente, la de consejo, invierte el flujo. Antes de escribir código consulta el modelo de amenaza acumulado, los linajes de fallos pasados y los patrones de parche verificados. El objetivo es que la misma clase de error no entre dos veces. Esa es la parte más difícil de cualquier herramienta de revisión: no cerrar lo hallado, sino evitar que vuelva en la siguiente versión. Al definirlo como etapa aparte, Mantis al menos lo hace medible.
Cuánto cuesta una pasada
No hay una respuesta única sobre el coste, porque la factura no depende del tamaño del repositorio sino de cuántos archivos debe leer el agente. Cuando el aprendizaje funciona bien, las etapas siguientes miran una superficie estrecha y el coste se vuelve previsible.
La medición práctica es esta: anota los tokens de la primera pasada y mira cuánto bajan en una segunda sobre el mismo repositorio. El árbol jerárquico entra desde la segunda vuelta y ahí aparece el ahorro. Convertir la herramienta en hábito semanal sin esa medición es ver la factura después.
Un plan realista para un equipo pequeño
Convertir Mantis en un hábito semanal aún no es realista para equipos pequeños. Encaja mejor como una revisión invocada en momentos concretos.
- Al añadir una dependencia externa nueva, ejecútalo solo sobre la superficie que toca esa dependencia.
- Al cambiar un flujo de autenticación o de pago, pasa la cadena completa una vez.
- Al cerrar un fallo de seguridad, comprueba si la misma clase se repite en otro sitio.
- Ejecútalo unos días antes de una versión y no justo antes; los parches deben ser leídos por una persona.
Ese último punto parece un detalle pero es lo más importante de la guía. Un parche generado por el agente debe tratarse como una propuesta a revisar, no como algo que entra solo en el código de producción.
Dónde detenerse
Mantis no saca la revisión de seguridad de las manos humanas. Lo que hace es absorber tres tareas que devoran las horas de un auditor: conocer el repositorio, filtrar la lista de candidatos y demostrar que una vulnerabilidad funciona de verdad.
Esas tres tareas son la parte repetitiva de una jornada de revisión. El tiempo que devuelve el agente se convierte en tiempo para las preguntas que sí exigen una decisión.
Sigue siendo humano decidir si el modelo de amenaza es correcto, qué significa el riesgo para el negocio y si el parche rompe el producto. Por eso tampoco se recomienda en producción: la salida de la cadena no es una decisión sino un expediente preparado para tomarla.