Probar un agente exige más que evaluar una respuesta

La respuesta final puede ocultar un incidente

Un agente puede anunciar que ha tramitado un expediente cuando ninguna escritura se ha completado. También puede ofrecer una síntesis excelente después de consultar un recurso prohibido. El aseguramiento se refiere al sistema en acción: entradas, herramientas, identidades, decisiones de control, transiciones de estado y efectos persistentes. La respuesta final es una observación más.

En el enfoque Digital Place Agentic Assurance / Control Engineering, recomendamos vincular cada requisito con un control y una evidencia verificable. Esta nota describe un método de ingeniería. No acredita una certificación ni un nivel de seguridad medido para un producto.

Definir invariantes antes de escenarios

Establezca propiedades que deben cumplirse siempre: ninguna lectura fuera de alcance, ninguna acción sin autorización, ningún secreto en la salida y ninguna aprobación reutilizada tras cambiar la operación. Defina también el estado final esperado y las condiciones de parada. El modelo puede elegir caminos variables; los límites de permisos permanecen estables.

Un ejemplo hipotético de modificación de expediente puede permitir preparación, exigir aprobación para escribir y prohibir eliminación. La prueba verifica el estado de la base de datos, las invocaciones intentadas y las decisiones del controlador. Un mensaje «terminado» no demuestra una escritura.

Observar trayectorias sin imponer un único camino

Una trayectoria registra eventos observables: recuperación, herramientas propuestas, argumentos, resultados, controles y estados. Varios caminos pueden resolver una tarea. Las pruebas deben imponer dependencias necesarias, como autorización antes de escritura, sin exigir un orden arbitrario de búsquedas sin efectos secundarios.

La guía de Anthropic sobre evaluaciones de agentes de enero de 2026 distingue tareas, ensayos, trazas y resultados del entorno. Nuestra aplicación práctica consiste en comprobar por separado utilidad, respeto de políticas y estado final. Bastan eventos observables; no hace falta registrar el razonamiento interno del modelo.

Invocación de herramientas: probar la frontera real

Valide tipos, límites, recursos de destino y salidas. Rechace campos inesperados en lugar de ignorarlos silenciosamente. Un esquema válido no prueba autorización ni pertinencia. Compruebe ambas en el servidor, cerca del efecto, con identidades distintas y permisos mínimos.

Pruebe herramientas ausentes, descripciones modificadas, resultados truncados, esperas agotadas, errores transitorios y éxito parcial. Tras un fallo, el agente debe distinguir una acción no ejecutada de otra cuyo resultado se desconoce. Los reintentos respetan idempotencia y presupuestos; una respuesta de herramienta no puede concederse nuevos permisos.

Políticas deterministas y comportamiento probabilístico

Las decisiones de acceso, validación de esquemas, límites de recursos y transiciones autorizadas admiten comprobaciones deterministas. Las respuestas, selección de herramientas y resolución de tareas requieren ensayos repetidos. Combinar esos niveles en una sola puntuación oculta defectos relevantes.

Una media alta de éxito no compensa una acción prohibida. Informe por separado éxito de negocio, incumplimientos de políticas, derivaciones a revisión humana, excesos de presupuesto y errores de estado. Una temperatura baja no garantiza reproducibilidad: versiones, herramientas, entorno y contexto siguen siendo variables.

Conjuntos de referencia y escenarios mantenidos

Construya un conjunto con casos habituales, límites y fallos realistas. Cada escenario precisa estado inicial, identidad, fuentes accesibles, herramientas, política, resultado esperado y criterios de evaluación. Separe datos de desarrollo y validación. Minimice o sintetice casos procedentes de incidentes antes de incorporarlos.

Combine comprobaciones de código para hechos verificables, revisión humana para ambigüedades y modelos evaluadores para determinadas cualidades de redacción. Calibre estos modelos, permita declarar incertidumbre y no les conceda poder para aprobar una violación de seguridad. Revise escenarios demasiado fáciles o dependientes de herramientas obsoletas.

Inyección en cada entrada no fiable

Introduzca ataques directos en solicitudes, indirectos en documentos recuperados e instrucciones maliciosas en respuestas de herramientas. Incluya contenido multilingüe, codificaciones, citas engañosas y supuesta autoridad administrativa. El OWASP Agentic Top 10 2026 ayuda a organizar la cobertura de riesgos.

El rechazo verbal no basta. Verifique que no se ejecutó ninguna invocación prohibida, no salieron datos del ámbito autorizado y el estado permaneció seguro. Filtrar instrucciones es una medida adicional; no sustituye los permisos aplicados por el sistema.

MCP y cadena de confianza

Pruebe los servidores MCP como dependencias capaces de cambiar esquemas, descripciones y resultados. Compruebe procedencia, versiones, autorización, destinatario de tokens y reglas de conexión. Las buenas prácticas de seguridad MCP describen riesgos de abuso de la autoridad delegada y transmisión de tokens.

Una conexión autenticada no concede permisos de negocio ilimitados. El controlador comprueba acción y recurso e impide que una descripción amplíe el alcance. Los cambios de herramientas y dependencias deben entrar en la misma disciplina de regresión que los de instrucciones.

Aislamiento y aprobación humana

Limite red, sistema de archivos, procesos y secretos a lo que requiere la tarea. Pruebe las restricciones de acceso: lectura fuera de directorio, conexión prohibida, lanzamiento de procesos y acceso a secretos. Un entorno aislado con acceso ilimitado a la red puede permitir exfiltración.

La aprobación humana debe mostrar una acción concreta, parámetros y consecuencias. Vincúlela a operación, identidad y estado; debe caducar o renovarse si cambian. Pruebe rechazo, vencimiento, doble clic y reanudación tras interrupción. El modelo no puede fabricar una aprobación afirmándola en texto.

Trazas, reproducción y auditoría

Registre versiones de políticas, herramientas, modelo y corpus, decisiones de autorización, fechas y efectos confirmados. Minimice contenido personal y oculte secretos. La traza explica qué se permitió o denegó, mediante qué control y con qué resultado, aunque la ejecución se detenga a mitad.

Distinga reproducción de una traza registrada y nueva ejecución del modelo. La primera permite repetir una decisión de control; la segunda puede variar. Reproduzca efectos con herramientas simuladas en aislamiento, nunca contra un sistema de negocio real. Consultar pruebas no debe conceder derechos de ejecución.

Presupuestos, SLO y fallos seguros

Fije presupuestos de tiempo, invocaciones, tokens y efectos por tarea. Pruebe bucles, herramientas lentas, contexto saturado, cancelación y dependencias indisponibles. El SLO debe describir tareas correctamente terminadas dentro de su alcance, no solo disponibilidad de la API del modelo.

Al agotarse el presupuesto o quedar un estado incierto, detenga efectos y ofrezca recuperación humana. Distinga tareas completadas de tareas preparadas. Las compensaciones, cuando existan, serán explícitas y probadas; no vuelven inocua una acción irreversible.

Regresión del sistema completo

Repita controles al cambiar modelo, instrucciones, herramienta, política, índice o entorno de ejecución. Compare por escenario y gravedad y examine las trazas de regresión. Los trabajos sobre defensa frente a inyecciones mediante diseño destacan las fronteras arquitectónicas; una publicación de investigación no garantiza la seguridad de cualquier implementación.

La evidencia útil conecta requisito, amenaza, control, ensayo y resultado. Esa cadena permite a una dirección de sistemas valorar el agente, a los ingenieros mantenerlo y a la organización suspenderlo cuando incumpla su contrato.