AWS mostró cómo restringir el acceso de los agentes de AI de AgentCore solo a dominios aprobados

AWS lanzó una guía práctica sobre cómo restringir el acceso a Internet para agentes de IA a nivel de dominio. No se trata de un nuevo modelo, sino de una medida básica de seguridad: los recursos AgentCore se pueden configurar para acceder solo a sitios preaprobados.

Por qué es necesario

Cuando un agente obtiene acceso a la red, el riesgo cambia drásticamente. Incluso si el modelo sigue bien las instrucciones, aún puede recibir una URL no deseada, redirección o servicio externo que no debería participar en el proceso. Para escenarios corporativos, esto es un problema no solo de seguridad, sino también de control de costos, cumplimiento de políticas internas y previsibilidad de resultados.

AWS sugiere resolver este problema a nivel de red en lugar de confiar solo en prompts y lógica de aplicación. En el desglose publicado, la empresa muestra cómo establecer una lista de permitidos de dominios para recursos AgentCore a través de AWS Network Firewall. La idea es simple: un agente no debe elegir toda Internet por sí mismo si el proceso empresarial requiere trabajar con un conjunto limitado de fuentes.

Para los equipos que construyen pipelines con agentes de IA sobre infraestructura en la nube, esto también es una cuestión de capacidad de gestión. Cuanto más estrecho sea el perímetro externo, más fácil será manejar incidentes, verificar el cumplimiento de la política de seguridad y entender por qué el agente pudo acceder a un recurso particular. Este enfoque es especialmente importante donde el agente de IA está asociado con datos internos, documentos de clientes o acciones automatizadas.

Cómo funciona el filtro

En el centro del esquema está el SNI, Server Name Indication. Este parámetro se envía al inicio de una conexión TLS y muestra a qué dominio quiere conectarse el cliente. El Network Firewall puede analizar este campo y compararlo con una lista de dominios permitidos. Si el dominio está en la lista blanca, la conexión se establece; si no, la solicitud se bloquea antes de que el agente comience a interactuar con el recurso externo.

Este enfoque es útil cuando un agente necesita acceso a varios puntos claros de la red externa: documentación, APIs internas a través de un punto de entrada público, servicios de socios o plataformas SaaS específicas. En este escenario, la seguridad se construye no alrededor de la "confianza abstracta del modelo", sino alrededor de reglas de red estrictamente definidas.

• Agente ve solo una lista aprobada de dominios externos
• Los nuevos sitios no pueden ser accedidos sin actualizaciones explícitas de reglas
• El bloqueo ocurre antes de la ejecución de la lógica de negocio en el recurso externo
• La política de acceso se centraliza en la infraestructura en lugar de dispersarse en el código
• El control se vuelve más claro para auditoría y equipos internos de seguridad

Por qué no es suficiente

AWS destaca por separado que el filtrado basado en dominios es solo la primera capa de defensa. Reduce la superficie de ataque, pero no resuelve todos los riesgos asociados con los agentes. Si un dominio aprobado sirve contenido dañino o no deseado, la lista blanca no ayudará. De manera similar, este enfoque no verifica qué hace el agente después de conectarse a un recurso aceptable.

"El filtrado a nivel de dominio mediante la verificación de SNI es la

primera capa de defensa multicapa."

Hay también una limitación más práctica: el control de dominio ve la dirección de destino pero no la intención completa de la solicitud. No distingue rutas de URL específicas, parámetros, tipos de operaciones y contexto empresarial dentro del mismo dominio permitido. Por lo tanto, la lista blanca es buena como un filtro áspero pero muy útil—especialmente en el punto de entrada de Internet—sin embargo, no puede considerarse una política completa para el comportamiento del agente.

La conclusión práctica de esto es: una lista blanca de red debe combinarse con otras medidas. Esto típicamente incluye aislamiento de ambiente, derechos IAM mínimos, verificación de acciones de salida del agente, registro, límites de herramientas y políticas adicionales a nivel de aplicación. En otras palabras, Network Firewall responde "adónde puede ir el agente" pero no reemplaza el control sobre "qué hace el agente" y "qué devuelve".

Lo que esto significa

AWS esencialmente formaliza un principio simple pero importante para sistemas de agentes: el acceso a Internet no debe estar abierto por defecto sino el mínimo necesario. Para las empresas que prueban agentes de IA en producción, esta es una buena directriz: primero restringir la red externa a una lista de dominios aprobados, luego construir capas más profundas de protección.