Uma equipa de plataforma implementa o Claude Code para uma dúzia de engenheiros. Para o tornar útil, ligam-no a alguns servidores MCP: um que lê o monorepo, um que consulta uma réplica de relatórios, um que abre tickets. Numa semana, um agente está a ler código-fonte, a tocar numa base de dados e a chamar ferramentas internas — e ninguém consegue responder à pergunta que um auditor acabará por fazer: qual o agente que fez o quê, a que recurso, e consegue provar que não foi alterado posteriormente?
Esta não é uma lacuna hipotética. Investigação independente do setor (CSA/Token, n=418) concluiu que cerca de 82% das organizações têm agentes de IA em execução de que não têm conhecimento, ao passo que apenas cerca de 21% mantêm um inventário deles em tempo real. O Claude Code e o MCP são exatamente o tipo de capacidade que aterra depressa e ultrapassa a narrativa de auditoria. A boa notícia: um registo defensável é alcançável inteiramente dentro do seu próprio perímetro, sem que payloads ou segredos saiam dele.
Porque é que a configuração óbvia não passa numa auditoria
A primeira implementação habitual partilha uma só credencial. Cada instância do Claude Code autentica-se na camada MCP e nas bases de dados a jusante como a mesma conta de serviço — mcp-runner, ci-bot, algo genérico. Funciona, e destrói silenciosamente a atribuição.
Quando dez agentes atuam como um único principal, o registo de auditoria da base de dados mostra dez escritas a partir de mcp-runner e nada mais. Não consegue saber qual a sessão de que engenheiro emitiu o UPDATE, se veio de um prompt interativo do Claude Code ou de um job não assistido, nem qual a ferramenta MCP que estava no caminho. Investigação independente (Optro) situa a fração de organizações que conseguem rastrear a ação de um agente até uma pessoa em cerca de 28%. Uma conta de serviço partilhada é uma das razões estruturais para o colapso da atribuição: o registo de auditoria pode mostrar o que aconteceu, mas nunca qual o agente que o fez.
A segunda falha é a integridade. Mesmo as equipas que registam por ação escrevem habitualmente para um armazenamento mutável. Se os registos vivem no mesmo sistema a que um atacante (ou um agente com bugs) consegue chegar, “temos registos” não é o mesmo que “temos provas”. Um auditor distingue claramente as duas coisas.
A identidade por agente é a base
Tudo o que vem a jusante depende da atribuição, por isso corrija a identidade primeiro. Em vez de um único token partilhado, emita uma identidade distinta e de curta duração por agente — idealmente por sessão. A identidade viaja com o pedido para dentro do servidor MCP e para qualquer recurso que o agente alcance, pelo que o principal registado na base de dados é o agente e não um runner genérico.
É isto que torna o least-privilege significativo. Um agente de relatórios pode ser fixado em apenas leitura na réplica de relatórios; um agente de release recebe escrita apenas para os artefactos que possui. Agora, uma única escrita observada fora desse envelope é um sinal preciso e atribuível, em vez de ruído numa conta partilhada. Expressa como política, a intenção é direta:
agent "reporting-assistant" {
# Claude Code session via the reporting MCP server
resource "prod-postgres/reporting_replica" {
access = "read" # SELECT only
deny = ["write", "ddl"]
}
resource "s3://billing-exports" {
access = "read"
}
on_violation {
action = "block_and_alert" # refuse at access time, not just log
}
}O ponto não é a sintaxe — é que a política nomeia o agente, nomeia o recurso e separa a leitura da leitura/escrita. Essa separação é tudo o que importa.
Trate as anotações MCP como sinais não confiáveis
As ferramentas MCP podem descrever-se a si próprias com anotações como readOnlyHint e destructiveHint. São genuinamente úteis para triagem — uma ferramenta que se declara destrutiva merece uma política mais apertada. Mas a especificação MCP é explícita ao afirmar que estas são sugestões, e os clientes não devem confiar nelas para decisões de segurança. Têm origem no servidor, que é precisamente aquilo que está a auditar. Uma ferramenta pode declarar readOnlyHint: true e ainda assim executar uma escrita, seja por um bug, por uma má configuração ou por evasão deliberada.
Por isso, a postura correta é a corroboração, não a confiança. Tome a anotação como uma alegação e, depois, verifique-a face à verdade fundamental de uma camada que a ferramenta não controla:
- Registos de auditoria da base de dados (por exemplo, o pgAudit do PostgreSQL) dizem-lhe se um
SELECTou umUPDATEfoi efetivamente executado. - Spans de OpenTelemetry do servidor MCP e dos serviços a jusante mostram o grafo de chamadas e as operações realizadas.
- Sinais eBPF ao nível do kernel são a salvaguarda anti-evasão: uma syscall de escrita para um ficheiro ou socket é observável no kernel, independentemente do que a ferramenta alegou no espaço de utilizador.
Quando a anotação diz apenas leitura e o kernel viu uma escrita, essa contradição é a descoberta de destaque — uma ferramenta readOnlyHint que escreveu em prod-postgres é precisamente o desvio de least-privilege que vale a pena acordar alguém para tratar. A diferença entre o que a política permitiu e o que os coletores observaram é onde reside o verdadeiro risco.
O registo que um auditor irá aceitar
Um registo só é prova se for à prova de adulteração. Escreva cada evento num registo apenas de acréscimo, encadeado por hash: cada registo inclui o hash do anterior, pelo que qualquer edição ou eliminação a jusante quebra a cadeia e é detetável. Cada linha atribui a ação ao agente específico, nomeia o recurso, regista leitura versus leitura/escrita e transporta um nível de confiança — attributed quando a identidade e o resultado estão ambos corroborados, approximate quando algo teve de ser inferido. A confiança é apresentada com honestidade; uma correspondência aproximada nunca é disfarçada de uma comprovada.
ts=2026-06-08T09:14:02Z agent=reporting-assistant@s3f1 tool=sql-read resource=prod-postgres/reporting_replica op=R outcome=allow conf=attributed prev=8a1c…
ts=2026-06-08T09:14:05Z agent=reporting-assistant@s3f1 tool=export-writer resource=s3://billing-exports op=R outcome=allow conf=attributed prev=2f90…
ts=2026-06-08T09:17:48Z agent=data-export-job@b22e tool=sql-write resource=prod-postgres/customers op=RW outcome=DENY conf=attributed prev=c7d3… policy=read_only_violationEssa terceira linha é aquela que interessa a um auditor: uma tentativa de escrita numa tabela para a qual o agente não tinha qualquer concessão de escrita, negada no momento do acesso, atribuída a um agente nomeado e ancorada na cadeia. Como a política é imposta quando o acesso acontece — e não meramente registada depois — a negação é um controlo, não uma autópsia.
Mais duas propriedades fazem o registo aguentar-se. As vistas privilegiadas são elas próprias auditadas: olhar para o mapa de acessos fica registado, pelo que “quem viu o quê” tem resposta. E a exportação de provas é à prova de adulteração — entrega a um auditor uma fatia assinada da cadeia que ele pode verificar de forma independente, em vez de um CSV que tem de aceitar de boa-fé.
| Propriedade | Conta de serviço partilhada | Identidade por agente + registo encadeado por hash |
|---|---|---|
| Atribuição | Um único principal para todos os agentes | Ação associada ao agente/sessão específico |
| Leitura vs escrita | Misturadas | Distinguidas e verificadas pela política |
| Integridade | Registos mutáveis | Apenas de acréscimo, a cadeia quebra-se na edição |
| Exportação pronta para auditoria | CSV aceite de boa-fé | Fatia assinada e verificável de forma independente |
Porque é que o self-hosted importa aqui
Tudo isto funciona sem que nada saia da sua rede. O coletor observa — registos, OpenTelemetry, eBPF como salvaguarda ao nível do kernel — em vez de se sentar no caminho de dados do agente, pelo que, se falhar, nunca quebra o agente nem o pedido de produção que está por trás dele. O registo armazena relações de acesso, não payloads: regista que reporting-assistant leu reporting_replica, não as linhas que devolveu. As entradas que possam transportar segredos ou dados pessoais são redigidas e analisadas em busca de segredos antes de qualquer coisa ser escrita. Para infraestruturas air-gapped, sujeitas ao RGPD ou com restrições de residência de dados, essa é a diferença entre uma narrativa de auditoria que pode defender e uma que não pode: nada sobre a sua utilização do Claude Code e do MCP comunica para o exterior, porque o sistema nunca vê os dados, para começar.
O Claude Code e o MCP valem a pena ser implementados. Só precisam de um registo de auditoria construído da mesma forma que o construiria para qualquer outra automação privilegiada — identidade primeiro, resultados corroborados, provas ancoradas. Se quiser ver como o mapa de acessos e o registo à prova de adulteração se encaixam, o modelo de segurança e a visão geral do produto aprofundam cada um deles.