Tutorial sobre o Agent Sandboxing: Construindo Aplicações LLM Seguras

“`html

Introdução ao Isolamento de Agentes

À medida que os Modelos de Linguagem de Grande Escala (LLMs) evoluem de agentes conversacionais simples para entidades autônomas poderosas capazes de executar código, interagir com APIs externas e tomar decisões no mundo real, a necessidade de medidas de segurança sólidas se torna crucial. Um agente LLM, quando lhe é conferida a capacidade de agir, pode representar um risco de segurança significativo se não estiver corretamente restrito. É aqui que entra o isolamento de agentes. O isolamento de um agente significa criar um ambiente isolado onde ele pode operar sem influenciar o sistema hospedeiro ou acessar recursos não autorizados. Este tutorial explorará os aspectos práticos do isolamento de agentes, fornecendo exemplos concretos para demonstrar como construir aplicações LLM seguras e confiáveis.

O princípio fundamental por trás do isolamento é o mínimo privilégio: um agente deve ter acesso apenas aos recursos absolutamente necessários para seu funcionamento, e nada mais. Sem um isolamento adequado, um agente malicioso ou defeituoso poderia:

• Executar código arbitrário no sistema hospedeiro, causando roubo de dados ou comprometimento do sistema.
• Acessar arquivos sensíveis ou recursos de rede.
• Iniciar chamadas API externas indesejadas, gerando custos ou realizando ações não autorizadas.
• Exfiltrar dados confidenciais através de vários canais.

Implementando um isolamento eficaz, podemos mitigar esses riscos, permitindo-nos aproveitar o imenso poder dos agentes LLM mantendo controle e segurança.

Compreendendo as Ameaças: Por Que Isolar?

Antes de explorar o ‘como’, solidifiquemos o ‘por que’. As ameaças impostas por agentes não isolados são multifacetadas e podem ser classificadas da seguinte forma:

1. Vulnerabilidades de Execução de Código

muitos agentes LLM avançados são projetados para escrever e executar código (por exemplo, scripts Python) para resolver problemas, analisar dados ou interagir com ferramentas. Se essa execução não estiver contida, o agente poderia:

• Injeção de Comando de Sistema: Gerar código que chama os.system('rm -rf /') ou comandos destrutivos semelhantes.
• Execução de Código Remoto (RCE): Explorar vulnerabilidades em bibliotecas para assumir o controle do hospedeiro.
• Exaustão de Recursos: Criar loops infinitos ou alocar memória/CPU excessiva, causando uma negação de serviço.

2. Acesso a Dados e Exfiltração

Um agente pode ser encarregado de processar dados sensíveis. Sem isolamento, ele poderia:

• Acesso Não Autorizado a Arquivos: Ler arquivos fora de seu diretório de trabalho designado (por exemplo, /etc/passwd, chaves API).
• Acesso à Rede: Conectar-se a recursos de rede internos, a servidores externos maliciosos, ou exfiltrar dados para endpoints arbitrários.
• Injeção de Prompt através de Leituras de Arquivo: Se um agente pode ler arquivos arbitrários, um ator malicioso pode preparar um prompt que engana o agente fazendo-o ler um arquivo sensível, e então incorporar seu conteúdo em uma saída posterior.

3. Abuso de APIs e Ferramentas

Os agentes frequentemente interagem com APIs externas ou ferramentas personalizadas. Um acesso não restrito pode levar a:

• Chamadas API Não Autorizadas: Fazer chamadas a APIs sensíveis às quais não deveria ter acesso (por exemplo, gerenciamento de usuários, processamento de pagamentos).
• Superação de Custos: Acionar chamadas API caras ou funções de nuvem dispendiosas em termos de recursos.
• Ações Maliciosas: Se um agente tem acesso a uma API de mensagens, ele pode enviar spam ou e-mails de phishing.

Técnicas e Ferramentas de Isolamento

Existem diferentes camadas e técnicas que podemos empregar para o isolamento de agentes, que vão da simples revisão de código à containerização avançada.

1. Isolamento a Nível de Linguagem (Restrições do Intérprete de Código)

Se o seu agente gera e executa principalmente código (por exemplo, Python), você pode limitar as capacidades do intérprete.

Exemplo: Execução Python Limitada com exec() e Listas Brancas

Um cenário comum é um agente que gera código Python. Em vez de chamar diretamente exec() ou eval() em strings arbitrárias, você pode limitar os globais e os built-ins disponíveis.

“““html

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 branca dos módulos seguros

 # Criar um espaço de nomes global restrito
 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 dinamicamente os módulos autorizados no espaço de nomes restrito
 for module_name in allowed_modules:
 try:
 restricted_globals[module_name] = __import__(module_name)
 except ImportError:
 print(f"Aviso: Não foi possível importar o módulo autorizado {module_name}")

 try:
 # Utilizar subprocess para executar em um processo isolado para melhor isolamento
 # Isso é mais robusto do que simplesmente `exec` no processo atual
 # e permite definir limites de tempo e 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"Erro durante a execução: {e.stderr}"
 except subprocess.TimeoutExpired:
 return "Erro: A execução do código ultrapassou o tempo limite."
 except Exception as e:
 return f"Ocorreu um erro inesperado: {e}"

# Exemplo de Uso :
# Código seguro
agent_code_safe = "import math; print(math.sqrt(16))"
print(f"Saída do código seguro: {safe_execute_python_code(agent_code_safe)}")

# Tentativa de código malicioso (será bloqueado pelo isolamento subprocess e restrições de built-in se tivesse sido usado um exec direto)
# Com subprocess, a importação de 'os' falharia sempre no processo filho, a menos que seja especificamente autorizada.
agent_code_malicious_os = "import os; print(os.listdir('/'))"
print(f"Saída do código malicioso OS: {safe_execute_python_code(agent_code_malicious_os)}")

# Tentativa de código malicioso (tentando ler um arquivo)
agent_code_malicious_file = "with open('/etc/passwd', 'r') as f: print(f.read())"
print(f"Saída do código de leitura de arquivo malicioso: {safe_execute_python_code(agent_code_malicious_file)}")

# Código com um loop infinito (será capturado pelo timeout)
agent_code_loop = "while True: pass"
print(f"Saída do código em loop: {safe_execute_python_code(agent_code_loop, timeout=3)}")

Explicação:

• Definimos uma função safe_execute_python_code.
• Ela recebe o código gerado pelo agente como entrada.
• Em vez de executar diretamente no processo atual, utilizamos subprocess.run. Este é um passo crucial para um verdadeiro isolamento, pois executa o código em um processo interpretador Python separado. Este processo herda privilégios mínimos e não é o mesmo que o processo pai que executa sua aplicação principal.
• A lista allowed_modules serve como uma lista branca. Mesmo que o agente tente importar os ou sys, eles não estarão disponíveis no ambiente restrito do subprocesso, a menos que sejam explicitamente autorizados (o que não deve ocorrer para o código do agente genérico).
• timeout impede o esgotamento de recursos devido a loops infinitos.
• capture_output=True e text=True nos permitem capturar a saída do agente.
• check=True ativa uma exceção se o subprocesso retornar um código de saída diferente de zero (indicando um erro).

Embora essa abordagem melhore significativamente a segurança em relação ao uso direto de exec(), não é infalível. Um agente altamente sofisticado ainda poderia encontrar maneiras de explorar chamadas de sistema subjacentes se o ambiente Python em si for vulnerável ou se muitos módulos estiverem na lista branca.

2. Isolamento a Nível do Sistema Operacional (Container & Máquinas Virtuais)

Para um isolamento verdadeiramente sólido, especialmente quando os agentes podem gerar código em mais linguagens ou interagir com o sistema de arquivos/rede, o isolamento a nível do sistema operacional é imprescindível.

a. Contêineres Docker

Docker é uma ótima escolha para isolamento. Cada execução de um agente pode ocorrer em seu próprio contêiner de vida curta com limites de recursos e políticas de acesso de rede rigorosamente definidas.

Exemplo Prático: Docker para a Execução de um Agente

Passo 1: Criar um Dockerfile para o ambiente de execução do agente.

“““html

# Dockerfile
FROM python:3.9-slim-buster

WORKDIR /app

# Criar um usuário não-root por motivos de segurança
RUN useradd --no-create-home --shell /bin/bash agentuser
USER agentuser

# Copiar um script simples que o agente poderia gerar e que desejamos executar
COPY run_agent_code.py .

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

Passo 2: Criar run_agent_code.py. Este script receberá o código gerado pelo agente.

# run_agent_code.py
import sys
import os

# Simular a recepção de código do agente (por exemplo, via stdin ou um arquivo)
# Para este exemplo, suporemos que o código seja passado como argumento ou escrito diretamente aqui

if __name__ == "__main__":
 agent_code = "print('Hello from the sandboxed agent!')"
 if len(sys.argv) > 1:
 agent_code = sys.argv[1] # Permitir a passagem do código como argumento

 try:
 # Executar o código. Nota: o próprio contêiner Docker é o sandbox.
 # Podemos querer impor restrições adicionais a nível de linguagem *neste* script
 # para um nível adicional de segurança, mas o isolamento principal é fornecido pelo contêiner.
 exec(agent_code)
 except Exception as e:
 print(f"A execução do código do agente falhou: {e}", file=sys.stderr)
 sys.exit(1)

 # Demonstrar o acesso limitado
 try:
 print(f"Tentativa de listar a raiz: {os.listdir('/')}")
 except Exception as e:
 print(f"Impossível listar o diretório raiz (esperado): {e}")

 try:
 with open('/etc/passwd', 'r') as f:
 print(f.read())
 except Exception as e:
 print(f"Impossível ler /etc/passwd (esperado): {e}")

Passo 3: Executar o código do agente a partir da sua aplicação 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 a imagem se não existir (pode ser feito uma vez)
 # client.images.build(path='.', tag='agent-sandbox-env')

 # Criar um arquivo temporário para transmitir o código do agente de forma segura
 # Ou passar como variável de ambiente ou argumento da linha de comando
 # Para simplificar, vamos passar aqui como argumento da linha de comando.

 container = client.containers.run(
 'agent-sandbox-env',
 command=['python', 'run_agent_code.py', agent_code], # Passar o código como argumento
 detach=False, # Executar em primeiro plano, aguardando a conclusão
 remove=True, # Remover automaticamente o contêiner após a saída
 # Limites de recursos
 cpu_period=100000, # Período da CPU em microsegundos
 cpu_quota=int(cpu_limit * 100000), # Quota da CPU (por exemplo, 50000 para 0.5 CPU)
 mem_limit=mem_limit, # Limite de memória
 # Restrições de rede
 network_mode='none' if not network_enabled else 'bridge',
 # Restrições no sistema de arquivos (raiz somente leitura, nenhum ponto de montagem para o código do agente)
 read_only=True, # Torna o sistema de arquivos do contêiner somente leitura após a configuração inicial
 # Opções de segurança (por exemplo, desabilitar o modo privilegiado, remover capacidades)
 security_opt=['no-new-privileges'],
 cap_drop=['ALL'], # Remove todas as capacidades para o contêiner
 # Variáveis de ambiente (podem ser usadas para passar chaves de API, mas tenha cuidado)
 # environment={
 # 'API_KEY': 'some_safe_key' # Somente se absolutamente necessário e com propósito limitado
 # }
 )
 return container.decode('utf-8')
 except docker.errors.ContainerError as e:
 return f"Erro de contêiner: {e.stderr.decode('utf-8')}"
 except docker.errors.ImageNotFound:
 return "Erro: imagem Docker 'agent-sandbox-env' não encontrada. Construa-a primeiro."
 except Exception as e:
 return f"Ocorreu um erro Docker inesperado: {e}"

# Construa primeiro a imagem Docker: docker build -t agent-sandbox-env .
# Depois, execute este script Python.

# Exemplo 1: Execução de código seguro
safe_code = "print('Hello from sandboxed agent!')"
print("\n--- Execução de Código Seguro ---")
print(execute_agent_in_docker(safe_code))

# Exemplo 2: Tentativa de acesso ao sistema de arquivos (deve ser bloqueada por read_only=True e permissões de usuário)
malicious_fs_code = "import os; print(os.listdir('/'))"
print("\n--- Tentativa de Acesso Malicioso ao Sistema de Arquivos ---")
print(execute_agent_in_docker(malicious_fs_code))

# Exemplo 3: Tentativa de criação de um arquivo (deve falhar)
malicious_write_code = "with open('/app/evil.txt', 'w') as f: f.write('malicious')"
print("\n--- Tentativa de Escrita Maliciosa ---")
print(execute_agent_in_docker(malicious_write_code))

# Exemplo 4: Tentativa de acesso à rede (deve falhar se network_mode='none')
malicious_network_code = "import requests; print(requests.get('http://example.com').status_code)"
print("\n--- Tentativa de Rede Maliciosa (desativada) ---")
print(execute_agent_in_docker(malicious_network_code, network_enabled=False))

# Exemplo 5: Acesso à rede (se explicitamente habilitado - cuidado!)
# print("\n--- Acesso à Rede (ativado - para demonstração) ---")
# print(execute_agent_in_docker("import requests; print(requests.get('http://example.com').status_code)", network_enabled=True))

Explicação:

• Dockerfile: Cria um ambiente Python mínimo. Crucialmente, cria e passa para um non-root usuário (agentuser) para minimizar os privilégios no contêiner.
• run_agent_code.py: É o ponto de entrada no contêiner. Executa o código fornecido pelo agente. Inclui tentativas de acesso a recursos limitados para demonstrar a eficácia do sandbox.
• Script Python (execute_agent_in_docker):
• client.containers.run(...): Aqui acontece a mágica.
• remove=True: Garante que os contêineres sejam limpos após a execução.
• cpu_quota, mem_limit: Essencial para prevenir a exaustão de recursos.
• network_mode='none': Crítico para desabilitar o acesso à rede. Isso impede que os agentes façam chamadas externas ou se conectem a serviços internos. Ativar apenas se o agente precisar absolutamente de acesso à rede para APIs externas específicas e autorizadas.
• read_only=True: Torna o sistema de arquivos do contêiner somente leitura após a inicialização. Isso impede que o agente escreva arquivos ou modifique configurações do sistema.
• security_opt=['no-new-privileges'], cap_drop=['ALL']: Opções de segurança avançadas para limitar ainda mais as capacidades dentro do contêiner.

Docker fornece uma forte barreira de isolamento, mas é fundamental configurá-lo de forma segura. Sempre utilize usuários não-root, desabilite capacidades desnecessárias e limite o acesso à rede / sistema de arquivos.

b. Máquinas Virtuais (VM)

Para o máximo nível de isolamento, especialmente em ambientes multi-tenant ou durante a execução de código altamente não confiável, as VMs (por exemplo, KVM, AWS Firecracker, Google Cloud Sandbox) oferecem uma separação em nível de hardware. Isso é mais complexo de configurar e gerenciar, mas fornece um ambiente isolado para cada execução do agente.

3. Restrições a Nível de Ferramenta/API (Chamada de Função)

muitos agentes LLM interagem com ferramentas externas ou APIs através de chamadas de função. Este nível de sandbox envolve um design cuidadoso das ferramentas expostas ao agente.

Exemplo: Acesso API Limitado através de Pydantic e Lista Branca

Ao definir ferramentas para um agente, certifique-se de que sejam o mais granulares e limitados possíveis em permissões.

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

# Defina as ferramentas autorizadas e seus esquemas

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

class SendEmailInput(BaseModel):
 recipient: str = Field(description="O endereço de e-mail do destinatário")
 subject: str = Field(description="O assunto do e-mail")
 body: str = Field(description="O conteúdo do corpo do e-mail")
 # Restrições sobre destinatários autorizados
 allowed_recipients: Literal["[email protected]", "[email protected]"] = Field(
 description="Apenas destinatários específicos e pré-aprovados são autorizados."
 )

class DatabaseQueryInput(BaseModel):
 query: str = Field(description="A consulta SQL a ser executada")
 # CRÍTICO: Não permitir SQL arbitrário. Filtrar ou usar ORM.
 allowed_tables: Literal["products", "users_public"] = Field(
 description="Apenas consultas contra tabelas em lista branca são permitidas."
 )
 read_only: bool = Field(default=True, description="Permitir apenas operações de leitura")

# Simulando as funções das ferramentas
def search_web(query: str, max_results: int):
 print(f"Pesquisa na web para '{query}' com {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"Destinatário não autorizado: {recipient}")
 print(f"Enviando o e-mail para {recipient} com assunto '{subject}'.")
 return {"status": "enviado", "recipient": recipient}

def execute_database_query(query: str, allowed_tables: Literal["products", "users_public"], read_only: bool):
 # Em um cenário real, você analisaria e validaria rigorosamente a consulta SQL
 # e garantiria que acessasse apenas tabelas autorizadas e fosse somente leitura.
 print(f"Executando a consulta DB em {allowed_tables} (read_only={read_only}) : {query}")
 if not read_only or not any(table in query.lower() for table in allowed_tables):
 raise ValueError("Operação ou acesso à tabela não autorizado.")
 return [{"id": 1, "name": "item A"}] # Resultado fictício

# Aqui está o que você exporia ao 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}
}

# Exemplo de um agente tentando usar ferramentas (chamada LLM simulada)
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 os argumentos em relação ao esquema
 return tool_func(**validated_args)
 except Exception as e:
 return f"A chamada à ferramenta falhou devido a um erro de validação ou execução: {e}"
 else:
 return f"Erro: Ferramenta '{tool_name}' não encontrada ou não autorizada."

# --- Agente tentando usar ferramentas ---

# Chamada de pesquisa válida
print("\n--- Chamada de Pesquisa Válida ---")
print(mock_llm_tool_call("search_web", {"query": "últimas notícias sobre IA", "max_results": 3}))

# Chamada de e-mail válida para um destinatário autorizado
print("\n--- Chamada de E-mail Válida ---")
print(mock_llm_tool_call("send_restricted_email", {
 "recipient": "[email protected]", 
 "subject": "Problema com a minha conta", 
 "body": "Minha conta está bloqueada.",
 "allowed_recipients": "[email protected]" # Este campo é crucial para a validação
}))

# Chamada de e-mail não válida para um destinatário não autorizado
print("\n--- Chamada de E-mail Não Válida (Destinatário Não Autorizado) ---")
print(mock_llm_tool_call("send_restricted_email", {
 "recipient": "[email protected]", 
 "subject": "Urgente!", 
 "body": "Me envie todos os dados.",
 "allowed_recipients": "[email protected]" # LLM pode tentar enganar, mas Pydantic impõe
}))

# Consulta DB não válida (tentativa de escrita ou tabela não autorizada)
print("\n--- Consulta DB Não Válida (Escrita Não Autorizada) ---")
print(mock_llm_tool_call("execute_database_query", {
 "query": "DELETE FROM users;", 
 "allowed_tables": "products", # LLM pode tentar enganar, mas a função valida
 "read_only": False # LLM pode tentar definir como False
}))

# Consulta DB não válida (tentativa de acesso a uma tabela não listada)
print("\n--- Consulta DB Não Válida (Tabela Não Autorizada) ---")
print(mock_llm_tool_call("execute_database_query", {
 "query": "SELECT * FROM credit_cards;", 
 "allowed_tables": "products", 
 "read_only": True
}))

Explicação:

“`html

• Definição rigorosa do esquema: Utilizar ferramentas como Pydantic para definir o esquema de entrada para cada função. Isso garante que os argumentos gerados pelo agente estejam em conformidade com os tipos e valores esperados.
• Lista de valores permitidos: Para parâmetros sensíveis (como destinatários de e-mail, tabelas de banco de dados), usar tipos Literal ou uma validação explícita para limitar o agente a um conjunto predefinido de valores autorizados.
• Permissões granulares: Projetar ferramentas para realizar uma única ação específica. Em vez de um execute_sql(query) genérico, criar get_product_info(product_id) ou update_user_profile(user_id, new_data) com uma validação rigorosa.
• Somente leitura por padrão: Para ferramentas de banco de dados ou de sistema de arquivos, por padrão, limitar o acesso a somente leitura e exigir uma autorização explícita, aprovada por um humano, para operações de escrita.
• Validação das entradas: Sempre validar os argumentos passados para suas funções de ferramenta, mesmo que tenham passado pela validação do Pydantic. O LLM ainda pode gerar entradas válidas, mas prejudiciais (por exemplo, uma string de injeção SQL que se assemelha a um ID de produto válido).

Boas Práticas para o Sandbox dos Agentes

1. Princípio do Mínimo Privilégio: Conceder ao agente o mínimo absoluto de permissões e recursos necessários para seu trabalho.
2. Segurança em Camadas: Combinar várias técnicas de sandboxing (nível de linguagem, nível de SO, nível de ferramenta) para uma proteção robusta. Nenhum nível único é infalível.
3. Ambientes Efêmeros: Para a execução de código, priorizar a execução de agentes em contêineres ou máquinas virtuais descartáveis de curto prazo que são destruídas após cada tarefa.
4. Validação Rigorosa das Entradas: Sempre validar e sanitizar cada entrada proveniente do LLM, especialmente antes de utilizá-la em chamadas de API, consultas de banco de dados ou execuções de código.
5. Monitoramento e Registro: Registrar todas as ações do agente, chamadas de ferramentas e uso de recursos. Isso é crucial para detectar comportamentos anômalos e para análise pós-incidente.
6. Timeout e Limites de Recursos: Implementar prazos rigorosos para a execução de código e chamadas de API, e definir limites de CPU/memória para evitar ataques de Negação de Serviço.
7. Isolamento de Rede: Por padrão, desabilitar o acesso à rede para os agentes. Ativá-lo apenas para endpoints e protocolos específicos e listados como permitidos, se absolutamente necessário.
8. Sistemas de Arquivos Somente Leitura: Configurar os ambientes dos agentes com sistemas de arquivos somente leitura sempre que possível para impedir modificações ou exfiltracão não autorizada de dados.
9. Usuários Não Root: Sempre executar os processos dos agentes como usuários não root com privilégios limitados dentro do sandbox.
10. Auditoria e Atualizações Regulares: Revisar continuamente as configurações de sandboxing, atualizar as imagens base e se manter informado sobre novas vulnerabilidades de segurança.

Conclusão

O sandboxing dos agentes não é um luxo opcional, mas uma necessidade fundamental para implantar agentes LLM com segurança. À medida que esses agentes se tornam mais capazes e autônomos, o potencial para uso indevido ou danos acidentais aumenta significativamente. Ao empregar uma combinação de restrições de nível de linguagem, contêineres robustos e interfaces de ferramentas cuidadosamente projetadas, os desenvolvedores podem criar aplicações LLM poderosas que sejam inovadoras e seguras ao mesmo tempo. Os exemplos fornecidos neste tutorial mostram passos práticos em direção à construção desses ambientes seguros, permitindo que você integre com confiança agentes LLM em seus sistemas minimizando os riscos.

“`

🕒 Published: April 5, 2026