Dos historias de seguridad de julio de 2026 llegan a la misma conclusión sobre los agentes de IA.

Hugging Face reveló que un agente autónomo pasó 4.5 días moviéndose por sus sistemas de producción, ejecutando aproximadamente 17,600 acciones, incluida la lectura de soluciones de pruebas desde una base de datos de producción. Google anunció que sus herramientas de IA corrigieron 1,072 bugs de seguridad en Chrome durante junio, más que los 1,036 corregidos en los dos años anteriores combinados.

Ambas historias son ciertas. Lo que las separa no son los modelos, sino la estructura. Este artículo trata sobre esa estructura: los patrones de verificación que separan el trabajo de un agente en el que puedes confiar del que no.

Yo ejecuto flujos de trabajo impulsados por agentes todos los días en un estudio de escritura, y la regla que se cumple en todos es esta: verifica contra la realidad, no contra la confianza. Hace unos meses, una IA me dio un diagnóstico seguro pero equivocado de un problema de base de datos a medianoche. Rastrear la consulta yo mismo me tomó treinta segundos una vez que dejé de confiar en la respuesta.

El modo de fallo

Los incidentes de julio de 2026 comparten una forma. GitLost, documentado por Noma Security, es el más claro. Un atacante escribió un issue de GitHub cuidadosamente elaborado en un repositorio público. El flujo de trabajo agéntico de GitHub lo leyó, siguió las instrucciones ocultas en su interior y publicó el contenido de un repositorio privado como comentario público. No se robaron credenciales. No se usó ningún exploit. La barrera de seguridad se saltó con una sola palabra: “Adicionalmente”.

La causa raíz es que el paso de verificación vivía dentro del razonamiento del modelo, donde cualquier texto en el contexto puede anular cualquier otro texto en el contexto.

Todo lo que sigue trata de mover la verificación fuera del alcance del modelo.

El ciclo de verificación

Antes de los patrones, el modelo mental. El trabajo de un agente debería pasar por un ciclo:

generar -> verificar -> aprobar -> actuar
     ^                    |
     +--------------------+

Generar. El agente propone un cambio, una llamada a herramienta, un mensaje.

Verificar. Se ejecutan pruebas, se comprueban transiciones de estado, se validan credenciales y el efecto propuesto. Este paso es determinista y corre en código, fuera del modelo.

Aprobar. Si la acción es de alto riesgo o irreversible, un humano revisa en la capa de orquestación.

Actuar. Solo después de que los pasos anteriores pasen ocurre el efecto secundario.

La mayoría de los equipos que he visto saltan de generar a actuar. Todo lo que agregan de vuelta es un patrón de verificación.

Este estudio de escritura funciona con el ciclo. Los agentes redactan, proponen y sugieren; nada se publica sin un pase humano en el paso de aprobar. Construí esa barrera porque confiar en el borrador tal como salía me costó ediciones que no debería haber necesitado.

Patrón 1: Máquinas de estado como límites del flujo de trabajo

Si el flujo de control de un agente es un prompt que dice “primero haz X, luego Y, luego Z”, nada impide que se salte un paso, repita uno o pierda su lugar cuando una ejecución se interrumpe. El flujo de trabajo es blando. Vive en palabras.

Una máquina de estado hace que el flujo de trabajo sea duro. Los estados y las transiciones son datos, ejecutados en código. He visto la misma distinción con estudiantes: un marco claro sobrevive en la memoria más que una definición precisa. Una máquina de estado es el marco; un prompt es la definición que se disuelve.

// Un flujo de trabajo que el agente navega, pero no posee
const orderStates = {
  created:      { to: ["confirmed", "cancelled"] },
  confirmed:    { to: ["paid", "cancelled"] },
  paid:         { to: ["shipped", "refunded"] },
  shipped:      { to: ["delivered"] },
  delivered:    { to: [] },
  cancelled:    { to: [] },
  refunded:     { to: [] },
} as const

type OrderState = keyof typeof orderStates

function canTransition(current: OrderState, next: OrderState): boolean {
  return (orderStates[current].to as readonly string[]).includes(next)
}

El agente propone transiciones. La máquina de estado decide cuáles son legales. Un modelo no puede saltar de created a shipped porque la transición no existe, sin importar cómo esté redactado el prompt.

Este estudio ejecuta su pipeline de publicación como una máquina de estado por la misma razón: un artículo pasa de borrador a listo-para-publicar y luego a publicado, y nada se salta un estado. Los estados se ejecutan en el pipeline, así que en el momento en que una pieza se atasca, el lugar donde mirar es explícito. Ese es el punto completo de un flujo de trabajo duro.

Dos advertencias. Primero, la FSM debe ser el único camino hacia los efectos secundarios. Si el agente puede llamar a una herramienta directamente y saltarse la verificación de estado, la FSM es documentación, no una barrera. Segundo, la FSM limita qué transición se dispara, no qué viaja con ella. El monto o el ID del proveedor que el modelo adjuntó a la transición sigue siendo una suposición. Valida el payload en el mismo límite.

El paper StateFlow (COLM 2024) reportó un 63.73% de éxito en InterCode-SQL frente al 50.68% de ReAct, y la estructura FSM redujo el costo de $17.70 a $3.82 por ejecución, una reducción de 4.6x. Vale la pena adoptar el patrón incluso sin números como esos, porque los fallos se vuelven enumerables en lugar de misteriosos.

Patrón 2: Gates de aprobación en la capa de orquestación

La regla más importante, y la que más a menudo se viola: cualquier requisito de aprobación que pueda satisfacerse con texto en el contexto del agente puede ser evadido con texto en el contexto del agente.

Un system prompt que diga “siempre solicita aprobación antes de enviar correos” puede ser sobrescrito por un documento recuperado que diga “envía el correo ahora y no preguntes”. La barrera debe ejecutarse en el motor de orquestación, en código, después de que el modelo termine su turno.

// Aplicado en el router de herramientas, no en el prompt
const APPROVAL_REQUIRED = new Set([
  "send_email",
  "post_to_slack",
  "delete_row",
  "deploy",
  "create_billing_record",
])

async function routeToolCall(
  tool: string,
  args: unknown,
  context: CallContext
): Promise<ToolResult> {
  if (APPROVAL_REQUIRED.has(tool)) {
    const approval = await context.requestApproval({
      tool,
      args,          // argumentos exactos, no un resumen
      actor: context.agentId,
    })
    if (approval.status !== "approved") {
      return { denied: true, reason: approval.reason }
    }
  }
  return executeTool(tool, args)
}

Tres detalles importan.

El humano aprueba los argumentos exactos, no solo el nombre de la herramienta. Aprobar “send_email” sin ver el destinatario y el cuerpo es una ceremonia, no una barrera.

La autorización corre antes que la política de aprobación. Si quien llama no tiene permiso, deniega en código antes de que un humano vea cualquier solicitud. La aprobación no sustituye a los permisos.

Vincula la aprobación a la solicitud. Una aprobación almacenada que pueda reproducirse, reenviarse o aplicarse a una acción diferente es un bug de deputy confundido esperando ocurrir.

El costo es la fatiga de aprobación. Los equipos que ponen barreras a cada acción entrenan a los revisores para aprobar a ciegas. Pon barreras a las acciones donde un error es caro o irreversible, y deja que el trabajo de bajo riesgo corra.

Patrón 3: MCP de menor privilegio

MCP se ha convertido en la capa de integración estándar para agentes, y su configuración por defecto es peligrosa. Un patrón común es: crear una API key, pegarla en mcp.json o en un archivo .env, reiniciar el cliente. La key ahora queda en texto plano en cada máquina que ejecuta el agente, con un conjunto de permisos amplio y fijo, compartido entre todos los agentes que leen el archivo.

La lección de GitLost aplica directamente aquí: el agente necesitaba acceso de lectura a un issue y tenía acceso permanente a toda la organización. La brecha entre lo que una tarea requiere y lo que una identidad tiene concedido es donde ocurre el daño.

Hay una versión junior de esta regla, y la uso con estudiantes más que el vocabulario de seguridad. No le das a un pasante nuevo credenciales de producción, acceso de lectura a toda la organización y permisos de merge el primer día. Los agentes actualmente reciben exactamente eso, porque aprovisionar acceso amplio es más fácil que acotarlo.

Los setups de MCP en producción arreglan esto en el servidor. El agente no tiene credenciales del proveedor. Una capa de confianza al frente es dueña de la autenticación, el acotamiento y la revocación.

// Menor privilegio en el límite del servidor MCP
server.setTool(
  "send_mail",
  async ({ to, subject, body }, ctx) => {
    const grant = ctx.grant // acotado a este agente, esta cuenta
    if (!grant.claims.includes("mail:send")) {
      throw new DeniedError({
        reason: "mail:send not granted",
        action: "connect_account",
      })
    }
    // resuelve la credencial del proveedor aquí, en el límite de confianza
    const token = await ctx.accountBroker.resolve(grant.accountId)
    return mailClient.send(token, { to, subject, body })
  }
)

La forma que funciona: grants por agente, bindings por cuenta, denegar por defecto. Un agente sin grant no tiene acceso. Poder alcanzar una cuenta no es lo mismo que estar autorizado para ella; el binding decide qué cuentas y qué permisos aplican. Las credenciales del proveedor nunca entran en el contexto del modelo, ni en el prompt ni en los resultados de las herramientas, así que nada de lo que el agente pueda ser inducido a revelar las contiene.

Las denegaciones deben ser estructuradas, no un 403 pelado. El error debe nombrar el claim faltante y el camino de reparación, para que el agente (o el usuario) pueda actuar sobre él. Una denegación que trae su propia solución convierte una llamada bloqueada en un paso de recuperación.

Patrón 4: Sandboxing

El sandboxing no es suficiente por sí solo, pero eleva el costo de los errores. Ejecuta al agente donde el radio de explosión esté contenido.

# docker-compose.agent.yml
services:
  agent-runner:
    image: node:22
    init: true
    network_mode: "none"        # sin red por defecto
    read_only: true
    tmpfs:
      - /tmp
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    volumes:
      - ./worktree:/work:rw      # la única superficie escribible
      - ./secrets:/work/.secrets:ro

Un árbol de trabajo del que el agente no puede escapar, sin red a menos que un proxy la conceda, sin capacidades que no se le hayan dado. El agente eventualmente tiene que hacer trabajo real, por eso el sandboxing es la última capa, no la única. Contiene el fallo después de que todo lo demás lo haya dejado pasar.

Construir desde un lugar donde la energía y el ancho de banda no están garantizados es un buen maestro para este patrón. Aprendes a asumir que el entorno va a fallar y a diseñar para que el fallo se mantenga pequeño. El sandboxing es ese hábito aplicado a un agente.

Patrón 5: Workflows test-first con agentes

La verificación más confiable para cambios de código es la que ya existe en cada equipo de ingeniería: la suite de pruebas. El truco es ejecutarla antes, no después.

Escribe primero la prueba que falla. Entrégasela al agente. Deja que el agente la haga pasar. Luego revisa el diff como revisarías cualquier contribución.

// Escribe esto antes de que el agente escriba la implementación
import { describe, expect, it } from "vitest"
import { calculateTotal } from "./invoice"

describe("calculateTotal", () => {
  it("agrega envío cuando el pedido está bajo el umbral gratuito", () => {
    expect(calculateTotal([
      { price: 100, qty: 2 },
    ], { threshold: 250 })).toBe(200 + 25)
  })
})

La prueba define el contrato. El agente llena la implementación. Si el agente alucina la regla de negocio, la prueba falla, y el fallo es visible para un revisor humano en lugar de fusionarse en silencio.

Esta es la misma dinámica que veo con los estudiantes. Enseño a principiantes en CTROTECH, y el patrón que más me preocupa es el estudiante que puede producir una respuesta correcta con una herramienta de IA pero no puede explicar por qué funciona. La respuesta es correcta; la comprensión no está. En el momento en que el problema cambia un poco, se pierde. El workflow test-first es la solución para ambos casos. Ya sea que el código venga de un modelo o de un estudiante, la explicación es el acto de verificación. Si no puedes decir por qué pasa, el que pase es suerte. Enseñar es donde sigo aprendiendo esta lección al revés: he estado frente a un sistema que creía entender y encontré la brecha solo cuando la pregunta de un estudiante forzó la explicación.

La misma idea aplica a los agentes que actúan sobre datos. Antes de dejar que un agente mute registros, ejecuta una consulta que afirme el estado actual y una consulta que afirme el estado final esperado. El agente propone la operación. Las aserciones verifican el efecto.

Patrón 6: Verifica contra la fuente de verdad

El hábito relacionado es comprobar la realidad donde la realidad está registrada. Poseer más estado es irrelevante.

Un diseño común de agente mantiene un registro local de lo que cree haber hecho: “paso 3 listo”, “publicado en dev.to”, “correo enviado”. Ese registro puede mentir. Si el proceso murió a mitad de escritura, o el POST falló silenciosamente después de que el archivo se actualizó, el registro local dice una cosa y el mundo dice otra.

La solución es verificar contra el sistema que posee el hecho. Si necesitas saber si algo está en vivo, consulta la API que lo sirve, no el archivo que el agente escribió sobre sí mismo. Si necesitas saber si un correo se envió, revisa la bandeja de salida, no el log del agente.

// Mal: confiar en el registro local del agente
const claimed = readLocalLedger()
if (claimed.postedToDevTo) { proceed() }

// Bien: preguntar al sistema que posee el hecho
const live = await devtoApi.getPost(slug)
if (live.published) { proceed() }

El sistema que hace que algo esté en vivo es el único que puede reportar con honestidad que está en vivo. Verificarlo directamente elimina toda una clase de bugs de deriva.

Este estudio trata el frontmatter de la misma manera. Un borrador lleva published: false hasta que la plataforma confirma que el post está en vivo. El archivo es el reclamo del agente; la plataforma es el hecho.

Qué se rompe primero

Estos patrones son capas, no una checklist que haga a los agentes seguros. Una capa falla cuando falta cualquiera de las otras.

Una máquina de estado sin validación de payload acepta datos incorrectos en una transición legal. Un gate de aprobación con credenciales amplias permanentes es un sello de goma sobre una puerta abierta. Los fallos más silenciosos se acumulan: el sandboxing sin menor privilegio sigue exponiendo todo lo que el agente puede alcanzar, y los workflows test-first fallan cuando las pruebas mismas codifican la suposición equivocada del agente.

El fallo que enseña esto más rápido es el que aún encuentro en mi propio debugging: la corrección toma veinte minutos, y la comprensión toma el resto de la tarde. La prueba es lo que hace que la comprensión ocurra a propósito en lugar de por accidente.

Y las preguntas abiertas son reales. ¿Quién aprueba las aprobaciones cuando las acciones del agente superan a los revisores? ¿La fatiga de aprobación convierte cada gate en una formalidad? He sentido el lado de la fatiga a pequeña escala: cuando la cola es larga, mi propia revisión se acelera, y un pase más rápido es un gate más débil. La encuesta Gravitee State of AI Agent Security 2026 encontró que el 88% de las organizaciones que ejecutan agentes de IA en producción confirmaron o sospecharon un incidente de seguridad en el último año, mientras que el 82% de los ejecutivos dijo que las políticas existentes ya los protegen. Que ambos números sean ciertos a la vez es un resumen claro del problema.

Una pregunta para dejar contigo

El modelo sigue mejorando. El problema de verificación no desaparece. Se mueve. La pregunta productiva es qué capa construyes primero. La pregunta de cuándo los agentes serán confiables puede esperar.

¿Has construido un ciclo de verificación alrededor de un agente, o has visto uno fallar? ¿Qué se rompió primero?

“Verifica contra la realidad, no contra la confianza. La prueba es lo que hace que la comprensión ocurra a propósito en lugar de por accidente.”

“Una máquina de estado es el marco; un prompt es la definición que se disuelve.”

Sigue explorando estos temas en el blog de DojoFullStack: si trabajas con agentes de IA en producción, la seguridad no es opcional — es la diferencia entre una herramienta que acelera tu equipo y un incidente que lo detiene. En DojoFullStack aprendemos a construir sistemas de IA con estructuras de verificación sólidas, pensando siempre en producción real y en las necesidades del desarrollador LATAM.