Mejores prácticas de seguridad para AgentCore Runtime

• Comprenda el límite de aislamiento: cada sesión de usuario se ejecuta en una microVM dedicada con CPU, memoria y sistema de archivos aislados. Los comandos y el código del agente no pueden acceder a las cargas de trabajo de otros clientes ni escapar del límite de las máquinas virtuales. Una vez finalizada la sesión, se cierra toda la microVM y se desinfecta la memoria.

• Imponga las asignaciones de sesión a usuario en su backend, pero no exige las asignaciones de sesión a usuario. AgentCore El backend del cliente debe mantener la relación entre los usuarios y sus identificadores de sesión e implementar una gestión del ciclo de vida, como el número máximo de sesiones por usuario.

• Tenga en cuenta el comportamiento de los permisos del sistema de archivos: cuando se utilizan sistemas de archivos persistentes, los permisos se almacenan pero no se aplican durante la sesión. chmody stat funcionan correctamente, pero las comprobaciones de acceso siempre se realizan correctamente porque el agente se ejecuta como el único usuario de la microVM.

• Comprenda la exposición de las credenciales en la máquina virtual: cualquier código o actor que se ejecute en la microVM puede acceder a las credenciales de la función de ejecución llamando al punto final de metadatos (MMDS). Controle cuidadosamente los permisos de su función de ejecución. Para obtener más información, consulte Administración de credenciales.

• No utilice CLI-generated políticas en producción: las políticas de IAM creadas por la AgentCore CLI están diseñadas con fines de desarrollo y pruebas. Estos permisos otorgan un acceso amplio y no son adecuados para la producción. Cree políticas de IAM personalizadas que restrinjan los permisos únicamente a los recursos y acciones específicos necesarios. Para obtener la referencia completa, consulte Permisos de IAM para AgentCore tiempo de ejecución.

• Limite los permisos a ARN de ejecución específicos: evite las declaraciones de recursos comodín. Utilice el ARN completo de sus recursos de tiempo de ejecución en los campos de políticas de IAM. Resource

• Restringir InvokeAgentRuntimeForUser: solo los directores de confianza deben tener este permiso. Limítelo a recursos de tiempo de ejecución específicos utilizando las condiciones de los recursos de IAM.

• Denegar la delegación de ID de usuario cuando no sea necesaria: en los tiempos de ejecución en los que no sea necesaria la delegación de ID de usuario, deniegue la acción de forma explícita:

  {
     "Statement": [
        {
           "Sid": "DenyUserIdDelegation",
           "Effect": "Deny",
           "Action": "bedrock-agentcore:InvokeAgentRuntimeForUser",
           "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT_ID:runtime/*"
        }
     ]
  }

• Evite la escalada de privilegios: asegúrese de que la función de ejecución asociada a su tiempo de ejecución tenga los mismos o menos privilegios que los responsables que pueden invocarla. Para obtener más información, consulte Administración de credenciales.

• Use claves de condición de IAM para hacer cumplir las implementaciones de VPC: bedrock-agentcore:subnets use bedrock-agentcore:securityGroups claves de condición para exigir que todos los tiempos de ejecución se implementen en VPC aprobadas. Para ver ejemplos, consulta Usar claves de condición de VPC con AgentCore Runtime.

• Utilice el analizador de acceso de IAM: valide sus políticas de IAM para asegurarse de que cumplen con las mejores prácticas y los principios de privilegios mínimos.

• Comprenda la autorización jerárquica: para operaciones de API en tiempo de ejecuciónInvokeAgentRuntime, como InvokeAgentRuntimeCommandInvokeAgentRuntimeCommandShell, y AWS evalúa las políticas tanto en el tiempo de ejecución del agente como en el punto final del agente. Ambas deben permitir la acción.

• Configure ambos recursos para el acceso entre cuentas: para conceder el acceso entre cuentas, cree políticas basadas en recursos tanto en el entorno de ejecución del agente como en el punto final del agente. Si alguno de los recursos carece de un permiso explícito, se deniega la solicitud.

• Recuerde que la denegación explícita siempre gana: si alguna política (basada en la identidad o en los recursos) deniega explícitamente una acción, se deniega el acceso independientemente de las demás políticas.

• Utilice aws:SourceArn y aws:SourceAccount añada estas condiciones a la política de confianza de su función de ejecución para limitar AgentCore los recursos que pueden asumir esa función:

  {
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": "bedrock-agentcore.amazonaws.com"
        },
        "Action": "sts:AssumeRole",
        "Condition": {
          "StringEquals": {
            "aws:SourceAccount": "123456789012"
          },
          "ArnLike": {
            "aws:SourceArn": "arn:aws:bedrock-agentcore:us-east-1:123456789012:*"
          }
        }
      }
    ]
  }

• Utilice el ARN completo siempre que sea posible: si conoce el recurso de tiempo de ejecución específico, utilice su ARN completo en aws:SourceArn lugar de caracteres comodín.

• Policy-based autorización: utilice el motor de políticas de la puerta de enlace para controlar qué personas que llaman pueden invocar qué objetivos y en qué condiciones. Para obtener más información, consulte Usar políticas para controlar el acceso a los destinos de la puerta de enlace.

• Barandillas: aplique las barandillas Amazon Bedrock a través del motor de políticas para filtrar las solicitudes y las respuestas. Para obtener más información, consulte Uso de barandas en las políticas.

• Interceptores de solicitudes y respuestas: inspeccione o transforme el tráfico con las funciones Lambda de los interceptores configuradas en la puerta de enlace.

• Tiempos de ejecución de IAM (SiGv4): adjunte una política basada en recursos que restrinja la invocación a la función de ejecución de la puerta de enlace. Consulte Restringir la invocación entrante de IAM (SiGv4) a su puerta de enlace.

• Tiempos de ejecución de OAuth (JWT): se configuran en el autorizador del tiempo de ejecución. allowedWorkloadConfiguration Consulta Restringir la invocación a tu puerta de enlace.

• Elija el método de autenticación correcto: utilice SiGv4 de IAM para las llamadas internas de servicio a servicio. AWS Utilice la autenticación mediante token portador JWT cuando los usuarios finales se autentiquen directamente a través de un proveedor de identidad. Un entorno de ejecución puede admitir un método a la vez; puede crear versiones independientes para distintos tipos de autenticación.

• Prefiera la identificación JWT-based del usuario para la producción: cuando su agente recupere los tokens de OAuth en nombre de los usuarios finales, prefiera la ruta del token portador de JWT (GetWorkloadAccessTokenForJWT), que valida el emisor, la firma y el vencimiento del token. La UserId ruta (GetWorkloadAccessTokenForUserId/X-Amzn-Bedrock-AgentCore-Runtime-User-Idheader) trata el identificador de usuario como una cadena opaca sin verificación del IdP; utilícela solo para escenarios de desarrollo, inicio rápido o arquitecturas empresariales que resuelvan la identidad del usuario de forma preliminar. Para obtener más información, consulte Obtener el token de acceso a la carga de trabajo.

• Configure completamente los autorizadores de JWT: cuando utilice la autenticación JWT, configure todos los campos de validación disponibles: la URL de descubrimiento, las audiencias permitidas, los clientes permitidos, los ámbitos permitidos y las notificaciones personalizadas obligatorias.

• Nunca codifique los tokens de forma rígida en el código de producción: utilice mecanismos seguros de recuperación de tokens. Los tokens codificados representan un riesgo de seguridad en el control de código fuente y en los artefactos desplegados.

• Obtenga el identificador de usuario del usuario principal autenticado: si utiliza el X-Amzn-Bedrock-AgentCore-Runtime-User-Id encabezado, el valor debe derivarse del contexto del principal autenticado (identidad de la persona que llama de IAM o declaraciones de token de usuario), no de valores arbitrarios proporcionados por el cliente. Esto evita que los usuarios autenticados se hagan pasar por otros usuarios.

• Denegar ForUserId cuando no sea necesario: en el caso de las cargas de trabajo en las que siempre haya un JWT disponible, bedrock-agentcore:GetWorkloadAccessTokenForUserId denéguelo de forma explícita en las políticas de IAM. bedrock-agentcore:InvokeAgentRuntimeForUser Esto garantiza que todas las identificaciones de los usuarios pasen por la ruta JWT verificada criptográficamente.

• Configure las políticas de puntos finales de la VPC para su método de autenticación: las políticas de puntos finales de la VPC solo pueden restringir las llamadas en función de los directores de IAM, no de los usuarios de OAuth. Para las OAuth-based solicitudes, configúrelo en la política de puntos finales. Principal * Para la SigV4-based autenticación, especifique las identidades de IAM permitidas.

• Utilice AgentCore Identity para la autenticación saliente: AgentCore Identity administra las credenciales de OAuth y las claves de API de forma segura, lo que evita que las credenciales queden expuestas en el código o los registros de los agentes. Úsala para todos los accesos a servicios de terceros (Slack, Zoom). GitHub

• Conozca la exposición de las credenciales del MMDS: el servicio de metadatos de microVM (MMDS) proporciona credenciales de función de ejecución para cualquier código que se ejecute en la máquina virtual, de forma similar al IMDS de EC2. Limite los permisos de las funciones de ejecución únicamente a lo que necesite su agente.

• Habilite MMDSv2: a partir del 30 de junio de 2026, los tiempos de ejecución de sus agentes deben tener MMDSv2 activado. Los tiempos de ejecución sin MMDSv2 activado no se pueden invocar y devuelven un. ValidationException Para activarlo, llame UpdateAgentRuntime con la requireMMDSV2 configuración in. true metadataConfiguration Para obtener más información sobre cómo resolver este error, consulte Solución de problemas con MMDSv2 ValidationException .

• Ejecute contenedores como usuarios no root: al crear imágenes de contenedores personalizadas, configúrelas para que se ejecuten como usuarios no root. Esto limita el impacto de las posibles vulnerabilidades de ejecución de código.

• Credenciales independientes delegadas por el usuario y autónomas: utilice la autenticación delegada por el usuario (concesión de código de autorización) cuando su agente actúe en nombre de un usuario específico. Utilice la autenticación autónoma (concesión de credenciales de cliente) cuando el agente funcione de forma independiente.

• Implemente tiempos de ejecución en una VPC para el acceso a recursos privados: configure la conectividad de la VPC para acceder a bases de datos privadas, API internas y servicios sin exponerlos a Internet. Para obtener detalles de configuración, consulte Configurar el AgentCore tiempo de ejecución para VPC.

• Úselo AWS PrivateLink para el acceso a la API: cree puntos finales de VPC de interfaz para el plano de AgentCore datos (com.amazonaws.region.bedrock-agentcore) y el plano de control (com.amazonaws.region.bedrock-agentcore-control) para evitar el cruce de Internet. Para obtener más información, consulte Uso. AWS PrivateLink

• Aplique el mínimo privilegio a los grupos de seguridad: defina reglas de salida que permitan solo el tráfico mínimo requerido. No abra un acceso saliente amplio a menos que sea necesario.

• Configure los puntos de enlace de VPC necesarios para los agentes de contenedor: en el caso de los agentes de VPC-mode contenedor, configure los puntos de enlace de VPC para ECR (com.amazonaws.region.ecr.dkr,com.amazonaws.region.ecr.api), S3 (punto de enlace de com.amazonaws.region.s3 enlace) y Logs (). CloudWatch com.amazonaws.region.logs El punto de enlace S3 elimina los cargos de procesamiento de datos de la puerta de enlace NAT para extraer la capa de imágenes de ECR.

• Limite la política de puntos de enlace de la puerta de enlace de S3 para los agentes de contenedores: restrinja la política de puntos de enlace de la puerta de enlace de S3 solo al depósito que Amazon ECR utiliza para el almacenamiento de la capa de imágenes:

  {
    "Statement": [
      {
        "Sid": "AllowECRLayerAccess",
        "Principal": "*",
        "Action": [
          "s3:GetObject"
        ],
        "Effect": "Allow",
        "Resource": ["arn:aws:s3:::prod-region-starport-layer-bucket/*"]
      }
    ]
  }

  regionSustitúyalo por el identificador de su AWS región (por ejemplo,us-east-2).

• Aplique la política de puntos finales de la puerta de enlace de S3 a los agentes de despliegue de código directo: en el caso de las implementaciones basadas en código zip, restrinja la política al grupo de artefactos de código propiedad del servicio interno. Añada una aws:PrincipalServiceName condición para garantizar que solo el director del AgentCore servicio pueda acceder a los buckets mediante esta política de puntos finales:

  {
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": "*",
        "Action": "s3:GetObject",
        "Resource": [
          "arn:aws:s3:::acr-code-*-region-an",
          "arn:aws:s3:::acr-code-*-region-an/*"
        ],
        "Condition": {
          "StringEquals": {
            "aws:PrincipalServiceName": "bedrock-agentcore.amazonaws.com"
          }
        }
      }
    ]
  }

  regionSustitúyalo por el identificador de tu AWS región (por ejemplo,us-west-2). Los depósitos AgentCore de artefactos de código se crean en los depósitos de uso general del espacio de nombres regional de la cuenta. Solo AWS puede ser propietario de los nombres de bucket reales utilizados por el servicio. La aws:PrincipalServiceName condición garantiza que solo el principal del AgentCore servicio pueda acceder a los depósitos a través de esta política de puntos finales. Si también utilizas sistemas de archivos persistentes, añade el depósito de almacenamiento de sesiones a esta política. Para obtener más información, consulte Configurar el AgentCore tiempo de ejecución para VPC.

• Utilice subredes privadas con puertas de enlace NAT: las subredes públicas no proporcionan acceso a Internet durante Runtime. AgentCore Coloque siempre las ENI en tiempo de ejecución en subredes privadas con una ruta a una puerta de enlace NAT para el acceso saliente a Internet.

• Seguridad en el transporte: todas las conexiones utilizan TLS 1.2 o superior. WebSocket las conexiones, incluidasInvokeAgentRuntimeCommandShell, utilizan WSS (WebSocket seguro) exclusivamente a través de HTTPS. No se admiten ws:// las conexiones de texto sin formato.

• Imponga límites de encabezados: los encabezados personalizados están limitados a 4 KB por valor y 20 encabezados por tiempo de ejecución. El Authorization encabezado está reservado para los agentes con acceso entrante de OAuth.

• Cifrado en tránsito: todas las comunicaciones entre los clientes y AgentCore Runtime, y entre AgentCore Runtime y sus dependencias, están protegidas mediante TLS 1.2 o superior. Está configurado de forma predeterminada y no requiere ninguna configuración adicional.

• Cifrado en reposo: los datos en reposo se cifran mediante claves de cifrado AWS propias del Servicio de administración de AWS claves (AWS KMS) de forma predeterminada.

• Utilice TLS 1.3 siempre que sea posible: si bien TLS 1.2 es el mínimo, se AWS recomienda TLS 1.3 para mejorar la seguridad y el rendimiento.

• Habilite el CloudTrail registro: AWS CloudTrail registra las llamadas a la APIInvokeAgentRuntime, incluidas las operaciones del plano de control InvokeAgentRuntimeCommandInvokeAgentRuntimeCommandShell, y las operaciones del plano de control. Cada registro incluye la identidad de la persona que llama, la marca de tiempo, la dirección IP de origen y el estado de la respuesta.

• Usa CloudWatch los registros para auditar los comandos: AgentCore Runtime envía el identificador de la solicitud y el comando de entrada al grupo de CloudWatch registros de tu agente. Utilice estos registros para mantener un registro de auditoría de los comandos ejecutados en sus sesiones.

• Correlaciona los registros mediante los ID de solicitud: usa el ID de solicitud para correlacionar CloudTrail los registros (quién llamó a la API) con CloudWatch los registros (qué comando se ejecutó).

• Configure filtros métricos y alarmas: configure los filtros métricos de los CloudWatch registros para detectar patrones de comandos inesperados o intentos de acceso no autorizados. Crea alarmas para avisar a tu equipo de cualquier anomalía.

• Registre las relaciones de delegación de identificadores de usuario: cuando utilice el X-Amzn-Bedrock-AgentCore-Runtime-User-Id encabezado, registre la relación entre el principal de IAM autenticado y el valor del identificador de usuario con fines de auditoría.

• Habilitar los registros de flujo de VPC: para los VPC-connected tiempos de ejecución, habilite los registros de flujo de VPC para auditar el tráfico a nivel de red e identificar patrones de comunicación inesperados.

• Revise CloudTrail los registros con regularidad: revise periódicamente los registros para detectar intentos de acceso no autorizados, especialmente en el caso de las cargas de trabajo delicadas.

AWS responsabilidades:

• Infraestructura segura y aislamiento de microVM a nivel de hardware

• Aplicación de parches al núcleo del sistema operativo para todos los modos de implementación

• Aplicación de parches en tiempo de ejecución del lenguaje para despliegues directos de código

• Seguridad de la infraestructura de red

• Disponibilidad y resiliencia del servicio

Sus responsabilidades:

• Gestión de dependencias y seguridad del código de agente

• Controles de acceso y políticas de recursos de IAM

• Seguridad de los comandos ejecutados en las sesiones de ejecución

• Session-to-user aplicación de la cartografía

• Actualizaciones de imágenes de contenedores (para despliegues de contenedores): reconstruya periódicamente con la imagen base segura más reciente

• Validación de entradas y prevención de inyecciones rápidas, incluida la validación de las InvokeHarness entradas cuando se utiliza el arnés gestionado (consulte El arnés comparte el límite de confianza en el AgentCore tiempo de ejecución)

• Configuración de red (grupos de seguridad, puntos finales de VPC, tablas de enrutamiento)

• InvokeAgentRuntimeCommand— One-shot, se ha HTTP/2 completado la ejecución de comandos no interactivos. Acción de IAM:. bedrock-agentcore:InvokeAgentRuntimeCommand

• InvokeAgentRuntimeCommandShell— Sesión de WebSocket shell interactiva con acceso PTY persistente. Acción de IAM:. bedrock-agentcore:InvokeAgentRuntimeCommandShell

• Comprenda el límite de seguridad: los comandos tienen acceso completo al sistema de archivos del contenedor y a cualquier credencial o secreto configurado en la microVM. El límite de aislamiento es la propia microVM. Según el modelo de responsabilidad compartida, usted es responsable de la seguridad de cualquier código que se ejecute en su contenedor de tiempo de ejecución.

• Utiliza operaciones deterministas para tareas deterministas: utilízalas InvokeAgentRuntimeCommand o InvokeAgentRuntimeCommandShell para operaciones como pruebas, git y compilaciones. No dirija las operaciones deterministas a través de la LLM. InvokeAgentRuntime

• Restrinja quién puede ejecutar comandos: utilice las políticas de IAM para limitar qué directores pueden llamar a o. InvokeAgentRuntimeCommand InvokeAgentRuntimeCommandShell No todos los usuarios que pueden invocar un agente deberían poder ejecutar comandos arbitrarios. Ejemplo de ARN de recurso:. arn:aws:bedrock-agentcore:us-west-2:123456789012:runtime/my-agent

• WebSocket shell solo usa wss://; InvokeAgentRuntimeCommandShell las conexiones se establecen exclusivamente a través de WSS (WebSocket seguro). No se admiten ws:// las conexiones de texto simple. Las personas que llaman se autentican mediante SiGv4 en el momento de la actualización. WebSocket

• Mantenga el tráfico dentro de su red: configure los puntos finales de la VPC para evitar el cruce de Internet para las llamadas a la API de ejecución de comandos.

• Establezca los tiempos de espera adecuados: configure los tiempos de espera de los comandos en función de la duración prevista de la ejecución para evitar el desperdicio de recursos debido a procesos incontrolados.

• Restrinja el acceso al servidor local en el código del agente: configure su agente y cualquier herramienta de red para evitar el acceso sin restricciones al servidor local. El código del agente no debe realizar llamadas HTTP arbitrarias a localhost a menos que sea necesario para una integración específica.

• Incluya en la lista solo los puertos necesarios para las configuraciones de sidecar: si su arquitectura utiliza un patrón contenedor dentro de un contenedor o sidecar en localhost, permita explícitamente incluir en la lista solo los puertos específicos que utilizan sus servicios de sidecar. No abra un acceso amplio a localhost.

• Audite las herramientas de red para determinar el alcance de los hosts locales: revise todas las herramientas que le proporcione a su agente (como las herramientas de solicitud HTTP o las utilidades generales de red) para asegurarse de que no puedan realizar solicitudes no deseadas a los puntos finales del servidor local. Aplica el filtrado de URL o permite la inclusión en las listas a nivel de herramienta.