Runtime sandbox e policy engine para tool use de LLMs
TL;DR
O recorte mais importante para tool use de LLMs em 2026 é sair do controle só “antes do deploy” e levar o enforcement para o runtime. Isso reduz a chance de um agente acessar filesystem, rede ou processos fora do escopo permitido, usando sandbox + gateway + engine de política.
No material pesquisado, a NVIDIA OpenShell exemplifica esse desenho com política declarativa, isolamento e atualização dinâmica de controles. Para quem constrói agentes, a mudança prática é simples: a capacidade do modelo deixa de ser a única linha de defesa, e a política passa a mandar no que realmente pode acontecer.
O que muda quando a política sai do papel e entra no runtime
Em sistemas com LLM tool use, o risco não está só na resposta do modelo. O problema aparece quando a ferramenta pode ler arquivos sensíveis, abrir conexões de rede indevidas, iniciar processos fora do previsto ou encaminhar inferência para destinos não aprovados. É por isso que o desenho com sandbox e policy engine ganhou espaço: ele transforma regra em decisão executável, no momento em que o agente tenta agir.
O brief aponta a OpenShell como exemplo de runtime open-source para agentes com política declarativa e isolamento de kernel, descrita na documentação oficial da NVIDIA: Overview of NVIDIA OpenShell. Na prática, isso significa que a autorização deixa de depender da disciplina do prompt e passa a ser aplicada por camadas técnicas.
O que normalmente é controlado
- Filesystem: limitar leitura e escrita a paths específicos.
- Network: permitir só destinos, portas e rotas aprovadas.
- Process: impedir execuções fora do escopo do agente.
- Inference: controlar roteamento e privacidade das chamadas ao modelo.
Essas camadas aparecem nas boas práticas oficiais da NVIDIA para o OpenShell: OpenShell Security Best Practices. A mensagem é clara: o agente pode até tentar ampliar seu acesso, mas a política runtime decide se a operação passa ou não.
Sandbox, gateway e policy engine: por que combinar os três
Isolamento sozinho não resolve tudo. Uma sandbox bem feita reduz a superfície de ataque local, mas ainda precisa de regras sobre o que pode sair para a rede e sobre como o agente faz roteamento de inferência. É aí que entram o gateway e o policy engine: um valida o tráfego, o outro aplica a regra.
O brief destaca que a OpenShell usa controles em runtime com um CONNECT proxy e um OPA policy engine para decisões de rede, além de enforcement em dois pontos: controles estáticos ao criar a sandbox e controles dinâmicos atualizáveis com comandos de política. Isso está descrito em OpenShell Security Best Practices.
Por que isso interessa para agentes com ferramentas
Considere um agente que soma três capacidades: consultar documentos internos, chamar uma API externa e gerar uma resposta final. Se o mesmo agente puder também abrir qualquer endpoint, ler qualquer arquivo do disco e redirecionar inferência sem regra, o risco operacional cresce rápido. O ponto do runtime policy engine é separar capacidade de permissão.
Essa separação é útil porque ferramentas diferentes exigem níveis diferentes de confiança. Um executador de tarefas de backoffice não precisa do mesmo alcance de rede de um agente que só consulta uma base interna. A política runtime permite aplicar esse princípio de menor privilégio sem reescrever toda a aplicação.
Filesystem com menor privilégio: o valor do isolamento por caminho
O brief cita o uso de Landlock para confinar acesso apenas aos caminhos declarados. A documentação oficial do OpenShell descreve esse modelo em Overview of NVIDIA OpenShell. O efeito prático é importante: em vez de confiar que o agente “vai usar certo” o caminho do arquivo, o runtime impede qualquer desvio para fora da área aprovada.
Em ambientes reais, isso reduz dois tipos de problema. Primeiro, leitura indevida de segredos ou bases locais. Segundo, escrita em diretórios que acabam contaminando estado do sistema ou dados de outros jobs. Em agentes que reorganizam arquivos, procuram documentos ou fazem ingestão de conteúdo, esse controle deixa de ser detalhe e vira requisito.
Exemplo de desenho seguro
Você pode pensar em uma política com três regras simples: permitir apenas a pasta de entrada, permitir apenas a pasta de saída e negar todo o resto. Esse modelo é fácil de explicar para times de produto, fácil de auditar e muito mais previsível do que tentar conter o comportamento só no prompt.
Em um cenário brasileiro, isso ajuda especialmente times que trabalham sob exigências de LGPD. Em vez de “esperar” que o agente não leia dados pessoais além do necessário, o runtime pode restringir o acesso aos diretórios e reduzir a exposição de informações sensíveis no processamento local. A diferença é concreta: a política passa a ser uma barreira técnica, não uma promessa de comportamento.
Rede e inferência: o ponto cego que costuma passar despercebido
Muita gente pensa em segurança de agentes só como “não deixar executar código perigoso”. Mas, em tool use, o vazamento pode acontecer pela rede ou pela forma como a inferência é roteada. O brief afirma que o OpenShell documenta controles de rede, filesystem, processo e inferência como camadas separadas, e que decisões de rede passam por CONNECT proxy + OPA policy engine. Veja a documentação oficial: OpenShell Security Best Practices.
Esse modelo é relevante porque um agente sem limite de rede pode chamar serviços não aprovados, exfiltrar dados ou consumir endpoints caros sem governança. Já o controle de inferência ajuda a reduzir riscos de privacidade e roteamento indevido, algo que pesa em empresas que tratam dados de clientes, saúde ou financeiro.
Quando a permissão fica embutida na política, o agente não “decide bem”; ele apenas opera dentro do que o runtime aceita. Isso é mais fácil de auditar do que confiar em instruções de prompt.
Aplicação prática em produção
Para um time de plataforma, isso vira uma arquitetura em que cada tool recebe um escopo explícito. Uma ferramenta pode consultar apenas um conjunto específico de hosts; outra pode ler só uma pasta temporária; outra pode nunca tocar a rede. O benefício é que incidentes deixam de depender da interpretação do modelo, porque a camada de enforcement está abaixo dele.
O mesmo raciocínio vale para rotas de inferência. Se uma empresa precisa garantir que certos prompts não saiam do perímetro esperado, a política runtime é o local certo para impor isso. O modelo, sozinho, não é controle de segurança.
Atualização dinâmica de políticas sem recriar tudo
Um detalhe operacional importante no brief é a distinção entre controles estáticos e dinâmicos. Controles estáticos ficam travados na criação da sandbox. Controles dinâmicos podem ser atualizados via CLI com comandos como `openshell policy update` e `openshell policy set`, conforme a documentação oficial de segurança: OpenShell Security Best Practices.
Isso importa porque agentes em produção mudam rápido. Uma nova ferramenta pode exigir acesso temporário a uma API externa, ou uma política pode precisar ser endurecida depois de uma revisão de segurança. Se todo ajuste exigir reconstruir o ambiente inteiro, o custo operacional sobe e o time tende a adiar correções. Atualizar a política em runtime reduz essa fricção.
O que vale monitorar
- Quais ferramentas precisam de permissão extra e por quanto tempo.
- Quais destinos de rede são realmente necessários para o caso de uso.
- Quais paths devem continuar bloqueados, mesmo em modo de exceção.
- Quais mudanças de inferência podem afotar privacidade ou custo.
Essa disciplina é especialmente útil em empresas brasileiras que precisam equilibrar segurança e prazo. Muitas equipes operam com orçamento em BRL, dependência de provedores internacionais e latência sensível para workloads em us-east-1. Nesse contexto, uma política runtime que evita chamadas desnecessárias e reduz retrabalho tem efeito direto no custo operacional.
Por que importa pro dev brasileiro
Tem um ponto bem concreto aqui: no Brasil, a LGPD torna mais sensível qualquer fluxo que exponha dados pessoais em ferramentas automatizadas. Em agentes com LLM, o erro mais caro não é só uma resposta errada; é um acesso indevido a arquivo, endpoint ou dado que o sistema não deveria tocar. Um runtime com policy engine ajuda a transformar esse limite em enforcement, não em intenção.
Outro fator local é custo. Muitos times brasileiros usam infraestrutura em nuvem com cobrança em dólar e margens apertadas, então um agente que faz chamadas externas desnecessárias pode virar problema de orçamento em poucos dias. Política runtime também serve para limitar ferramentas, destinos e caminhos de inferência, ajudando a conter desperdício.
Na prática, o ganho para o dev brasileiro é construir agentes com menos risco de vazamento e menos dependência de confiança implícita no modelo. Isso é especialmente útil em projetos com bootcamps, squads reduzidos e entregas rápidas, onde a segurança precisa caber na realidade do time e não em um desenho idealizado.
Como começar a aplicar isso no seu projeto
Se você já tem um agente com ferramentas, o primeiro passo é mapear três coisas: quais arquivos ele precisa tocar, quais destinos de rede são realmente necessários e quais ações nunca deveriam existir. Depois, a lógica de autorização precisa sair do código do agente e ir para uma política verificável no runtime.
O brief sugere exatamente esse caminho para o OpenShell: política declarativa em YAML, isolamento na sandbox e enforcement em camadas. A documentação oficial de visão geral está em Overview of NVIDIA OpenShell, e as práticas de segurança estão em OpenShell Security Best Practices. Para quem quer entender a superfície de implementação, o repositório público é GitHub - NVIDIA/OpenShell.
Esta seção descreve a versão pública documentada no material pesquisado. APIs de IA e ferramentas de runtime mudam rápido — confira a documentação oficial e o changelog antes de adotar em produção.
Conclusão
Tool use de LLM não fica seguro só com prompt bom. O que realmente muda o jogo é colocar sandbox, gateway e policy engine no runtime, para que filesystem, rede, processo e inferência sejam controlados por regras executáveis. A OpenShell é um exemplo claro desse desenho, com enforcement em camadas e política atualizável.
Se você está desenhando um agente agora, pegue um caso pequeno do seu sistema e faça o exercício em até 1 hora: liste as três permissões mínimas que ele precisa, escreva a política correspondente e bloqueie todo o resto. Esse é o tipo de refatoração que já melhora segurança e previsibilidade no mesmo dia.
Conteúdos da DIO para quem quer aprofundar
- Aceleração Microsoft AI Agents — série prática com agentes e ferramentas de IA em cenários aplicados, útil para entender fluxos de automação e integração.
- CrewAI Fundamentals — formação para criar agentes inteligentes e organizar fluxos colaborativos com IA Generativa.
- Microsoft AI for Tech - OpenAI Services — trilha para integrar serviços de IA em aplicações cloud e back-end com foco em uso prático.
- Formação AI-102 Certification — formação voltada para desenvolver soluções de IA no Azure com foco em arquitetura e serviço gerenciado.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
