Los agentes de IA se están convirtiendo en participantes activos de los sistemas de software. Leen issues, abren pull requests, consultan bases de datos, llaman APIs SaaS, programan tareas y disparan automatizaciones. Eso significa que necesitan modelos de identidad y autorización tan bien diseñados como los que usamos para personas y servicios backend.
Durante años, los sistemas backend separaron a los actores en dos grupos: personas y servicios. Las personas iniciaban sesión con cuentas de usuario. Los servicios usaban claves de API, cuentas de servicio, clientes OAuth o identidad de workload. Los agentes de IA rompen esa frontera porque se comportan como servicios, pero muchas veces actúan en nombre de una persona y dentro de un contexto que cambia con cada tarea.
Un agente que resume logs quizá solo necesita lectura. Cinco minutos después, ese mismo agente puede intentar crear un ticket de incidente, rotar una credencial o disparar un despliegue. Si el sistema lo trata como una cuenta de servicio administrativa permanente, cada llamada nace con demasiados privilegios. Si lo trata como una sesión normal de usuario, pierde la capacidad de distinguir intención humana de ejecución autónoma.
En 2026, esto dejó de ser un ejercicio teórico de arquitectura. NIST lanzó una iniciativa de estándares para agentes de IA centrada en ecosistemas seguros e interoperables. NIST también publicó un resumen de respuestas sobre seguridad de agentes de IA, donde hubo amplio acuerdo en que los agentes introducen riesgos nuevos y que las prácticas tradicionales de ciberseguridad necesitan adaptarse.
Para quienes construyen backend, la conclusión práctica es clara: el acceso de agentes no puede improvisarse. Cuando un agente tiene acceso a herramientas, tus APIs deben saber quién es el agente, a quién representa, qué puede hacer y cómo revocar esa autoridad cuando la tarea termina.
OAuth es útil porque modela autorización delegada. Un usuario o sistema concede a un cliente acceso limitado a un resource server. Eso encaja bien con flujos de agentes, siempre que la implementación no convierta OAuth en un contenedor de permisos amplios y de larga duración.
En un flujo delegado por una persona, el agente normalmente debería recibir un token estrecho, temporal y vinculado a una tarea. En flujos de agentes en segundo plano, client credentials o workload identity pueden tener sentido, pero también necesitan alcances, restricciones de política y trazabilidad. La clave es evitar un único "token del agente" capaz de leer y escribir todo.
Un buen modelo de identidad para agentes registra más de un actor. Debe capturar la persona solicitante, la instancia del agente, la herramienta o servidor MCP usado, la API destino y la decisión de política que permitió la acción. Es parecido al tracing distribuido: una petición pasa por varios sistemas, pero el trace mantiene conectada la historia.
Esta identidad por capas importa mucho durante una respuesta a incidentes. Si cambia una fila de la base de datos, el log no debería decir solo "service-account-agent-prod actualizó la fila 123". Debería responder: qué usuario inició la tarea, qué agente generó la acción, qué permiso fue concedido, qué herramienta la ejecutó y si el resultado coincide con el plan aprobado.
El lugar más seguro para aplicar autorización de agentes no es el prompt. Los prompts pueden describir reglas, pero la aplicación real pertenece al código. Un gateway de políticas se ubica entre el agente y las herramientas. Recibe llamadas propuestas, las evalúa contra políticas, solicita aprobación humana cuando hace falta, emite credenciales acotadas y escribe eventos de auditoría.
Esto es especialmente importante en ecosistemas de herramientas tipo MCP. MCP puede exponer capacidades muy útiles a los agentes, pero cada capacidad expuesta también es una frontera de permisos. Un servidor MCP de base de datos no debería conceder escritura solo porque el agente formuló una petición convincente. El gateway debe decidir si esa tarea, actor, ambiente y recurso justifican la acción.
Los alcances tradicionales suelen describir permisos amplios de aplicación: leer facturas, escribir tickets, administrar usuarios. Los agentes necesitan alcances más contextuales. Un alcance con forma de tarea podría permitir crear un solo ticket para un cliente, leer logs de un servicio durante la última hora o generar un pull request en borrador sin permiso de merge.
| Control | Patrón débil | Patrón más seguro |
|---|---|---|
| Vida del token | Token compartido y duradero para todas las acciones del agente. | Token corto, vinculado a una tarea o sesión concreta. |
| Diseño de alcance | Alcances genéricos de administrador, como write:all. |
Alcances limitados por recurso, acción, ambiente y tiempo. |
| Aprobación humana | El agente decide por sí mismo cuándo una acción es segura. | La política exige aprobación para llamadas destructivas o de alto riesgo. |
| Auditabilidad | Los logs muestran solo el nombre de una cuenta de servicio. | Los logs conectan persona, agente, herramienta, token, petición y resultado. |
| Revocación | La credencial sigue activa después de terminar la tarea. | El token expira automáticamente y puede revocarse de inmediato. |
Para una implementación práctica y útil como pieza de portafolio, construiría un gateway de autorización para agentes con Cloudflare Workers o FastAPI, usando Postgres/Supabase para políticas y auditoría. El agente nunca llamaría APIs sensibles directamente. Enviaría la acción propuesta al gateway. El gateway validaría la petición, la mapearía a una política, emitiría una credencial corta o un token interno firmado y luego haría proxy de la llamada aprobada.
La primera versión incluiría: registro de herramientas, definiciones de acciones acotadas, niveles de riesgo, estados de aprobación humana, expiración de tokens, logs estructurados y un pequeño dashboard con acciones recientes de agentes. Ese dashboard importa. La seguridad de agentes no consiste solo en bloquear ataques; también consiste en hacer visible la actividad autónoma para que las personas puedan confiar en ella.
Los sistemas de autorización para agentes fallan de formas bastante predecibles. El fallo más común es el exceso de privilegios: un token amplio es más fácil de entregar que uno acotado. El segundo es la falta de atribución: el log muestra que se llamó una API, pero no explica por qué. El tercero es el bypass de política: el agente encuentra una ruta directa a la API y evita el gateway. El cuarto es la fatiga de aprobación: las personas aprueban todo porque el sistema pide confirmación demasiadas veces.
Un buen diseño reduce estos fallos con políticas default-deny, emisión estrecha de tokens, acceso a herramientas por un camino controlado, aprobación basada en riesgo y dashboards que resumen actividad en lugar de hundir a los revisores en logs crudos.
Cada acción de agente debería generar telemetría estructurada. Como mínimo: ID del agente, solicitante humano, ID de tarea, herramienta usada, recurso objetivo, alcances solicitados, alcances concedidos, decisión de política, estado de aprobación, latencia, resultado y si hubo campos sensibles redactados.
Con esos eventos, el sistema puede responder preguntas útiles: qué herramientas usan más los agentes, qué acciones requieren más aprobación manual, qué alcances son demasiado amplios, qué prompts producen bloqueos repetidos y qué automatizaciones ya son lo suficientemente seguras para ganar más autonomía.
Los agentes de IA no deberían heredar confianza por escribir con fluidez. Un plan bien redactado no es autorización. Una llamada de herramienta formulada con seguridad no es aprobación. Los sistemas de producción necesitan límites aplicables: identidad, alcances, política, aprobación, ejecución, auditoría y revocación.
Esa es la diferencia entre un agente simplemente conectado a herramientas y un agente capaz de participar con seguridad en operaciones backend reales.
Artículo sobre identidad y autorización para agentes de IA que cubre OAuth para agentes, identidad no humana, autorización de APIs, tokens acotados, gateways de políticas, seguridad de herramientas MCP, logs de auditoría, mínimo privilegio, aprobación humana y arquitectura backend para acciones autónomas seguras.