Guía para asegurar tus agentes IA: gestión de identidad, control de acceso granular, secrets management. Prácticas 2026 con Claude y MCP.
Los primeros asistentes IA desplegados en la empresa tenían un rol relativamente pasivo. Respondían preguntas, resumían documentos o generaban contenido. Su impacto se limitaba a la producción de información.
Las arquitecturas agentivas cambian completamente esta lógica.
Hoy en día, un agente puede abrir un ticket en Jira, modificar un CRM, lanzar un workflow CI/CD, enviar un correo electrónico, desencadenar un reembolso en Stripe u orquestar múltiples llamadas a API de forma autónoma.
A partir del momento en que un agente actúa sobre sistemas reales, surge una pregunta inevitable:
¿Quién actúa realmente?
No es una pregunta sobre el proveedor del modelo, el framework o el protocolo. Es una pregunta de arquitectura.
Una nueva categoría de identidad
Durante años, las arquitecturas de seguridad se han basado en dos categorías de identidades:
- los usuarios humanos;
- las identidades técnicas (aplicaciones, servicios, microservicios).
Los agentes IA no pertenecen completamente a ninguna de estas categorías.
Razonan, eligen herramientas, adaptan sus acciones al contexto y a veces ejecutan decenas de operaciones sucesivas.
Constituyen una nueva categoría de identidad que en este artículo denominaremos identidad agentiva.
Definición
Una identidad agentiva es el conjunto de información que permite identificar un agente, determinar en nombre de quién actúa, conocer los límites de su autonomía y reconstruir cada una de sus decisiones.
Esta definición servirá como hilo conductor para el resto del artículo.
Una clave API no es una identidad
Las primeras implementaciones de agentes suelen seguir esta arquitectura.
Aplicación
│
▼
Clave API LLM
│
▼
Agente IA
Esta representación es práctica.
También es engañosa.
La clave API identifica tu aplicación ante el proveedor del modelo.
No identifica el agente que actúa en tu sistema de información.
Dos agentes pueden compartir la misma clave API mientras tienen responsabilidades completamente diferentes.
La identidad del agente pertenece, por lo tanto, a tu arquitectura, no al proveedor de modelos.
El modelo nunca realiza directamente una acción
A menudo se escucha:
"Claude eliminó un pedido."
o
"GPT creó un reembolso."
En realidad, un modelo de lenguaje solo emite una propuesta.
Tu infraestructura decide luego:
- si esta acción está autorizada;
- con qué permisos;
- para qué usuario;
- sobre qué recursos.
Usuario
│
▼
Aplicación
│
▼
Agent Runtime
│
propone una acción
▼
Policy Engine
│
▼
Herramienta empresarial
│
▼
Sistema destino
Esta separación entre razonamiento y ejecución constituye uno de los principios fundamentales de las arquitecturas agentivas modernas.
La verdadera cuestión es la responsabilidad
Una empresa debe poder responder, varias semanas después de un incidente:
- ¿Qué agente actuó?
- ¿Para qué usuario?
- ¿En qué tenant?
- ¿Qué política autorizó esta operación?
- ¿Qué herramienta fue invocada?
Un registro que solo indique:
"El modelo llamó a updateCustomer()"
aporta prácticamente ningún valor.
Una arquitectura moderna debe permitir reconstruir la cadena de decisión completa.
Una identidad siempre es contextual
El mismo agente puede intervenir:
- para varios usuarios;
- en varias organizaciones;
- en varios entornos;
- con permisos diferentes según la tarea.
Su identidad nunca se reduce a un simple identificador.
Agente
├ identidad
├ usuario representado
├ tenant
├ entorno
├ sesión
└ permisos temporales
El contexto es parte integral de la identidad.
Las arquitecturas históricas no responden a esta problemática
OAuth, OpenID Connect, Kubernetes Service Accounts o las identidades de workloads responden principalmente a una pregunta:
¿Qué componente solicita acceso a un recurso?
Los agentes IA añaden una dimensión adicional:
¿Por qué se realiza esta acción, en nombre de quién y dentro de qué límites?
Esta diferencia es la que justifica una nueva capa de gobernanza.
Antes de hablar de JWT o rbac
La mayoría de los artículos comienzan inmediatamente con las tecnologías:
- JWT;
- OAuth;
- RBAC;
- Vault;
- rotación de secretos.
Todas son importantes.
Pero llegan demasiado pronto.
Antes de elegir una tecnología, hay que definir qué es la identidad de un agente y qué información debe portar.
Este es precisamente el objetivo del siguiente capítulo, que introduce un Agent Identity Reference Model independiente de proveedores, frameworks y modelos de lenguaje.
Para recordar
Los modelos evolucionarán.
Los frameworks cambiarán.
Los protocolos aparecerán y desaparecerán.
Sin embargo, toda arquitectura agentiva siempre deberá responder a la misma pregunta:
¿Quién actúa realmente, en nombre de quién, con qué permisos y bajo qué control?
Definición
Un Agent Identity Reference Model es un modelo conceptual que describe la información mínima que una plataforma debe conocer para identificar un agente, determinar en nombre de quién actúa, decidir qué acciones puede realizar y garantizar la trazabilidad completa de su actividad.
Una vez que consideramos un agente como una verdadera identidad de software, surge inmediatamente otra pregunta:
¿De qué información necesita realmente una plataforma para autorizar a un agente a actuar?
La mayoría de las implementaciones responden con una lista de mecanismos técnicos: un JWT, una clave API, algunos permisos y a veces un rol RBAC.
En realidad, estos mecanismos solo expresan parte de la identidad. Para que un agente pueda actuar de forma segura, hay que responder varias preguntas independientes.
Descripción general
| Capa | Pregunta | Ejemplos de tecnologías |
|---|---|---|
| Identity | ¿Quién es este agente? | UUID, SPIFFE ID |
| Authentication | ¿Puede probar su identidad? | JWT, OAuth 2.0, mTLS |
| Delegation | ¿En nombre de quién actúa? | OAuth, OIDC |
| Authorization | ¿Qué puede hacer? | RBAC, ABAC, Cedar, OPA |
| Secrets | ¿Cómo accede a los recursos? | Vault, AWS Secrets Manager |
| Observability | ¿Puede explicarse cada decisión? | OpenTelemetry |
| Revocation | ¿Se puede detener inmediatamente? | Token revocation |
Las capas son independientes
Un error frecuente es mezclar varias responsabilidades.
Un JWT no decide los permisos. Un motor de políticas no prueba la identidad. Un gestor de secretos no autoriza ninguna acción.
Cada capa responde a una responsabilidad única. Esta separación permite reemplazar una tecnología sin cuestionar la arquitectura global.
Esquema del modelo
Identity
│
┌─────────────────┴─────────────────┐
│ │
Authentication Delegation
│ │
└─────────────────┬─────────────────┘
▼
Authorization
│
┌────────────────┴────────────────┐
│ │
Secret Access Observability
│ │
└────────────────┬────────────────┘
▼
Revocation
Identity no es authentication
Estos dos conceptos a menudo se confunden.
La identidad describe quién es el agente.
La autenticación verifica que realmente es quien dice ser.
Estar autenticado nunca significa estar autorizado.
Las seis capas
1. Identity
Cada agente posee un identificador estable, una versión, un propietario y un entorno de ejecución.
agent:
id: support-agent
version: 2.3.1
owner: customer-support
environment: production
2. Authentication
La autenticación permite probar esta identidad mediante JWT, OAuth, mTLS o una identidad de workload.
3. Delegation
Un agente rara vez actúa por su propia cuenta. Actúa en nombre de un usuario, un tenant o un proceso empresarial.
4. Authorization
Las autorizaciones modernas se basan cada vez más en motores de políticas.
Los principales modelos son:
- RBAC
- ABAC
- PBAC
- ReBAC
Las arquitecturas agentivas generalmente favorecen PBAC, capaz de evaluar el contexto de ejecución.
Ejemplo Node.js:
const decision = await policyEngine.evaluate({
identity,
tool: "refundOrder",
amount: 75,
tenant: "acme",
});
if (!decision.allow) {
throw new ForbiddenError(decision.reason);
}
await refundOrder();
5. Secrets
El modelo nunca manipula los secretos directamente.
Expresa una intención; la aplicación recupera los secretos de un gestor dedicado.
6. Observability
Cada decisión debe ser rastreable: identidad, usuario representado, política aplicada, resultado y duración de ejecución.
7. Revocation
Toda identidad debe poder desactivarse inmediatamente para evitar cualquier acción nueva.
Para recordar
Los modelos cambian.
Los frameworks evolucionan.
Los protocolos aparecen y desaparecen.
Sin embargo, una arquitectura siempre deberá responder a las mismas preguntas:
- ¿Quién actúa?
- ¿En nombre de quién?
- ¿Qué puede hacer?
- ¿Cómo se protegen los recursos?
- ¿Cómo explicar las decisiones?
- ¿Cómo detener inmediatamente este agente?
Mientras estas preguntas encuentren respuesta, tu arquitectura seguirá siendo válida independientemente del proveedor de modelos o el framework utilizado.
El Agent Identity Reference Model presentado en el capítulo anterior es intencionalmente independiente de las tecnologías.
Responde a una pregunta de arquitectura:
¿Qué información necesito manipular para asegurar un agente?
Este capítulo responde a otra pregunta:
¿Cómo implementar concretamente este modelo en una aplicación moderna?
La buena noticia es que no es necesario inventar un nuevo stack de seguridad. La mayoría de las empresas ya poseen los componentes necesarios.
Una arquitectura de referencia
Usuario
│
▼
Identity Provider
│
▼
Aplicación empresarial
│
▼
Agent Runtime
┌───────────────┼────────────────┐
▼ ▼ ▼
Policy Engine Secret Manager Observability
│
▼
Tool Gateway
│
┌────┼───────────────┐
▼ ▼ ▼
CRM PostgreSQL Stripe
El modelo de lenguaje deliberadamente no es el centro del esquema.
Produce propuestas.
El runtime aplica las políticas de seguridad.
El runtime se convierte en el punto de control
Cada invocación de herramienta debe tratarse como una decisión de seguridad.
Antes de ejecutar una acción, el runtime debe responder varias preguntas:
- ¿Quién es el agente?
- ¿Para qué usuario actúa?
- ¿Qué tenant está involucrado?
- ¿Está autorizada esta acción?
- ¿Se respetan los límites de seguridad?
En otras palabras, el runtime se convierte en un Policy Enforcement Point (PEP).
Un middleware node.js en lugar de lógica dispersa
Una buena práctica es centralizar los controles.
export async function authorizeTool(ctx, toolName) {
const decision = await policyEngine.evaluate({
identity: ctx.identity,
tool: toolName,
tenant: ctx.tenant,
delegatedUser: ctx.user.id
});
if (!decision.allow) {
throw new ForbiddenError(decision.reason);
}
return decision;
}
Luego cada herramienta utiliza este middleware.
server.registerTool({
name: "refundOrder",
async execute(args, ctx) {
await authorizeTool(ctx, "refundOrder");
return refundService.execute(args);
}
});
De esta forma, las reglas de seguridad permanecen independientes del modelo y del prompt.
Un JWT transporta una identidad, no decide nada
Un JWT puede contener información útil:
{
"agent":"support-agent",
"tenant":"acme",
"delegatedUser":"user-482",
"scope":["orders.read","orders.update"]
}
Pero un JWT nunca responde a la pregunta:
¿Está autorizada esta operación ahora?
Esta decisión siempre pertenece al motor de políticas.
Los permisos se evalúan en cada acción
En una arquitectura agentiva, los permisos no están fijados en el momento de la conexión.
Cada invocación de herramienta constituye una nueva decisión.
Por ejemplo, un reembolso puede depender de:
- el monto;
- el tenant;
- el rol del usuario representado;
- el entorno;
- la política de riesgo.
El runtime debe consultar un motor de políticas antes de cada operación sensible.
Las herramientas representan capacidades empresariales
Evita exponer primitivas técnicas directamente.
A evitar:
executeSQL()
executeShell()
deleteCustomer()
Prefiere herramientas que expresen una intención empresarial.
findCustomer()
refundOrder()
updateShippingAddress()
generateInvoice()
Este enfoque reduce significativamente la superficie de ataque y simplifica las políticas de autorización.
Los secretos nunca abandonan la infraestructura
El modelo nunca debería recibir una clave Stripe, una contraseña PostgreSQL o un token AWS.
El runtime recupera estos secretos de un gestor dedicado.
import Stripe from "stripe";
const stripe = new Stripe(
await secretManager.get("stripe-API-key")
);
El modelo expresa una intención.
La aplicación realiza la llamada técnica.
MCP no reemplaza los controles
El Model Context Protocol (MCP) estandariza el descubrimiento e invocación de herramientas.
Nunca decide si una herramienta puede ser utilizada.
Incluso si un servidor MCP expone:
deleteAllCustomers()
la decisión final siempre pertenece a:
- el runtime;
- al motor de políticas;
- a tu arquitectura.
MCP describe las capacidades.
Tu plataforma decide cuáles son realmente accesibles.
¿Build o buy?
No todos los equipos tienen las mismas necesidades.
| Tamaño del proyecto | Recomendación |
|---|---|
| Prototipo | Reglas codificadas en el runtime |
| Algunos agentes | RBAC simple |
| Multi-tenant | Policy Engine |
| Organización regulada | Cedar, OPA o solución equivalente |
El paso a un motor de políticas se justifica cuando las reglas se vuelven numerosas, evolutivas o compartidas entre múltiples agentes.
Una arquitectura duradera
Uno de los principales beneficios de este enfoque es su independencia de los proveedores.
Puedes reemplazar:
- Claude por GPT;
- GPT por Gemini;
- LangGraph por CrewAI;
- MCP por otro protocolo.
La arquitectura de seguridad permanece sin cambios.
Tu runtime, tus políticas, tus secretos y tus registros de auditoría pertenecen a tu sistema de información.
Constituyen la verdadera capa de confianza de tu plataforma.
Para recordar
El modelo de lenguaje nunca es la autoridad de seguridad.
Propone acciones.
Tu infraestructura decide si pueden ejecutarse.
En este punto, una arquitectura moderna posee:
- una identidad para cada agente;
- un mecanismo de autenticación;
- un motor de políticas;
- una gestión centralizada de secretos.
Estos componentes son necesarios, pero no son suficientes.
Una arquitectura es realmente segura solo si puede auditarse, explicarse y detenerse en cualquier momento.
La auditoría ya no es un simple archivo de logs
En un sistema agentivo, no basta con registrar que un endpoint fue llamado.
Cada decisión importante debería producir un evento que rastree:
- la identidad del agente;
- el usuario representado;
- el tenant;
- la herramienta solicitada;
- la política aplicada;
- la decisión (ALLOW o DENY);
- el resultado de la ejecución.
Ejemplo:
{
"timestamp": "2026-07-17T10:48:31Z",
"agent": "support-agent",
"delegatedUser": "user-482",
"tenant": "acme",
"tool": "refundOrder",
"decision": "ALLOW",
"policy": "refund-policy-v3",
"durationMs": 91
}
Estos eventos permiten reconstruir una decisión varias semanas después de su ejecución.
Los anti-patrones más frecuentes
1. Una clave API compartida
Todos los agentes utilizan la misma identidad.
Consecuencia: imposible saber cuál es responsable.
2. Los secretos transmitidos al modelo
Una clave Stripe o una contraseña SQL nunca deben aparecer en el contexto enviado al LLM.
3. Permisos definidos en el prompt
Un prompt no constituye un mecanismo de seguridad.
Las reglas de autorización deben implementarse en la infraestructura.
4. Herramientas demasiado genéricas
Evita:
executeSQL()
executeShell()
Prefiere:
createInvoice()
updateShippingAddress()
Las herramientas deben representar intenciones empresariales.
Una lista de control de auditoría
Antes de pasar a producción, verifica especialmente:
- ¿Cada agente posee una identidad única?
- ¿Se identifican los usuarios representados?
- ¿Se evalúan las autorizaciones antes de cada invocación de herramienta?
- ¿Los secretos se almacenan en un Secret Manager?
- ¿Se registra cada decisión?
- ¿Puede un agente revocarse inmediatamente?
- ¿Las herramientas exponen capacidades empresariales en lugar de primitivas técnicas?
Si una respuesta es negativa, la arquitectura probablemente merezca una revisión.
Zero trust aplicado a agentes
Los principios Zero Trust siguen siendo perfectamente aplicables a las arquitecturas agentivas.
Cada solicitud debe ser:
- autenticada;
- autorizada;
- rastreada;
- limitada a lo estrictamente necesario.
Ningún agente debe considerarse implícitamente confiable.
Preguntas frecuentes
¿Se necesita un JWT por agente?
No necesariamente.
Lo importante es que cada ejecución disponga de una identidad autenticable y contextualizada.
¿Es suficiente rbac?
Para un prototipo, a menudo sí.
Para varios agentes, múltiples tenants o reglas dinámicas, un motor de políticas se vuelve rápidamente preferible.
¿MCP asegura las herramientas?
No.
MCP describe las herramientas disponibles.
Los controles de acceso siguen siendo responsabilidad de tu plataforma.
¿Debe el modelo conocer los secretos?
Nunca.
El modelo formula una intención.
El runtime realiza las llamadas técnicas con sus propias identidades.
Conclusión
Durante mucho tiempo, la seguridad de las aplicaciones se organizó en torno a los usuarios y los servicios.
Las arquitecturas agentivas introducen una tercera categoría de identidad: el agente autónomo.
Esta evolución obliga a replantear varios fundamentos:
- la identidad;
- la delegación;
- la autorización;
- la gestión de secretos;
- la observabilidad;
- la revocación.
Las tecnologías continuarán evolucionando.
Los modelos de lenguaje serán reemplazados.
Los frameworks cambiarán.
Sin embargo, las preguntas fundamentales seguirán siendo las mismas:
- ¿Quién actúa?
- ¿En nombre de quién?
- ¿Con qué permisos?
- ¿Cómo explicar cada decisión?
- ¿Cómo interrumpir inmediatamente un agente?
Las organizaciones capaces de responder estas preguntas dispondrán de una arquitectura duradera, independiente de los proveedores de modelos y lo suficientemente robusta para evolucionar sus sistemas agentivos con el tiempo.
