O que os seus agentes de IA conseguem realmente alcançar: mapear o acesso dos agentes em infraestrutura real

Um agente de IA é, operacionalmente, um processo que detém credenciais. Alguém provisiona-lhe uma conta de serviço, uma chave de API ou um papel de IAM para que possa fazer o seu trabalho e, a partir desse momento, consegue alcançar tudo o que essas credenciais alcançam. A descrição da tarefa dizia «exportar dados de faturação todas as noites». A credencial dizia «ler e escrever na base de dados de produção, no armazenamento de objetos e na fila». Ninguém reconciliou as duas. Meses depois, ninguém na equipa consegue responder a uma pergunta que devia ser trivial: o que é que este agente consegue realmente alcançar e em que é que ele realmente toca?

Essa diferença não é hipotética. Investigação independente da indústria (CSA/Token) concluiu que cerca de 82% das organizações têm agentes de IA em execução que desconhecem, enquanto apenas cerca de 21% mantêm um inventário em tempo real dos mesmos. Não se pode governar o que não se consegue ver e, neste momento, a maioria dos parques não consegue ver os seus agentes de todo — quanto mais as ligações que unem cada agente aos recursos que consegue alcançar.

Três perguntas diferentes, rotineiramente confundidas

A razão pela qual «o que é que este agente consegue alcançar» é difícil de responder é que junta três perguntas separadas numa só. Mantê-las distintas é o cerne de toda a questão.

• Detido — as credenciais que o agente possui. Um token, uma chave, uma associação de papel. É um facto de identidade: que portas o agente tem chaves para abrir.
• Permitido — o que essas credenciais estão autorizadas a fazer, segundo a política: as concessões de IAM, os papéis da base de dados, as regras de rede. É um facto de política e é quase sempre mais amplo do que alguém se lembra, porque as concessões acumulam-se e ninguém as revoga.
• Observado — o que o agente foi efetivamente visto a fazer: que recursos alcançou e se cada acesso foi uma leitura ou uma escrita. É um facto comportamental e, até o recolher, simplesmente não existe em parte alguma.

A maioria das ferramentas de segurança fica-se pelo permitido. Lê o seu IAM e diz-lhe que o agente poderia escrever no bucket de exportações de faturação. Isso é necessário, mas insuficiente, porque «poderia» é um conjunto de milhares de capacidades latentes e um humano não consegue triar milhares de talvez. O que muda a conversa é colocar o observado ao lado do permitido e olhar para a diferença.

O mapa de acessos

Um mapa de acessos é o grafo dessas ligações: para cada agente descoberto, uma ligação a cada recurso que consegue alcançar, anotada com o que foi efetivamente observado nessa ligação. A unidade que importa é a ligação e a anotação mais importante na ligação é a distinção entre leitura e escrita.

R (leitura) significa que o agente obteve dados sem os alterar: um SELECT, um GET, a leitura de um ficheiro. RW (leitura/escrita) significa que alterou o estado: um INSERT/UPDATE/DELETE, um PUT para armazenamento de objetos, uma migração de esquema. O raio de impacto dos dois não é comparável. Uma ligação de leitura numa tabela sensível é uma questão de exposição. Uma ligação de escrita — sobretudo uma não intencional — é uma questão de integridade e de incidente. Tratá-las como o mesmo «acesso» é como as equipas deixam escapar a descoberta que importava.

Eis o aspeto da linha de um único agente depois de o mapa estar construído:

Repare na primeira linha. A tarefa de exportação destinava-se a ler de prod-postgres e a escrever o resultado em s3://billing-exports. Ler na origem, escrever no destino. Mas a credencial que lhe foi entregue concede RW na base de dados e o coletor observou-a a escrever em prod-postgres — uma alteração no sistema de registo de produção que ninguém reviu, pretendeu ou consegue atualmente explicar. A coluna do permitido dizia em silêncio que isto sempre fora autorizado. Essa é a semente de um incidente, à vista de todos, e sem a coluna do observado não há nada para assinalar.

Permitido menos observado é igual a deriva

O resultado característico é o diff. A deriva do least-privilege é o que se obtém ao subtrair uma coluna da outra e funciona em ambos os sentidos:

• Permitido mas nunca observado — o agente consegue alcançar internal-metrics-api, mas em toda a janela de observação nunca o fez. Isso é âmbito morto: uma concessão que se pode propor revogar com segurança, reduzindo a superfície de ataque sem tocar no comportamento.
• Observado para além do que foi revisto — a escrita em prod-postgres que ninguém aprovou. Esta é a descoberta de alto sinal: uma ação a acontecer que, se alguém tivesse sido consultado no momento do provisionamento, não teria aprovado.

A segunda categoria é o risco em destaque e a versão honesta do produto nunca a inventa. Cada ligação observada tem um nível de confiança — atribuído quando a ação está associada a uma identidade de agente específica com sinal corroborante, aproximado quando a evidência é mais fraca. Mostra-se a diferença em vez de disfarçar uma suposição como uma certeza. Uma descoberta que não se consegue sustentar é pior do que nenhuma descoberta.

Descoberto passivamente, atribuído por agente

Duas decisões de design tornam isto fidedigno em vez de ser apenas mais um painel.

Primeiro, a descoberta é passiva. O coletor observa — logs, traces de OpenTelemetry, fluxos de auditoria de base de dados como o pgAudit do PostgreSQL e eBPF ao nível do kernel como rede de segurança de verdade-fundamental — e não se interpõe no caminho de dados do agente. Não há proxy obrigatório. Se o coletor falhar, o agente continua a funcionar; a observabilidade degrada-se, a produção não. Para um sistema cujo propósito é governar infraestrutura crítica, essa assimetria é o design: pouco a perder, muito sinal.

Segundo, cada ação é atribuída a uma identidade de agente específica, não a uma conta de serviço partilhada. Esta é a diferença entre um registo de auditoria que diz «o papel de exportação escreveu em prod-postgres às 02:14» e um que diz qual o agente que o fez, sob a posse de quem e contra que âmbito pretendido. A identidade por agente é a precondição para que o least-privilege tenha algum significado — sem ela, uma ação pode ser vista, mas nunca rastreada até um responsável.

As ligações e os factos de leitura/escrita são a única coisa armazenada. O mapa regista relações — agente a recurso, R ou RW — não os payloads, não as linhas que foram lidas, nem segredos. As entradas que possam transportar segredos ou dados pessoais são redigidas e analisadas em busca de segredos antes de algo ser escrito. O grafo é sensível precisamente por ser um mapa de acessos, por isso é construído para conter o mínimo que torna a governação possível e nada mais.

Os sinais do próprio ecossistema do agente ajudam, mas não merecem confiança por si só. Um servidor MCP pode anunciar que uma ferramenta é apenas de leitura através de anotações como readOnlyHint; segundo a especificação MCP, essas pistas são não fidedignas e têm de ser corroboradas, nunca acreditadas cegamente. A visão ao nível do kernel é o que apanha uma ferramenta que afirmava ser apenas de leitura e escreveu na mesma.

Assim que o mapa existe, o passo seguinte é a aplicação: fixar a tarefa de exportação como apenas de leitura na base de dados, negar a escrita e alertar em vez de apenas registar — política aplicada no momento do acesso, não reconstruída após o incidente.

agent "data-export-job" {
  resource "prod-postgres" {
    access = "read"        # intended scope: read source only
    deny   = ["write", "ddl"]
  }
  resource "s3://billing-exports" {
    access = "read-write"  # intended scope: write destination
  }
  on_violation {
    action = "block"
    alert  = "secops"
  }
}

O mapa diz-lhe a política que devia ter escrito, porque lhe mostra o único acesso de que o agente realmente precisou e a dúzia que nunca usou. Essa é a diferença entre adivinhar o least-privilege e derivá-lo da verdade-fundamental.

Se esta é a pergunta a que o seu parque não consegue responder hoje — o que é que cada agente consegue alcançar e em que é que ele realmente toca — é exatamente para isso que o mapa de acessos serve. A visão geral do produto percorre a descoberta e o diff entre permitido e observado; a arquitetura explica como a recolha passiva, a identidade por agente e o registo de auditoria se encaixam sem nunca se interporem no caminho de dados dos seus agentes.