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 (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
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 (a captura ao nível do kernel vem de um sensor Tetragon que implementa; Olivares AI lê a exportação do Tetragon e não carrega programas eBPF por si), 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:
| Agente | Recurso | Permitido | Observado | Desvio |
|---|---|---|---|---|
| data-export-job | prod-postgres | R | R | nenhum |
| data-export-job | s3://billing-exports | R | RW | escrita não revista |
| report-builder | analytics-db | R | (não utilizado) | privilégio morto |
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 política avaliada no momento do acesso.
Olivares AI avalia o Cedar como uma camada de forbid sobre papéis que negam por defeito, pelo que uma regra só pode retirar acesso; esta nega qualquer pedido que toque numa credencial secreta, diga o papel o que disser.
permit(principal, action, resource);
forbid(principal, action, resource)
when { resource.kind == "credential" && resource.sensitivity == "secret" };Escrever as suas próprias regras Cedar requer Business; Community aplica os papéis integrados, a camada de negação nativa e o kill switch; os papéis personalizados e as concessões delimitadas são Business.
Percorra o antes e o depois de forma concreta.
Antes. Um agente de código, detendo um papel abrangente, chama uma ferramenta MCP que escreve em 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 chamada de ferramenta chega ao ponto de controlo MCP. O papel do agente não permite a escrita, pelo que o ponto de controlo nega a chamada antes de ser executada (deny-closed) e regista a negação no registo de auditoria assinado, que permite detetar adulterações. A escrita não revista nunca chega a ser uma alteração não revista. Olivares AI bloqueia uma ação apenas nos seus quatro pontos de imposição: dentro do Claude Code, no proxy de modelos, em cada chamada de ferramenta MCP e entre agentes. Um trabalho que escreve diretamente no S3, fora desses pontos, não é bloqueado: o mapa de acessos regista a escrita e assinala-a como desvio para revisão.
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 aresta cuja origem transporta uma identidade por agente é marcada como attributed, ao passo que uma vista apenas pelo kernel é marcada como approximate, porque os sinais do kernel identificam um processo, um cgroup ou um contentor, não um agente. 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.