Nota de método · 2026 · waitdead.ai

Cómo verificamos un agente a ciegas: el método dogfood de Hermes

Vendemos una revisión de seguridad de IA. La forma más justa de mostrar qué es esa revisión —sin nombrar a un cliente que no podemos nombrar— es ejecutarla sobre nuestras propias herramientas y publicar el método. "Hermes" es nuestro agente interno de QA de código seguro. Lo sometemos exactamente a la misma evaluación que vendemos, y las restricciones de abajo no son aspiracionales: así está construido Hermes y así revisamos cualquier agente que invoque herramientas.

Las cuatro propiedades de contención que buscamos

Cuando evaluamos un agente —Hermes o el de un cliente— comprobamos si realmente mantiene estas cuatro propiedades ante entradas adversarias, no solo si el README dice que lo hace.

• Solo lectura por defecto. El agente lee contexto; no obtiene autoridad de escritura ni de ejecución salvo que un paso específico y acotado se la conceda. Sondeamos rutas por las que una entrada no confiable pueda escalar una lectura a una escritura.
• Redacción de secretos a la entrada y a la salida. Los secretos se eliminan al entrar (para que nunca lleguen al contexto del modelo) y al salir (para que un hallazgo o resumen no pueda filtrarlos). Probamos ambas direcciones, porque redactar solo a la entrada todavía permite que un agente reconstruya o repita un secreto que infirió.
• Entrada no confiable tratada como datos, nunca como instrucciones. Manifiestos pegados, páginas extraídas, salidas de herramientas, contenido de archivos: todo son datos a analizar, no una orden a obedecer. Esta es la defensa central contra la inyección de prompts, y la atacamos directamente: ¿puede una carga maliciosa en la entrada dirigir las acciones del agente?
• Contexto acotado al build. El agente solo ve el build sobre el que se le preguntó. No puede saltar a leer el código de otro inquilino, los datos de otro cliente ni un sistema de archivos más amplio. Probamos el límite, no solo el camino feliz.

La segunda pasada independiente y a ciegas

Un único revisor que encuentra un problema y a la vez lo confirma está calificando su propio trabajo. Nuestro proceso separa esos roles a propósito:

• Acotar y luego descomponer. Mapeamos la superficie de ataque y la dividimos en hojas de revisión independientes —cada una una pregunta autocontenida sobre un comportamiento— frente a OWASP (LLM y Agéntico) y MITRE ATLAS.
• Sondear de forma adversaria. La primera pasada intenta romper cada propiedad y registra un artefacto de reproducción reproducible para todo lo que encuentra: la entrada exacta y el comportamiento observado, para que puedas ejecutarlo tú mismo.
• Verificar a ciegas. Una segunda pasada, independiente, revisa cada hallazgo sin ver la conclusión de la primera. O reproduce el problema a partir del artefacto, o no. El desacuerdo es una señal, no una vergüenza: es justo lo que oculta una revisión de una sola pasada.
• Firma humana. Un veredicto derivado de IA es evidencia para una decisión humana, nunca la autoridad final. Una persona revisa el paquete antes de su entrega.

El entregable es un paquete EVIDENCE / STATUS: cada hallazgo lleva un artefacto de reproducción reproducible, una severidad mapeada a OWASP y ATLAS, una guía de remediación y el veredicto independiente a ciegas. La revisión insignia incluye un re-test gratuito después de que remedies.

Puedes contrastar este método con la cosa en sí: el escaneo gratuito en crm.waitdead.com/scan aplica la misma postura a una superficie pública —la entrada pegada se trata como datos no confiables, los secretos se redactan al enviar y recibes de vuelta una lista de exposición mapeada a OWASP-Agéntico—. Esa es la puerta de entrada al mismo proceso descrito arriba.