Como Tornar Agentes de IA Seguros: Uma Análise da Arquitetura de Segurança da OpenAI

Com o crescente uso de agentes de Inteligência Artificial (IA) capazes de ler repositórios, executar comandos shell e interagir com ferramentas de desenvolvimento, a segurança da informação se torna uma preocupação primordial. A OpenAI publicou detalhes sobre como eles abordam a segurança de seus agentes internamente. Vamos analisar essa arquitetura em detalhes.

O que é Codex?

Codex é um agente de IA que navega autonomamente por repositórios, executa comandos, acessa APIs externas e ferramentas de desenvolvedor. Agentes podem operar em paralelo, em cópias isoladas de código, permitindo que o usuário alterne entre tarefas, visualize alterações e obtenha resultados. Diante da possibilidade de ambientes multi-agentes que dispensam a intervenção humana, a questão da segurança se torna ainda mais crítica.

A Abordagem da OpenAI

A OpenAI implementou um princípio claro: ações de baixo risco são executadas sem interrupção, enquanto ações de alto risco passam por verificação.

Camada 1: Sandbox e Sistema de Aprovações

A primeira linha de defesa é o sandbox. Ele define os limites técnicos de execução, incluindo onde o Codex pode escrever e quais caminhos ele pode acessar, garantindo a proteção de áreas sensíveis. Acima do sandbox, opera uma política de aprovações: se um agente precisa realizar uma ação fora do sandbox, ele deve solicitar permissão. O usuário pode aprovar a ação individualmente ou permitir uma classe inteira de ações para a sessão.

Para evitar que o agente se torne uma máquina de aprovações, a OpenAI adicionou o modo de auto-revisão (auto_review). Este é um subagente que aprova silenciosamente solicitações de baixo risco sem interromper o usuário. No entanto, se algo incomum ou potencialmente perigoso surgir, o controle é transferido para um humano.

toml
# config.toml
approvals_reviewer = "auto_review"
sandbox_workspace_write.writable_roots = ["~/development"]

# requirements.toml
allowed_sandbox_modes = ["read-only", "workspace-write"]

Camada 2: Gerenciamento de Rede

O Codex não tem acesso de saída irrestrito. A política de rede é baseada em uma allowlist: apenas o que é explicitamente permitido é autorizado.

toml
# requirements.toml
allowed_web_search_modes = ["cached"]

[experimental_network]
enabled = true
allow_local_binding = true
denied_domains = ["pastebin.com"]
allowed_domains = ["login.microsoftonline.com", "*.openai.com"]

A lógica é simples: o agente deve ser capaz de executar processos de trabalho padrão, acessar os serviços necessários e trabalhar com localhost, mas não deve ter a capacidade de enviar dados para qualquer lugar. Um domínio desconhecido fora da lista resultará em uma pausa e uma solicitação de aprovação.

Camada 3: Regras no Nível de Comando

Nem todos os comandos shell são igualmente seguros. A OpenAI define políticas granulares através de prefix_rules: comandos padrão para leitura e inspeção (por exemplo, logs do Kubernetes) são permitidos sem aprovação, enquanto padrões potencialmente destrutivos são imediatamente bloqueados ou exigem permissão explícita.

# default.rules
prefix_rule(
    pattern = ["gh", "pr", ["view", "list"]],
    decision = "allow",
    justification = "Allows read-only GitHub PR inspection via gh CLI.",
)
prefix_rule(
    pattern = ["kubectl", ["get", "describe", "logs"]],
    decision = "allow",
    justification = "Allows Kubernetes resource inspection for debugging.",
)

Isso permite que o Codex lide rapidamente com tarefas de engenharia diárias sem parar em cada git status, mas sem executar nada destrutivo em silêncio.

Camada 4: Autenticação e Gerenciamento de Credenciais

As credenciais CLI e MCP OAuth são armazenadas no keychain do sistema operacional, e não em arquivos de configuração ou variáveis de ambiente. O login é feito apenas através do ChatGPT Workspace corporativo.

toml
# config.toml
cli_auth_credentials_store = "keyring"
mcp_oauth_credentials_store = "keyring"
forced_login_method = "chatgpt"
forced_chatgpt_workspace_id = "<workspace-uuid>"

Essa abordagem oferece duas vantagens: primeiro, toda a atividade do Codex está vinculada a um espaço de trabalho específico e é registrada na plataforma de conformidade da OpenAI. Segundo, a comprometimento da configuração não equivale ao comprometimento das credenciais.

Camada 5: Telemetria no Nível do Agente

Os logs de segurança tradicionais registram fatos: um processo foi iniciado, um arquivo foi modificado, uma conexão de rede foi estabelecida. Eles não respondem à pergunta por quê. O Codex exporta logs OpenTelemetry com contexto completo do agente: solicitação do usuário, decisões de aprovação de ferramentas, resultados de execução, uso de servidores MCP, eventos de rede (permitido/bloqueado).

toml
# config.toml
[otel]
log_user_prompt = true
environment = "prod"

[otel.exporter.otlp-http]
endpoint = "http://localhost:14318/v1/logs"
protocol = "binary"

Esses logs podem ser enviados para qualquer SIEM. A OpenAI foi além: eles adicionaram um agente de IA para classificação de segurança, que analisa os logs do Codex no contexto de alertas de segurança de endpoint. Uma IA monitora a outra e explica à equipe de segurança se o comportamento foi normal, um erro inofensivo ou algo que realmente precisa ser escalado.

Conclusão

Ao analisar o sistema, a OpenAI construiu várias camadas de controle independentes que trabalham juntas: limitação técnica (sandbox) → limitação comportamental (regras de comando) → isolamento de rede → gerenciamento de identidade → telemetria com contexto → triagem de IA sobre telemetria. Cada camada resolve seu próprio problema e não depende de que a anterior funcione perfeitamente. Isso é defense in depth, embora não seja um conceito novo, mas aplicado a sistemas de agentes de forma bastante consistente.