Desvio do privilégio mínimo: detetar agentes de IA com privilégios excessivos antes de um incidente

O privilégio mínimo é uma das ideias mais antigas e fiáveis em segurança. Dê a uma identidade exatamente o acesso de que precisa, nada mais, e o raio de impacto de qualquer comprometimento mantém-se reduzido. Para contas humanas e contas de serviço de longa duração, o modelo aguenta-se razoavelmente bem: os papéis são revistos, as concessões são delimitadas e as certificações de acesso correm com uma cadência trimestral.

Os agentes de IA quebram este modelo em silêncio. Um agente recebe uma credencial, uma ferramenta, uma ligação a um servidor MCP e, a partir desse momento, o seu comportamento é dinâmico. Decide em runtime que recursos ler, quais escrever, que ferramenta invocar a seguir. A concessão que escreveu no primeiro dia descreve um teto, não o que o agente faz. E como os agentes são produtivos, esse teto tende a ser generoso: papéis de base de dados abrangentes, acesso de escrita “por via das dúvidas”, uma conta de serviço partilhada por meia dúzia de fluxos de trabalho. O resultado é um parque onde o acesso permitido e o acesso efetivamente utilizado se afastam, em silêncio, todos os dias.

Investigação independente do setor capta a dimensão deste ponto cego: cerca de 82% das organizações relatam ter agentes de IA em execução de cuja existência não tinham conhecimento, ao passo que apenas cerca de 21% mantêm um inventário em tempo real dos mesmos (CSA/Token Security, n=418). Não se pode aplicar o privilégio mínimo a um parque que não se consegue ver.

Definir o desvio do privilégio mínimo

Deixe-me nomear a coisa com precisão. O desvio do privilégio mínimo é a diferença crescente entre o acesso que um agente está autorizado a usar e o acesso que se observa que ele usa. Tem duas direções de falha, e apenas uma delas é evidente.

A direção evidente é a subutilização: um agente detém acesso de escrita a uma tabela onde nunca escreveu. Isso é privilégio morto, e é um risco que está a carregar sem qualquer benefício. A direção perigosa é o sinal inverso que ela implica: quando o conjunto observado contém algo que o conjunto permitido nunca concedeu deliberadamente, tem uma ação a acontecer que ninguém reviu. Um trabalho de exportação que, de repente, escreve num bucket de onde apenas lia. Um agente que a política delimitou a um esquema a estender-se a outro. Estes casos não são exóticos; são a textura quotidiana de agentes ligados entre si com concessões genéricas.

A razão pela qual isto é difícil, e a razão pela qual é específico dos agentes e não dos humanos, é que o comportamento é gerado, não configurado. Um humano com demasiado acesso, na maioria dos casos, não o exerce. Um agente com demasiado acesso vai exercer tudo o que ajude a concluir a tarefa que tem à frente, incluindo caminhos que ninguém antecipou. A revisão estática de políticas não consegue acompanhar um comportamento que muda a cada execução.

Transformar o desvio num sinal revisável

O desvio só é perigoso enquanto é invisível. A tarefa é torná-lo um sinal que um humano possa rever, e isso exige duas coisas a funcionar em conjunto: observação contínua daquilo em que os agentes tocam realmente e um registo estável daquilo que estavam autorizados a tocar.

A observação tem de ser read-first. Um coletor que observa a partir de logs, traces do OpenTelemetry e sinais do kernel via eBPF fica fora do caminho de dados do agente. Não é um proxy, não controla chamadas e, se falhar, falha de forma aberta no bom sentido: o agente continua a funcionar, perde-se visibilidade em vez de disponibilidade. Essa assimetria é importante: um controlo de segurança que pode derrubar a produção é um controlo que as equipas desativam em silêncio. A camada eBPF, em particular, atua como ground truth ao nível do kernel, a parte que um agente não consegue contornar, e é por isso que pistas ao nível do protocolo, como as anotações de ferramentas MCP (readOnlyHint, destructiveHint), são corroboradas contra ela em vez de serem aceites como fidedignas. A própria especificação MCP afirma que essas anotações não são fidedignas; são os sinais do kernel que tornam a corroboração real.

O que a observação produz é um mapa de acessos: para cada agente, que recursos alcançou e se leu (R) ou leu/escreveu (RW). O mapa armazena relações de acesso, não payloads, segredos ou PII. A parte interessante é o diff:

A linha que importa é a do meio. A política concedeu leitura no bucket de exportação; o coletor observou uma escrita. Essa única linha é o risco de destaque que o desvio do privilégio mínimo se destina a expor: um privilégio exercido que ninguém reviu, atribuído a um agente específico e não a uma conta de serviço partilhada, porque é a identidade por agente que torna possível, em primeiro lugar, a atribuição e a auditoria.

Aplicar no momento do acesso, não apenas registar

A deteção diz-lhe que o desvio aconteceu. Para fechar o ciclo, quer que a escrita não revista seja um caminho negado, não um caminho registado. É aí que entra a policy-as-code avaliada no momento do acesso. O mesmo diff que assinalou o desvio passa a ser a regra que o impede.

Considere fixar o trabalho de exportação a apenas leitura na base de dados de produção e negar liminarmente as escritas, com uma violação que bloqueia e alerta em vez de passar silenciosamente:

agent "data-export-job" {
  # Read-only on the operational database. No writes, ever.
  access "prod-postgres" {
    mode  = "read"
    deny  = ["write", "delete", "ddl"]
  }

  # The export target the job is *supposed* to use.
  access "s3://billing-exports" {
    mode = "read"
  }

  on_violation {
    action = "block"        # deny the call at access time
    alert  = "security-oncall"
    audit  = "append"       # write to the tamper-evident ledger
  }
}

Percorra o antes e o depois de forma concreta.

Antes. O trabalho de exportação, detendo um papel abrangente, emite uma escrita para s3://billing-exports. Nada o impede. A ação tem sucesso, mistura-se com o tráfego normal e aparece dias mais tarde, se é que aparece, como uma anomalia no mapa de acessos. A diferença entre permitido e observado alargou-se, e o único artefacto é uma linha de log que ninguém leu.

Depois. A mesma escrita chega. A política é avaliada no momento do acesso, vê write num recurso delimitado a read e devolve uma negação antes de a operação se concretizar. A violação bloqueia a chamada, levanta um alerta para a rotação de on-call e acrescenta uma entrada ao registo de auditoria que permite apenas anexação e está encadeado por hash. A escrita não revista nunca chega a ser uma alteração não revista. O desvio é convertido, no momento, de volta num caminho de privilégio mínimo.

Duas propriedades mantêm isto honesto. Primeiro, cada visualização privilegiada do mapa de acessos é, ela própria, auditada — quem viu o quê —, porque o mapa é sensível e uma ferramenta de segurança que não consegue prestar contas dos seus próprios operadores não é digna de confiança. Segundo, a confiança é mostrada de forma clara: uma ação atribuída a um agente por evidência ao nível do kernel é marcada de modo diferente de uma inferida de forma aproximada. Nunca lhe é pedido que aja com base numa certeza fabricada.

A conclusão

O privilégio mínimo não falhou para os agentes de IA; o que falhou foi a cadência de revisão. As concessões são genéricas, o comportamento é dinâmico e as certificações trimestrais não conseguem acompanhar uma superfície de acesso que muda a cada execução. A correção não é um proxy mais pesado no caminho crítico. É a observação contínua e read-first que produz um diff de permitido vs. observado, mais policy-as-code que aplica a fronteira corrigida no momento do acesso, para que um agente com privilégios excessivos seja detetado como um sinal revisável muito antes de se tornar um incidente.

Se quiser ver como o coletor, o mapa de acessos e a aplicação no momento do acesso se encaixam sem se colocarem no caminho de dados dos seus agentes, a página de arquitetura percorre o design, e o produto mostra o aspeto da vista de permitido vs. observado num parque real.