agent-access-review: revisões de acesso para agentes de IA e servidores MCP

O que faz

agent-access-review é uma ferramenta de linha de comando de código aberto, publicada sob licença MIT pelo usuário do GitHub Mihirajmera, que aplica o processo de revisão de acesso de usuários a agentes de IA. Ela inventaria todos os agentes e servidores MCP que uma organização executa, determina o que cada um pode ler, escrever, executar e enviar, testa esse acesso contra um catálogo de controles e produz o pacote que um auditor espera: uma folha de aprovação do revisor, evidências com hash e resultados de avaliação OSCAL mapeados para NIST 800-53, SOC 2, o NIST AI Risk Management Framework e o OWASP Top 10 for LLM Applications.

O autor a resume como a revisão trimestral de "quem tem acesso a quê" que as empresas já fazem para funcionários, aplicada a agentes de IA. Como estudo de caso real, o projeto relata o que resulta de copiar as configurações MCP mostradas em READMEs oficiais: 8 de 9 pacotes sem versão fixada, 7 de 9 com acesso de escrita, envio ou execução não revisado, e um caminho de exfiltração quando as permissões são combinadas.

Início rápido

A ferramenta exige Python 3.11 ou superior. Não precisa de conta em nuvem, chaves de API nem acesso à rede.

pip install agent-access-review
agent-access-review demo

A demo revisa cinco agentes de exemplo e grava o pacote em review-demo/; o relatório é review-demo/access-review.md, e um relatório de exemplo também está no repositório.

Para revisar uma configuração real, aponte a varredura para um arquivo de configuração:

Os segredos encontrados nas configurações são mascarados antes de qualquer gravação, de modo que a saída pode ser compartilhada com segurança.

Termos-chave

• Agente de IA: um modelo de IA capaz de realizar ações por meio de ferramentas: ler arquivos, consultar bancos de dados, enviar e-mail ou executar comandos.
• MCP (Model Context Protocol): a forma padrão pela qual aplicações como Claude Desktop, Cursor e VS Code conectam ferramentas a uma IA. Cada servidor MCP em uma configuração é uma ferramenta que o agente pode usar.
• Revisão de acesso de usuários (UAR): a verificação periódica em que o acesso de cada pessoa é listado, um responsável confirma que ele ainda é necessário e o restante é revogado; auditores a testam sob SOX e SOC 2.
• ITGC: IT General Controls, os controles básicos (acesso, gestão de mudanças, operações) que os auditores testam para relatórios financeiros.
• Identidade não humana: uma conta usada por software, e não por uma pessoa: contas de serviço, chaves de API e agora agentes de IA.
• Caminho de exfiltração: uma rota para os dados saírem da organização; aqui, um agente que pode ler dados sensíveis, lê conteúdo que um atacante pode escrever e pode enviar dados para fora.
• Injeção de prompt: esconder instruções em conteúdo que uma IA lê (um e-mail, página web ou ticket) para que ela faça algo que o usuário nunca pediu.
• OSCAL: o formato legível por máquina do NIST para controles de segurança e resultados de avaliação, que permite a ferramentas de GRC importar achados automaticamente.

O problema

Todo programa SOX e SOC 2 executa revisões trimestrais de acesso de usuários: listar quem tem acesso a quê, fazer um responsável confirmar que o acesso ainda é necessário, revogar o restante e guardar as evidências. Os agentes de IA agora detêm o mesmo tipo de acesso (tokens de API, conexões de banco de dados, acesso a shell, caixas de e-mail) e quase ninguém os revisa. O README lista quatro lacunas:

• Sem responsável, sem aprovação. Um desenvolvedor adiciona um servidor MCP à sua configuração do Claude Desktop ou do Cursor e o agente passa a ter imediatamente o token do GitHub e o diretório pessoal dessa pessoa: sem ticket, sem aprovador, e isso nunca aparece em uma revisão de acesso.
• Amplo demais por padrão. Os guias de instalação orientam conceder o diretório pessoal inteiro, o escopo de repositório com controle total ou permissões *.All do Microsoft Graph para todo o tenant.
• Segredos em texto claro. Configurações MCP costumam conter tokens brutos e senhas de banco de dados.
• Um novo caminho de ataque. Um agente que pode ler dados sensíveis, lê conteúdo escrito por um atacante (uma issue do GitHub, um e-mail, uma página web) e pode enviar dados para fora pode ser induzido por injeção de prompt a vazar esses dados; nenhum controle de acesso tradicional examina essa combinação.

A premissa do autor é que agentes são identidades não humanas: precisam dos mesmos controles de joiner/mover/leaver e recertificação que as pessoas, mais alguns específicos de IA.

O catálogo de controles

O texto de apresentação descreve a revisão como um teste de acesso contra 12 controles, enquanto o próprio catálogo e a arquitetura da ferramenta listam 14 verificações, numeradas de AAR-01 a AAR-14:

Cada controle é definido uma única vez em controls.yaml e relacionado a todos os frameworks, de modo que um único teste produz evidências para todos eles. O autor afirma que os mapeamentos para os frameworks são de seu próprio julgamento e devem ser verificados contra os crosswalks oficiais antes de serem usados em uma auditoria real.

Caminhos de exfiltração: o risco específico de IA (AAR-09)

As revisões de acesso tradicionais examinam uma permissão por vez. Nos agentes de IA, o perigo está em uma combinação: um agente que pode ler dados sensíveis, lê conteúdo escrito por alguém de fora e pode enviar dados para fora. Cada trecho é inofensivo sozinho; juntos, uma única injeção de prompt escondida em um e-mail, ticket, issue ou página web pode instruir o agente a vazar os dados. Uma etapa de aprovação humana em qualquer trecho quebra a cadeia.

O README ilustra isso com dois agentes de exemplo. O finance-ops-agent é sinalizado: qualquer pessoa pode escrever para sua caixa de contas a pagar (entrada não confiável), ele lê faturas de fornecedores restritas no NetSuite e pode enviar e-mail para qualquer destinatário sem aprovação humana. O support-copilot passa: lê tickets de clientes e histórico confidencial de tickets, mas um humano aprova cada resposta redigida antes do envio ao cliente.

O AAR-09 é mapeado para OWASP LLM01 (injeção de prompt) e LLM02 (divulgação de informações sensíveis), NIST 800-53 AC-4 (aplicação do fluxo de informações) e NIST AI RMF MEASURE 2.7 (segurança e resiliência de IA).

Como funciona

• Descobrir. Aponte para arquivos ou pastas. A ferramenta lê dois formatos: configurações MCP (Claude Desktop, Cursor, VS Code .vscode/mcp.json), cobrindo servidores locais npx, uvx ou docker e servidores HTTP remotos (essas configurações não trazem responsável nem aprovação, o que segundo o autor é exatamente por que são o problema da IA invisível), e manifestos de agentes (agents.yaml), um registro governado para agentes LangChain, CrewAI ou personalizados com responsável, aprovação, ferramentas, escopos, credenciais e datas de último uso.
• Classificar. Uma configuração MCP diz qual servidor roda, não o que ele pode fazer; o catálogo de capacidades transforma o nome de um servidor em uma permissão: ações, classificação de dados, se ingere conteúdo não confiável e se pode enviar dados para fora. Servidores desconhecidos são sinalizados sob o AAR-12 e nunca presumidos seguros.
• Mascarar e depois aplicar hash. Os segredos são mascarados durante a análise, antes de qualquer armazenamento, de modo que as evidências possam ser compartilhadas com auditores. O inventário de cada agente e seu registro de origem mascarado recebem hash SHA-256 sobre JSON canônico, tornando detectável qualquer edição posterior das evidências.
• Revisar. Cada permissão de ferramenta recebe uma decisão recomendada (Keep, Modify, Revoke ou Investigate) mais uma coluna vazia para o revisor, no mesmo formato de uma planilha de revisão de acesso de usuários.
• Exportar. A ferramenta emite resultados de avaliação OSCAL 1.1.2: uma observação por agente apontando para seu arquivo de evidência e hash, e um achado por objetivo de controle do NIST 800-53.

O ciclo de revisão espelha a revisão trimestral de acesso de usuários que os auditores de SOX e SOC 2 já testam para pessoas: descobrir configurações e manifestos, classificar pelo catálogo de capacidades, testar os controles, deixar cada responsável revisar cada permissão de ferramenta, guardar as evidências com hash e a saída OSCAL para permissões marcadas como Keep, abrir um ticket de remediação e repetir a varredura em caso de Modify ou Revoke, e recertificar a cada 90 dias.

Execução de exemplo

Os exemplos incluídos são a configuração do Claude Desktop de um desenvolvedor, uma configuração MCP do VS Code e três agentes governados; a saída completa está em sample-output/: o pacote do revisor, a folha de decisões, as evidências com hash e o OSCAL. Executar a demo produz:

$ agent-access-review demo
AGENT                        TOOLS  HIGH   MED   LOW
support-copilot                  2     0     0     0
finance-ops-agent                4     4     3     0
devops-agent                     2     6     1     1
claude-desktop-config            6    12     5     1
vscode-mcp                       3     6     2     3
5 agents · 17 tool grants · 44 findings

Por severidade, os achados se dividem em 28 high, 11 medium e 5 low. Os controles que mais falham entre os cinco agentes:

Um trecho do pacote do revisor para o finance-ops-agent:

Nos achados de exemplo, o finance-ops-agent lê faturas de fornecedores no NetSuite (dados restricted), lê uma caixa de entrada para a qual fornecedores podem escrever (entrada não confiável) e pode enviar e-mail (saída) sem aprovação humana: um caminho AAR-09, o que significa que um único e-mail de fatura manipulado poderia fazer o agente enviar os dados bancários dos fornecedores. Sua aprovação tem 216 dias e sua ferramenta de OCR não é usada há 164 dias, por isso é marcado como Revoke. O exemplo claude-desktop-config concede a um agente todo o diretório pessoal /Users/dev, um terminal sem sandbox, um token do GitHub e uma senha de banco de dados em texto claro, e executa quatro pacotes sem fixação. O support-copilot passa em todas as verificações: escreve em tickets, mas um humano aprova antes de qualquer envio. O CI regenera sample-output/ a cada push e falha se diferir do que está commitado, de modo que o exemplo sempre corresponde ao código atual.

Como ler os resultados

Cada permissão de ferramenta recebe uma decisão recomendada, registrada no pacote e no CSV:

A severidade é definida assim: high significa corrigir antes do próximo uso do agente (um agente sem responsável, segredos em texto claro, um caminho de exfiltração); medium significa corrigir dentro do ciclo de revisão (uma aprovação vencida, um pacote sem fixação); low significa uma lacuna de evidência, não um risco (sem registros de uso, sem data de rotação). O revisor preenche a coluna vazia de decisão e a tabela de aprovação; o pacote completo mais os arquivos de evidência com hash constituem a evidência de auditoria da revisão.

Execução

Além de instalar uma versão com pip, a ferramenta pode ser executada a partir do código-fonte, com dependências fixadas exatamente em requirements.txt:

git clone https://github.com/Mihirajmera/agent-access-review.git
cd agent-access-review
python -m venv .venv && source .venv/bin/activate     # Windows: .venv\Scripts\activate
pip install -r requirements.txt
python -m agent_access_review demo                    # grava review-demo/
pytest -q

O comando scan aceita --out DIR (padrão review/), --as-of YYYY-MM-DD (a data usada para recertificação, rotação e inatividade) e --fail-on high|medium|low (sai com código 1 se um achado atingir ou superar essa severidade). agent-access-review --help lista exemplos.

Como barreira de CI

As configurações MCP e o agents.yaml podem ficar no repositório para bloquear pull requests que deem a um agente acesso sem fixação, arquivado, vulnerável ou excessivamente privilegiado:

# .github/workflows/agent-access.yml
on: pull_request
permissions:
  contents: read
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: Mihirajmera/[email protected]   # or a commit SHA
        with:
          paths: .mcp.json .vscode/mcp.json agents.yaml   # files or folders; default "."
          fail-on: high                                    # high | medium | low | never

O pacote de revisão vai para o resumo do job e o passo falha diante de achados iguais ou acima do limite fail-on. Um repositório sem configurações recebe um aviso em vez de uma falha. A saída report contém o caminho do pacote, de modo que a pasta (padrão agent-access-review/) pode ser enviada como artefato. O autor recomenda fixar a action em uma tag de release ou em um SHA de commit, e não em main, para que uma nova versão não possa alterar a barreira sem revisão, algo que descreve como o controle AAR-10 aplicado à própria ferramenta. Sem a action, pip install agent-access-review seguido de agent-access-review scan ... --fail-on high faz a mesma coisa.

Decisões de design

• Agentes são identidades, não aplicações. A revisão é modelada sobre as revisões de acesso de usuários de ITGC (responsável, aprovação, recertificação, inatividade, higiene de credenciais) porque esse é o framework de controle que os auditores já testam; os riscos específicos de IA são adicionados por cima, não no lugar.
• AAR-09 olha combinações, não permissões isoladas. Cada trecho de um caminho de exfiltração é inofensivo sozinho; o risco só aparece quando um agente reúne os três, razão pela qual as revisões de permissões tradicionais não o detectam. Uma etapa de aprovação humana no trecho de entrada não confiável ou de saída quebra a cadeia.
• Falhar fechado diante de ferramentas desconhecidas. Um servidor MCP não classificado é um achado, não uma aprovação; como o catálogo é dados, uma equipe de GRC pode estendê-lo sem tocar no código.
• Mascarar antes de aplicar hash. Evidências contendo segredos não podem ser compartilhadas, e mascarar depois quebraria o hash, portanto o mascaramento acontece no parser.
• Tags de Docker contam como não fixadas. Apenas um digest de imagem é imutável; :v1.0 pode ser republicada.

Limitações

• Revisa a configuração, não o comportamento em tempo de execução: vê que um agente pode enviar e-mail, não o que ele realmente enviou. As datas de uso vêm do manifesto, que em produção seria alimentado por logs de chamadas de ferramentas.
• O catálogo de capacidades é aproximado: descreve o que um servidor pode fazer por padrão, e os escopos reais de um token (por exemplo, um PAT de GitHub de granularidade fina) podem ser mais estreitos; o formato de manifesto permite registrar escopos exatos.
• Configurações JSON com comentários são ignoradas com um aviso.

O que o autor faria em escala empresarial

• Descobrir a partir de endpoints, não de arquivos: coletar configurações MCP de laptops gerenciados via MDM ou EDR, e identidades de agentes do IdP (service principals, aplicações OAuth), de modo que agentes invisíveis surjam automaticamente.
• Alimentar o uso a partir de logs: preencher last_used a partir de logs de gateway ou proxy MCP para que o AAR-08 se baseie em evidências, e não em autorrelato.
• Executar a revisão na plataforma de GRC: enviar a folha de decisões para o ServiceNow GRC ou SailPoint como campanha de certificação com responsáveis, prazos e escalonamento, e revogar automaticamente permissões não certificadas.
• Fechar o ciclo: transformar achados OSCAL não satisfeitos em itens de POA&M com responsáveis e prazos.

Segundo o README, a forma mais fácil de contribuir é adicionar um servidor MCP ao catálogo de capacidades (ver CONTRIBUTING.md); as mudanças são listadas no CHANGELOG e o projeto é publicado sob licença MIT.