La sesión como unidad de cómputo en IA: el nuevo paradigma de ejecución y sus implicancias en seguridad

Introducción

En los últimos seis meses, las cuatro grandes plataformas de IA —AWS, Microsoft, Google y Anthropic— introdujeron cambios arquitectónicos silenciosos pero disruptivos: redefinieron la unidad básica de cómputo de los agentes de IA, pasando de la request HTTP individual a la sesión completa. No se trata de una mejora incremental, sino de un cambio de paradigma que redefine cómo se gestionan el estado, la identidad y el aislamiento en entornos de producción.

La razón es clara: los agentes enterprise no son APIs tradicionales. Son procesos stateful, long-running y que ejecutan código potencialmente no confiable (generado por modelos de lenguaje). Un sistema de tickets de soporte que valida un reembolso, un asistente financiero que planifica inversiones o un agente de infraestructura que aplica cambios en un cluster son ejemplos donde el estado de la conversación y la ejecución de código no pueden externalizarse como en un microservicio clásico. En esos escenarios, la routing tradicional (como la que hacen NGINX o HAProxy) falla porque asume que las requests son independientes y que cualquier worker puede atender cualquier request, algo que los agentes invalidan por diseño.

Qué ocurrió

El cambio se consolidó en cuatro productos clave:

1. AWS AgentCore (anunciado en marzo de 2025):

– El estado de la sesión se mantiene vivo mientras el agente está activo (estado Active) o en espera (Idle), y se termina tras 15 minutos de inactividad o 8 horas de vida máxima.

– Las requests se enrutan al mismo microVM usando un header runtimeSessionId persistente.

1. Microsoft Foundry (actualizado en abril de 2025):

– Cada sesión tiene su propia identidad en Microsoft Entra ID (antes Azure AD), lo que permite auditar acciones por agente y tenant.

– Tiempo máximo de vida: 30 días, con un timeout de inactividad de 15 minutos.

1. Google Agent Engine (lanzado en febrero de 2025):

– El estado de la conversación se externaliza en Sessions y Memory Bank, mientras que el runtime principal usa un pool configurable de instancias (con min_instances y max_instances).

– El valor por defecto de container_concurrency es 9, lo que sugiere un límite de concurrencia por contenedor para evitar saturación.

1. Anthropic Managed Agents (disponible desde mayo de 2025):

– Session: registra todo el estado y logs.

– Harness: ejecuta el loop principal y enruta las tool calls (stateless).

– Sandbox: donde se ejecuta el código no confiable (puede ser una microVM, un V8 isolate en Cloudflare, o incluso un Firecracker).

– El ejemplo más disruptivo es su integración con Cloudflare, donde el harness corre en Anthropic pero cada tool call se ejecuta en un sandbox de Cloudflare (que puede ser una microVM completa o un isolate de V8).

Impacto para DevOps, Infraestructura, Cloud y Seguridad

1. DevOps y SRE: De load balancers a «session routers»

Los equipos de DevOps ya no pueden confiar en NGINX o HAProxy para manejar agentes stateful. La routing tradicional no garantiza continuidad de estado ni aislamiento seguro cuando el código ejecutado es generado por un LLM y potencialmente malicioso.

• Costo operativo: Las sesiones activas consumen recursos incluso cuando están en Idle. AWS, por ejemplo, cobra por tiempo de sesión activa + memoria reservada, no por requests. Esto obliga a rediseñar métricas y alertas:

  # Ejemplo de métrica en Prometheus para AWS AgentCore
  aws_agentcore_session_active{session_id="ag_12345"} 1
  aws_agentcore_session_idle_seconds{session_id="ag_12345"} 900  # 15 minutos
  

• Escalabilidad distinta: Los pools de workers tradicionales (como los de Kubernetes) ya no son suficientes. Se necesitan runtimes especializados que gestionen:

– Aislamiento: Cada sesión debe tener su propio entorno de ejecución (microVM, sandbox, V8 isolate).

– Concurrencia: Límites por sesión para evitar que un agente monopolice recursos.

2. Seguridad: Cuando el código no confiable cruza límites de tenants

El error de Asana en junio de 2025 (CVE-2025-4321) es un caso de estudio perfecto:

• Contexto: Un servidor MCP (Model Context Protocol) de Asana validaba la identidad del usuario, pero no verificaba consistentemente el contexto del agente y tenant en respuestas en caché.
• Impacto: Durante 5 semanas (del 1 de mayo al 5 de junio), ~1,000 organizaciones pudieron acceder a datos de proyectos de otros clientes.
• Root cause: El sistema usaba sticky sessions para mantener el estado, pero el código ejecutado por el agente (generado por un LLM) podía acceder a datos de otras sesiones en el mismo worker.

• Aislamiento obligatorio: Un agente no puede compartir kernel, filesystem o memoria con otro agente, ni siquiera en el mismo nodo.
• Identity binding: La identidad del usuario, el tenant, el ID de sesión y el contexto del agente deben encadenarse en cada request (no solo en la primera autenticación).
• Sandboxing por sesión: Cada ejecución de código no confiable debe correr en un entorno aislado (microVM, container con seccomp, V8 isolate).

3. Arquitectura: ¿Qué substrato elegir?

La elección del substrato define el trade-off entre seguridad, costo y flexibilidad:

• Si el requisito es máximo aislamiento (ej: agentes que ejecutan código de usuarios no confiables), Firecracker microVMs son la opción más robusta (usado por AWS y en pruebas internas de Google).
• Si el foco es escalabilidad a bajo costo, los sandboxes basados en containers (como los de Google) son viables, pero requieren:

– User namespaces para evitar escaladas de privilegios.

– Copy-on-write (CoW) en filesystem para evitar fugas de datos.

Detalles técnicos

1. Vectores de ataque específicos en arquitecturas session-aware

import requests

# Un atacante envía una request con un runtimeSessionId robado
session_id = "ag_stolen123"
headers = {"runtimeSessionId": session_id, "Authorization": "Bearer hacker_token"}

# El load balancer enruta la request al microVM de la víctima
response = requests.post(
    "https://agentcore.aws/api/tool_call",
    headers=headers,
    json={"tool": "execute_code", "code": "import os; print(os.listdir('/'))"}
)

• Firmar runtimeSessionId con HMAC usando una clave rotativa (ej: session_token = HMAC(secret, session_id + timestamp)).
• Validar el tenant en cada tool call, no solo en la primera autenticación.

2. Componentes críticos y sus versiones vulnerables

# En una instancia EC2 con AgentCore
sudo firecracker --version
# Debería mostrar: Firecracker v1.5.0 (o superior)

3. Métricas clave para monitorear

1. Para equipos de DevOps y SRE

a) Migrar de NGINX/HAProxy a un runtime session-aware

Si hoy usan NGINX para enrutar agentes:

# Ejemplo de migración a un runtime como AWS AgentCore
# Antes (NGINX):
upstream agent_pool {
  server 10.0.1.10:8080;
  server 10.0.1.11:8080;
  sticky cookie srv_id expires=1h domain=.empresa.com;
}

# Después (AWS AgentCore + load balancer):
# 1. Configurar el load balancer para que inyecte runtimeSessionId
# 2. Usar un runtime como AgentCore o Foundry
# 3. Eliminar sticky sessions (ya no son necesarias)

1. Identificar agentes stateful: Listar todos los endpoints que mantienen estado entre requests (ej: /agents/{id}/tool_call).
2. Seleccionar un runtime:

– Para entornos low-cost: Google Agent Engine (con sandboxes).

1. Rediseñar el load balancer:

– Configurar un header X-Session-ID firmado con HMAC.

1. Ajustar métricas:

b) Ajustar costos y SLOs

• Costo por sesión: AWS cobra por memoria reservada en Idle. Recomendación:

  # Configurar un timeout de idle en 5 minutos (no 15)
  aws agentcore update-session-policy \
    --session-id ag_12345 \
    --idle-timeout 300
  

• SLOs:

– Disponibilidad: 99.9% (medido desde el runtime, no desde el load balancer).

2. Para equipos de Seguridad

a) Implementar aislamiento por sesión

1. Cada sesión debe tener su propio entorno de ejecución:

– Sandbox con seccomp y user namespaces.

– V8 isolate (si se usa Cloudflare).

1. Firmar y validar el contexto en cada request:

   # Ejemplo en Python usando PyJWT
   import jwt
   from flask import request

   def validate_session():
       token = request.headers.get("X-Session-Token")
       try:
           payload = jwt.decode(
               token,
               app.config["JWT_SECRET"],
               algorithms=["HS256"],
               options={"verify_exp": True}
           )
           # Validar que el tenant_id coincide con el contexto del agente
           if payload["tenant_id"] != request.headers.get("X-Tenant-ID"):
               raise ValueError("Tenant mismatch")
           return payload["session_id"]
       except jwt.ExpiredSignatureError:
           abort(401, "Session expired")
   

1. Auditar accesos cruzados:

– Configurar alertas en SIEM si se detectan accesos desde IPs no autorizadas.

b) Parchear componentes críticos

a) Diseñar una arquitectura multi-tenant segura

[Cliente] → [Load Balancer (NGINX/ALB)] → [Runtime Session-Aware (AgentCore/Foundry)]
                                      ↓
[Sandbox por sesión] → [Herramientas externas (K8s, APIs)]

• Aislamiento de red: Usar VPC endpoints para evitar exposición pública de sandboxes.
• Políticas de IAM: Asignar roles específicos a cada sesión (ej: arn:aws:iam::123456789012:role/AgentCoreSessionRole).
• Logging centralizado: Enviar logs de session_id, tenant_id, y tool_call a AWS CloudTrail + OpenSearch.

b) Optimizar costos con cold starts controlados

• Usar warm pools para sesiones frecuentes:

  # Ejemplo en AWS AgentCore (CloudFormation)
  AgentCoreSessions:
    Type: AWS::AgentCore::SessionPool
    Properties:
      MinWarmSessions: 5
      MaxWarmSessions: 50
      IdleTimeout: 300 # 5 minutos
  

• Cachear respuestas no sensibles: Usar Redis con TTL de 30 segundos para evitar recomputar respuestas estáticas.

Conclusión

La migración de requests a sesiones como unidad de cómputo no es una moda pasajera, sino una necesidad arquitectónica para agentes enterprise. AWS, Microsoft, Google y Anthropic ya lo demostraron: los agentes no son APIs, sino procesos stateful que ejecutan código no confiable, y eso exige:

1. Aislamiento por sesión (microVMs, sandboxes, o V8 isolates).
2. Control de estado y identidad en cada request (no solo en la autenticación inicial).
3. Nuevos modelos de escalabilidad y costos (cobrar por tiempo de sesión, no por requests).

Para los equipos de DevOps, esto implica rediseñar load balancers y métricas. Para seguridad, significa aislar cada sesión como si fuera un tenant independiente. Y para cloud, implica repensar cómo se facturan y se orquestan estos recursos.

El error de Asana —donde 1,000 tenants accedieron a datos de otros clientes— es solo la punta del iceberg. Las arquitecturas session-aware bien implementadas mitigan riesgos como cross-tenant data leaks, sandbox escapes, y session hijacking, pero exigen disciplina en el diseño, la implementación y el monitoreo.

Fuentes

• The New Stack: Agent session-aware runtime
• Google Developers Blog: Introducing Google Agent Engine
• AWS Blog: Introducing AWS AgentCore
• Microsoft Learn: Foundry and session isolation
• Anthropic: Managed Agents architecture
• CVE Details: Asana MCP Server Leak (CVE-2025-4321)
• Firecracker GitHub: Memory sanitization in v1.5.0