Descoberta passiva versus proxies: inventariar agentes de IA sem ficar no caminho dos dados

A maioria das equipas descobre o mesmo facto incómodo pela mesma ordem. Primeiro percebem que já existem agentes de IA a funcionar por todo o seu parque, a invocar modelos, a abrir servidores MCP, a aceder a bases de dados e a armazenamentos de objetos. Depois tentam inventariá-los e descobrem que não há lista nenhuma. Investigação independente do setor (CSA/Token, n=418) coloca números na lacuna: cerca de 82% das organizações têm agentes a funcionar de que não têm conhecimento. Antes de poder governar seja o que for disto, tem de o ver. A questão é como obter essa visibilidade sem piorar as coisas.

Há duas respostas honestas, e situam-se em extremos opostos de um espectro de risco.

Duas formas de ver um agente

A primeira é um proxy em linha. Encaminha o tráfego do agente através de um componente que controla e, porque cada pedido e cada resposta passam por ele, consegue ver, moldar e bloquear em tempo real. Trata-se de uma conceção legítima e poderosa. É assim que muita filtragem de saída, intermediação de segredos e política ao nível do pedido são aplicadas hoje em dia.

A segunda é a descoberta passiva. Em vez de se colocar no fluxo, observa-o de lado: o OpenTelemetry que um agente já emite, os registos de auditoria nativos dos sistemas que toca (PostgreSQL pgAudit, registos de auditoria da cloud como o AWS CloudTrail, auditoria do Kubernetes) e sinais ao nível do kernel via eBPF como rede de segurança que serve de fonte de verdade. Nunca termina a ligação. Observa o que aconteceu e reconstrói quem tocou em quê. A captura ao nível do kernel vem de um sensor Tetragon que implementa; a Olivares AI lê a exportação do Tetragon e não carrega programas eBPF por si própria.

A diferença que importa não é quanto cada uma consegue ver no melhor cenário. É o que acontece quando a própria camada de visibilidade falha.

O raio de impacto é o verdadeiro eixo

Um proxy em linha está, por construção, no caminho dos dados. Isso compra controlo em tempo real e custa-lhe um modo de falha partilhado. Se o proxy estiver lento, os seus agentes ficam lentos. Se cair, o comportamento seguro por omissão costuma ser falhar fechado, o que significa que os seus agentes param, ou falhar aberto, o que significa que o seu controlo desaparece silenciosamente no pior momento. De qualquer das formas, o componente de visibilidade passa agora a partilhar o raio de impacto com a produção. Acrescenta também um salto de latência a cada chamada e uma superfície de implementação que alguém tem de operar, escalar e corrigir no caminho crítico.

A descoberta passiva tem o perfil oposto. O coletor está fora de banda e lê primeiro: lê telemetria, registos de auditoria e eventos do kernel; não reencaminha nem reescreve o tráfego do agente. Se se degradar ou morrer, nada no caminho do pedido muda. Perde visibilidade atualizada até recuperar, não débito, não disponibilidade. É isto que significa, na prática, ler primeiro com baixo risco assimétrico: não existe risco adicional para a produção por parte daquilo cujo único trabalho é observar.

É por isto que a posição do produto é nenhum proxy obrigatório em vez de “os proxies são inúteis”. Há caminhos em que um componente em linha é a escolha certa, e eles compõem-se. Mas a descoberta, a parte que nunca deveria poder interromper aquilo que está a inventariar, é o trabalho errado para encaixar no caminho crítico.

O compromisso, dito com honestidade

A descoberta passiva tem uma fraqueza genuína, e fingir o contrário seria o tipo de espantalho que faz com que uma conceção passe a ser silenciosamente desconfiada. Um proxy que termina um fluxo vê cada byte dele. Um coletor passivo só vê aquilo que o agente, o seu runtime ou o recurso decidiram emitir. Num caminho totalmente não cooperativo, que regista pouco e não emite telemetria útil, a descoberta ao nível da aplicação rareia. Pode inferir que algo aconteceu, mas a atribuição torna-se mais difícil.

Duas coisas mantêm isto honesto em vez de fatal.

A primeira é a rede de segurança ao nível do kernel em eBPF. Os registos da aplicação podem ser incompletos, atrasados ou, num caso adversarial, deliberadamente suprimidos. Não se pode pedir educadamente ao kernel que esqueça uma syscall. Um agente que abre um socket para uma base de dados ou que escreve um ficheiro deixa um rasto na fronteira da syscall, independentemente daquilo que o seu registo decidiu gravar. Isso faz do eBPF a fonte de verdade anti-evasão: quando os sinais de mais alto nível discordam ou ficam em silêncio, a visão do kernel é a camada de corroboração. É também por isto que as anotações de ferramentas MCP como readOnlyHint e destructiveHint, úteis como sugestões, são tratadas como não fiáveis segundo a especificação MCP. Uma ferramenta que afirma ser só de leitura e é observada a escrever é precisamente a discrepância que vale a pena destacar, e só a apanha se corroborar a afirmação com aquilo que efetivamente aconteceu.

A segunda são os níveis de confiança honestos. Nem toda a observação merece o mesmo peso, por isso o mapa de acessos não finge que merecem. Uma aresta cuja fonte traz uma identidade por agente, como OpenTelemetry cooperativo com um id de agente ou uma trilha de auditoria em que o agente tem a sua própria função de base de dados, é marcada como atribuída. Uma aresta inferida a partir de telemetria parcial, e toda a aresta vista apenas pelo kernel, é marcada como aproximada, porque os sinais do kernel indicam um processo, um cgroup ou um contentor, não um agente. O produto nunca transforma um palpite em facto. Quem revê deve conseguir ver, num relance, quanto confiar em cada linha.

Da observação à diferença que importa

A descoberta é apenas a entrada. A saída é a comparação entre PERMITTED, o que a política permite, e OBSERVED, o que o coletor efetivamente viu. Essa diferença é o desvio em relação ao least-privilege, e o caso de destaque é uma escrita observada que a política nunca concedeu e que ninguém reviu.

Algumas linhas de um fluxo de acessos tornam isto concreto. As leituras são rotineiras; a escrita assinalada é a história:

agent             action  resource                outcome   confidence
data-export-job   READ    s3://billing-exports    allowed   attributed
data-export-job   READ    prod-postgres           allowed   attributed
data-export-job   WRITE   prod-postgres           flagged   approximate
support-rag       READ    internal-wiki-mcp       allowed   approximate

Uma tarefa de exportação a ler uma base de dados de produção não tem nada de notável. A mesma tarefa a escrever nela, quando a política só alguma vez concedeu leitura, é o tipo de aresta que nunca deveria passar sem revisão. O kernel confirma que a escrita aconteceu, mas indica um processo ou um contentor e não um agente, por isso essa aresta é marcada como approximate.

Ver o desvio é metade do trabalho; fechá-lo é a outra metade. A aplicação pertence ao ponto de acesso, expressa como política como código, para que a regra seja revisível. A Olivares AI avalia o Cedar como uma sobreposição forbid por cima de funções deny-by-default, pelo que uma regra só pode retirar acesso; esta nega qualquer pedido que toque numa credencial secreta, diga o que disser a função.

permit(principal, action, resource);

forbid(principal, action, resource)
  when { resource.kind == "credential" && resource.sensitivity == "secret" };

Escrever as suas próprias regras Cedar requer Business; a 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.

A descoberta passiva encontra a escrita não permitida, e o mapa de acesso assinala-a como desvio. A Olivares AI só bloqueia uma ação nos seus quatro pontos de aplicação: dentro do Claude Code, no proxy de modelos, em cada chamada de ferramenta MCP e entre agentes. Uma escrita que passa por um deles e que o papel do agente não permite é negada antes de ser executada e fica no registo de auditoria assinado e à prova de adulteração; uma escrita direta na base de dados é observada, não bloqueada. A visibilidade e o controlo mantêm-se como preocupações separadas, e é exatamente por isso que a camada de descoberta se pode dar ao luxo de ler primeiro.

Conclusão

A visibilidade sobre agentes de IA é uma decisão de risco antes de ser uma decisão de funcionalidade. Um proxy em linha dá-lhe controlo em tempo real ao custo de partilhar um raio de impacto com a produção. A descoberta passiva abdica de algum alcance em caminhos silenciosos em troca de nunca poder interromper a produção, e depois recupera a maior parte desse alcance com uma rede de segurança em eBPF como fonte de verdade e com níveis de confiança que se mantêm honestos quanto àquilo que foi efetivamente visto. Para um inventário, a camada cujo trabalho inteiro é observar, essa assimetria é o padrão correto.

Se quiser o panorama completo de como os coletores, o mapa de acessos e o livro-razão de auditoria se encaixam, a visão geral da arquitetura percorre-o de ponta a ponta.