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, e apenas cerca de 21% mantêm um inventário em tempo real. 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 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 apoiada por um sinal do kernel e por uma entrada de auditoria correspondente é marcada como atribuída; uma aresta inferida a partir de telemetria parcial é marcada como aproximada. 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   attributed
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. Como a escrita está corroborada na fronteira do kernel, é marcada como attributed, não como uma suposição.

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 e a violação seja tratada, não apenas registada:

policy "data-export-readonly" {
  agent        = "data-export-job"
  resource     = "prod-postgres"
  allow        = ["read"]
  deny         = ["write"]
  on_violation = "block + alert"
}

A descoberta passiva encontra a escrita não permitida; a política prende o agente de volta ao least-privilege e bloqueia a próxima. 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.