Por que os agentes de IA precisam de ambientes de execução isolados?
As atividades dos agentes de IA (AI Agents) não se limitam apenas a chamadas de APIs em nuvem; elas estendem-se à execução de comandos de terminal, instalação de pacotes, leitura de arquivos e abertura de conexões de rede diretas. Em muitos casos, o agente opera com base em textos não confiáveis obtidos da internet momentos antes, tornando-o equivalente a um código não confiável que carrega credenciais reais dentro da infraestrutura.
O projeto OpenShell, iniciado pela NVIDIA e integrado aos projetos Sandbox da CNCF, fornece um ambiente de execução seguro para agentes, isolando cada agente em um contêiner dedicado. O sistema conta com um supervisor confiável (Supervisor) fora do ambiente isolado para controlar permissões por meio de quatro eixos fundamentais especificados em arquivos YAML:
- Sistema de arquivos: Restringe os caminhos de leitura e escrita usando a tecnologia Landlock no kernel Linux, tornando caminhos como /usr e /etc somente leitura.
- Gerenciamento de processos: Remove privilégios de root do contêiner, revoga todos os recursos do kernel e aplica regras de seccomp antes da inicialização.
- Controle de rede: Bloqueia o tráfego externo por padrão, permitindo apenas domínios específicos de acordo com o nome do arquivo executável, host, conceito e porta.
- Credenciais: Oculta as chaves reais do agente e as substitui por viagens temporárias tratadas exclusivamente pelo supervisor ao se conectar aos endpoints autorizados.
Como funciona o ambiente isolado no Kubernetes
No nível do Kubernetes, o OpenShell não possui um agendador próprio; em vez disso, ele aproveita o projeto Agent Sandbox do grupo de interesse SIG Apps. O Gateway OpenShell gerencia o ciclo de vida do ambiente, enquanto o Agent Sandbox traduz essas solicitações em recursos padrão do Kubernetes, como Pods, Services, PVCs e NetworkPolicies.
O ciclo começa com o envio de uma solicitação de criação de ambiente isolado via protocolo mTLS para o Gateway, onde a identidade do chamador é verificada, as políticas são traduzidas e quaisquer configurações inseguras são anuladas. Em seguida, as políticas de rede são criadas para bloquear o tráfego externo do agente e limitar a comunicação interna estritamente ao supervisor através da porta 5500. Na etapa seguinte, o supervisor deve verificar as propriedades de segurança do Pod gerado, como garantir que nenhum privilégio de root seja usado ou namespaces de host compartilhados, antes de suspender as restrições de agendamento e iniciar a execução do agente de IA.
Comparação entre OpenShell e Agent Substrate
Outro projeto na CNCF que oferece uma solução semelhante é o Agent Substrate. Embora ambos os projetos tenham como objetivo isolar agentes de IA no Kubernetes, eles diferem fundamentalmente em infraestrutura e casos de uso:
- Granularidade das políticas: O OpenShell inspeciona cada solicitação de rede no supervisor dedicado a um único ambiente, permitindo, por exemplo, ler issues do GitHub e impedir a criação de novas issues usando a mesma ferramenta. Em contrapartida, o Substrate analisa o tráfego em um gateway de saída compartilhado (Egress Gateway) com base no domínio e no host.
- Visibilidade no Kubernetes: Cada ambiente isolado no OpenShell é considerado um conjunto de recursos que podem ser inspecionados e gerenciados por meio de ferramentas nativas do Kubernetes e RBAC. Em contraste, o Substrate mantém seus modelos e políticas em um banco de dados PostgreSQL próprio, separado do servidor de API do Kubernetes.
- Modelo de isolamento e escalabilidade: O Substrate requer técnicas rigorosas de isolamento, como gVisor ou Cloud Hypervisor, para permitir a suspensão e retomada de contêineres ociosos visando economia de custos, enquanto o OpenShell oferece contêineres Linux padrão com a capacidade de integrar tecnologias de isolamento mais rígidas quando necessário.
Aprimorando a segurança com o motor Kyverno
Enquanto o OpenShell controla o comportamento interno do agente, motores de políticas como o Kyverno garantem que os próprios recursos do Kubernetes não sejam adulterados no momento da admissão (Admission Control). O Kyverno garante a verificação da instalação de digests de imagens de software, define limites máximos para o uso de CPU e memória, e impede a concessão de privilégios estendidos às funções RBAC dos supervisores.
Além disso, ferramentas de monitoramento de kernel baseadas em eBPF, como o Runtime for Kyverno, permitem a detecção de ferramentas de IA não autorizadas dentro dos clusters, como a execução de clientes CLI ou a conexão a modelos externos sem passar pelos gateways de segurança aprovados.
O que muda na prática para os engenheiros de plataforma?
Impor segurança a aplicações de IA não se resume mais apenas a proteger APIs, estendendo-se ao contexto real de execução de códigos dentro de contêineres. O projeto OpenShell concede às equipes de plataforma a capacidade de exercer um controle refinado no nível da camada 7 (L7) para cada processo executado pelo agente, enquanto a integração com o Kyverno garante a manutenção dos padrões de governança e conformidade estrutural em ambientes Kubernetes sem complexidade operacional adicional.