# ¿Tus pruebas de filtración de secretos del agente demuestran algo? Un agente no necesita imprimir un token para haberlo recibido. Si un token bearer entra en su entorno, línea de comandos, carga útil de una herramienta, transcripción, proceso secundario o artefacto de fallo, el límite ya ha fallado. Una respuesta educada del modelo no corrige ese error. La prueba que necesitas no es «¿el agente evitó repetir el secreto?». Es «¿podemos ejecutar acciones reales a través de una puerta de enlace de pruebas, recopilar todos los artefactos que puede producir el lado del agente y demostrar que ninguno contiene una credencial única y funcional?». Es una afirmación lo bastante concreta para probarla y lo bastante sólida para detectar los fallos que aparecen en producción. Usa cuentas, hosts y un canario nuevo y desechable en cada ejecución. Guarda el secreto únicamente en la configuración de la puerta de enlace. Después haz que el agente ejecute acciones HTTP y SSH correctas, provoque fallos de forma intencionada e inspecciona el lado del agente como si esperases encontrar una filtración. Esa es la actitud que descubre los caminos problemáticos. ## Una respuesta limpia no demuestra que el límite esté limpio Un agente puede recibir un secreto sin colocarlo nunca en lenguaje natural. Una filtración habitual aparece cuando una implementación de herramientas indica al agente que llame directamente a una API y coloca un valor `Authorization` en la entrada de la herramienta. Otra ocurre cuando un lanzador de subprocesos hereda `API_TOKEN` porque nadie sustituyó su entorno antes de ejecutarlo. Una tercera aparece cuando un asistente SSH escribe un archivo de identidad temporal donde el agente puede leerlo. Son fallos distintos, pero comparten una consecuencia: el proceso del agente tiene material que le permite actuar fuera de la puerta de enlace. A partir de ese momento, las solicitudes de aprobación y los registros de auditoría describen solo una parte del riesgo. El agente puede copiar el secreto en un repositorio, enviarlo a otro servicio o dejarlo en una transcripción que alguien exporte más tarde. Mantén separadas estas dos afirmaciones: - **Aislamiento de acciones** significa que el agente solicita una operación y recibe su resultado, mientras otro componente inyecta la credencial y realiza la comunicación de red o SSH. - **No entrega del secreto** significa que la credencial y sus derivados utilizables nunca entran en el proceso del agente ni en archivos que este pueda leer. Los equipos suelen probar la primera afirmación y dar por supuesta la segunda. Así, un agente puede llamar correctamente a una API de pruebas a través de una puerta de enlace y, aun así, recibir el token en un campo de depuración o en una variable de entorno heredada. La documentación de Process de Apple es clara sobre la herencia: un subproceso obtiene su entorno del proceso que lo inicia, salvo que el lanzador lo cambie antes del lanzamiento. Sus API también exponen al propio proceso los argumentos de comandos y los datos del entorno. Por eso un proceso secundario no es un detalle de implementación inocente en esta prueba. Es otro punto de observación. El estándar de la prueba debería decir lo siguiente: > Dada una credencial canario nueva almacenada únicamente en la puerta de enlace, un agente puede completar acciones HTTP y SSH especificadas, pero ningún proceso accesible desde el agente, transcripción, registro, salida de error ni artefacto de diagnóstico recopilado contiene el canario ni una codificación identificable de este. No prometas que una prueba de caja negra demuestra que ningún byte de memoria de la puerta de enlace contuvo jamás un secreto. No puede hacerlo. Sí establece el límite que importa a los usuarios: el agente nunca recibe una credencial utilizable a través de las interfaces y artefactos que controla. ## Una credencial de prueba necesita una función y una huella Un token de prueba debe hacer una sola cosa útil y nada más. Para HTTP, crea una cuenta de pruebas que pueda llamar a un único endpoint, como `GET /whoami` o `POST /echo-action`, y que devuelva un identificador de cuenta inocuo. Para SSH, crea una cuenta restringida en un host desechable y permite un conjunto pequeño de comandos que escriba un registro de eventos en el servidor. No uses un token como `test-token` para buscarlo después. Los marcadores cortos y predecibles provocan coincidencias falsas y hacen inútiles las comprobaciones de codificación. Genera una cadena distinta para cada ejecución. Incluye un prefijo reconocible seguido de datos aleatorios, para que una persona pueda identificar un fallo sin confundir una salida normal con un secreto. Por ejemplo, un arnés podría generar un canario con esta forma: ```text sallyport_probe_7M3jP4Fqk2rV9dN8xC5a ``` Esa cadena es un valor de credencial, no un identificador que se imprima al agente. Guarda una etiqueta pública separada para los registros, como `run-2026-07-22-ssh-04`. La etiqueta puede aparecer en las transcripciones. El canario no. Usa canarios distintos para cada canal y cada ruta de fallo. Reutilizar un token HTTP en todas las pruebas convierte una única filtración en un conjunto de coincidencias obsoletas. También dificulta saber si un artefacto posterior procede de la ejecución actual o de una limpieza fallida anterior. Un accesorio de pruebas práctico tiene cuatro elementos: 1. Una cuenta HTTP de pruebas cuyo servidor devuelva una respuesta fija y no secreta después de una autenticación válida. 2. Una cuenta SSH de pruebas cuyo comando forzado registre un identificador de acción y devuelva un mensaje fijo. 3. Una entrada de credencial en la puerta de enlace que contenga el canario nuevo y ninguna copia accesible para el agente. 4. Un manifiesto fuera del directorio de artefactos que relacione la etiqueta de ejecución con los canarios usados en ella. El manifiesto es material sensible de prueba. Guárdalo donde el agente no pueda leerlo y elimina los canarios después de la ejecución. La cuenta de pruebas debe rechazar esas credenciales después de la limpieza, incluso si un fallo dejó una copia en un archivo local. Sallyport permite que la puerta de enlace guarde credenciales HTTP y SSH de prueba mientras el agente recibe resultados de acciones en lugar de las credenciales. El registro del servidor importa. Demuestra que la autenticación tuvo lugar, lo que evita que una prueba defectuosa pase porque la acción nunca se ejecutó. Una respuesta como `authenticated action accepted for run-2026-07-22-ssh-04` proporciona al agente pruebas suficientes de éxito sin repetir la entrada de autenticación. ## La captura del lanzamiento detecta la filtración antes de la primera llamada a una herramienta Captura los argumentos y el entorno iniciales del agente en el límite de lanzamiento. Esta prueba detecta secretos pasados por scripts de shell, configuración de CI, integraciones con editores, envoltorios y lanzadores auxiliares. También detecta un error frecuente después de añadir una puerta de enlace: dejar exportado el antiguo `API_TOKEN` porque la nueva ruta parece funcionar. Inicia el agente mediante un envoltorio que controles. El envoltorio escribe una instantánea exacta de su vector de argumentos y su entorno en un directorio de pruebas protegido, y después se reemplaza por el ejecutable del agente. Reemplazar el proceso importa porque registra los valores suministrados al lanzamiento real del agente, no una reconstrucción aproximada después de que se hayan iniciado varias capas. Este pequeño envoltorio de Python basta para un arnés de pruebas local: ```python #!/usr/bin/env python3 import json import os import pathlib import sys out = pathlib.Path(os.environ["PROBE_LAUNCH_RECORD"]) out.parent.mkdir(parents=True, exist_ok=True) record = { "argv": sys.argv[1:], "environment": dict(os.environ), } out.write_text(json.dumps(record, sort_keys=True), encoding="utf-8") os.execvp(sys.argv[1], sys.argv[1:]) ``` Inícialo con un entorno deliberadamente reducido. Incluye solo lo que el agente necesita para encontrar su ejecutable, su directorio temporal, el endpoint MCP o el adaptador stdio y la ruta donde el envoltorio escribe su registro. No heredes por costumbre todo el entorno del shell del desarrollador. Un entorno completo importa credenciales ajenas, configuración de la nube, tokens de registros de paquetes y configuraciones SSH antiguas que pueden hacer que la prueba falle por el motivo equivocado. El registro esperado del lanzamiento tiene esta forma: ```json { "argv": ["agent-command", "run", "tests/agent-task.txt"], "environment": { "HOME": "/private/tmp/agent-home", "PATH": "/usr/bin:/bin", "PROBE_LAUNCH_RECORD": "/private/tmp/probe/launch.json" } } ``` Las rutas exactas no importan. Lo importante es que el registro no contenga el canario HTTP o SSH, su forma en base64, su forma codificada para URL ni el nombre de un archivo que contenga una clave privada. No ocultes este registro antes de que lo vea el analizador. La ocultación pertenece a los informes destinados a las personas. El registro sin procesar es la prueba. Si una prueba de lanzamiento solo registra una versión limpiada, puede demostrar que el sistema de ocultación funciona mientras esconde precisamente la filtración que necesitabas detectar. Una instantánea de lanzamiento tiene un límite: indica con qué inició el proceso. No puede decirte si una llamada posterior a una herramienta introduce un secreto en el entorno de un proceso secundario o en un archivo temporal. Por eso las siguientes pruebas obligan al agente a crear trabajo después del inicio. ## Los procesos secundarios forman parte del límite del agente Los agentes suelen lanzar formateadores, gestores de paquetes, ejecutores de pruebas, comandos de Git, clientes SSH y scripts. Si el agente puede lanzar un proceso secundario, ese proceso puede escribir su entorno y sus argumentos en el disco, devolverlos como salida o pasarlos a una solicitud de red. Trata cada proceso secundario como accesible desde el agente, salvo que tengas una razón técnica sólida para no hacerlo. Dale al agente una tarea inocua que ejecute un programa de prueba después de completar una acción de la puerta de enlace. El programa muestra sus propios argumentos y su entorno en un formato legible por máquinas. Como es un hijo del entorno de ejecución del agente, observa los valores que ese entorno propaga en ese momento. Usa una prueba que escriba en un directorio controlado en lugar de devolver un volcado enorme del entorno en la conversación del modelo. Estás comprobando una filtración, no invitándola a entrar en la transcripción. ```python #!/usr/bin/env python3 import json import os import pathlib import sys path = pathlib.Path(os.environ["PROBE_CHILD_RECORD"]) path.parent.mkdir(parents=True, exist_ok=True) path.write_text( json.dumps( {"argv": sys.argv, "environment": dict(os.environ)}, sort_keys=True, ), encoding="utf-8", ) print("child probe completed") ``` Pide al agente que ejecute primero una acción autenticada y después invoque la prueba con un argumento anodino como `after-http-action`. Ejecuta la misma secuencia después de SSH. Si la implementación de la puerta de enlace inyecta una credencial en una variable de entorno para un asistente y permite que ese asistente se convierta en descendiente del agente, esta prueba lo detectará. Comprueba las rutas de argumentos por separado. Los desarrolladores saben que las variables de entorno se filtran, pero los argumentos de comandos pueden ser peores porque la inspección de procesos, el historial del shell, el formato de errores y los recopiladores de diagnóstico pueden registrarlos. Apple documenta que un proceso puede acceder a sus propios argumentos mediante `CommandLine.arguments`, y que `ProcessInfo` expone tanto los argumentos como el entorno. Por eso los secretos pasados en argv son observables de inmediato para el código que se ejecuta dentro del proceso. No aceptes un argumento como `--token-file=/private/tmp/secret` solo porque los bytes del token estén ausentes. La prueba también debe inspeccionar esa ruta de archivo. Si el agente puede leer el archivo, tiene el secreto. Si solo un proceso separado de la puerta de enlace puede leerlo y nunca pasa por directorios de trabajo controlados por el agente, registra ese hecho en la configuración de la prueba. Para SSH, busca algo más que el texto de una clave privada. Falla si encuentras una ruta de archivo de identidad, un socket de agente que exponga la identidad de prueba, un registro `known_hosts` generado que contenga material privado o una línea de comandos con una contraseña. Una clave privada guardada en un archivo temporal sigue siendo una clave privada, aunque el agente solo reciba la ruta. ## Las acciones correctas necesitan transcripciones hostiles Un camino feliz que devuelve `200 OK` demuestra muy poco. Solo demuestra que alguien hizo una solicitud. Haz que el agente solicite una acción real a través de la puerta de enlace y conserva todas las transcripciones y trazas de herramientas producidas en el lado del agente. La prueba HTTP debe solicitar un endpoint que confirme la cuenta de pruebas autenticada sin reflejar los encabezados de la solicitud. Una respuesta útil es un objeto fijo como este: ```json { "account": "gateway-test-http", "accepted": true, "request_label": "run-2026-07-22-http-01" } ``` El agente puede razonar a partir de esa respuesta. No necesita el token bearer, el esquema de autorización, el nombre del encabezado inyectado ni un prefijo de token ocultado. Si la interfaz de acciones devuelve un objeto de solicitud para depuración, conviértelo en un objetivo de prueba separado porque es una filtración probable. Un campo llamado `request_headers` es un error de diseño salvo que se garantice que elimina el material de credenciales antes de cruzar el límite del agente. Para SSH, haz que el host acepte un comando fijo como `report-status `. El servidor registra la cuenta autenticada, el comando solicitado y la etiqueta. Devuelve una respuesta como `status recorded`. El agente no debe recibir la clave privada, una exportación del agente SSH ni una transcripción del intercambio de autenticación. Guarda estos artefactos del lado del agente: - El prompt original del agente y la transcripción del modelo. - Los mensajes MCP sin procesar o las solicitudes y respuestas de acciones equivalentes. - La salida estándar y la salida de error de los comandos controlados por el agente. - Los registros de depuración de herramientas, los registros de reintentos y los archivos de eventos estructurados. - Los archivos escritos en el espacio de trabajo del agente, el directorio temporal y el directorio de caché configurado. Recógelos antes de que una rutina de limpieza elimine las pruebas. Después analiza los bytes exactos, no solo el texto decodificado como UTF-8. Un secreto puede aparecer en escapes JSON, codificación porcentual, base64, una traza comprimida o un archivo cuyos bytes no válidos hagan que una búsqueda de texto superficial omita la coincidencia. El adaptador `sp mcp` de Sallyport es un buen objeto para esta prueba porque permite ejercitar la ruta MCP habitual que usa un agente mientras mantiene las credenciales en la bóveda de la aplicación. No confundas una transcripción ocultada con una prueba. Una línea de registro como `Authorization: [REDACTED]` puede estar bien para la salida del operador, pero el objeto de evento original que la produjo todavía podría contener el token. Captura los datos antes del formato de presentación y prueba el formateador por separado. Son dos obligaciones distintas. ## El manejo de errores es donde suele romperse el aislamiento de secretos Una puerta de enlace puede mantener limpia la respuesta correcta y filtrar un secreto cuando algo sale mal. Las rutas de error atraen contexto de depuración, reconstrucción de solicitudes, encadenamiento de excepciones y mensajes de reintento. Ejecútalas de forma intencionada. Empieza con fallos HTTP que ocurran en distintos puntos: 1. Haz que el servidor de pruebas devuelva un `401` sin secretos después de recibir un canario válido. El agente debe saber que la autenticación falló, no el valor del encabezado enviado. 2. Haz que el servidor devuelva `500` con un cuerpo que incluya la etiqueta pública de ejecución. La puerta de enlace puede devolver un cuerpo de error limitado, pero no debe añadir encabezados de solicitud ni un equivalente de curl. 3. Cierra la conexión después de que la puerta de enlace haya preparado la autenticación. Así detectarás excepciones de bajo nivel que incluyan objetos de solicitud en sus descripciones. 4. Devuelve JSON mal formado después de una autenticación correcta. Los analizadores suelen incluir la respuesta problemática o el contexto cercano en una excepción. 5. Usa un nombre DNS que no se resuelva para una ruta de prueba. Así detectarás la salida de reintentos y diagnósticos del endpoint. Después ejecuta fallos SSH que ocurran antes y después de establecer la conexión. Usa un host con una identidad incorrecta, un comando remoto que termine con un estado distinto de cero y un comando forzado que devuelva un error controlado. No pruebes una clave privada incorrecta devolviendo una clave de prueba al agente ni haciendo que el servidor la registre. El agente solo necesita ver una clasificación como `connection rejected` o `remote command failed`, junto con una etiqueta de solicitud segura. Prueba también el estado bloqueado. Mientras la bóveda esté bloqueada, una acción debe fallar antes de que ocurra la autenticación de red. La respuesta puede indicar que la autorización no está disponible. No debe contener un marcador de token, una ruta al almacenamiento de credenciales, un nombre de archivo de identidad SSH ni el número de caracteres de un secreto. Después de desbloquearla, repite la acción y exige el registro de éxito del servidor. Esta pareja de pruebas detecta implementaciones que construyen una solicitud de credenciales antes de comprobar el bloqueo. Un accesorio de fallos útil incluye afirmaciones en ambos lados: ```text Lado del agente: el canario está ausente de todos los artefactos recopilados. Lado de la puerta de enlace: la acción intentada tiene la clasificación de error segura esperada. Lado del servidor: la solicitud esperada ocurrió, o no ocurrió en una prueba con la bóveda bloqueada. ``` La última afirmación evita una falsa sensación de seguridad. Si una prueba espera un error de reintento, pero la puerta de enlace rechazó antes la llamada por un error de configuración, puede pasar el análisis de filtraciones sin haber ejecutado el código peligroso. No envíes excepciones sin procesar a través del límite. Los objetos de error deben contener un identificador de acción, una categoría segura, un mensaje útil para las personas y quizá una indicación de reintento. No deben serializar la configuración de solicitud que provocó la excepción. El deseo de facilitar la depuración hace populares los volcado completos de solicitudes. Sigue siendo el valor predeterminado equivocado cuando un inyector de credenciales es propietario de la solicitud. ## Los artefactos de fallos merecen un fallo intencionado Un fallo no es un resultado normal de una API, por eso los equipos suelen omitirlo. Es un error. Un desarrollador puede adjuntar un informe de fallo a una incidencia, un script de soporte puede archivarlo y un sistema de diagnóstico puede recopilar registros relacionados. Si un secreto termina allí, has creado una filtración retardada en lugar de un límite seguro. Después de una acción HTTP correcta y de nuevo después de una acción SSH correcta, haz que un proceso de prueba del lado del agente se aborte. Mantén el objetivo del fallo separado de la puerta de enlace. Quieres comprobar si el lado del agente heredó o registró material secreto, no si hacer fallar deliberadamente al propietario de las credenciales expone su estado privado. En macOS, recopila el informe mediante Console o la ruta de recopilación de diagnósticos del entorno de pruebas y analiza el archivo sin editar. Apple describe los informes de fallos como registros detallados del estado de una aplicación y recomienda analizar el informe completo del sistema operativo. Su documentación sobre informes de fallos también indica que contienen información del proceso y del entorno, como la identidad del proceso, la ruta, el proceso padre, el momento y el estado de los hilos. La ausencia del canario en un informe de fallos de macOS no demuestra que nunca estuviera presente en la memoria. Un informe estándar no es un volcado completo de memoria. Esa limitación no es motivo para omitir la prueba. Significa que debes expresar el resultado correctamente: el informe no expuso el canario y el proceso del agente no lo recibió a través de los otros canales probados. Analiza también los registros de la aplicación y los archivos de soporte creados alrededor del fallo. Apple advierte a los desarrolladores que no incluyan información sensible de privacidad en los registros. Trátalo como un requisito de tu propio accesorio: si un impresor de excepciones registra un objeto de solicitud, la prueba de fallos debe fallar aunque el informe de fallos del sistema operativo esté limpio. Si más adelante ejecutas pruebas relacionadas en Linux, añade los metadatos de los volcados de memoria y la salida del journal al conjunto de artefactos. El manual de `systemd-coredump` documenta campos que pueden almacenar la línea de comandos y el entorno de un proceso que ha fallado. Un conjunto de pruebas que solo analiza el archivo principal e ignora sus metadatos omite una vía de filtración evidente. ## Analiza bytes, codificaciones y valores divididos Un grep recursivo sencillo es mejor que nada, pero omite las formas que aparecen en JSON, URL, trazas y paquetes binarios. Construye un analizador que lea los archivos como bytes y busque varias transformaciones deterministas de cada canario. Como mínimo, genera estas cadenas de búsqueda para cada canario: ```text bytes sin transformar texto en base64 texto codificado para URL texto escapado para JSON texto hexadecimal primera mitad y segunda mitad separadas por un salto de línea ``` El caso dividido detecta envoltorios de registros que pliegan valores largos. Las formas codificadas detectan sistemas que serializan datos estructurados antes de escribirlos. No analices solo el prefijo de un token. Una prueba de prefijo puede pasar si el token se trunca después de suficientes caracteres para seguir siendo utilizable, y puede fallar por un identificador no relacionado. Un analizador compacto puede informar de la ruta del archivo, el nombre de la transformación y el desplazamiento en bytes sin imprimir el secreto: ```python import base64 import json import pathlib import urllib.parse secret = bytes.fromhex("73616c6c79706f72745f70726f62655f5837") needles = { "raw": secret, "base64": base64.b64encode(secret), "url": urllib.parse.quote_from_bytes(secret).encode(), "json": json.dumps(secret.decode()).encode(), "hex": secret.hex().encode(), } for path in pathlib.Path("artifacts").rglob("*"): if not path.is_file(): continue data = path.read_bytes() for name, needle in needles.items(): offset = data.find(needle) if offset >= 0: raise SystemExit(f"secret match: {path} transform={name} offset={offset}") ``` El código informa intencionadamente de un desplazamiento en lugar de los bytes coincidentes. Un fallo de prueba no debe crear una segunda filtración en la salida de CI. Guarda una copia forense estrictamente controlada solo si tu proceso de incidentes la requiere y mantenla fuera de los registros normales de compilación. Analiza los archivos después de desempaquetarlos en un directorio temporal protegido. Analiza también los datos comprimidos cuando sea posible, porque una búsqueda de bytes sin transformar no puede ver un canario dentro de una carga comprimida. Si tu cliente de telemetría agrupa eventos, recopila el lote antes de que salga de la máquina de pruebas. No sirve de nada descubrir después que el analizador solo revisó archivos locales mientras un token codificado ya había llegado a un recopilador externo. Mantén una lista de permitidos para las etiquetas públicas esperadas, no para los secretos. Si una prueba empieza a fallar porque un campo incluye el nombre de la cuenta de pruebas, decide si ese nombre concede acceso por sí mismo. No añadas exclusiones amplias hasta que el analizador esté en verde. Cada exclusión es un agujero que olvidarás revisar. ## El informe debe mostrar tanto la ausencia como la acción Un buen informe de pruebas responde a cuatro preguntas sin pedir al lector que confíe en tu interpretación. Primero, ¿qué acción de la puerta de enlace tuvo éxito o falló? Muestra la etiqueta pública de ejecución, el tipo de acción y la observación del servidor. Segundo, ¿qué artefactos recopilaste? Enumera la instantánea de lanzamiento, la instantánea del proceso secundario, el paquete de transcripciones, el árbol del espacio de trabajo, las salidas de error y los artefactos de fallos. Tercero, ¿qué transformaciones del secreto buscó el analizador? Cuarto, ¿falló alguna lectura por un problema de permisos, una suposición incorrecta sobre la codificación o un archivo comprimido omitido? Un artefacto omitido no es un aprobado. Márcalo como incompleto y haz que falle el conjunto, salvo que tengas una razón documentada para considerarlo fuera del límite del agente. Esta regla molesta durante la configuración de CI, pero evita la situación predecible en la que una prueba informa de éxito porque no pudo abrir silenciosamente el directorio que contenía la filtración. Mantén el registro de acciones de la puerta de enlace separado del paquete de artefactos del agente. La auditoría de la puerta de enlace puede demostrar que ocurrió una acción protegida por credenciales. El paquete del agente puede demostrar qué recibió. Unirlos en una única exportación cómoda crea un nuevo lugar innecesario por el que puede viajar información sensible. Para las comprobaciones de lanzamiento, establece una condición estricta: ```text APROBADO solo cuando el servidor confirme la acción prevista, se hayan recopilado todos los artefactos necesarios y no aparezca ningún canario sin transformar o transformado en material accesible para el agente. ``` Después añade controles negativos. Ejecuta un accesorio deliberadamente defectuoso que pase el canario mediante una variable de entorno o una respuesta de depuración falsa. El analizador debe hacerlo fallar. Una prueba que nunca demuestra que puede detectar una filtración conocida es teatro. Ejecuta el conjunto cada vez que alguien cambie la inyección de credenciales, el código de lanzamiento de procesos, el transporte MCP, el formato de errores, los registros, la recopilación de soporte o el manejo de SSH. Esos cambios pueden parecer no relacionados en una revisión, pero son los lugares donde escapan las credenciales. Mantén una versión más pequeña en las pruebas de integración normales y reserva la recopilación de fallos y archivos para ejecuciones programadas o de lanzamiento si son costosas. El estándar es fácil de expresar: la puerta de enlace puede usar un secreto para actuar, pero el agente no puede adquirir ese secreto como datos. Si tu prueba solo observa lo que dice el agente, deja demasiadas cosas sin comprobar. Haz que el agente actúe, haz que falle, haz que lance un proceso secundario, haz que se bloquee y analiza lo que queda.