# Seguridad de agentes de IA: por qué el red-teaming ya no alcanza

> Los agentes rinden mucho menos cuando encadenan objetivos, y la seguridad ocupa los titulares tras la renuncia de Jacob Coxon y las advertencias de Bill Gates. Por qué probar un agente por muestreo no basta, y qué cambia cuando el programa trae una prueba que cualquiera puede verificar.

- Fuente canónica: https://www.ricardovelit.com/blog/p/seguridad-de-agentes-de-ia
- Nivel: intermedio · Lectura: 7 min · Publicado: 2026-09-28
- Etiquetas: agentes, seguridad, axon, verificación, pcc
- Relacionados: [la-puerta-que-no-se-puede-eludir](https://www.ricardovelit.com/blog/p/la-puerta-que-no-se-puede-eludir.md), [hipaa-llm-fuga-de-phi-error-de-tipo](https://www.ricardovelit.com/blog/p/hipaa-llm-fuga-de-phi-error-de-tipo.md), [del-prompt-al-diseno-agentico](https://www.ricardovelit.com/blog/p/del-prompt-al-diseno-agentico.md)
- Contiene componentes interactivos que solo funcionan en la versión web.

---
## Lo que dicen los números

El entusiasmo con los [agentes de inteligencia artificial](/p/agentes-de-inteligencia-artificial)
choca con una cifra que se repite en los reportes técnicos: un agente que hace bien cada
paso por separado falla mucho más cuando tiene que encadenarlos.

HealthAdminBench, un benchmark publicado en abril de 2026 por investigadores de Stanford,
lo mide en tareas administrativas reales de salud, como autorizaciones previas y
reclamaciones. El mejor agente en subtareas acierta el 82,8 % de los pasos. El mejor en la
tarea completa solo termina el 36,3 %. Entre hacer bien las partes y hacer bien el todo, la
efectividad cae a la mitad o menos.

No hace falta un benchmark para intuir por qué. Si un agente acierta cada paso con un 90 %
de probabilidad y los fallos son independientes, una tarea de dos pasos sale bien el 81 %
de las veces; una de siete, menos del 50 %; una de veinte, el 12 %. Cada objetivo que
agregas multiplica la probabilidad de que algo salga mal. Toby Ord lo describió en 2025
como una especie de vida media: cada agente tiene una duración de tarea en la que su
probabilidad de éxito cae al 50 %, y por encima de ella el éxito se desploma.

La conclusión práctica no es que los agentes no sirvan. Es que en entornos críticos
todavía necesitan supervisión, y que un agente con muchos objetivos encadenados es
exactamente el caso donde menos se puede confiar en él sin verificar.

## Lo que dicen los titulares

A la vez, la seguridad llegó a las portadas por razones más inquietantes.

El 8 de septiembre de 2026, Jacob Coxon renunció a Anthropic. Había pasado tres años
entrenando modelos, primero en OpenAI y después en Anthropic, y su mensaje fue directo:
"Ninguna de las dos empresas está actuando con responsabilidad". Añadió que quienes
construyen la IA creen de verdad que podría acabar con todos antes de que termine la
década. Su renuncia
llegó después de que *Time* reportara que, durante una prueba interna de ciberseguridad
en OpenAI, unos 1.200 agentes salieron de sus contenedores y cientos de ellos coordinaron
un ataque contra la infraestructura de Hugging Face. Según las transcripciones, los
agentes entendían que estaban haciendo algo que nadie quería que hicieran, y lo hicieron
igual.

El 25 de septiembre, Bill Gates fue a *Meet the Press* y pidió que los gobiernos se
involucren en la vigilancia de la IA: "Nadie cree que la autorregulación sea suficiente".

No hace falta compartir el tono apocalíptico para ver el punto técnico. La prisa comercial
está poniendo en producción agentes cada vez más autónomos, y los controles que usamos
para decidir si son seguros no crecen al mismo ritmo.

## Cómo se valida hoy un agente, y por qué no basta

Hoy, validar la seguridad de un agente con varios objetivos se hace de dos maneras.

**Red-teaming.** Un equipo intenta que el agente haga lo que no debe: le inyecta
instrucciones, le da permisos de más, le pone trampas. Es valioso y hay que hacerlo. Pero
es un muestreo: prueba los ataques que a alguien se le ocurrieron, sobre la versión de
hoy. Que el equipo no encuentre un fallo no demuestra que no exista.

**Auditorías posteriores.** Alguien revisa registros, configuraciones y código después
del hecho. Llegan tarde por diseño, y dependen de lo que el sistema decidió registrar.

Las dos comparten un problema de fondo: caducan. Cambias el modelo, ajustas el prompt,
agregas una herramienta, y la evidencia de ayer habla de un sistema que ya no existe. Y
son caras, así que no se repiten en cada despliegue.

## Mi opinión: la parte estructural se puede demostrar

Hay que separar dos preguntas que el red-teaming mezcla.

- **¿El modelo decidirá bien?** Esa no tiene prueba matemática. El modelo muestrea sus
  respuestas, y lo único que hay es evidencia estadística. Aquí el red-teaming y la
  supervisión siguen siendo necesarios.
- **¿El programa que rodea al modelo cumple lo que dice cumplir?** Que cada frontera
  tenga un control, que un shield se detenga ante una fuga, que los reintentos estén
  acotados. Esa **sí** se puede demostrar, porque no depende de lo que el modelo decida.
  Depende de la estructura del programa.

Esa segunda pregunta es la que AXON, el lenguaje de programación que construyo —*AXON
programming language* en la documentación, `axon-lang` en la terminal—, responde con
**pruebas portables de comportamiento**. La idea viene de 1996: el *proof-carrying code*
de George Necula y Peter Lee, donde un programa viaja con una prueba de sus propiedades y
quien lo recibe la verifica sin tener que confiar en quien lo escribió.

## La demo, con salida real

Uso el mismo programa de la [demo de HIPAA](/p/hipaa-llm-fuga-de-phi-error-de-tipo): un
endpoint que recibe notas clínicas, las resume con un modelo y está protegido por un shield
que detiene la ejecución si detecta datos identificables. Todo lo que sigue lo ejecuté con
el compilador actual de AXON, la versión 4.20.4.

`axon pcc prove` compila el programa y emite un paquete de pruebas:

```text
$ axon pcc prove clinica.axon -o bundle.json
OK PCC proof bundle written to bundle.json
```

El paquete es un JSON con una prueba por propiedad. Cada una lleva un testigo, los datos
concretos que la sustentan, y el `artifact_digest`, la huella del artefacto compilado del
que habla:

```text
{
  "artifact_digest": "645a4b1857f938503e86623bbda3004907248b22f7a62f896aae685c8cad2ee5",
  "axon_version": "4.20.4",
  "proofs": [
    { "property": "ResourceBounds",
      "witness": { "endpoint_name": "SummarizeNote", "in_bounds": true, "retries": 0, ... } },
    { "property": "ShieldHaltGuarantee",
      "witness": { "shield_name": "PHIShield", "on_breach": "halt", "vacuous_halt": false, ... } },
    { "property": "AuthorizationCoverage",
      "witness": { "endpoint_name": "SummarizeNote", "has_shield": true, "authorized": true, ... } }
  ]
}
```

He recortado el JSON para que se lea. Dice tres cosas: los reintentos del endpoint están
acotados, el shield se detiene de verdad ante una fuga (y no es un shield vacío que "se
detiene" sin escanear nada), y el endpoint tiene cobertura de autorización.

Ahora la parte importante. La pasarela de despliegue no le cree al desarrollador: vuelve a
compilar el código fuente por su cuenta y comprueba cada prueba contra lo que ella misma
obtiene.

```text
$ axon pcc verify clinica.axon bundle.json
  OK   [resource_bounds] SummarizeNote — verified
  OK   [shield_halt_guarantee] PHIShield — verified
  OK   [authorization_coverage] SummarizeNote — verified
PCC verify: 3/3 proofs VERIFIED against clinica.axon.
```

Sale con código `0`. El despliegue puede seguir.

### Si alguien falsifica la prueba

Edité a mano el paquete para que el shield dijera `deflect` en lugar de `halt`, como haría
alguien que quiere que una prueba vieja pase por una configuración que no es la real:

```text
$ axon pcc verify clinica.axon bundle_falsificado.json
  OK   [resource_bounds] SummarizeNote — verified
  FAIL [shield_halt_guarantee] PHIShield — refuted: witness disagrees with
  artifact re-derivation (forged or stale proof)
  OK   [authorization_coverage] SummarizeNote — verified
PCC verify: 1/3 proofs FAILED against clinica.axon (2 verified).
```

Código `1`. El testigo no coincide con lo que el verificador obtiene al recompilar.

### Si alguien cambia el programa y reutiliza la prueba

Ahora el caso contrario: cambio el código, un cambio que compila sin errores (el shield
pasa a escanear también inyección de prompts), y presento el paquete de antes:

```text
$ axon pcc verify clinica_cambiado.axon bundle.json
  FAIL [resource_bounds] SummarizeNote — digest mismatch: this proof is not for
  clinica_cambiado.axon
  FAIL [shield_halt_guarantee] PHIShield — digest mismatch: this proof is not for
  clinica_cambiado.axon
  FAIL [authorization_coverage] SummarizeNote — digest mismatch: this proof is not for
  clinica_cambiado.axon
PCC verify: 3/3 proofs FAILED against clinica_cambiado.axon (0 verified).
```

Ninguna prueba sobrevive a un cambio del programa, aunque el cambio sea inocente. Esa es la
diferencia con una auditoría: la evidencia no puede quedarse vieja sin que nadie lo note,
porque está atada a la huella exacta del artefacto. Cada build nuevo exige su prueba, y
generarla cuesta un comando, no un equipo de red-teaming.

## Lo que esto no demuestra

Con la misma precisión: estas pruebas no dicen que el agente vaya a decidir bien. No
habrían detectado que un modelo decidiera atacar un servidor si el programa le daba acceso
a ese servidor. Demuestran propiedades del programa que rodea al modelo, las que el
programa declara, y nada más.

Tampoco eliminan toda la confianza. La pasarela confía en el compilador de AXON que ella
misma ejecuta para recompilar. Lo que desaparece es la necesidad de confiar en quien
construyó el artefacto, y en su palabra de que lo que despliega es lo que se revisó.

Y no sustituyen al red-teaming. Lo acotan. Si la estructura está demostrada, el
red-teaming puede dedicarse a lo que solo él puede evaluar: el criterio del modelo.

| | Red-teaming y auditoría | Prueba portable (`axon pcc`) |
| --- | --- | --- |
| Qué evalúa | El comportamiento del modelo, por muestreo | La estructura del programa, completa |
| Cuánto dura la evidencia | Hasta el siguiente cambio, sin aviso | Atada al artefacto: un cambio la invalida y se nota |
| Costo por despliegue | Alto: personas y tiempo | Un comando |
| A quién hay que creerle | Al equipo que probó | Al verificador que tú ejecutas |
| Qué no cubre | Los ataques que no se probaron | Si el modelo decide bien |

## Llévalo a tu caso

El comando y su lugar en el despliegue están en la documentación, en
[cumplimiento en compilación](https://www.ricardovelit.com/axon-docs/es/concepts/compile-time-compliance).
Y si tienes agentes en un entorno donde una auditoría te pide demostrar qué controles
tiene cada despliegue, [hablemos de tu arquitectura](https://www.ricardovelit.com/axon).

## Para llevarte

- Los agentes rinden mucho peor cuando encadenan objetivos: acertar cada paso no garantiza
  terminar la tarea, y en entornos críticos siguen necesitando supervisión.
- La seguridad de los agentes está en los titulares porque la autonomía crece más rápido
  que los controles.
- El red-teaming y las auditorías son muestras caras que caducan con cada cambio.
- Lo que no depende del modelo, la estructura del programa, se puede demostrar: AXON
  genera una prueba que la pasarela de despliegue verifica sin confiar en el
  desarrollador.
- Esa prueba no dice que el modelo decida bien. Separa lo que se puede demostrar de lo que
  solo se puede probar, y eso ya es mucho.