Identidad y autorización de agentes

Imagina que el agente de recordatorios de Citas corre con las credenciales de la ingeniera que lo desplegó. Funciona de maravilla hasta que una inyección de prompt indirecta escondida en las notas de una cita tuerce su objetivo. A partir de ahí el agente no es un recordatorio con permisos de recordatorio: es la ingeniera entera, con acceso a producción, a los secretos y a la consola. El radio de impacto no es el del agente, es el del humano. Dos controles evitan este salto: darle al agente una identidad propia y sacar la autorización de sus herramientas fuera de su código.

Por qué un agente necesita identidad propia#

La regla es la misma que para cualquier carga de trabajo: cada actor con permisos debe tener su propia identidad y el mínimo privilegio. Un agente autónomo no es una extensión del usuario; es un proceso que toma decisiones y llama a APIs por su cuenta. Si hereda las credenciales de una persona, pierdes tres cosas a la vez:

Acotación del impacto. Los permisos del agente deberían ser los de su tarea (enviar emails de recordatorio), no los de un humano que además es administrador.
Atribución. En CloudTrail quieres ver que fue citas-recordatorios quien llamó a ses:SendEmail, no maria@clinica. Si comparten credencial, la auditoría y la respuesta a incidentes se vuelven ciegas.
Revocación. Cuando algo va mal, quieres revocar al agente sin dejar a la persona sin acceso, y al revés.

Autorización de herramientas: Cedar decide qué, no qué datos

Controles · AgentCore Gateway + Policy

Paso 1 de 6La llamada sale del agente

El agente decide invocar una herramienta. Pero la decisión de si puede hacerlo no vive en su código: toda llamada pasa primero por AgentCore Gateway.

AgentCore Identity: identidad de workload y credenciales delegadas#

En AWS, Amazon Bedrock AgentCore (disponible de forma general desde octubre de 2025) resuelve esto con AgentCore Identity. Da al agente una identidad de workload propia y un vault de tokens donde guarda de forma segura las credenciales que el agente necesita para actuar, incluidos refresh tokens OAuth.

El patrón clave es la credencial delegada: cuando el agente necesita hablar con un servicio externo en nombre de un usuario (por ejemplo, el calendario de la clínica), no almacena una contraseña ni una clave de larga duración en su código. Obtiene un token OAuth con el alcance (scope) justo, acotado en el tiempo, que representa ese permiso para ese usuario. Así separas dos planos de autorización:

Inbound: ¿quién puede invocar al agente? (el usuario o servicio que lo llama, verificado por JWT/OAuth o IAM).
Outbound: ¿a qué puede acceder el agente? (los tokens delegados del vault, cada uno con su alcance mínimo).

Autorización de herramientas fuera del código del agente#

Aquí está la segunda idea, la que más se pregunta en entrevistas. No autorices las herramientas dentro del prompt ni dentro del código del agente. Un agente manipulado razona sobre su propio prompt; si la regla de “no borres la base de datos” vive en el system prompt, una inyección puede convencerle de ignorarla. La autorización tiene que ser un control externo, no negociable, que el agente no pueda razonar para saltárselo.

AgentCore Gateway convierte tus APIs y funciones Lambda en herramientas (y conecta con servidores MCP), y presenta un único punto por el que pasa toda llamada de herramienta. Sobre ese punto, Policy in AgentCore (GA en marzo de 2026) evalúa políticas escritas en lenguaje Cedar con semántica default-deny: si ninguna regla permite la llamada, se deniega; y un forbid siempre gana a un permit.

Lo potente es que Cedar decide no solo qué herramienta puede invocar el agente, sino con qué parámetros declarados. Un ejemplo ilustrativo (el esquema exacto de entidades depende de tu configuración de AgentCore):

// El agente de recordatorios SOLO puede enviar email, y solo de su clínica.
permit (
  principal == Agent::"citas-recordatorios",
  action    == Action::"invoke",
  resource  == Tool::"enviar_email"
) when {
  context.clinica_id == principal.clinica_id
};

// Nadie exporta la tabla de pacientes a través de una herramienta.
forbid (
  principal,
  action   == Action::"invoke",
  resource == Tool::"exportar_tabla"
);

La misma lógica de evaluación que estudiaste en IAM —deny explícito gana, default-deny— se aplica aquí, pero al plano de las herramientas del agente en vez de a las APIs de AWS.

Vulnerable

Seguro

// Antipatrón: la autorización vive en el prompt y el agente usa
// las credenciales del humano. Una inyección puede reescribir la regla.
const system = `Eres un asistente. NUNCA borres datos ni
exportes la tabla de pacientes.`;
const agent = new Agent({ system, tools: todasLasHerramientas });
await agent.run(entradaDelUsuario, humanCredentials);

// El Gateway expone las herramientas; Policy (Cedar) autoriza cada
// llamada fuera del agente; la identidad es propia, no la del humano.
const agent = new Agent({
  identity: 'citas-recordatorios', // AgentCore Identity
  gateway: citasGateway, // toda llamada pasa por aquí
});
// enviar_email → permit · exportar_tabla → forbid (Cedar)
await agent.run(entradaDelUsuario);

El punto de entrevista: autorizar no es inspeccionar#

Aquí está el matiz que separa una buena respuesta de una excelente. Policy in AgentCore controla qué herramienta se llama y con qué parámetros, pero no inspecciona qué datos viajan dentro de la llamada. Una política puede exigir que enviar_email solo se use para la clínica del agente, pero no entiende que el cuerpo de ese email lleva la lista de pacientes robada. Para la política es una llamada perfectamente autorizada.

Por eso la autorización de herramientas es necesaria pero no suficiente. Cierra el abuso de herramientas (que el agente llame a algo que no debe), pero no la exfiltración a través de lo que sí puede llamar. Contra eso necesitas una capa que mire el contenido: filtros de salida con Bedrock Guardrails, DLP y egreso de red restringido, además de minimizar qué datos ve el agente en primer lugar. Lo desarrollamos en guardrails y sandbox.

Errores comunes#

Tu turno

Diseña la identidad y la autorización de un agente de tu entorno

Elige un agente o automatización con IA que uses o quieras construir (en tu trabajo o en tu laboratorio).

¿Con qué identidad corre hoy? ¿Es propia o hereda las credenciales de una persona o de un rol amplio?
Lista sus herramientas. Para cada una, escribe la regla de autorización: ¿qué principal, qué parámetros, qué condición? ¿Cuál debería ser un forbid absoluto?
Marca, de esas herramientas permitidas, cuáles tienen un canal de salida (email, HTTP, escritura en storage). Esas son tus vías de exfiltración aunque la llamada esté autorizada.
¿Qué control de contenido añadirías sobre ellas?

Agente: ...
Identidad: propia / heredada → acción: ...

| Herramienta | permit/forbid | Parámetros/condición | ¿Canal de salida? |
| ----------- | ------------- | -------------------- | ----------------- |
|             |               |                      |                   |

Reto

Tu agente corre con una identidad propia y permisos mínimos, pero sigues poniendo «no exportes datos» en el system prompt como única barrera. ¿Es suficiente?

▸Mostrar solución

No. El system prompt es parte de lo que el agente razona y una inyección puede neutralizarlo. La regla de «no exportar» tiene que ser un control externo (un forbid en Cedar sobre el Gateway, o la ausencia de esa herramienta), no una instrucción dentro del prompt. El prompt endurecido ayuda, pero no es un control de seguridad.

Reto

Policy in AgentCore ya autoriza por parámetros. Entonces, ¿por qué dices que no frena la exfiltración?