Tutorial de Sandboxing de Agentes: Construyendo Aplicaciones LLM Seguras

Introducción al Sandboxing de Agentes

A medida que los Modelos de Lenguaje Grande (LLMs) evolucionan de simples agentes conversacionales a poderosas entidades autónomas capaces de ejecutar código, interactuar con APIs externas y tomar decisiones en el mundo real, la necesidad de medidas de seguridad sólidas se vuelve primordial. Un agente LLM, al recibir la capacidad de actuar, puede convertirse en un riesgo de seguridad significativo si no se limita adecuadamente. Aquí es donde entra en juego el sandboxing de agentes. Sandboxing un agente significa crear un entorno aislado donde puede operar sin afectar al sistema anfitrión ni acceder a recursos no autorizados. Este tutorial explorará los aspectos prácticos del sandboxing de agentes, proporcionando ejemplos prácticos para demostrar cómo construir aplicaciones LLM seguras y confiables.

El principio básico detrás del sandboxing es el de menor privilegio: un agente solo debe tener acceso a los recursos absolutamente necesarios para su función, y nada más. Sin un sandboxing adecuado, un agente malicioso o erróneo podría:

• Ejecutar código arbitrario en el sistema anfitrión, lo que podría llevar al robo de datos o a la comprometida del sistema.
• Acceder a archivos sensibles o recursos de red.
• Iniciar llamadas no deseadas a APIs externas, incurriendo en costos o realizando acciones no autorizadas.
• Exfiltrar datos confidenciales a través de varios canales.

Al implementar un sandboxing eficaz, podemos mitigar estos riesgos, permitiéndonos usar el inmenso poder de los agentes LLM mientras mantenemos el control y la seguridad.

Comprendiendo las Amenazas: ¿Por Qué Sandboxing?

Antes de explorar el ‘cómo,’ solidifiquemos el ‘por qué.’ Las amenazas planteadas por agentes no sandboxed son multifacéticas y se pueden categorizar como sigue:

1. Vulnerabilidades de Ejecución de Código

Muchos agentes LLM avanzados están diseñados para escribir y ejecutar código (por ejemplo, scripts de Python) para resolver problemas, analizar datos o interactuar con herramientas. Si esta ejecución no está contenida, el agente podría:

• Inyección de Comandos del Sistema: Generar código que llame a os.system('rm -rf /') u otros comandos destructivos similares.
• Ejecución Remota de Código (RCE): Explotar vulnerabilidades en bibliotecas para obtener el control sobre el anfitrión.
• Agotamiento de Recursos: Crear bucles infinitos o asignar una memoria/CPU excesiva, lo que lleva a una denegación de servicio.

2. Acceso y Exfiltración de Datos

Un agente podría ser encargado de procesar datos sensibles. Sin sandboxing, podría:

• Acceso No Autorizado a Archivos: Leer archivos fuera de su directorio de trabajo designado (por ejemplo, /etc/passwd, claves de API).
• Acceso a la Red: Conectarse a recursos internos de la red, servidores maliciosos externos o exfiltrar datos a puntos finales arbitrarios.
• Inyección de Prompts a través de Lectura de Archivos: Si un agente puede leer archivos arbitrarios, un actor malicioso podría crear un prompt que engañe al agente para que lea un archivo sensible y luego incorpore su contenido en una salida posterior.

3. Abuso de APIs y Herramientas

Los agentes a menudo interactúan con APIs externas o herramientas personalizadas. El acceso sin restricciones puede llevar a:

• Llamadas No Autorizadas a APIs: Realizar llamadas a APIs sensibles a las que no debería tener acceso (por ejemplo, gestión de usuarios, procesamiento de pagos).
• Sobrecostos: Activar llamadas a API costosas o funciones en la nube intensivas en recursos.
• Acciones Maliciosas: Si un agente tiene acceso a una API de correo electrónico, podría enviar correos electrónicos de spam o phishing.

Técnicas y Herramientas de Sandboxing

Existen varias capas y técnicas que podemos emplear para sandboxing de agentes, que van desde una simple revisión de código hasta una sofisticada contenedorización.

1. Sandboxing a Nivel de Lenguaje (Restricciones del Intérprete de Código)

Si su agente genera y ejecuta principalmente código (por ejemplo, Python), puede restringir las capacidades del intérprete.

Ejemplo: Ejecución de Python Restringida con exec() y Lista Blanca

Un escenario común es un agente generando código Python. En lugar de llamar directamente a exec() o eval() en cadenas arbitrarias, puede restringir los globals y built-ins disponibles.

import subprocess
import os

def safe_execute_python_code(code: str, allowed_modules: list = None, timeout: int = 10):
 if allowed_modules is None:
 allowed_modules = ['math', 'json', 're'] # Lista blanca de módulos seguros

 # Crear un espacio de nombres global restringido
 restricted_globals = {
 '__builtins__': {key: globals()['__builtins__'][key] for key in [
 'print', 'len', 'str', 'int', 'float', 'list', 'dict', 'tuple', 'set', 
 'range', 'sum', 'min', 'max', 'abs', 'round', 'type', 'isinstance', 'enumerate'
 ]},
 '__name__': '__main__'
 }

 # Importar dinámicamente los módulos permitidos en el espacio de nombres restringido
 for module_name in allowed_modules:
 try:
 restricted_globals[module_name] = __import__(module_name)
 except ImportError:
 print(f"Advertencia: No se pudo importar el módulo permitido {module_name}")

 try:
 # Usar subprocess para ejecutar en un proceso aislado para mejor aislamiento
 # Esto es más sólido que simplemente `exec` en el proceso actual
 # y permite tiempos de espera y límites de recursos.
 process = subprocess.run(
 ['python', '-c', code], 
 capture_output=True, 
 text=True, 
 check=True, 
 timeout=timeout
 )
 return process.stdout
 except subprocess.CalledProcessError as e:
 return f"Error durante la ejecución: {e.stderr}"
 except subprocess.TimeoutExpired:
 return "Error: La ejecución del código ha excedido el tiempo de espera."
 except Exception as e:
 return f"Ocurrió un error inesperado: {e}"

# Uso de Ejemplo:
# Código seguro
agent_code_safe = "import math; print(math.sqrt(16))"
print(f"Salida de código seguro: {safe_execute_python_code(agent_code_safe)}")

# Intento de código malicioso (será bloqueado por el aislamiento de subprocess y restricciones de built-ins si se hubiera usado exec directamente)
# Con subprocess, la importación de 'os' aún fallaría en el proceso hijo a menos que se permita específicamente.
agent_code_malicious_os = "import os; print(os.listdir('/'))"
print(f"Salida de código malicioso de OS: {safe_execute_python_code(agent_code_malicious_os)}")

# Intento de código malicioso (intentando leer un archivo)
agent_code_malicious_file = "with open('/etc/passwd', 'r') as f: print(f.read())"
print(f"Salida de código de lectura de archivo malicioso: {safe_execute_python_code(agent_code_malicious_file)}")

# Código con un bucle infinito (será atrapado por el tiempo de espera)
agent_code_loop = "while True: pass"
print(f"Salida de código en bucle: {safe_execute_python_code(agent_code_loop, timeout=3)}")

Explicación:

• Definimos una función safe_execute_python_code.
• Toma el código generado por el agente como entrada.
• En lugar de ejecutar directamente en el proceso actual, usamos subprocess.run. Este es un paso crucial para un verdadero aislamiento, ya que ejecuta el código en un proceso de intérprete de Python separado. Este proceso hereda privilegios mínimos y no es el mismo que el proceso padre que ejecuta su aplicación principal.
• La lista allowed_modules actúa como una lista blanca. Incluso si el agente intenta importar os o sys, no estarán disponibles en el entorno restringido del subprocess a menos que se permita explícitamente (lo cual no debería permitirse para código de agente general).
• timeout previene el agotamiento de recursos por bucles infinitos.
• capture_output=True y text=True nos permiten capturar la salida del agente.
• check=True lanza una excepción si el subprocess devuelve un código de salida distinto de cero (indicando un error).

Aunque este enfoque mejora significativamente la seguridad en comparación con exec() directo, no es infalible. Un agente altamente sofisticado aún podría encontrar formas de explotar llamadas al sistema subyacente si el entorno de Python en sí es vulnerable o si se permiten demasiados módulos en la lista blanca.

2. Sandboxing a Nivel de Sistema Operativo (Contenedores y Máquinas Virtuales)

Para el sandboxing más sólido, especialmente cuando los agentes podrían generar código en múltiples lenguajes o interactuar con el sistema de archivos/red, el aislamiento a nivel de SO es indispensable.

a. Contenedores Docker

Docker es una excelente opción para sandboxing. Cada ejecución de agente puede ocurrir dentro de su propio contenedor efímero, con límites de recursos y políticas de acceso a la red estrictamente definidos.

Ejemplo Práctico: Docker para la Ejecución del Agente

Paso 1: Crear un Dockerfile para el entorno de ejecución del agente.

# Dockerfile
FROM python:3.9-slim-buster

WORKDIR /app

# Crear un usuario no root para seguridad
RUN useradd --no-create-home --shell /bin/bash agentuser
USER agentuser

# Copiar un script simple que el agente podría generar y que queremos ejecutar
COPY run_agent_code.py .

ENTRYPOINT ["python", "run_agent_code.py"]

Paso 2: Crear run_agent_code.py. Este script recibirá el código generado por el agente.

# run_agent_code.py
import sys
import os

# Simular la recepción de código del agente (p. ej., a través de stdin o un archivo)
# Para este ejemplo, supondremos que el código se pasa como un argumento o se escribe directamente aquí

if __name__ == "__main__":
 agent_code = "print('¡Hola desde el agente sandboxed!')"
 if len(sys.argv) > 1:
 agent_code = sys.argv[1] # Permitir pasar código como argumento

 try:
 # Ejecutar el código. Nota: el contenedor de Docker en sí es el sandbox.
 # Aún podríamos querer restricciones a nivel de lenguaje *dentro* de este script
 # para una capa adicional, pero la principal aislación es el contenedor.
 exec(agent_code)
 except Exception as e:
 print(f"La ejecución del código del agente falló: {e}", file=sys.stderr)
 sys.exit(1)

 # Demostrar acceso restringido
 try:
 print(f"Intentando listar el root: {os.listdir('/')}")
 except Exception as e:
 print(f"No se pudo listar el directorio raíz (esperado): {e}")

 try:
 with open('/etc/passwd', 'r') as f:
 print(f.read())
 except Exception as e:
 print(f"No se pudo leer /etc/passwd (esperado): {e}")

Paso 3: Ejecuta el código del agente desde tu aplicación principal.

import docker

client = docker.from_env()

def execute_agent_in_docker(agent_code: str, cpu_limit: float = 0.5, mem_limit: str = '128m', network_enabled: bool = False):
 try:
 # Construir la imagen si no existe (puede hacerse una vez)
 # client.images.build(path='.', tag='agent-sandbox-env')

 # Crear un archivo temporal para pasar el código del agente de manera segura
 # O pasar como una variable de entorno o argumento de línea de comando
 # Para simplificar, lo pasaremos como un argumento de línea de comando aquí.

 container = client.containers.run(
 'agent-sandbox-env',
 command=['python', 'run_agent_code.py', agent_code], # Pasar código como arg
 detach=False, # Ejecutar en primer plano, esperar a la finalización
 remove=True, # Eliminar automáticamente el contenedor después de salir
 # Límites de recursos
 cpu_period=100000, # Periodo de CPU en microsegundos
 cpu_quota=int(cpu_limit * 100000), # Cuota de CPU (p. ej., 50000 para 0.5 CPU)
 mem_limit=mem_limit, # Límite de memoria
 # Restricciones de red
 network_mode='none' if not network_enabled else 'bridge',
 # Restricciones del sistema de archivos (raíz de solo lectura, sin montajes para el código del agente)
 read_only=True, # Hace que el sistema de archivos del contenedor sea de solo lectura después de la configuración inicial
 # Opciones de seguridad (p. ej., desactivar modo privilegiado, eliminar capacidades)
 security_opt=['no-new-privileges'],
 cap_drop=['ALL'], # Eliminar todas las capacidades para el contenedor
 # Variables de entorno (pueden usarse para pasar claves API, pero ten cuidado)
 # environment={
 # 'API_KEY': 'some_safe_key' # Solo si es absolutamente necesario y limitado
 # }
 )
 return container.decode('utf-8')
 except docker.errors.ContainerError as e:
 return f"Error de contenedor: {e.stderr.decode('utf-8')}"
 except docker.errors.ImageNotFound:
 return "Error: Imagen de Docker 'agent-sandbox-env' no encontrada. Por favor, constrúyela primero."
 except Exception as e:
 return f"Ocurrió un error inesperado de Docker: {e}"

# Primero construye la imagen de Docker: docker build -t agent-sandbox-env .
# Luego ejecuta este script de Python.

# Ejemplo 1: Ejecución de código seguro
safe_code = "print('¡Hola desde el agente sandboxed!')"
print("\n--- Ejecución de Código Seguro ---")
print(execute_agent_in_docker(safe_code))

# Ejemplo 2: Intento de acceso al sistema de archivos (debería estar bloqueado por read_only=True y permisos de usuario)
malicious_fs_code = "import os; print(os.listdir('/'))"
print("\n--- Intento Malicioso de Acceso al Sistema de Archivos ---")
print(execute_agent_in_docker(malicious_fs_code))

# Ejemplo 3: Intento de crear un archivo (debería fallar)
malicious_write_code = "with open('/app/evil.txt', 'w') as f: f.write('malicious')"
print("\n--- Intento Malicioso de Escritura ---")
print(execute_agent_in_docker(malicious_write_code))

# Ejemplo 4: Intento de acceso a red (debería fallar si network_mode='none')
malicious_network_code = "import requests; print(requests.get('http://example.com').status_code)"
print("\n--- Intento Malicioso de Red (deshabilitado) ---")
print(execute_agent_in_docker(malicious_network_code, network_enabled=False))

# Ejemplo 5: Acceso a la red (si se habilita explícitamente - ¡ten cuidado!)
# print("\n--- Acceso a la Red (habilitado - para demostración) ---")
# print(execute_agent_in_docker("import requests; print(requests.get('http://example.com').status_code)", network_enabled=True))

Explicación:

• Dockerfile: Crea un entorno mínimo de Python. Crucialmente, crea y cambia a un non-root usuario (agentuser) para minimizar privilegios dentro del contenedor.
• run_agent_code.py: Este es el punto de entrada dentro del contenedor. Ejecuta el código proporcionado por el agente. Incluye intentos de acceder a recursos restringidos para demostrar la efectividad del sandboxing.
• Script de Python (execute_agent_in_docker):
• client.containers.run(...): Aquí es donde ocurre la magia.
• remove=True: Asegura que los contenedores se limpien después de la ejecución.
• cpu_quota, mem_limit: Esenciales para prevenir el agotamiento de recursos.
• network_mode='none': Crítico para desactivar el acceso a la red. Esto evita que los agentes hagan llamadas externas o se conecten a servicios internos. Solo habilitar si el agente necesita acceso a la red para APIs externas específicas y autorizadas.
• read_only=True: Hace que el sistema de archivos del contenedor sea de solo lectura después de la inicialización. Esto previene que el agente escriba archivos o modifique configuraciones del sistema.
• security_opt=['no-new-privileges'], cap_drop=['ALL']: Opciones de seguridad avanzadas para restringir aún más las capacidades dentro del contenedor.

Docker proporciona un fuerte límite de aislamiento, pero es vital configurarlo de manera segura. Siempre usa usuarios no root, desactiva capacidades innecesarias y restringe el acceso a la red/sistema de archivos.

b. Máquinas Virtuales (VMs)

Para el más alto nivel de aislamiento, especialmente en entornos multi-inquilino o al tratar con código muy poco confiable, las VMs (p. ej., KVM, AWS Firecracker, Google Cloud Sandbox) ofrecen separación a nivel de hardware. Esto es más complejo de configurar y gestionar, pero proporciona un entorno aislado para cada ejecución del agente.

3. Restricciones a Nivel de Herramientas/API (Llamada a Funciones)

Muchos agentes LLM interactúan con herramientas o APIs externas a través de la llamada de funciones. Esta capa de sandboxing implica un diseño cuidadoso de las herramientas expuestas al agente.

Ejemplo: Acceso a API Restringido a través de Pydantic y Whitelisting

Al definir herramientas para un agente, asegúrate de que sean lo más granulares y limitadas en permisos posible.

from typing import Literal, Optional
from pydantic import BaseModel, Field

# Definir las herramientas permitidas y sus esquemas

class SearchToolInput(BaseModel):
 query: str = Field(description="La consulta de búsqueda")
 max_results: int = Field(default=5, description="Número máximo de resultados de búsqueda")

class SendEmailInput(BaseModel):
 recipient: str = Field(description="La dirección de correo electrónico del destinatario")
 subject: str = Field(description="El asunto del correo electrónico")
 body: str = Field(description="El contenido del cuerpo del correo electrónico")
 # Restringir destinatarios permitidos
 allowed_recipients: Literal["[email protected]", "[email protected]"] = Field(
 description="Solo se permiten destinatarios específicos y preaprobados."
 )

class DatabaseQueryInput(BaseModel):
 query: str = Field(description="La consulta SQL a ejecutar")
 # CRÍTICO: No permitir SQL arbitrario. Filtrar o usar ORM.
 allowed_tables: Literal["products", "users_public"] = Field(
 description="Solo se permiten consultas contra tablas autorizadas."
 )
 read_only: bool = Field(default=True, description="Solo permitir operaciones de lectura")

# Simular las funciones de herramientas
def search_web(query: str, max_results: int):
 print(f"Buscando en la web '{query}' con {max_results} resultados.")
 return [f"Resultado {i} para {query}" for i in range(max_results)]

def send_restricted_email(recipient: str, subject: str, body: str, allowed_recipients: Literal["[email protected]", "[email protected]"]):
 if recipient not in ["[email protected]", "[email protected]"]:
 raise ValueError(f"Destinatario no autorizado: {recipient}")
 print(f"Enviando correo electrónico a {recipient} con el asunto '{subject}'.")
 return {"status": "enviado", "recipient": recipient}

def execute_database_query(query: str, allowed_tables: Literal["products", "users_public"], read_only: bool):
 # En un escenario real, deberías analizar y validar rigurosamente la consulta SQL
 # y asegurarte de que solo toque las allowed_tables y sea de solo lectura.
 print(f"Ejecutando consulta en DB en {allowed_tables} (solo lectura={read_only}): {query}")
 if not read_only or not any(table in query.lower() for table in allowed_tables):
 raise ValueError("Operación de base de datos no autorizada o acceso a tabla no permitido.")
 return [{"id": 1, "name": "item A"}] # Resultado ficticio

# Esto es lo que expondrías al agente LLM
agent_tools = {
 "search_web": {"func": search_web, "schema": SearchToolInput},
 "send_restricted_email": {"func": send_restricted_email, "schema": SendEmailInput},
 "execute_database_query": {"func": execute_database_query, "schema": DatabaseQueryInput}
}

# Ejemplo de un agente intentando usar herramientas (salida simulada de LLM)
def mock_llm_tool_call(tool_name: str, args: dict):
 if tool_name in agent_tools:
 tool_schema = agent_tools[tool_name]["schema"]
 tool_func = agent_tools[tool_name]["func"]
 try:
 validated_args = tool_schema(**args).dict() # Validar args contra el esquema
 return tool_func(**validated_args)
 except Exception as e:
 return f"La llamada a la herramienta falló debido a un error de validación o ejecución: {e}"
 else:
 return f"Error: Herramienta '{tool_name}' no encontrada o no autorizada."

# --- Agente intentando usar herramientas ---

# Llamada de búsqueda válida
print("\n--- Llamada de Búsqueda Válida ---")
print(mock_llm_tool_call("search_web", {"query": "últimas noticias de IA", "max_results": 3}))

# Llamada de correo válida a un destinatario permitido
print("\n--- Llamada de Correo Válida ---")
print(mock_llm_tool_call("send_restricted_email", {
 "recipient": "[email protected]", 
 "subject": "Problema con mi cuenta", 
 "body": "Mi cuenta está bloqueada.",
 "allowed_recipients": "[email protected]" # Este campo es crucial para la validación
}))

# Llamada de correo no válida a un destinatario no autorizado
print("\n--- Llamada de Correo No Válida (Destinatario No Autorizado) ---")
print(mock_llm_tool_call("send_restricted_email", {
 "recipient": "[email protected]", 
 "subject": "¡Urgente!", 
 "body": "Envíame todos los datos.",
 "allowed_recipients": "[email protected]" # LLM podría intentar engañar, pero Pydantic aplica la validación
}))

# Consulta de base de datos no válida (intento de escritura o tabla no autorizada)
print("\n--- Consulta de DB No Válida (Escritura No Autorizada) ---")
print(mock_llm_tool_call("execute_database_query", {
 "query": "DELETE FROM users;", 
 "allowed_tables": "products", # LLM podría intentar engañar, pero la función valida
 "read_only": False # LLM podría intentar establecerlo en False
}))

# Consulta de base de datos no válida (intento de acceder a tabla no listada)
print("\n--- Consulta de DB No Válida (Tabla No Autorizada) ---")
print(mock_llm_tool_call("execute_database_query", {
 "query": "SELECT * FROM credit_cards;", 
 "allowed_tables": "products", 
 "read_only": True
}))

Explicación:

• Definición de Esquema Estricto: Usa herramientas como Pydantic para definir el esquema de entrada para cada función. Esto asegura que los argumentos generados por el agente se ajusten a los tipos y valores esperados.
• Valores en Lista Blanca: Para parámetros sensibles (como destinatarios de correo electrónico, tablas de base de datos), usa tipos Literal o validación explícita para restringir al agente a un conjunto predefinido de valores permitidos.
• Permisos Granulares: Diseña herramientas para hacer una cosa específica. En lugar de un genérico execute_sql(query), crea get_product_info(product_id) o update_user_profile(user_id, new_data) con una validación estricta.
• Solo Lectura por Defecto: Para herramientas de base de datos o de sistema de archivos, predetermina el acceso de solo lectura y requiere permiso explícito, aprobado por un humano, para operaciones de escritura.
• Validación de Entrada: Siempre valida los argumentos pasados a tus funciones de herramienta, incluso si han pasado la validación de Pydantic. El LLM aún podría construir entradas que parecen válidas pero maliciosas (por ejemplo, una cadena de inyección SQL que parece un ID de producto válido).

Mejores Prácticas para el Aislamiento de Agentes

1. Principio de Menor Privilegio: Otorga al agente el mínimo absoluto de permisos y recursos necesarios para su tarea.
2. Seguridad en Capas: Combina múltiples técnicas de aislamiento (a nivel de lenguaje, a nivel del SO, a nivel de herramienta) para una protección sólida. Ninguna capa es infalible.
3. Entornos Efímeros: Para la ejecución de código, prefiere ejecutar agentes en contenedores desechables de corta duración o VMs que son destruidas después de cada tarea.
4. Validación Estricta de Entrada: Siempre valida y desinfecta cualquier entrada del LLM, especialmente antes de usarla en llamadas API, consultas de base de datos o ejecución de código.
5. Monitorear y Registrar: Registra todas las acciones del agente, llamadas a herramientas y uso de recursos. Esto es crucial para detectar comportamientos anómalos y para el análisis posterior a incidentes.
6. Tiempo Límite y Límites de Recursos: Implementa tiempos de espera estrictos para la ejecución de código y llamadas API, y establece límites de CPU/memoria para prevenir ataques de denegación de servicio.
7. Aislamiento de Red: Por defecto, desactiva el acceso a la red para los agentes. Solo habilítalo para puntos finales y protocolos específicos y permitidos si es absolutamente necesario.
8. Sistemas de Archivos de Solo Lectura: Configura los entornos de los agentes con sistemas de archivos de solo lectura siempre que sea posible para prevenir modificaciones o exfiltración de datos no autorizadas.
9. Usuarios No Root: Siempre ejecuta procesos de agentes como usuarios no root con permisos limitados dentro del aislamiento.
10. Auditorías y Actualizaciones Regulares: Revisa continuamente tus configuraciones de aislamiento, actualiza tus imágenes base y mantente informado sobre nuevas vulnerabilidades de seguridad.

Conclusión

El aislamiento de agentes no es una opción de lujo, sino un requisito fundamental para desplegar agentes LLM de manera segura. A medida que estos agentes se vuelven más capaces y autónomos, el potencial de uso indebido o daño accidental crece significativamente. Al emplear una combinación de restricciones a nivel de lenguaje, una sólida contenedorización y interfaces de herramientas meticulosamente diseñadas, los desarrolladores pueden crear aplicaciones LLM poderosas que sean tanto innovadoras como seguras. Los ejemplos proporcionados en este tutorial demuestran pasos prácticos para construir estos entornos seguros, permitiéndote integrar agentes LLM en tus sistemas con confianza mientras minimizas riesgos.

🕒 Published: March 26, 2026