Los agentes de IA que pueden navegar por la web abren posibilidades poderosas, desde la automatización de la investigación hasta la recopilación de datos en tiempo real. Sin embargo, brindarle a un agente de IA acceso a Internet sin restricciones genera preocupaciones de seguridad y cumplimiento. ¿Qué pasa si el agente accede a sitios web no autorizados? ¿Qué pasa si los datos confidenciales se filtran a dominios externos?
Amazon Bedrock AgentCore proporciona herramientas administradas que permiten a los agentes de IA interactuar con la web (navegador), ejecutar código (intérprete de código) y alojar agentes (tiempo de ejecución). Cuando se implementa en una nube privada virtual de Amazon (Amazon VPC), puede controlar el acceso a la red de herramientas mediante AWS Network Firewall para implementar el filtrado basado en dominio. AWS Network Firewall también le proporciona reglas administradas para ayudar a reducir el acceso a botnets, dominios de malware conocido y otros recursos de alto riesgo.
En esta publicación, le mostramos cómo configurar AWS Network Firewall para restringir los recursos de AgentCore a una lista permitida de dominios de Internet aprobados. Puede utilizar esta arquitectura para:
Permitir el acceso solo a dominios específicos (por ejemplo, wikipedia.org, stackoverflow.com) Bloquear explícitamente ciertas categorías (por ejemplo, sitios de redes sociales) usando plantillas de reglas Registrar los intentos de conexión para la alineación de auditoría y cumplimiento Aplicar una política de denegación predeterminada para dominios no especificados
Esta publicación se centra en el filtrado a nivel de dominio mediante la inspección SNI, la primera capa de un enfoque de defensa en profundidad. Para conocer técnicas de inspección de contenido y filtrado a nivel de DNS, consulte Continuar al final de esta publicación. Para el control de acceso entrante (restringir quién puede invocar a sus agentes), también puede ver Políticas basadas en recursos para Amazon Bedrock AgentCore. Estas condiciones de soporte, como aws:SourceIp, aws:SourceVpc y aws:SourceVpce. Estos controles son capas complementarias en una estrategia de defensa en profundidad.
Por qué esto es importante: requisitos de seguridad empresarial
Los clientes que implementan agentes de IA en industrias reguladas tienen requisitos de seguridad consistentes en torno al control de entrada y salida de la red:
Organizaciones empresariales con altos requisitos de seguridad.
Los clientes de industrias reguladas que realizan revisiones de seguridad para implementaciones de agentes de IA preguntan constantemente sobre el aislamiento de la red y el control de salida, lo que requiere explicaciones detalladas sobre cómo se controla y audita el tráfico de los agentes. Estos clientes quieren tener la seguridad de que los puntos finales del tiempo de ejecución del agente permanezcan privados y que estén disponibles controles de seguridad adicionales, como protecciones de firewall de aplicaciones web.
Proveedores de SaaS multiinquilino
Los proveedores de software empresarial como servicio (SaaS) requieren listas de permitidos y denegados a nivel de DNS porque sus arquitecturas multiinquilino necesitan políticas de red por cliente. Por ejemplo, es posible que el cliente A deba permitir dominios que el cliente B bloquea. Los requisitos comunes incluyen:
Bloqueo específico de ejecución (evitar el acceso a ciertos dominios durante el inicio de un navegador específico) Restricciones regionales (bloquear categorías de sitios web en regiones específicas) Reglas basadas en categorías (deshabilitar sitios de apuestas o redes sociales a través de conjuntos de reglas preempaquetados)
Requisitos de auditoría de cumplimiento y mitigación de vulnerabilidades de seguridad
Los equipos de seguridad que evalúan a los agentes de IA han identificado que se puede engañar a los agentes para que naveguen a sitios no deseados mediante ataques de inyección rápida. Las listas de URL permitidas personalizadas reducen la superficie de ataque al restringir el navegador a dominios aprobados, independientemente de lo que se le indique al agente que haga. El filtrado de salida basado en dominio proporciona la visibilidad del control de acceso y registro que los equipos de seguridad a menudo necesitan para sus procesos de monitoreo de seguridad.
Descripción general de la solución
La solución implementa AgentCore Browser en una subred privada sin acceso directo a Internet. El tráfico saliente se enruta a través de AWS Network Firewall, que inspecciona los encabezados de indicación de nombre del servidor (SNI) TLS para determinar el dominio de destino y aplicar reglas de filtrado. También puede monitorear las acciones de Network Firewall tomadas para restringir el tráfico a través de la integración nativa de Network Firewall con las métricas de Amazon CloudWatch.
Figura 1: Implementación de AgentCore con AWS Network Firewall y filtrado de salida basado en dominio
La arquitectura incluye:
Subred privada: aloja instancias de AgentCore Browser sin direcciones IP públicas Subred pública: contiene la puerta de enlace NAT para la conectividad saliente Subred de firewall: aloja el punto final del Network Firewall Cuatro tablas de rutas: controla el flujo de tráfico a través del firewall tanto para las solicitudes salientes como para el tráfico de retorno
Flujo de tráfico
AgentCore Runtime ejecuta el agente e invoca la herramienta AgentCore Browser AgentCore Browser inicia una solicitud HTTPS desde la subred privada La tabla de rutas de la subred privada dirige el tráfico a la puerta de enlace NAT en la subred pública La puerta de enlace NAT traduce la dirección IP privada y reenvía la solicitud al extremo del Network Firewall Network Firewall inspecciona el encabezado TLS SNI para identificar el dominio de destino Si el dominio coincide con una regla de la lista de permitidos, el firewall reenvía el tráfico a la puerta de enlace de Internet Las rutas de la puerta de enlace de Internet aprobadas el tráfico al destino externo El tráfico de retorno sigue la ruta simétrica de regreso a través del firewall hasta el agente
Esta arquitectura ayuda a garantizar que el tráfico del navegador se inspeccione y filtre, independientemente del destino.
Nota: El filtrado basado en SNI ayuda a controlar a qué dominios se conectan los agentes en la capa TLS. Para un control a nivel de DNS, incluidos controles para ayudar a prevenir la exfiltración y la tunelización de DNS, combínelo con Amazon Route 53 Resolver DNS Firewall. DNS Firewall ayuda a abordar una limitación de la inspección SNI: un agente podría potencialmente resolver un dominio bloqueado a través de DNS y conectarse directamente por dirección IP.
Requisitos previos
Antes de comenzar, asegúrese de tener:
Una cuenta de AWS con permisos para crear recursos de VPC, firewall de red y roles de IAM Interfaz de línea de comandos de AWS (AWS CLI) versión 2.x configurada con las credenciales adecuadas Acceso a Amazon Bedrock AgentCore Familiaridad básica con los conceptos de redes de VPC
Tutorial
Para obtener la configuración completa paso a paso de VPC y Network Firewall, consulte la documentación de configuración de Amazon Bedrock AgentCore VPC.
Esta sección resalta la configuración específica del navegador AgentCore.
Paso 1: implementar recursos utilizando la plantilla de CloudFormation
Inicie la plantilla de CloudFormation desde el repositorio. Puede mantener los valores predeterminados de la pila. Sin embargo, asegúrese de agregar un nombre de pila (por ejemplo, "agentcore-egress") al campo "Nombre de pila", elija una zona de disponibilidad en el menú "Zona de disponibilidad" e incluya un nombre de depósito existente válido en el parámetro "BucketConfigForOutput". Espere a que se complete la creación de la pila, lo que normalmente demora 10 minutos. Continúe con los siguientes pasos después de que el estado de la pila cambie a CREATE_COMPLETE.
Paso 2: revisar la función de ejecución de IAM
AgentCore Browser requiere una función de IAM con una política de confianza para el servicio Amazon bedrock-agentcore.amazonaws.com:
{ "Versión": "2012-10-17", "Declaración": [ { "Efecto": "Permitir", "Principal": { "Servicio": "bedrock-agentcore.amazonaws.com" }, "Acción": "sts:AssumeRole" } ] }
Paso 3: configurar la lista de permitidos del Firewall de red
Cree un grupo de reglas con estado con sus dominios aprobados. Tenga en cuenta el punto inicial (.) para que coincida con los subdominios:
cat > enablelist-rules.json << 'EOF' { "RulesSource": { "RulesSourceList": { "Targets": [ ".wikipedia.org", ".stackoverflow.com", ".docs.aws.amazon.com", ".amazonaws.com", ".pypi.org", ".pythonhosted.org" ], "TargetTypes": ["HTTP_HOST", "TLS_SNI"], "GeneratedRulesType": "ALLOWLIST" } }, "StatefulRuleOptions": { "RuleOrder": "STRICT_ORDER" } } EOF aws network-firewall create-rule-group –rule-group-name dominios-permitidos por el navegador –type STATEFUL –capacity 100 –rule-group file://allowlist-rules.json –region us-east-2
Importante: incluya .amazonaws.com en su lista de permitidos si el navegador requiere acceso al servicio AWS o utilice puntos finales de VPC como alternativa.
Consideración de seguridad: el dominio .amazonaws.com es una amplia lista de permitidos que permite el acceso a puntos finales alojados en AWS, incluidos los depósitos públicos de Amazon Simple Storage Service (Amazon S3), los puntos finales de Amazon API Gateway y las URL de funciones de AWS Lambda. Para un control más estricto, utilice puntos finales de VPC para el acceso a servicios de AWS y incluya en la lista de permitidos solo los dominios externos específicos que sus agentes necesitan.
Para intérprete de código: considere agregar “.pypi.org” y “.pythonhosted.org” si necesita la instalación de un paquete pip. Los paquetes más comunes están preinstalados, lo que hace que estos dominios sean opcionales para su caso de uso.
Paso 4: configurar la política de firewall
La política de firewall debe utilizar aws:drop_establecido como acción predeterminada. Esto permite que se completen los protocolos de enlace TCP (requeridos para la inspección TLS SNI) mientras se eliminan las conexiones a dominios no permitidos:
cat > firewall-policy.json << 'EOF' { "StatelessDefaultActions": ["aws:forward_to_sfe"], "StatelessFragmentDefaultActions": ["aws:forward_to_sfe"], "StatefulRuleGroupReferences": [ { "ResourceArn": "arn:aws:network-firewall:us-east-2:ACCOUNT_ID:stateful-rulegroup/browser-allowed-domains", "Priority": 1 } ], "StatefulEngineOptions": { "RuleOrder": "STRICT_ORDER" }, "StatefulDefaultActions": ["aws:drop_establecido"] } EOF
No utilice aws:drop_strict porque bloquea los paquetes TCP SYN antes del protocolo de enlace TLS, lo que impide la inspección SNI.
Paso 5: crear el grupo de seguridad
Cree un grupo de seguridad que permita el tráfico saliente. El Network Firewall maneja el filtrado de dominios, por lo que el grupo de seguridad permite la salida:
# Crear grupo de seguridad aws ec2 create-security-group –group-name agentcore-egress-sg –description "Herramientas AgentCore – solo salida, filtradas por Network Firewall" –vpc-id vpc-XXXXXXXXX –region us-east-2 # Permitir todo el tráfico saliente (Network Firewall maneja el filtrado) aws ec2 Authorize-security-group-egress –group-id sg-XXXXXXXXX –protocol -1 –port -1 –cidr 0.0.0.0/0 –region us-east-2 # Eliminar reglas de entrada predeterminadas si están presentes (las herramientas AgentCore no necesitan entrada) aws ec2 revoke-security-group-ingress –group-id sg-XXXXXXXXX –protocol -1 –port -1 –cidr 0.0.0.0/0 –region us-east-2
Paso 6: cree el navegador AgentCore
Cree el navegador con la configuración de VPC apuntando a su subred privada:
aws bedrock-agentcore-control create-browser –name my_secure_browser –execution-role-arn arn:aws:iam::ACCOUNT_ID:role/AgentCoreBrowserExecutionRole –network-configuration '{ "networkMode": "VPC", "vpcConfig": { "securityGroups": ["sg-XXXXXXXXX"], "subredes": ["subred-XXXXXXXXX"] } }' –region us-east-2
Paso 6b: Crear intérprete de código AgentCore (opcional)
También puede implementar AgentCore Code Interpreter en la misma VPC con la misma protección de firewall:
aws bedrock-agentcore-control create-code-interpreter –name my_secure_code_interpreter –network-configuration '{ "networkMode": "VPC", "vpcConfig": { "securityGroups": ["sg-XXXXXXXXX"], "subnets": ["subnet-XXXXXXXXX"] } }' –region us-east-2
AgentCore Code Interpreter utiliza la misma ruta de red que el navegador. Si necesita pip para instalar paquetes, asegúrese de que .pypi.org y .pythonhosted.org estén en su lista de permitidos.
Paso 6c: Implementar el agente en AgentCore Runtime (opcional)
Para implementaciones de agentes basados en contenedores, utilice la misma configuración de VPC:
aws bedrock-agentcore-control create-agent-runtime –agent-runtime-name my_vpc_agent –role-arn arn:aws:iam::ACCOUNT_ID:role/AgentCoreRuntimeRole –agent-runtime-artifact '{ "containerConfiguration": { "containerUri": "ACCOUNT_ID.dkr.ecr.us-east-2.amazonaws.com/my-agent:latest" } }' –network-configuration '{ "networkMode": "VPC", "networkModeConfig": { "securityGroups": ["sg-XXXXXXXXX"], "subnets": ["subnet-XXXXXXXXX"] } }' –protocol-configuration '{"serverProtocol": "HTTP"}' –region us-east-2
Los requisitos de dominio de AgentCore Runtime dependen de su proveedor de modelo. Incluya .amazonaws.com para las llamadas a la API del modelo de Amazon Bedrock o agregue los dominios adecuados para otros proveedores de modelos que utilice su agente. Además, permita dominios personalizados a los que su agente debe acceder.
Paso 7: Pruebe la configuración
Inicie una sesión del navegador y verifique que las reglas del firewall funcionen correctamente:
# Iniciar sesión del navegador aws bedrock-agentcore start-browser-session –browser-identifier my_secure_browser-ABC123xyz –region us-east-2
Utilice la URL de WebSocket devuelta con una herramienta de automatización del navegador como Playwright para probar dominios permitidos y bloqueados:
# test_firewall_rules.py de playwright.sync_api import sync_playwright import boto3 de botocore.auth import SigV4Auth de botocore.awsrequest import AWSRequest WEBSOCKET_URL = "wss://your-session-url" # Desde la respuesta de inicio de sesión del navegador REGION = "us-east-2" # Firma la URL de WebSocket con sesión SigV4 = boto3.Session(region_name=REGION) credenciales = session.get_credentials().get_frozen_credentials() solicitud = AWSRequest(method="GET", url=WEBSOCKET_URL.replace("wss://", "https://")) SigV4Auth(credentials, "bedrock-agentcore", REGION).add_auth(solicitud) encabezados = dict(request.headers) def dominio_prueba(página, url, éxito_esperado): intente: respuesta = page.goto(url, tiempo de espera=10000) éxito = respuesta y respuesta.status < 400 estado = "PASS" si éxito == éxito_esperado else "FALLO" print(f"{estado}: {url} – {'cargado' si el éxito es 'bloqueado'}") devuelve éxito == éxito_esperado excepto Excepción como e: éxito = Falso estado = "PASS" si no es éxito_esperado de lo contrario "FALLO" print(f"{status}: {url} – bloqueado ({type(e).__name__})") devuelve no éxito_esperado con sync_playwright() como p: browser = p.chromium.connect_over_cdp(WEBSOCKET_URL, headers=headers) page = browser.new_page() # Prueba permitida dominios (debería cargarse) test_domain(page, "https://wikipedia.org", expected_success=True) test_domain(page, "https://docs.aws.amazon.com", expected_success=True) # Probar dominios bloqueados (debería expirar/fallar) test_domain(page, "https://example.com", expected_success=False) test_domain(page, "https://twitter.com", esperado_éxito=False) browser.close()
Resultados esperados:
Los dominios permitidos (.wikipedia.org, .amazonaws.com) deberían cargarse correctamente. Los dominios bloqueados deberían expirar después del protocolo de enlace TCP o devolver errores de conexión.
Nota: Algunos dominios permitidos, como docs.aws.amazon.com, dependen de los recursos CDN de dominios como awsstatic.com y cloudfront.net. Si las páginas de los dominios permitidos no se muestran completamente, agregue los dominios CDN requeridos a su lista de permitidos.
También puede consultar los registros del firewall en CloudWatch para detectar intentos de conexión bloqueados:
# Ver registros de alertas recientes (conexiones bloqueadas) aws logs filter-log-events –log-group-name "/aws/network-firewall/agentcore-egress/alerts" –filter-pattern '{ $.event.alert.action = "blocked" }' –region us-east-2 –start-time $(($(date +%s) – 300))000 # Verificar firewall estado de sincronización antes de probar aws network-firewall describe-firewall –firewall-name agentcore-egress-firewall –region us-east-2 –query 'FirewallStatus.ConfigurationSyncStateSummary'
Solución de problemas: si los dominios permitidos están bloqueados, verifique:
El estado de sincronización del firewall muestra IN_SYNC (los cambios de reglas toman unos minutos) Las entradas de dominio incluyen el punto inicial (.wikipedia.org, no wikipedia.org) Las tablas de rutas están configuradas correctamente para el enrutamiento simétrico Si recibe errores HTTP 403 en dominios permitidos, generalmente se trata de una detección de bot por parte del sitio de destino, no de un bloqueo del firewall. Consulte los registros de ALERTAS de CloudWatch para confirmar: las conexiones bloqueadas tendrán entradas de alerta explícitas.
Mejores prácticas
Utilice la evaluación STRICT_ORDER: esto facilita el procesamiento de reglas predecibles al combinar listas permitidas y listas prohibidas. Incluya .amazonaws.com para acceder al servicio de AWS: o utilice puntos finales de VPC para evitar enrutar llamadas a la API de AWS a través de Internet. Configure la tabla de rutas de ingreso IGW: esto es fundamental para el enrutamiento simétrico. Sin él, el tráfico de retorno pasa por alto el firewall. Habilite los registros de ALERTA y FLUJO: los registros de ALERTA capturan las conexiones bloqueadas; Los registros de FLOW proporcionan metadatos de conexión para el tráfico. Espere la sincronización del firewall: los cambios de reglas tardan unos minutos en propagarse. Verifique ConfigurationSyncStateSummary: IN_SYNC antes de realizar la prueba. Configure HOME_NET para arquitecturas de múltiples VPC: de forma predeterminada, la inspección del dominio de Network Firewall solo filtra el tráfico que se origina en el rango de enrutamiento entre dominios sin clase (CIDR) de la VPC de implementación. Si utiliza un firewall centralizado con AWS Transit Gateway para inspeccionar el tráfico de varias VPC, debe configurar la variable HOME_NET en su grupo de reglas para incluir los rangos CIDR de origen. Sin esto, el tráfico de otras VPC puede eludir el filtrado de dominio.
Limitaciones y consideraciones de costos
La inspección de contenido requiere inspección TLS: de forma predeterminada, el filtrado de dominio opera en metadatos TLS no cifrados (encabezados SNI) y no puede inspeccionar cuerpos de solicitud o respuesta cifrados. Para inspeccionar el contenido HTTPS, habilite la inspección TLS en su Network Firewall y agregue reglas de Suricata que coincidan con el contenido del cuerpo HTTP. Riesgo de omisión de encabezados SNI/Host: Network Firewall utiliza encabezados TLS SNI y encabezados HTTP Host (no direcciones IP) para determinar los dominios de destino. Si se manipulan estos encabezados, el tráfico podría eludir el filtrado del dominio. Para implementaciones de alta seguridad, combine reglas de dominio con reglas basadas en IP para destinos críticos bloqueados o agregue filtrado DNS como una capa adicional. Además, considere combinar reglas basadas en SNI con Route 53 DNS Firewall para ayudar a evitar que los agentes resuelvan dominios bloqueados a través de DNS y se conecten directamente por dirección IP. Alcance HOME_NET en implementaciones de múltiples VPC: de forma predeterminada, la inspección del dominio de Network Firewall solo se aplica al tráfico que se origina en el rango CIDR de la VPC de implementación. Si utiliza un firewall centralizado con AWS Transit Gateway (múltiples VPC enrutadas a través de un firewall compartido), debe configurar la variable HOME_NET en su grupo de reglas para incluir los rangos CIDR de origen. Sin esto, el tráfico de las VPC radiales pasa por alto la inspección del dominio. Consulte Grupos de reglas de lista de dominios con estado para obtener más detalles. Los costos variarán según su uso. Consulte los precios de NAT Gateway y Network Firewall para conocer las tarifas actuales.
Limpiar
Elimine recursos en este orden para evitar cargos continuos:
Elimine el navegador AgentCore Elimine el Firewall de red (primero deshabilite la configuración de protección) Elimine la puerta de enlace NAT Libere la dirección IP elástica Elimine las subredes y las tablas de rutas Separe y elimine la puerta de enlace de Internet Elimine la VPC
Nota: AgentCore Browser y Code Interpreter crean interfaces de red elásticas en su VPC. Después de eliminar estos recursos, espere unos minutos hasta que se libere la interfaz de red antes de eliminar el grupo de seguridad, la subred o la VPC. Si la eliminación falla, verifique si hay interfaces de red persistentes en la subred y espere a que se desconecten.
Recursos relacionados
Para obtener más información, consulte los siguientes recursos.
Yendo más lejos
El filtrado de dominios mediante la inspección SNI es una capa de seguridad de salida. Dependiendo de sus requisitos, considere estas mitigaciones adicionales:
Técnica Qué hace Ayuda en escenarios donde Referencia Route 53 DNS Firewall Ayuda a bloquear o permitir consultas de DNS por dominio y evitar la exfiltración y la tunelización de DNS. Necesita filtrado a nivel de DNS o protección contra la filtración de datos basada en DNS. Protéjase contra amenazas avanzadas de DNS Inspección TLS + Suricata DLP Descifre HTTPS, inspeccione los cuerpos de solicitud/respuesta con reglas de Suricata, ayude a bloquear patrones de datos confidenciales (PII, credenciales). Necesita prevención de pérdida de datos (DLP) para el tráfico generado por agentes. Inspección TLS para tráfico de salida cifrado Arquitectura de inspección centralizada Enrute el tráfico desde múltiples VPC a través de una VPC de inspección compartida con Network Firewall. Ejecuta varias implementaciones de AgentCore y desea una aplicación de políticas centralizada. Implementar filtrado de tráfico centralizado
Cuando utilice la inspección TLS, configure certificados personalizados en sus recursos de AgentCore para confiar en la CA que vuelve a firmar el Firewall de red.
Conclusión
Al combinar las herramientas de Amazon Bedrock AgentCore con AWS Network Firewall, puede brindar a los agentes de IA acceso web controlado mientras mantiene la seguridad y el cumplimiento normativo. El enfoque de filtrado basado en dominio le ayuda a definir con precisión a qué sitios web pueden acceder los agentes, bloquear destinos no deseados y registrar los intentos de conexión con fines de auditoría. Esta arquitectura aborda las preocupaciones de seguridad planteadas por los clientes empresariales:
Cumplimiento de FSI: proporciona el aislamiento de red y el registro de auditoría necesarios para las revisiones de seguridad a nivel de CISO. Control multiinquilino: habilita políticas de dominio por cliente o por ejecución para proveedores de SaaS. Defensa de inyección rápida: restringe la navegación del agente a dominios aprobados, lo que ayuda a reducir la superficie de ataque para la inyección rápida. Evidencia de auditoría: genera registros de CloudWatch que respaldan los requisitos de auditoría de cumplimiento.
Para las empresas que implementan agentes de IA que necesitan acceso a Internet para investigación, recopilación de datos o integraciones de API, este patrón proporciona un enfoque listo para producción para mantener un control estricto sobre a dónde conduce ese acceso. En lugar de mantener servidores proxy Squid personalizados o una infraestructura de red compleja, puede utilizar los servicios administrados de AWS para implementar filtrado de salida de nivel empresarial en horas, no semanas.
Para obtener más información sobre el navegador AgentCore, consulte la documentación del navegador AgentCore.
Sobre los autores
Kosti Vasilakakis
Kosti Vasilakakis es PM principal en AWS en el equipo de Agentic AI, donde ha dirigido el diseño y desarrollo de varios servicios Bedrock AgentCore desde cero, incluidos Runtime, Browser, Code Interpreter e Identity. Anteriormente trabajó en Amazon SageMaker desde sus inicios, lanzando capacidades de IA/ML que ahora utilizan miles de empresas en todo el mundo. Al principio de su carrera, Kosti fue científico de datos. Fuera del trabajo, crea automatizaciones de productividad personal, juega tenis y disfruta de la vida con su esposa e hijos.
Evandro Franco
Evandro Franco es un científico de datos senior que trabaja en Amazon Web Services. Es parte del equipo Global GTM que ayuda a los clientes de AWS a superar los desafíos comerciales relacionados con AI/ML en AWS, principalmente en Amazon Bedrock AgentCore y Strands Agents. Tiene más de 18 años de experiencia trabajando con tecnología, desde desarrollo de software, infraestructura, serverless hasta aprendizaje automático. En su tiempo libre, a Evandro le gusta jugar con su hijo, principalmente construir divertidos ladrillos Lego.
Kevin Orellana
Kevin Orellana es ingeniero de desarrollo de software en Amazon Web Services en el equipo Bedrock AgentCore, con sede en Seattle. Construye y opera la infraestructura central que impulsa las capacidades de IA agente, incluidos el navegador, el intérprete de código y el tiempo de ejecución. Al principio de su carrera, Kevin trabajó en el equipo de inferencia de Bedrock que albergaba modelos de frontera. En su tiempo libre, le gusta caminar con su Goldendoodle, experimentar con simulaciones de múltiples agentes y trabajar para crear un asistente personal de inteligencia artificial que hable inglés, español y mandarín.
Yan Marim
Yan Marim es arquitecto senior de soluciones especializado en GenAI en Amazon Web Services, con sede en Brasil. Como parte del equipo de especialistas de LATAM, guía a los clientes a través de su viaje de adopción de IA generativa, enfocándose en Amazon Bedrock y soluciones de IA agente. En su tiempo libre, Yan disfruta pasar tiempo de calidad con su esposa y su perro, y ver partidos de fútbol.