¿Puede la seguridad con IA sustituir SAST, DAST y pentests?

La pregunta útil es dónde merece confianza un agente. Confío en él para ampliar la cobertura de una revisión, relacionar indicios entre archivos, generar pruebas dirigidas y convertir una traza confusa de un escáner en una corrección comprensible para un desarrollador. No confío en que deduzca las reglas de autorización de una empresa a partir de nombres de rutas, demuestre todas las fronteras entre inquilinos o decida que un flujo financiero extraño es abusivo sin que una persona defina la regla. Trata al agente como un revisor activo dentro de un programa de pruebas por capas, no como el programa entero.

Una revisión de agente interpreta, no crea otra clase de prueba

Un agente de IA cambia la forma de recopilar y entender las pruebas, pero no crea una clase nueva de evidencia. Si lee el código fuente sin ejecutar la aplicación, realiza una modalidad flexible de revisión estática. Si envía peticiones a un objetivo en ejecución, hace pruebas dinámicas. Si explora objetivos, cambia de táctica y sigue comportamientos inesperados, se parece a un pentester, pero ese parecido no le concede su autorización ni su contexto empresarial.

La diferencia importa cuando un proveedor afirma que su agente "sustituye a los escáneres". Pregunta qué puede observar realmente el sistema. ¿Recibe el repositorio completo, el código generado, las opciones de compilación, las políticas de infraestructura y los archivos de bloqueo de dependencias? ¿Puede autenticarse como varios usuarios y comprobar el estado de la base de datos después de cada petición? ¿Sabe qué acciones prohíbe una política, en lugar de limitarse a ver que no aparecen en la interfaz? Una explicación brillante no compensa entradas ausentes.

Los agentes sí son buenos relacionando señales débiles. Una regla convencional puede marcar un parámetro de una petición que llega a un constructor de consultas. El agente puede revisar la función envolvente, advertir que un punto de llamada omite el predicado del inquilino, preparar una petición de prueba y explicar por qué el ayudante supuestamente seguro falla en ese recorrido. También puede descartar un candidato cuando el valor pasa por una API parametrizada de verdad. Eso mejora el triaje, pero no demuestra que el análisis estático o dinámico haya quedado obsoleto.

La frontera precisa separa revisión y verificación. Una revisión pregunta: "¿Parece insegura esta implementación con el material que puedo ver?". La verificación pregunta: "En las condiciones indicadas, ¿puede este actor provocar un resultado prohibido?". La IA ayuda en ambos trabajos, pero una puerta de seguridad debe registrar qué afirmación está haciendo. Los equipos sufren cuando ascienden una observación bien redactada a exploit verificado o consideran que un intento fallido demuestra seguridad.

El comportamiento del modelo añade otra distinción: capacidad no equivale a repetibilidad. Un agente puede descubrir un recorrido sutil en una ejecución y perderlo después de cambiar el modelo, el prompt, el índice de recuperación o la política de herramientas. Conserva los prompts, permisos de herramientas, archivos recuperados, peticiones generadas y el identificador del modelo cuando el resultado sea importante. Convierte después los descubrimientos confirmados en pruebas cuyo resultado no dependa de que el modelo redescubra su propia idea.

SAST conserva la cobertura repetible del código fuente

SAST sigue siendo la forma más barata de aplicar comprobaciones estables a cada cambio en una base de código grande. Puede enumerar orígenes y destinos, imponer APIs prohibidas, inspeccionar el flujo de datos e indicar la revisión exacta que analizó. Una regla determinista produce mañana el mismo resultado, algo necesario cuando una puerta de publicación necesita una razón auditable para permitir o detener una entrega.

Un agente aporta contexto que un motor de reglas no suele tener. Puede seguir envoltorios propios del proyecto, leer los comentarios con escepticismo, comparar un controlador con sus vecinos y proponer una consulta para un patrón nuevo. Puede detectar omisiones sospechosas, por ejemplo nueve endpoints que llaman a authorizeProject() y un décimo que carga directamente el registro. También resulta útil cuando el código generado o un framework poco conocido derrota a un paquete de reglas estándar.

Pero cuesta más demostrar la cobertura de código de un agente. Las ventanas de contexto, la prioridad de recuperación, los archivos ignorados, los artefactos generados y los límites de tiempo pueden dejar código sin leer. Pedir "revisa este repositorio en busca de inyecciones" no prueba que se haya alcanzado cada destino. Un informe SAST al menos puede indicar archivos, reglas y revisión analizados. El agente necesita un registro de cobertura equivalente antes de ocupar una puerta obligatoria.

NIST SP 800-218 formula una recomendación sensata: usar análisis de código desde el principio y verificar manualmente las funciones y mitigaciones de seguridad. El valor está en combinar ambos trabajos. Las reglas estables encuentran formas de defectos conocidas en cada commit; el agente investiga excepciones, escribe regresiones concretas y ayuda a ajustar reglas cuando reaparece el mismo patrón. Eliminar SAST porque el agente encontró varios fallos ingeniosos cambia una amplitud medible por anécdotas llamativas.

SAST también ve código que una prueba en ejecución quizá nunca alcance: rutas de error, opciones de funciones, utilidades de migración, endpoints administrativos inactivos y ramas propias de una plataforma. No puede decir si el entorno desplegado habilita esos caminos. Esa incertidumbre pide pruebas de ejecución, no la eliminación de la cobertura estática.

No todo pertenece a una regla SAST que bloquee la entrega. Un patrón exacto para un algoritmo criptográfico prohibido puede detenerla de inmediato. Una heurística amplia que pregunta si una comprobación de autorización "parece bastante cercana" normalmente debe crear una tarea de revisión hasta que el equipo mida su precisión. Los agentes ayudan a transformar una heurística en regla recopilando ejemplos correctos, contraejemplos y funciones envolventes comunes del proyecto. Así la puerta sigue siendo estricta sin enseñar a los desarrolladores a ignorarla.

Las correcciones generadas necesitan el mismo examen que los hallazgos. Un modelo puede silenciar una traza de datos añadiendo validación en la capa equivocada, capturar una excepción y continuar de forma insegura, o reemplazar una llamada peligrosa mientras cambia el comportamiento. Ejecuta la prueba original contra el parche, las pruebas funcionales normales y una revisión del control nuevo donde se establece la confianza. Un escaneo limpio solo demuestra que la regla original ya no coincide.

DAST demuestra un comportamiento que el repositorio no revela

DAST observa la aplicación que está funcionando, incluidas reglas del proxy, cabeceras, serialización, middleware de autenticación, valores predeterminados del framework y errores de despliegue. La revisión del código puede indicar que un endpoint parece protegido. Una prueba dinámica puede demostrar que la ruta de producción evita el middleware porque una pasarela reescribe su dirección.

Aquí un agente puede hacer que las pruebas dinámicas sean mucho menos ciegas. Dale una descripción de la API, identidades de prueba, ámbitos permitidos y un entorno desechable, y podrá construir secuencias de peticiones en vez de lanzar cargas genéricas. Puede llevar el identificador de un recurso de una respuesta a la siguiente, renovar una sesión, comparar dos roles y comprobar si una escritura altera lecturas posteriores. El DAST convencional suele tener dificultades con estos flujos con estado.

El agente aún necesita límites operativos estrictos. Un rastreador no sabe si enviar un correo, crear un envío o invocar una integración de pago resulta seguro. Incluso un entorno de prueba puede conectarse a servicios reales. Define hosts permitidos, cuentas, tasas de peticiones, acciones destructivas y condiciones de parada fuera del prompt, y haz que el ejecutor los imponga. Una frase como "evita acciones peligrosas" no es un control.

Mantén una base dinámica convencional para comprobaciones conocidas como cabeceras de seguridad, archivos expuestos, entrada reflejada, sondas habituales de inyección y configuración TLS. Son pruebas baratas, comparables entre versiones y fáciles de seguir en el tiempo. Deja que el agente dedique su presupuesto a recorridos autenticados y comportamientos encadenados. Si ambos sistemas cubren la misma sonda sencilla, conserva el que aporte pruebas más claras y menos variación.

DAST también puede crear una falsa sensación de exhaustividad porque solo informa de lo que alcanza. Registra junto al resultado la cobertura de rutas, identidades usadas, opciones activas y datos iniciales. Un escaneo limpio contra una cuenta casi vacía dice poco de una aplicación cuyas ramas peligrosas aparecen tras una aprobación, invitación, facturación o importación.

La preparación de la autenticación necesita sus propias pruebas. Registra cómo obtuvo el test cada sesión, qué segundos factores o controles de dispositivo se evitaron en pruebas y si los tokens tienen las mismas declaraciones y duración que en producción. Un token administrativo hecho a mano puede abrir cobertura mientras omite precisamente las transiciones de sesión y privilegios que necesitan revisión. Deja visibles esos atajos en el informe.

Una repetición dinámica debe empezar con la secuencia guardada, no con un rastreo autónomo nuevo. Repite la prueba confirmada contra la compilación corregida, comprueba que el efecto prohibido ya no ocurre y varía después entradas cercanas para detectar un filtro demasiado estrecho. Solo entonces debe explorar el agente. Este orden separa "la corrección detiene el exploit conocido" de la afirmación más amplia de que desapareció la clase de defecto.

Las pruebas de autorización necesitan identidades y resultados prohibidos

La autorización no consiste en que el endpoint haya devuelto 403 una vez. Una prueba útil indica quién actúa, qué objeto ataca, qué operación intenta y qué resultado debe seguir siendo imposible. Un agente puede generar las combinaciones, pero el propietario del producto y el revisor de seguridad tienen que aportar la política.

OWASP ASVS dice que las aplicaciones deben aplicar el control de acceso en una capa de servicio de confianza y usar el mínimo privilegio para funciones y datos. Coincido con el requisito de la capa de servicio, aunque los equipos suelen verificarlo de forma demasiado estrecha. Prueban el controlador HTTP visible y olvidan trabajos en segundo plano, exportaciones, índices de búsqueda, suscripciones websocket y URLs directas de almacenamiento. La misma política debe resistir todos los caminos hacia el objeto.

Una pequeña matriz ejecutable descubre más que una orden vaga de "probar IDOR". El siguiente fragmento de shell supone un entorno desechable, dos tokens bearer y un documento propiedad del usuario A. Comprueba tanto el estado como la ausencia del marcador secreto de A en la respuesta de B:

base_url="https://test.example.invalid"
doc_id="d_1042"

curl -sS -D /tmp/headers.txt \n  -H "Authorization: Bearer $TOKEN_B" \n  "$base_url/api/documents/$doc_id" \n  -o /tmp/body.json

status="$(awk 'NR==1 {print $2}' /tmp/headers.txt)"
test "$status" = "403" || test "$status" = "404"
! grep -q "A_ONLY_MARKER" /tmp/body.json

La salida esperada es silencio y un estado de salida cero. Si falla en CI, conserva el estado, el cuerpo saneado, la identidad activa, el propietario de destino, la ruta y la revisión de la compilación. No conserves credenciales reales ni datos ajenos de la respuesta.

Ahora cambia una dimensión cada vez: lectura frente a actualización, ID directo frente a búsqueda, pertenencia activa frente a revocada, ruta normal frente a exportación y token de usuario frente a token de servicio. El agente puede producir y ejecutar estos casos con eficiencia. Una persona debe revisar si la matriz refleja la política y si el resultado correcto es 404, 403, una respuesta vacía o un objeto censurado. De otro modo, el agente podría celebrar una conducta que la empresa considera una brecha.

Las pruebas negativas requieren cuidado. Una actualización rechazada puede revelar que un objeto existe mediante el tiempo de respuesta, el texto del error o un contador de versión. Una lectura rechazada puede aumentar un contador de visitas o escribir en el registro metadatos secretos. Decide qué efectos secundarios están permitidos y compruébalos. Las pruebas que solo miran la respuesta pueden perder un canal de enumeración útil o una escritura dañina.

Prueba también cambios de política durante una sesión. Quita a un usuario de un proyecto, transfiere la propiedad, desactiva una cuenta o reduce un rol de servicio y reutiliza después tokens antiguos y conexiones abiertas. El plazo esperado de revocación debe venir de la política del producto. "Más adelante" no se puede probar y la revocación inmediata quizá no sea necesaria, pero el equipo debe elegir un límite y verificarlo en peticiones API, trabajos en cola, descargas y suscripciones abiertas.

El aislamiento entre inquilinos falla fuera de la petición obvia

El aislamiento necesita pruebas en las fronteras de almacenamiento, caché, colas, búsqueda, archivos, análisis y administración. El fallo habitual no es que falte tenant_id en el endpoint principal de listas. Es una ruta secundaria que copia, indexa, guarda en caché o exporta datos sin transportar el contexto del inquilino.

Empieza con dos inquilinos que contengan registros deliberadamente similares y un marcador inconfundible para cada uno. Usa usuarios, sesiones y, cuando la arquitectura lo permita, credenciales de servicio separadas. Ejercita creación, lectura, actualización, borrado, listas, búsqueda, exportación, importación, adjuntos, notificaciones y procesos de fondo. Tras cada acción, inspecciona la respuesta visible y el estado persistente. Una petición rechazada que aun así encola un trabajo entre inquilinos es un fallo.

Los agentes ayudan porque pueden seguir un identificador entre capas y generar combinaciones tediosas para una persona. Pueden observar que una clave de caché usa document_id mientras la consulta de base de datos emplea también tenant_id. Pueden comparar un trabajador de exportación con el controlador interactivo y preguntar por qué solo uno establece el contexto de seguridad por fila. Son movimientos de revisión útiles.

También hacen una suposición peligrosa: los nombres implican fronteras. Una función llamada getTenantDocument puede aceptar desde la petición un argumento de inquilino arbitrario. Puede existir una política en las migraciones y faltar en una tabla nueva. Un filtro de búsqueda puede aplicarse después de contar los resultados y revelar actividad de otra cuenta. La verificación debe inspeccionar el predicado impuesto y después intentar leer y escribir entre inquilinos.

No permitas que el agente cree su propio oráculo leyendo el mismo código que prueba. Obtén el acceso esperado de una tabla de políticas independiente, mantenida con los requisitos del producto. Si implementación y prueba entienden mal la misma regla, coincidirán a la perfección mientras exponen datos.

Las rutas asíncronas necesitan comprobaciones retrasadas. Activa como inquilino A una exportación, notificación, miniatura o tarea de indexado, cambia la propiedad o pertenencia antes de que se ejecute y mira dónde llega el resultado. Decide si el trabajador debe usar la autoridad capturada al solicitar la tarea o volver a comprobar la actual. Cualquiera puede ser correcta para una operación concreta, pero una mezcla accidental crea filtraciones y registros incoherentes.

Las herramientas administrativas necesitan identidades propias y comprobaciones del registro. El soporte cruza fronteras a propósito, así que una regla simple de "otro inquilino debe fallar" sería incorrecta. Prueba que el operador tenga el rol y caso exigidos, que se respete la política visible para el cliente, que el acceso caduque y que el evento de auditoría identifique al operador en vez de suplantar al cliente.

La lógica de negocio necesita una historia de abuso

Las pruebas de lógica empresarial empiezan con una historia prohibida: un usuario obtiene valor, autoridad o estado que no debería recibir tomando acciones válidas en un orden o una combinación no válidos. Las etiquetas genéricas de vulnerabilidad no bastan. El evaluador debe saber cómo se relacionan invitaciones, aprobaciones, cuotas, reembolsos, créditos, transferencias de propiedad y cancelaciones.

La guía OWASP Web Security Testing Guide pide probar pasos omitidos, funciones repetidas, peticiones falsificadas, cambios temporales y el abuso de funciones válidas. Su introducción anterior sobre lógica empresarial afirma sin rodeos que la automatización de un escáner no aporta conocimiento específico ni creatividad. Los agentes modernos mejoran la automatización, pero no cierran esa falta de conocimiento. Un modelo puede sugerir que un cupón quizá sea reutilizable; no sabe si eso es una promoción o un fraude hasta que alguien expresa la regla.

Entrega al agente un modelo de estados con transiciones permitidas e invariantes. En una aprobación, una invariante podría decir: "Quien solicita un pago no puede aprobarlo, ni siquiera después de transferir la propiedad". Pídele secuencias con cambios de rol, peticiones duplicadas, cancelación, reintentos, concurrencia y sesiones antiguas. El agente puede explorar muchas más secuencias de las que una persona ejecutaría a mano.

Los casos difíciles tienen consecuencias fuera de la respuesta HTTP. Dos canjes simultáneos pueden devolver éxito y una conciliación posterior eliminar uno. Una cancelación puede detener el trabajo visible sin revocar una descarga firmada. Una invitación aceptada después de que el remitente pierda acceso puede crear una pertenencia huérfana. Las pruebas deben observar libros, colas, permisos de objetos y estado posterior, no solo códigos.

Los evaluadores humanos justifican su lugar al cuestionar el modelo declarado. Preguntan si el soporte puede combinar funciones inocuas, si un operador puede influir en su propio registro o si un objeto "caducado" sigue accesible por otro canal. Un agente trabaja dentro de los objetivos y herramientas que recibe. Una persona puede advertir que los objetivos omiten la parte peligrosa del negocio.

El riesgo de dependencias no es solo una versión vulnerable

Las pruebas de dependencias responden cuatro preguntas distintas: qué paquetes están presentes, si sus versiones conocidas tienen vulnerabilidades publicadas, si la compilación obtuvo los artefactos previstos y si la aplicación expone de verdad el comportamiento vulnerable. El análisis de composición de software (SCA) y los controles de procedencia responden a las tres primeras de forma más fiable que una revisión conversacional.

El agente resulta útil cuando ya existe el inventario. Puede revisar cómo se llama a una dependencia, determinar si la función afectada es alcanzable, localizar un control compensatorio y preparar una actualización con pruebas de regresión. También puede marcar comportamientos arriesgados sin identificador de vulnerabilidad, como un script de instalación con acceso a red o una biblioteca nueva que recibe secretos en su entorno.

No pidas al modelo que recuerde datos actuales de vulnerabilidades. Proporciónale una fuente de avisos fechada, el archivo de bloqueo resuelto y el inventario del artefacto construido. La memoria de un modelo no es una base de vulnerabilidades y el manifiesto de paquetes no demuestra qué se publicó. La procedencia de SLSA distingue algo relacionado: describe dónde, cuándo y cómo se produjo un artefacto. No declara que sea seguro.

La alcanzabilidad puede reducir la prioridad, pero no debe borrar al responsable. Las opciones cambian, el código muerto vuelve y las dependencias indirectas se llaman de formas inesperadas. Registra por qué se aplazó un hallazgo, qué versión y recorrido se evaluaron y qué acontecimiento debe reabrirlo. El agente puede mantener ese razonamiento mientras un inventario determinista vigila el evento.

Los nombres de paquetes también crean trampas de identidad. Una dependencia con el nombre esperado puede proceder del registro equivocado, un archivo de bloqueo puede apuntar a una ubicación mutable o la compilación puede descargar código que no aparece en el manifiesto. Comprueba fuentes resueltas, hashes, firmas cuando existan y acceso de red durante la compilación. El agente puede explicar diferencias, pero el sistema de construcción debe imponer qué fuentes acepta.

Actualizar no siempre es seguro. Una versión de seguridad puede cambiar el análisis, los valores predeterminados de autorización o la serialización y romper la aplicación. Genera una reproducción mínima del aviso, aplica la actualización en una rama aislada y ejecuta tanto la prueba de seguridad como las funcionales. Esa evidencia permite decidir; que un modelo diga que la versión nueva "debería ser compatible" no lo hace.

Los falsos positivos son un problema de diseño de pruebas

Un hallazgo merece tiempo de desarrollo solo cuando contiene una afirmación, pruebas, impacto y recorrido reproducible. Los informes generados por IA suelen parecer completos aunque falte una pieza. Un texto de corrección fluido hace más difícil detectar una evidencia débil.

Exige en cada hallazgo la revisión y el entorno analizados, el componente afectado, las condiciones previas del atacante, la frontera cruzada, el resultado observado o deducido, pasos de reproducción e incertidumbre. Marca de forma distinta los hallazgos inferidos del código y los exploits ejecutados. Si el agente no pudo ejecutar la aplicación, debe decirlo en el hallazgo y no ocultarlo en una nota general.

Aplica después un vocabulario sencillo: confirmado, probable, necesita contexto, no reproducible, riesgo aceptado o corregido. "Falso positivo" debe significar que la afirmación es incorrecta, no que al equipo le molesta la gravedad o ha aplazado la tarea. Mezclar decisiones destruye la información. El agente no puede aprender qué regla falló si cada ticket incómodo recibe la misma etiqueta.

La IA puede reducir ruido agrupando trazas duplicadas, comprobando saneadores y repitiendo pruebas después de una corrección. También puede multiplicarlo al redactar diez variantes convincentes de una sospecha débil. Deduplica por causa y frontera, no por URL. Una comprobación de propiedad ausente usada por ocho endpoints es un solo defecto de ingeniería con ocho puntos expuestos.

Mide la precisión por categoría y origen. Si los informes de scripting entre sitios del agente suelen ser válidos pero sus afirmaciones de concurrencia rara vez se reproducen, enrútalos de manera distinta. No resumas clases de defectos distintas en una puntuación. Una puerta debe fallar por evidencia y política, no por el adjetivo de confianza del modelo.

La responsabilidad cierra el ciclo. Cada hallazgo aceptado necesita una persona o equipo que corrija, un método previsto de repetición y una prueba guardada que otro evaluador pueda ejecutar. Si el informe solo vive en una conversación del agente, desaparecerá al cambiar la conversación, el modelo o el proveedor. El trabajo de seguridad perdura cuando la prueba sobrevive a la herramienta.

La privacidad también importa durante el triaje. El código, los cuerpos de peticiones, los registros y las muestras de base de datos pueden contener credenciales o datos de clientes. Reduce lo que recibe el agente, censura las transcripciones, separa pruebas de producción y aplica al proveedor y sus herramientas las reglas aprobadas de tratamiento. Detectar mejor no justifica copiar un incidente entero a un prompt sin control.

Un pentest humano examina los supuestos de la prueba

Un pentester competente cambia el plan cuando la aplicación contradice el encargo. Esa es la parte que los agentes no han sustituido. La persona entrevista a responsables, resuelve reglas ambiguas, detecta atajos operativos, solicita otra identidad y decide cuándo un comportamiento extraño merece una cadena de experimentos.

Las personas también responden por decisiones con evidencia incompleta. Distinguen una acción técnicamente posible de una ruta de ataque creíble, explican un fallo compuesto a dirección y desarrollo y acuerdan una prueba segura cuando explotarlo dañaría datos. Un agente autónomo debe detenerse en el límite marcado por su operador. Si lo amplía en silencio, se convierte en otro riesgo.

Esto no significa que cada publicación necesite una semana de consultoría externa. Usa pruebas humanas donde coinciden cambio y consecuencias: un modelo nuevo de autorización, arquitectura de inquilinos, pagos o créditos, plano administrativo, integración sensible, migración grande o lanzamiento público. Programa trabajos periódicos más amplios según riesgo y repite las correcciones graves. Las versiones rutinarias siguen necesitando cobertura automática.

Entrega al evaluador los resultados del agente, trazas SAST, cobertura DAST, notas de arquitectura, cuentas de prueba y supuestos pendientes. El agente puede asumir reconocimiento y variantes repetitivas mientras la persona persigue comportamientos sorprendentes. Así el tiempo humano rinde más sin fingir que sobra.

Desconfía de afirmaciones de "pentest autónomo" medidas por número de hallazgos. Diez inyecciones conocidas no equivalen a una ruta demostrada entre asignación de roles, autorización caducada y almacenamiento de exportaciones. Evalúa fronteras probadas, calidad de la evidencia y supuestos importantes cuestionados.

Decide quién limpia antes de empezar. Las cuentas, archivos subidos, mensajes en cola, roles temporales y opciones cambiadas pueden sobrevivir al escaneo. Un responsable humano debe aprobar pruebas destructivas, mantener contacto con operaciones y verificar la restauración. El agente puede seguir un guion de limpieza, pero no decidir si un estado de producción inexplicado se puede borrar.

Un buen evaluador también informa de lo que no pudo probar. Compilaciones móviles ausentes, roles no disponibles, límites de tasa, devoluciones de terceros y entornos inestables reducen la seguridad obtenida. Los agentes suelen rodear obstáculos y presentar los recorridos completados. El informe final debe mostrar las exclusiones para que un resultado limpio no parezca cobertura completa.

Construye una sola puerta con varias clases de evidencia

El programa correcto asigna un trabajo a cada método y une sus salidas ante los mismos requisitos. Usa SAST para patrones deterministas y cobertura amplia de cambios. Usa SCA y procedencia para hechos de dependencias y compilación. Usa DAST para comportamiento desplegado y controles básicos de ejecución. Usa agentes para relacionar evidencia, explorar flujos autenticados, crear pruebas y mejorar el triaje. Usa personas para definir políticas, cuestionar supuestos de negocio e investigar cambios con consecuencias.

La política de publicación puede ser concreta. Detén una compilación cuando coincida una regla determinista grave en un recorrido no aprobado, falle una invariante de autorización, aparezca un marcador de otro inquilino o siga abierto un exploit confirmado. Envía los hallazgos inciertos a revisión con un plazo según exposición. No permitas que la confianza declarada por el modelo decida si se publica.

Conserva la evidencia en formatos portátiles. Exporta hallazgos, pruebas generadas, transcripciones de peticiones, versiones de herramientas, revisiones, identidades, cobertura y decisiones en formatos que el equipo pueda examinar sin el agente. Sirve para auditorías, incidentes, cambios de proveedor y para el día normal en que una actualización altera el comportamiento.

La misma separación se aplica a aplicaciones creadas mediante chat. Koder.ai puede generar aplicaciones web, de servidor y móviles y exportar su código, pero el software generado sigue necesitando requisitos de seguridad explícitos y pruebas independientes sobre el resultado desplegado. La creación rápida hace más útil una puerta clara porque la arquitectura y el código pueden cambiar deprisa.

Ejecuta el agente continuamente, pero convierte sus mejores descubrimientos en regresiones deterministas. Cada salto confirmado de autorización debe ser un caso de política. Cada fuga entre inquilinos debe añadir una invariante en la frontera que falló. Cada regla ruidosa necesita una decisión registrada. Con el tiempo, el agente debe dejar el sistema de pruebas más preciso que al llegar.

No preguntes qué herramienta gana. Pregunta si cada afirmación importante tiene evidencia independiente: se revisó el código, se ejercitó el comportamiento desplegado, la regla empresarial procede de un responsable y una persona cuestionó los supuestos donde un fallo haría daño. Si falta una línea, un "todo correcto" generado por IA no la rellena.