AWS AgentCore Harness — Exfiltración de Credenciales de Identidad mediante Inyección de Prompts en Entornos de IA (N/A)

Fecha de publicación: 18 de septiembre de 2026
Categoría: AI attacks (LLM/LocalAI)

Introducción

Investigadores de la unidad de amenazas de Palo Alto Networks (Unit 42) identificaron un problema crítico de arquitectura y configuración predeterminada en AWS AgentCore Harness, un entorno de ejecución gestionado para agentes de inteligencia artificial. El fallo permite que un atacante, mediante técnicas indirectas de inyección de prompts (prompt injection), manipule el comportamiento de un agente para ejecutar comandos de sistema y exfiltrar credenciales corporativas almacenadas en texto plano dentro del espacio de memoria del runtime (PID 1). Aunque AWS cerró el reporte como meramente informativo bajo el modelo de responsabilidad compartida, el hallazgo pone de manifiesto la peligrosa brecha existente entre los mecanismos de almacenamiento cifrado (vaults) y la ejecución dinámica de herramientas en tiempo de ejecución.

¿Qué es AWS AgentCore Harness y el Riesgo de la Memoria en Uso? (Análisis General)

AWS AgentCore Harness es un entorno administrado diseñado para simplificar el despliegue de agentes de IA, encargándose del aprovisionamiento de infraestructura, cómputo, redes y herramientas integradas. Entre sus capacidades predeterminadas, el harness incluye dos herramientas nativas habilitadas por defecto: shell (para ejecutar comandos Bash) y file_operations (para manipulación de archivos).

Para integrarse con servicios externos, la plataforma utiliza AWS AgentCore Identity, una bóveda (identity vault) que cifra credenciales en reposo y en tránsito mediante claves KMS. Sin embargo, para que el agente pueda autenticarse ante servicios externos —como servidores Model Context Protocol (MCP)—, el identificador ARN almacenado en la bóveda debe resolverse obligatoriamente a un token en texto plano (por ejemplo, un JSON Web Token o JWT) en el espacio de memoria del proceso principal (PID 1).

Dado que la herramienta shell viene habilitada por defecto y se ejecuta con privilegios de root en el mismo espacio de proceso, un atacante que logre inyectar instrucciones puede leer la memoria directamente y extraer las credenciales activas del operador.

Nota técnica sobre Identificadores de Vulnerabilidad: Este incidente no posee un identificador CVE oficial asignado al momento de su divulgación pública. Se clasifica conceptualmente como una debilidad de diseño arquitectónico y exposición de información sensible en memoria, estimándose un vector de severidad CVSS v3.1: 8.6 (Alto) y una clasificación CWE-316 (Cleartext Storage of Sensitive Information in Memory) / CWE-276 (Incorrect Default Permissions) basados en estimaciones razonadas del comportamiento de exposición de privilegios.

¿Cómo funciona? (Análisis Técnico)

El mecanismo de explotación no requiere vulnerabilidades de software complejas, sino que explota la interacción natural entre el razonamiento del modelo de lenguaje, las capacidades predeterminadas del harness y la resolución dinámica de credenciales.

  • Flujo inicial de entrada y ejecución: El atacante introduce una instrucción maliciosa oculta (por ejemplo, mediante un comentario HTML en un ticket de soporte o documento procesado por el agente). Esta inyección fuerza al LLM a invocar la herramienta shell incorporada, ejecutando un comando externo como curl script.py | python3.
  • Escalada y descubrimiento en el espacio de procesos: Una vez dentro del contenedor del harness, el script de reconocimiento ejecuta comandos como whoami y descubre que el proceso hijo y el proceso padre (PID 1, ejecutando python3.10 -m loopy.server) operan bajo el usuario root. Mediante una exploración del sistema de archivos virtual (procfs), el atacante localiza el mapa de memoria en /proc/1/maps y el acceso directo a la memoria física del proceso en /proc/1/mem.
  • Extracción y exfiltración de secretos: El script personalizado recorre las regiones de memoria legibles del heap, buscando patrones de cadenas correspondientes a tokens JWT de autenticación y URLs de servicios downstream (MCP). Una vez identificados, los datos son empaquetados y enviados mediante una petición HTTP POST (curl) hacia un servidor controlado por el atacante (webhook externo), permitiendo la reutilización del token desde internet sin requerir credenciales de AWS.

Sistemas / Entornos Afectados

El problema afecta a despliegues que utilicen configuraciones por defecto de AWS AgentCore Harness, específicamente:

  • Entornos de AWS AgentCore Harness donde el parámetro allowedTools no haya sido estrictamente limitado al inicio de la sesión.
  • Instancias que mantengan habilitadas por defecto las herramientas nativas shell y file_operations.
  • Aplicaciones que utilicen integraciones downstream mediante servidores Model Context Protocol (MCP) autenticados a través de AgentCore Identity.
  • Arquitecturas donde el proceso principal del harness y las herramientas de ejecución compartan el mismo espacio de memoria sin aislamiento de contenedores o privilegios mínimos (root).

Mitigación y Detección

Remediación

  • Restricción estricta de herramientas (allowedTools): Configure explícitamente el parámetro allowedTools durante la invocación (InvokeHarness), deshabilitando las herramientas shell y file_operations si la sesión del agente no las requiere estrictamente.
  • Principio de menor privilegio en Identity Vaults: Limite los alcances y permisos de las cuentas de servicio asociadas a las integraciones downstream para mitigar el impacto en caso de una filtración de tokens.
  • Aislamiento de procesos y sandboxing: Separe la ejecución de herramientas del proceso gestor de credenciales mediante contenedores aislados o usuarios sin privilegios (non-root).

Detección

  • Monitoreo de tráfico saliente (Egress Filtering): Implemente reglas estrictas de filtrado de salida en los contenedores del harness. Cualquier conexión hacia endpoints no autorizados o webhooks externos debe considerarse un indicador inmediato de compromiso (IoC).
  • Auditoría de logs de ejecución: Monitoree la ejecución anómala de intérpretes de comandos (bash, python3) iniciados por procesos de agentes de IA.
bash 
# Ejemplo conceptual de regla de monitoreo/detección de procesos anómalos en contenedores de IA
# Detecta ejecución de shell derivada de procesos de servidor Python (loopy.server)
ps faux | grep -E "python3.*loopy\.server" -A 5 | grep -E "bash|sh|curl.*\|.*python"

“El cifrado en reposo y en tránsito protege los datos en almacenamiento y en red, pero la memoria en uso sigue siendo un punto ciego crítico si el motor de ejecución otorga privilegios de sistema ilimitados al agente.”

Recapitulando

El caso de AWS AgentCore Harness demuestra que a medida que los agentes de IA adquieren mayor autonomía y capacidad de acción mediante herramientas programáticas avanzadas (como interfaces de línea de comandos y shells completos), la superficie de ataque se expande exponencialmente. La capacidad de un atacante para subvertir el razonamiento del modelo mediante inyección de prompts y extraer credenciales directamente de la memoria del proceso principal subraya la necesidad urgente de rediseñar los límites de aislamiento en los runtimes modernos de inteligencia artificial, alejándose de configuraciones predeterminadas permisivas.

Referencias

  • Palo Alto Networks - Unit 42. (2026). A Vault with a Heap-View: The Uncomfortable Space Between AgentCore Harness and Identity. Recuperado de https://unit42.paloaltonetworks.com/?p=187347
  • Amazon Web Services. (2026). Amazon Bedrock AgentCore Developer Guide: AgentCore Harness Tools.
  • Amazon Web Services. (2026). Amazon Bedrock AgentCore Developer Guide: Provide identity and credential management for agent applications with Amazon Bedrock AgentCore Identity.