Segurança de IA: como limitar ferramentas e redes de agentes

Um modelo de IA não precisa “querer” atacar um sistema para causar um incidente: basta receber acesso a ferramentas, credenciais e uma rede permissiva sem controles adequados. É por isso que a proposta de criar um órgão internacional para supervisionar a segurança de sistemas avançados importa também para quem desenvolve aplicações com IA — não só para os laboratórios que treinam os modelos.

Segundo o Olhardigital.com.br, cerca de 400 cientistas, entre eles Geoffrey Hinton e Yoshua Bengio, defenderam em uma carta aberta padrões de segurança, avaliações independentes e um registro de incidentes. O grupo também recomenda manter modelos avançados isolados de redes externas durante etapas iniciais de desenvolvimento e avaliação.

O que um órgão global de segurança de IA poderia fiscalizar

A proposta tenta enfrentar um problema que compromissos voluntários das empresas não resolvem por completo: cada organização pode definir seus próprios critérios para testar um modelo e decidir o que divulgar quando algo dá errado. Sem parâmetros comuns, fica difícil comparar riscos, aprender com incidentes e cobrar medidas consistentes.

Um órgão internacional poderia estabelecer requisitos mínimos para avaliações, critérios para reportar incidentes e procedimentos de auditoria. Isso não significa necessariamente que uma única entidade teria acesso irrestrito aos modelos ou controlaria todo o setor. Mandato, poderes de fiscalização, transparência e participação de diferentes países seriam parte central do debate.

Também é importante separar três coisas que às vezes aparecem misturadas: o modelo, o produto que o incorpora e o ambiente em que ele opera. Um modelo pode gerar código ou instruções; o produto decide quais ferramentas disponibilizar; e a infraestrutura define que redes, arquivos e credenciais essas ferramentas conseguem acessar.

Na prática, o risco costuma surgir da combinação. Um modelo conectado a um navegador, terminal ou API interna pode realizar ações que um modelo isolado não consegue. Por isso, avaliar apenas as respostas do modelo é insuficiente: é preciso testar permissões, integrações, armazenamento de segredos e controles de rede.

Air gap, sandbox e firewall: qual a diferença?

Air gap é o isolamento de um sistema em relação a redes externas. Em termos práticos, uma máquina com air gap não tem conexão de rede com a internet nem com outras redes que possam servir de ponte. Isso reduz a superfície de ataque durante testes, mas não elimina todos os riscos.

Um sandbox, por outro lado, restringe o que um processo pode fazer dentro de um ambiente. Pode limitar acesso a arquivos, memória, dispositivos e chamadas do sistema. Um firewall controla conexões de rede. São controles diferentes e, para sistemas de alto risco, funcionam melhor em camadas do que como alternativas excludentes.

Air gap: reduz a conectividade externa, mas dificulta atualizações, coleta de dados e colaboração entre equipes.
Sandbox: limita ações do processo, mas não impede automaticamente que uma ferramenta autorizada faça uma conexão perigosa.
Firewall ou proxy de saída: controla destinos e protocolos, mas precisa de regras bem configuradas e monitoramento.
Lista de permissões da aplicação: restringe ferramentas e operações disponíveis, mas não substitui controles na infraestrutura.

Uma armadilha comum é chamar qualquer container de “isolado”. Containers compartilham o kernel do sistema hospedeiro e podem ter permissões excessivas. Configurar uma imagem em container não equivale a criar um air gap, nem garante que o processo não consiga alcançar serviços internos pela rede.

Por que a avaliação independente importa

Um teste interno pode ser útil, mas também sofre com limitações previsíveis: a equipe conhece o sistema, os cenários de avaliação podem não representar ataques reais e os indicadores podem favorecer resultados positivos. Uma avaliação independente ajuda a questionar esses pressupostos e documentar o que foi testado.

Isso não significa que uma auditoria única prove que um modelo é seguro. Capacidades, integrações e ameaças mudam. Uma avaliação responsável precisa considerar o modelo em diferentes configurações, registrar limitações e ser repetida quando houver alterações importantes — como a liberação de novas ferramentas ou o aumento de permissões.

O debate também conversa com abordagens já usadas em gestão de risco e governança, como o NIST AI Risk Management Framework e a norma ISO/IEC 42001. Esses referenciais ajudam organizações a estruturar processos, mas não são, por si só, uma garantia de segurança técnica nem substituem regras específicas para modelos de capacidades avançadas.

Registro de incidentes: aprender sem expor novos riscos

A carta, de acordo com a fonte, propõe um registro de ocorrências relevantes que poderiam ser divulgadas ao público futuramente. Para desenvolvedores, essa ideia é familiar: sistemas de segurança precisam de logs e análise pós-incidente. A diferença é que, nesse contexto, os dados podem revelar vulnerabilidades, informações pessoais ou métodos de exploração.

Um registro útil deve documentar o que aconteceu, qual versão estava em uso, que ferramentas o modelo podia acessar, quais controles falharam e como a equipe conteve o problema. A divulgação pode ocorrer depois de uma avaliação, com detalhes técnicos suficientes para permitir aprendizado, mas sem publicar instruções que facilitem a repetição do ataque.

O objetivo não deveria ser apenas criar uma lista pública de falhas. É importante que as organizações tenham canais para reportar incidentes, um processo de triagem e critérios claros para decidir quando e como divulgar informações. Sem isso, o registro pode virar uma coleção incompleta de relatos ou até aumentar o risco para sistemas ainda vulneráveis.

Na Prática: como limitar o acesso de um agente de IA

Se você está criando um agente que usa ferramentas, não trate a mensagem do modelo como uma política de autorização. O modelo pode sugerir uma ação; é o seu código que deve decidir se ela pode ser executada. Eu começaria com estas etapas:

Liste as ferramentas disponíveis. Dê ao agente somente as funções necessárias para a tarefa. Não ofereça um terminal genérico se uma função específica resolver o caso.
Defina permissões por ferramenta. Uma ferramenta de consulta não deve herdar permissão para alterar dados ou enviar informações para qualquer destino.
Bloqueie a rede por padrão. Permita apenas destinos e protocolos necessários, usando regras na infraestrutura, não só uma validação na aplicação.
Exija aprovação humana para ações sensíveis. Por exemplo: executar código em produção, enviar arquivos ou alterar dados de clientes.
Registre decisões e resultados. Guarde identificadores de execução, ferramenta acionada, decisão de autorização e motivo, evitando incluir segredos nos logs.
Teste os limites. Simule entradas maliciosas, redirecionamentos, endereços internos e tentativas de contornar as permissões.

O exemplo abaixo mostra uma verificação simples antes de uma ferramenta fazer uma requisição. Ele bloqueia esquemas inesperados, credenciais embutidas na URL, portas não padrão e hosts fora da lista permitida. Também registra a decisão em JSONL.

from urllib.parse import urlsplit
import json
import time

ALLOWED_HOSTS = {"api.exemplo.com"}
ALLOWED_TOOLS = {"consultar_api"}

def authorize(tool: str, url: str) -> tuple[bool, str]:
    if tool not in ALLOWED_TOOLS:
        return False, "ferramenta não permitida"

    try:
        parsed = urlsplit(url)
        host = (parsed.hostname or "").lower()
        port = parsed.port
    except ValueError:
        return False, "URL inválida"

    if parsed.scheme != "https":
        return False, "somente HTTPS é permitido"
    if not host or parsed.username or parsed.password:
        return False, "host ausente ou credenciais na URL"
    if port not in (None, 443):
        return False, "porta não permitida"
    if host not in ALLOWED_HOSTS:
        return False, "destino fora da lista permitida"

    return True, "destino autorizado"

def audit(tool: str, url: str, allowed: bool, reason: str) -> None:
    event = {
        "timestamp": int(time.time()),
        "tool": tool,
        "url": url,
        "allowed": allowed,
        "reason": reason,
    }
    with open("tool-audit.jsonl", "a", encoding="utf-8") as log:
        log.write(json.dumps(event, ensure_ascii=False) + "\n")

def call_tool(tool: str, url: str) -> None:
    allowed, reason = authorize(tool, url)
    audit(tool, url, allowed, reason)

    if not allowed:
        raise PermissionError(reason)

    # Faça a requisição apenas depois da autorização.
    # Em produção, use também proxy/firewall de saída e timeouts.
    print(f"Requisição autorizada para {url}")

if __name__ == "__main__":
    call_tool("consultar_api", "https://api.exemplo.com/v1/status")

Esse código não cria um air gap e não é uma proteção completa contra SSRF. Uma validação no processo não resolve, sozinha, problemas como DNS rebinding, redirecionamentos para outro host ou configurações inseguras de proxy. Em produção, configure o cliente para não seguir redirecionamentos sem nova validação e imponha limites de saída na rede, de preferência em um proxy ou firewall controlado.

Erros comuns ao conectar IA a ferramentas

Confiar apenas no prompt. Instruções como “não acesse sites externos” não são controle de segurança. A autorização precisa estar no código e na infraestrutura.
Usar credenciais amplas. Chaves administrativas aumentam o impacto de um erro. Prefira credenciais de curta duração, escopo mínimo e rotação definida.
Permitir acesso irrestrito à internet. Se a aplicação só precisa consultar um serviço, não há motivo para liberar qualquer destino de saída.
Ignorar redirecionamentos e DNS. Validar o domínio inicial pode não ser suficiente se a requisição for redirecionada ou se a resolução do host mudar.
Registrar tudo sem filtrar. Logs podem acabar armazenando tokens, dados pessoais ou conteúdo confidencial. Audite decisões, mas minimize e proteja os dados registrados.
Tratar um teste aprovado como certificado permanente. Mudanças no modelo, nas ferramentas e nos dados exigem reavaliação do risco.

O que muda para quem desenvolve software

Mesmo que um órgão internacional leve tempo para surgir — e a proposta não determine como ele seria estruturado — as práticas de engenharia podem melhorar agora. A recomendação mais útil para uma equipe é tratar cada integração de IA como uma nova fronteira de segurança: documentar o que o modelo pode fazer e reduzir essas permissões ao mínimo.

Para aplicações web, isso inclui separar o serviço que conversa com o modelo dos sistemas internos, evitar enviar segredos no contexto, validar saídas antes de executá-las e exigir confirmação para operações irreversíveis. Para pipelines de avaliação, significa testar o comportamento do modelo com as mesmas ferramentas e restrições que existirão em produção.

O ponto central é não confundir capacidade com acesso. Um modelo pode ser capaz de produzir uma instrução perigosa, mas o impacto depende do que o sistema ao redor permite que ele faça. É nesse intervalo entre a resposta e a ação que controles de rede, autorização, revisão humana e auditoria fazem diferença.

Perguntas frequentes sobre segurança de IA avançada

O que é um air gap em sistemas de IA?

É o isolamento do sistema em relação a redes externas. Pode reduzir o risco de acesso remoto durante testes, mas não substitui controles sobre arquivos, dispositivos removíveis, credenciais e pessoas com acesso ao ambiente.

Um sandbox é suficiente para proteger um agente de IA?

Não necessariamente. O sandbox limita ações dentro do ambiente, mas uma ferramenta autorizada ainda pode acessar uma rede ou serviço. Combine isolamento de processo com permissões mínimas, firewall de saída e monitoramento.

Por que um agente de IA precisa de uma lista de permissões?

Porque o modelo pode solicitar ações que não deveriam ser executadas. Uma lista de permissões limita ferramentas e destinos ao que a tarefa realmente exige, reduzindo o impacto de erros, instruções maliciosas e configurações inadequadas.

O código de autorização apresentado bloqueia ataques SSRF?

Não sozinho. Ele demonstra validações básicas, mas uma defesa contra SSRF exige controles adicionais, como proxy de saída, bloqueio de redes internas, tratamento seguro de DNS e validação de redirecionamentos.

Um registro público de incidentes pode criar novos riscos?

Sim, se revelar detalhes exploráveis antes de uma correção ou expuser dados sensíveis. Por isso, o processo precisa prever triagem, proteção de informações e divulgação responsável, sem eliminar o aprendizado público.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.