Skip to content

AWS introduce controles de acceso para agentes de IA que llaman herramientas externas

Respuesta corta

AWS lanzó Bedrock AgentCore Gateway, una capa gestionada que autentica y autoriza a los agentes de IA antes de que puedan invocar herramientas externas, APIs o bases de datos, y registra cada llamada. Cierra una brecha habitual en la que los agentes creados para automatización terminan con acceso amplio y sin auditar a los sistemas internos.

Qué significa para las operaciones

Si tu empresa ha conectado un agente de IA a tu CRM, sistema de tickets o APIs internas para automatizar la prospección de ventas o la clasificación de soporte, es probable que ese agente tenga más acceso del necesario y que no exista un rastro de auditoría de lo que realmente hizo. AgentCore Gateway permite fijar permisos por herramienta (por ejemplo, que un agente pueda leer registros de clientes pero no modificar la facturación) y obtener un registro de cada llamada, algo que importa en el momento en que un cliente pregunta qué datos tocó la IA o una revisión de seguridad plantea la misma pregunta. Para una empresa de 10 a 200 personas sin equipo de seguridad dedicado, esto convierte la gobernanza de agentes en una configuración que se activa, en lugar de un desarrollo a medida hecho a última hora, siempre que ya se opere sobre AWS o se esté dispuesto a enrutar el tráfico de los agentes a través de Bedrock.

AWS ha lanzado Bedrock AgentCore Gateway, una capa de gobernanza gestionada para agentes de IA que necesitan invocar herramientas externas, APIs y bases de datos, según el blog de Machine Learning de AWS.

El gateway se sitúa entre un agente de IA y las herramientas que tiene permitido usar, aplicando autenticación y autorización granular en cada llamada. En lugar de que un agente mantenga credenciales amplias y permanentes hacia los sistemas internos, el gateway puede restringir el acceso por herramienta, por acción, y registrar cada solicitud con fines de auditoría.

Esto responde a una brecha que ha crecido junto con la adopción de IA agéntica: muchos equipos han conectado agentes a CRMs, plataformas de soporte y bases de datos internas más rápido de lo que han construido controles sobre lo que esos agentes pueden hacer realmente una vez conectados. Un agente de soporte al que se le da acceso a una API de tickets con fines de automatización podría, sin barreras, también leer o modificar registros fuera de su alcance previsto. AgentCore Gateway está diseñado para hacer ese alcance explícito y exigible, en lugar de implícito.

Para las empresas que ya operan cargas de trabajo en AWS, la función se integra con el esquema de permisos tipo IAM existente, lo que significa que la gobernanza puede configurarse sin construir una capa de autorización personalizada desde cero. AWS posiciona esto como parte del stack más amplio de Bedrock AgentCore, orientado a que los despliegues agénticos sean lo bastante auditables para entornos regulados o con requisitos estrictos de seguridad.

Qué cambia para los operadores. Una empresa B2B de 10 a 200 personas que automatiza ventas o soporte con agentes de IA típicamente no tiene hoy ninguna de estas salvaguardas — el acceso se concede de forma amplia porque construir permisos granulares es costoso y lento para un equipo pequeño. AgentCore Gateway convierte eso en una configuración gestionada: se define qué herramientas puede invocar un agente, bajo qué condiciones, y se obtiene un registro para cumplimiento o revisión de incidentes. Esto importa cada vez más a medida que clientes y socios comienzan a preguntar a los proveedores qué acceso tienen sus sistemas de IA a datos sensibles, una pregunta que se está volviendo habitual en los cuestionarios de seguridad de proveedores y en los procesos de compra empresarial.

La contrapartida es el bloqueo tecnológico: el beneficio de gobernanza está ligado específicamente al uso del stack de agentes de Bedrock, de modo que las empresas que ejecutan agentes en otras plataformas (LangChain, orquestación propia o frameworks de agentes ajenos a AWS) no obtienen esto por defecto y necesitarían controles equivalentes en otro lugar. Para los equipos ya comprometidos con AWS, es una forma de menor esfuerzo para cerrar una brecha de auditoría real antes de que se convierta en una pregunta de un cliente o en un incidente de seguridad.

Fuente: AWS Machine Learning Blog

Siguiente paso

Sprint de Discovery

Si el argumento vale para tu operación, el paso siguiente es medir. Treinta minutos sobre un proceso, y decimos si la cuenta tiende a cerrar.

Elegir una hora

Treinta minutos, gratis. El sprint es de lo que va la llamada.

Precio
$2,500
Duración
1-2 semanas

Se devuelve entero si concluimos que no conviene construir.