Los agentes de IA están por todas partes. Reservan vuelos, envían correos, procesan pagos y acceden a tu repositorio de código. Pero hay una pregunta que casi nadie hace:

¿Quién autoriza qué agente puede hacer qué?

La mayoría usa API keys. Y una API key es binaria: la tienes o no la tienes. Si la key de tu agente financiero se filtra, alguien puede vaciar tu cuenta. Si tu agente de code review es comprometido, puede empujar commits maliciosos. No hay punto intermedio.

Yo me estrellé contra esta pared mientras construía prototipos de agentes. Así que construí algo para arreglarlo.

“Una API key no sabe qué agente está llamando, qué está haciendo ni cuándo debería dejar de funcionar.”

Qué construí

Agent Firewall es una capa de seguridad basada en capacidades para agentes de IA. Te da permisos granulares, firmados criptográficamente, con seguimiento completo del ciclo de vida.

En lugar de entregar a un agente una key que desbloquea todo, le entregas una capacidad:

from agent_firewall import FirewallSDK

sdk = FirewallSDK(
    revocation_store_path="revocations.db",
    lifecycle_store_path="lifecycle.db",
)

capability = sdk.issue(
    private_key=private_key,
    agent="finance-agent",
    capability="payments.send",
    constraints={
        "amount_max": 100,
        "expires_at": "2026-08-30T00:00:00Z"
    },
)

Ese agente ahora puede enviar pagos — pero solo montos menores a 100, y solo hasta el 30 de agosto. Si revocas la capacidad, muere al instante. Si alguien reproduce una solicitud antigua, es rechazada.

Por qué las capacidades ganan a las API keys

La diferencia no es cosmética, es estructural:

API Keys:

  • Acceso binario (todo o nada)
  • Sin expiración incorporada
  • No se pueden acotar
  • Sin rastro de auditoría
  • Si se filtran, game over

Capacidades:

  • Permisos granulares
  • Con límite de tiempo por defecto
  • Se pueden atenuar (reducir autoridad sin incrementarla)
  • Ciclo de vida completo: ISSUED → USED → REVOKED → EXPIRED
  • Revocables individualmente

El ciclo de vida de una capacidad

Cada capacidad en Agent Firewall tiene un ciclo de vida explícito:

ISSUED
↓
DELEGATED
↓
ATTENUATED
↓
USED
↓
REPLAYED
↓
REVOKED
↓
DENIED
↓
EXPIRED

Esto no es solo logging: es estado de seguridad. Puedes consultar si una capacidad fue usada, reproducida o revocada. Puedes delegar una capacidad a otro agente con autoridad reducida (tu agente financiero delega payments.send con amount_max=50 a un sub-agente). Puedes atenuarla tú mismo.

Y en v0.8, todo esto persiste en SQLite. Reinicia tu servicio y el registro de revocaciones y el historial de ciclo de vida sobreviven.

Límites del mundo real

Agent Firewall no es solo una librería: es una capa de frontera.

Frontera HTTP: mapea las solicitudes entrantes a namespaces de capacidades.

POST /payments/refund
↓
http.POST.payments.refund

Frontera MCP: autoriza las llamadas de herramientas del Model Context Protocol antes de ejecutarlas.

Ambas fronteras verifican la capacidad, la vinculan a la identidad del agente, revisan las restricciones y aplican protección contra replay antes de permitir la ejecución.

La historia detrás

Hace seis meses estaba construyendo modelos de detección de COVID para tareas universitarias. ML estándar de pregrado.

Luego empecé a jugar con agentes de IA — LangChain, CrewAI, AutoGen — y me topé una y otra vez con el mismo problema: estos agentes tienen demasiado poder por defecto. Una API key no sabe qué agente está llamando, qué está haciendo ni cuándo debería dejar de funcionar.

Así que profundicé en la seguridad basada en capacidades — un modelo de la investigación en sistemas operativos donde los permisos son tokens infalsificables que se pueden delegar y atenuar. Construí Agent Firewall para traer ese modelo a la era de los agentes.

Hoy tiene 1,438 tests pasando, incluyendo cobertura de regresión adversarial. Tiene documentación de arquitectura y un modelo de amenazas. Y ayer publiqué v0.8 con persistencia de ciclo de vida respaldada por SQLite.

Hacia dónde va

v1.0 es el siguiente hito: congelar la API, publicar documentación completa y llevarlo a producción. El objetivo es simple:

Todo agente de IA que llame a una herramienta debería tener una capa de autorización que entienda quién, qué y cuándo.

El repo está en github.com/Shubhbhangoo/agent-firewall/tree/v0.8. Si estás construyendo agentes que llaman herramientas — pagos, APIs, bases de datos, lo que sea — la retroalimentación es bienvenida. Abre un issue, un PR o cuéntanos cómo luce hoy tu setup de autorización.

En DojoFullStack sabemos que la seguridad de los agentes no es un extra: es la diferencia entre una automatización que escala y un pasivo financiero esperando a explotar. Sigue explorando estos temas en el blog de DojoFullStack.