1.3 — Gestão de Permissões e I/O: RBAC no Agent Loop e Raio de Impacto

Objetivo da Aula

Aplicar o modelo RBAC (Role-Based Access Control) ao loop de execução de um agente de IA

Calcular e classificar o raio de impacto de uma ação antes de permitir sua execução

Distinguir operações de leitura, escrita local e escrita com efeito externo, e o tratamento que cada uma exige

Projetar um gate de aprovação humana (HITL) que não pode ser contornado pelo próprio modelo

Justificar quando isolamento de rede é a barreira certa em vez de apenas checagem de permissão

Por que isso importa

Um agente de IA com acesso de leitura a um repositório e um agente com acesso de escrita e execução de comandos de shell são, do ponto de vista de risco, sistemas completamente diferentes — mesmo que rodem o mesmo modelo, com o mesmo prompt. A diferença não está no "quão inteligente" o agente é. Está em quanto dano ele pode causar antes que um humano perceba.

Isso não é uma preocupação teórica. Times de engenharia já perderam bases de dados de produção porque um agente com credencial de escrita executou um comando destrutivo interpretando mal uma instrução ambígua. O modelo não "quis" causar dano — ele operou dentro da permissão que tinha, e a permissão era maior do que a tarefa exigia. Esse é exatamente o tipo de falha que RBAC bem desenhado existe para prevenir: não impedir que o modelo erre (isso é impossível de garantir com um componente probabilístico), mas garantir que o erro, quando acontecer, tenha um teto de dano conhecido e aceitável.

Impacto direto no seu trabalho: toda vez que você configura um novo agente, a primeira pergunta de arquiteto não é "que tarefa ele vai fazer" — é "qual é o pior resultado possível se ele fizer essa tarefa errado, e esse pior resultado é algo que a empresa pode absorver?" Se a resposta for não, a permissão precisa ser menor, mesmo que isso signifique mais fricção operacional. Esse capítulo dá o vocabulário e o modelo mental para tomar essa decisão de forma sistemática, em vez de na base do medo ou da confiança cega.

Conceitos Fundamentais

RBAC adaptado ao Agent Loop

RBAC (controle de acesso baseado em papel) é um modelo clássico de segurança: em vez de conceder permissões a um usuário individualmente, você define papéis (roles), cada papel tem um conjunto de permissões, e usuários são atribuídos a papéis. No contexto de um agente de IA, o "usuário" que precisa de um papel não é uma pessoa — é a combinação de agente + tarefa + sessão.

O ponto central: o papel não é atribuído ao modelo (que é o mesmo LLM por trás dos três exemplos acima) — é atribuído à instância operacional do agente para aquela tarefa específica. O mesmo modelo, chamado em contextos diferentes, opera sob papéis diferentes, com permissões concedidas e aplicadas pelo harness, nunca pelo próprio modelo.

Raio de impacto: read, write local, write externo

Nem toda ação tem o mesmo risco. Classificar operações por raio de impacto é o que permite decidir, de forma objetiva, quais exigem aprovação humana e quais podem rodar de forma autônoma:

O harness classifica cada ferramenta disponível ao agente com um desses níveis antes mesmo de o agente rodar — a classificação não é uma decisão em tempo real do modelo, é uma configuração estática de arquitetura. Isso significa que, mesmo que o modelo "decida" que uma ação de Nível 3 é urgente e deveria pular a aprovação, o harness não expõe caminho técnico para isso acontecer.

Aprovação humana (HITL) como gate, não como sugestão

Um erro de implementação comum é fazer o próprio modelo "perguntar" ao usuário antes de agir — via texto, esperando que o usuário responda "sim" no chat. Isso não é HITL de verdade, é um teatro de aprovação: se o modelo decide não perguntar (por erro, por prompt malicioso injetado, por confusão de contexto), nada tecnicamente impede a execução.

HITL falso (aprovação como sugestão do modelo):
  1. Modelo decide chamar ferramenta de Nível 3
  2. Modelo GERA TEXTO perguntando "posso prosseguir?"
  3. Modelo TAMBÉM chama a ferramenta na mesma resposta
  4. Harness executa a ferramenta porque foi chamada
  → falha: a "pergunta" não bloqueou nada de fato.

HITL real (aprovação como gate do harness):
  1. Modelo decide chamar ferramenta de Nível 3
  2. Harness INTERCEPTA a chamada antes de executar
  3. Harness verifica: nivel_de_risco(ferramenta) >= 3?
  4. Se sim, harness SUSPENDE o loop e aguarda aprovação
     explícita fora do canal de texto do modelo
     (ex: clique de confirmação numa interface separada)
  5. Só após aprovação humana registrada, harness EXECUTA
  → a execução é fisicamente impossível sem o passo 4.

A diferença central: no HITL real, a suspensão do loop e a checagem de aprovação são código do harness, executado independentemente do que o modelo "disse" que ia fazer. O modelo pode pedir a ferramenta; só o harness decide se ela roda.

Aprofundamento Técnico

Isolamento de rede como segunda camada, não substituto de RBAC

RBAC controla quem pode pedir o quê. Isolamento de rede controla o que é fisicamente alcançável, independentemente de permissão lógica. As duas camadas são complementares, não redundantes — e um erro comum é achar que uma substitui a outra.

Cenário: agente de revisão de código

Só RBAC (sem isolamento de rede):
  → Papel do agente diz "sem permissão de rede externa"
  → Mas o processo do agente roda numa máquina com acesso
    de rede irrestrito
  → Se houver um bug no harness, ou uma ferramenta mal
    configurada, ou uma dependência comprometida (supply
    chain attack), o agente TEM meio físico de vazar dados
    mesmo violando a política declarada.

RBAC + isolamento de rede (defesa em profundidade):
  → Papel do agente diz "sem permissão de rede externa"
  → Processo do agente roda em sandbox/container SEM
    rota de rede para fora, exceto allowlist explícita
    (ex: apenas o endpoint da API do LLM e do provedor
    de git, nada mais)
  → Mesmo que o RBAC lógico falhe (bug, exploit), não
    existe caminho físico para exfiltração de dados.

Isolamento de rede é a aplicação do princípio "não confie apenas em política, aplique com barreira física" — o mesmo raciocínio por trás de VLANs e firewalls em arquitetura de rede tradicional, adaptado ao Agent Loop. Para agentes com raio de impacto alto (Nível 2-3), a combinação de RBAC lógico e isolamento de rede físico é o padrão mínimo aceitável, não um exagero de segurança.

Modelando permissão como função do contexto operacional, não fixa

Um sistema mais maduro não trata permissão como um valor estático atribuído uma vez — trata como uma função do contexto operacional corrente:

function permissao_efetiva(papel_base, contexto):
    permissoes = copiar(papel_base.permissoes)

    # Restringir ainda mais sob condições de risco elevado
    if contexto.ambiente == "producao":
        permissoes.write = remover_paths(permissoes.write,
                                          "/infra/prod/**")

    if contexto.confianca_da_sessao == "baixa":
        # ex: sessão iniciada a partir de conteúdo externo
        # não confiável (email, ticket de suporte, PR de
        # fora da organização)
        permissoes.execute = []
        permissoes.write = []

    if contexto.horario_fora_de_expediente:
        permissoes.nivel_maximo_sem_hitl = 1

    return permissoes

Esse padrão — permissão como função, não constante — é o que permite que o mesmo papel base ("agente-deploy-assistido") se comporte de forma mais restritiva quando o contexto de risco aumenta (fora do horário comercial, sessão iniciada a partir de fonte não confiável, ambiente de produção). É a aplicação prática, na camada de permissões, do mesmo princípio de contexto dinâmico do capítulo 1.2: a permissão certa depende do estado operacional, não é um valor fixo decidido uma vez na configuração inicial.

Trade-off: fricção de aprovação vs. velocidade operacional

Cada gate de HITL adicionado reduz risco e aumenta fricção. Um sistema com aprovação obrigatória para toda escrita, mesmo local e reversível, é seguro mas lento demais para ser útil — os usuários eventualmente encontram formas de contornar o processo (aprovar sem revisar de verdade), o que anula o benefício de segurança e ainda cria falsa sensação de controle. A calibração correta do raio de impacto (Nível 0 a 3) existe justamente para concentrar fricção de aprovação onde ela importa — ações irreversíveis ou caras — e deixar fluir sem atrito tudo que é barato de reverter. Arquitetar permissões bem não é maximizar segurança a qualquer custo; é alinhar o custo de fricção ao custo real do risco.

Padrões e Armadilhas

Padrões recomendados

Padrão 1: audite ferramentas de alto raio de impacto separadamente. Mantenha um inventário explícito de todas as ferramentas classificadas como Nível 2-3, revisado periodicamente por alguém fora do time que as implementou. É comum uma ferramenta nascer como Nível 1 (escrita local reversível) e, meses depois, ganhar um efeito colateral externo — por exemplo, passar a disparar uma notificação irreversível — sem que sua classificação de risco seja atualizada junto.

Padrão 2: torne o HITL assíncrono quando possível, não bloqueante. Nem toda aprovação humana precisa pausar o agente no meio da tarefa esperando um clique. Para ações de Nível 2, muitas vezes é suficiente que o harness prossiga com o restante do trabalho que não depende daquela ação específica, e só bloqueie o passo que de fato exige aprovação — reduzindo a fricção percebida sem abrir mão do gate.

Padrão 3: registre toda decisão de permissão, inclusive as negações. Um log que só registra o que foi executado é incompleto. Registrar também as tentativas bloqueadas pelo RBAC — o agente tentou chamar uma ferramenta fora do seu papel e foi barrado — é o dado mais valioso para detectar tanto bugs de configuração de papel quanto tentativas de manipulação via prompt injection.

Armadilhas comuns

⚠️ Armadilha 1: papel amplo demais "por praticidade". O que acontece: durante o desenvolvimento, é mais rápido dar ao agente um papel com permissão ampla (acesso de leitura e escrita a tudo) para não precisar reconfigurar RBAC a cada nova ferramenta testada — e esse papel amplo migra, sem revisão, para produção. Versão correta: o papel de desenvolvimento nunca é promovido diretamente a produção; um papel de produção é definido a partir do menor conjunto de permissões que a tarefa real exige, revisado antes do primeiro deploy.

⚠️ Armadilha 2: classificar o raio de impacto pela ferramenta, ignorando o argumento. O que acontece: a ferramenta escrever_arquivo é classificada uniformemente como Nível 1 (escrita local reversível), mas nada impede que ela seja chamada com um caminho que aponta para /infra/prod/config.yaml. A classificação de risco de uma ferramenta genérica de escrita depende do alvo, não só do nome da ferramenta. Versão correta: validar o argumento (caminho, escopo, destino) contra a política de RBAC antes de decidir o nível de risco efetivo daquela chamada específica.

⚠️ Armadilha 3: tratar isolamento de rede como opcional para agentes "só de leitura". O que acontece: um agente com permissão apenas de leitura é considerado de baixo risco e roda sem isolamento de rede, sob a lógica de que "ele não escreve nada". Mas leitura de dados sensíveis seguida de capacidade de rede irrestrita é, por si só, um vetor de exfiltração — o dano não vem de escrita, vem de vazamento. Versão correta: isolamento de rede é dimensionado pela sensibilidade do que é lido, não apenas pela permissão de escrita.