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 de los límites de las máquinas virtuales. Una vez finalizada la sesión, se cierra toda la microVM y se desinfecta la memoria.

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

• Tenga en cuenta el comportamiento de los sistemas de archivos con respecto a los permisos: cuando se utilizan sistemas de archivos persistentes, los permisos se almacenan pero no se aplican dentro de 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 micromáquina virtual puede acceder a las credenciales del rol de ejecución llamando al punto final de metadatos (MMDS). Determine con cuidado los permisos de su rol 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 para fines de desarrollo y pruebas. Estos permisos permiten un acceso amplio y no son adecuados para la producción. Cree políticas de IAM personalizadas que restrinjan los permisos solo a los recursos y acciones específicos necesarios. Para ver la referencia completa, consulta los permisos de IAM para AgentCore el tiempo de ejecución.

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

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

• Denegar la delegación de identificadores de usuario cuando no sea necesaria: en tiempos de ejecución en los que no sea necesaria la delegación de identificadores 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/*"
        }
     ]
  }

• Impida la escalada de privilegios: asegúrese de que el rol de ejecución asociado a su tiempo de ejecución tenga los mismos o menos privilegios que los de los directores que pueden invocarlo. Para obtener más información, consulte Administración de credenciales.

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

• Usa IAM Access Analyzer: valida tus políticas de IAM para asegurarte de que cumplen con las prácticas recomendadas y los principios de mínimos privilegios.

• Comprenda la autorización jerárquica: para las operaciones de la 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 los recursos tanto en el tiempo 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.

• Recuerda 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 sus funciones de ejecución para limitar AgentCore los recursos que pueden asumir la 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:*"
          }
        }
      }
    ]
  }

• Usa el ARN completo siempre que sea posible: si conoces el recurso de tiempo de ejecución específico, usa su ARN completo en aws:SourceArn lugar de comodines.

• Exija el tipo de cadena en el campo de solicitud: el que recibe payload su punto de entrada se analiza a partir de un JSON arbitrario. La persona que llama puede enviar un valor que no sea una cadena (como una lista o un objeto) en el campo. prompt Si el marco de su agente acepta bloques de contenido que no sean cadenas, especialmente toolUse bloques, el marco puede enviar una herramienta directamente. Esto evita el razonamiento modelo, las barreras y la aplicación rápida del sistema. Compruebe siempre que la solicitud es una cadena antes de pasarla al agente:

  @app.entrypoint
  def invoke(payload, context):
      user_message = payload.get("prompt", "")
      if not isinstance(user_message, str) or not user_message.strip():
          return {"error": "Invalid input: 'prompt' must be a non-empty string"}
      result = agent(user_message)
      return {"response": result.message}

• Rechazar o eliminar los bloques de toolUse contenido: si su agente acepta matrices de mensajes estructurados (para conversaciones con varios turnos), filtre los bloques de toolUse contenido de los mensajes proporcionados por los usuarios. Un toolUse bloqueo en el historial de mensajes puede provocar que el bucle de eventos del marco del agente ejecute la herramienta indicada inmediatamente sin evaluar el modelo.

• Valide la estructura de la carga útil con un esquema: utilice Pydantic, Zod o una biblioteca de esquemas equivalente para garantizar que el cuerpo de la solicitud se ajuste a la estructura esperada. Defina prompt como str (no) en su esquema: Any

  from pydantic import BaseModel
  
  class InvocationRequest(BaseModel):
      prompt: str  # Enforces string type at the schema level

• No confíe en los valores predeterminados como validación: un patrón como el que payload.get("prompt", "Hello") proporciona un valor predeterminado pero no rechaza la entrada que no sea una cadena. El valor devuelto es el que ha enviado la persona que llama, que puede ser un dictado o una lista que contenga bloques de contenido.

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

• Barreras: aplique Amazon Bedrock Guardrails a través del motor de políticas para filtrar las solicitudes y respuestas. Para obtener más información, consulte Usar barreras de protección en las políticas.

• Interceptores de solicitud y respuesta: inspeccione o transforme el tráfico con las funciones del interceptor Lambda configuradas en la puerta de enlace.

• Tiempos de ejecución de IAM (SIGv4): adjunte una política basada en los 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): configúralos 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 de servicio a servicio interno. AWS Utilice la autenticación mediante el token portador de JWT cuando los usuarios finales se autentiquen directamente a través de un proveedor de identidad. Un motor de ejecución puede admitir un método a la vez; crea versiones independientes para diferentes 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 el token path (GetWorkloadAccessTokenForJWT) del portador de JWT, que valida el emisor, la firma y la caducidad del token. La UserId ruta (X-Amzn-Bedrock-AgentCore-Runtime-User-IdencabezadoGetWorkloadAccessTokenForUserId/) trata el identificador de usuario como si fuera una cadena opaca sin necesidad de verificar el IdP. Utilízala únicamente para proyectos de desarrollo, escenarios de inicio rápido o arquitecturas empresariales que resuelvan la identidad de los usuarios en etapas iniciales. 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 de 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 requeridas.

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

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

• Denegar ForUserId cuando no sea necesario: en el caso de las cargas de trabajo que siempre tienen un JWT disponible, bedrock-agentcore:GetWorkloadAccessTokenForUserId denégalo de forma explícita y en las políticas de IAM. bedrock-agentcore:InvokeAgentRuntimeForUser Esto garantiza que toda la identificación de los usuarios pase por la ruta JWT verificada criptográficamente.

• Configure las políticas de punto final de la VPC para su método de autenticación: las políticas de punto final de la VPC solo pueden restringir a las personas que llaman basándose en los principios de IAM, no en los usuarios de OAuth. Para las OAuth-based solicitudes, configúralo en la política de terminales. Principal * Para la SigV4-based autenticación, especifique las identidades de IAM permitidas.

• Usa 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 acceder a todos los servicios de terceros (Slack, Zoom). GitHub

• Comprenda la exposición de credenciales al MMDS: el servicio de metadatos de microVM (MMDS) proporciona credenciales de funciones 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 los requisitos de su agente.

• Habilite MMDSv2: a partir del 30 de junio de 2026, los tiempos de ejecución de sus agentes deben tener habilitado MMDSv2. Los tiempos de ejecución sin MMDSv2 activado no se pueden invocar y devolver un. ValidationException Para habilitarlo, llama UpdateAgentRuntime con la opción requireMMDSV2 configurada true en inmetadataConfiguration. Para obtener más información sobre cómo resolver este error, consulte Solución de problemas de MMDSv2 ValidationException .

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

• Credenciales autónomas y delegadas por el usuario separadas: 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 opere de forma independiente.

• Implemente tiempos de ejecución en una VPC para acceder 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 más información sobre la configuración, consulte Configurar el tiempo de AgentCore ejecución para una VPC.

• Úselo AWS PrivateLink para acceder 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 que Internet atraviese Internet. Para obtener más información, consulte Uso. AWS PrivateLink

• Conceda los privilegios mínimos 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 la VPC necesarios para los agentes de contenedores: en el caso de los agentes de VPC-mode contenedores, configure los puntos de enlace de la VPC para ECR (com.amazonaws.region.ecr.dkr,com.amazonaws.region.ecr.api), S3 (punto final de com.amazonaws.region.s3 puerta de enlace) y Logs (). CloudWatch com.amazonaws.region.logs El punto final de la puerta de enlace S3 elimina los cargos por procesamiento de datos de la puerta de enlace NAT para las extracciones de la capa de imágenes ECR.

• Amplíe 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 bucket 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).

• Aplica la política de terminales de S3 Gateway a los agentes de implementación directa de código: en el caso de las implementaciones basadas en zip, restringe la política al depósito interno de artefactos de código propiedad del servicio. Añada una aws:PrincipalServiceName condición para garantizar que solo el principal del AgentCore servicio pueda acceder a los buckets mediante esta política de terminales:

  {
    "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 su AWS región (por ejemplo,us-west-2). Los cubos AgentCore de artefactos de código se crean en los cubos de uso general del espacio de nombres regional de la cuenta. Solo AWS pueden ser propietarios de los nombres de los cubos reales que utiliza el servicio. La aws:PrincipalServiceName condición garantiza que solo el principal del AgentCore servicio pueda acceder a los buckets a través de esta política de terminales. Si también usas sistemas de archivos persistentes, agrega el depósito de almacenamiento de sesión a esta política. Para obtener más información, consulta 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 de transporte: todas las conexiones utilizan TLS 1.2 o superior. WebSocket las conexiones, incluidasInvokeAgentRuntimeCommandShell, utilizan exclusivamente WSS (WebSocket seguro) a través de HTTPS. No se admiten ws:// las conexiones de texto sin formato.

• Aplica límites de encabezados: los encabezados personalizados están limitados a 4 KB por valor y a 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, se protegen mediante TLS 1.2 o una versión superior. Está configurado de forma predeterminada y no requiere ninguna configuración adicional.

• Cifrado en reposo: los datos en reposo se cifran con las 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, AWS recomienda TLS 1.3 para mejorar la seguridad y el rendimiento.

• Habilite el CloudTrail registro: AWS CloudTrail registra las llamadas a la API InvokeAgentRuntime InvokeAgentRuntimeCommandInvokeAgentRuntimeCommandShell, incluidas las operaciones del plano de control, y. 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.

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

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

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

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

• Habilite los registros de flujo de la VPC: para los VPC-connected tiempos de ejecución, habilite los registros de flujo de la 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 cargas de trabajo delicadas.

AWS responsabilidades:

• Infraestructura segura y aislamiento de microVM a nivel de hardware

• Parches del kernel del sistema operativo para todos los modos de implementación

• Parches de lenguaje en tiempo de ejecución para despliegues directos de código

• Seguridad de la infraestructura de red

• Disponibilidad y resiliencia de los servicios

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 mapas

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

• Validación de entradas y prevención de la inyección inmediata, incluida la validación de las InvokeHarness entradas cuando se utiliza el arnés administrado (consulte Harness comparte el límite de confianza en el AgentCore tiempo de ejecución)

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

• InvokeAgentRuntimeCommand— One-shot, finalización de la ejecución de comandos no interactivos. HTTP/2 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 los límites de seguridad: los comandos tienen acceso total al sistema de archivos del contenedor y a todas las credenciales o secretos configurados 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.

• Usa operaciones deterministas para tareas deterministas: usa InvokeAgentRuntimeCommand o InvokeAgentRuntimeCommandShell para operaciones como pruebas, git y compilaciones. No dirija las operaciones deterministas a través del LLM via. InvokeAgentRuntime

• Restrinja quién puede ejecutar comandos: utilice las políticas de IAM para limitar qué directores pueden llamar o. InvokeAgentRuntimeCommand InvokeAgentRuntimeCommandShell No todos los usuarios que pueden invocar a 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 sin formato. 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 que las llamadas a la API de ejecución de comandos se transmitan a Internet.

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

• Restrinja el acceso a localhost en el código del agente: configure su agente y cualquier herramienta de red para evitar el acceso sin restricciones a localhost. 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 solo los puertos obligatorios para las configuraciones de sidecar: si su arquitectura usa un patrón de contenedor dentro de contenedor o sidecar en localhost, incluya explícitamente en la lista los puertos permitidos solo los puertos específicos que usan sus servicios de sidecar. No abras un acceso amplio a localhost.

• Controle el alcance de las herramientas de red a nivel local: revise las herramientas que proporcione a su agente (como las herramientas de solicitud HTTP o las utilidades de red generales) para asegurarse de que no puedan realizar solicitudes no deseadas a los puntos finales del host local. Aplica el filtrado de URL o las listas de direcciones permitidas a nivel de herramienta.