Agent Passport: como avaliar um componente de IA antes de instalar

Um Agent Passport é uma ficha operacional que torna um componente de IA compreensível antes da instalação. Ele reúne origem, versão, checksum, compatibilidade, permissões, dependências, Trust Score, mudanças e recomendações de governança. O objetivo é reduzir surpresa, não prometer segurança absoluta.

Identifique a origem

Registre repositório, autor, licença, mantenedor, versão e commit. Um nome conhecido não substitui a verificação do artefato que será instalado.

Leia as capacidades

Procure rede, shell, arquivos, credenciais, MCPs, hooks e ações externas. Marque o que está documentado e o que permanece desconhecido. Not-tested significa evidência insuficiente, nunca reprovação.

Fixe o que foi aprovado

Salve versão, checksum e permissões no arquivo de versões. Se houver alteração relevante, compare registros coletados antes de atualizar. Mudança de capability merece nova revisão.

Conecte ao contexto

Um mesmo componente pode ser aceitável em um teste local e inadequado para produção. Considere dados acessados, decisões afetadas, aprovação humana, logs, responsável e retorno à versão anterior.

Decida o próximo passo

Use o Commons para descobrir, analisar, comparar e instalar. Se a composição ganhar múltiplos agentes, dados sensíveis ou ações externas, o diagnóstico de governança passa a ser o próximo passo.

Como aplicar Agent Passport: como avaliar um componente de IA antes de instalar em uma decisão real

Comece descrevendo o resultado que precisa existir ao final, quem vai revisar a entrega e qual dado pode entrar. Não parta da ferramenta. Um componente só entra quando reduz um gap observável no fluxo. Registre a hipótese, o ambiente, a versão e um critério simples de sucesso. Isso evita instalar capacidade redundante apenas porque ela está em evidência.

Exemplo operacional

Suponha que uma equipe queira aplicar este tema a um processo recorrente. Primeiro, escolha um caso limitado e reversível. Use dados fictícios ou anonimizados, mantenha qualquer ação externa desabilitada e peça revisão humana do resultado. Depois compare tempo, qualidade, erro e necessidade de retrabalho. Se o ganho for real, documente o método antes de ampliar acesso ou autonomia.

Checklist de origem e instalação

• Confirme autor, repositório original, licença, versão e última atualização.
• Leia o manifesto e a documentação antes de copiar o comando.
• Revise rede, shell, arquivos, credenciais, hooks e dependências.
• Entenda se o componente lê, escreve, envia ou decide.
• Confirme onde existe aprovação humana e quem é o responsável.
• Preserve retorno à versão anterior e a versão anterior antes de atualizar.

Teste mínimo seguro

Instale somente em ambiente controlado, com acesso mínimo e sem credenciais de produção. Execute entradas conhecidas, inclua casos de erro e observe se a saída respeita o escopo. Uma triagem estática pode encontrar padrões, mas não garante comportamento de execução real; por isso o teste precisa combinar evidência da origem com observação prática.

Como documentar a decisão

Guarde nome, source URL, commit ou versão, comando usado, permissões concedidas, resultado do teste e pessoa responsável. Se houver uma stack, gere reveno.lock e CLAUDE.md. O arquivo de versões descreve o que foi escolhido; o CLAUDE.md leva instruções e limites ao ambiente. A política inicial registra gates para revisão, mas deve ser adaptada ao contexto.

Quando não avançar

Pare se a origem não puder ser confirmada, se a licença for incompatível, se o acesso pedido for maior do que o tarefa exige ou se não houver alguém responsável pelo resultado. Também não avance quando o componente sugerir ação irreversível sem confirmação, quando credenciais aparecerem em configuração aberta ou quando a manutenção estiver abandonada e não existir alternativa de retorno à versão anterior.

Como interpretar Trust

Not-tested significa evidência insuficiente e é excluído da nota; nunca vira zero. Community Tested depende de sinal comunitário registrado e não é auditoria. Reveno Verified só aparece depois de revisão real documentada. Medium ou high risk pede contexto e controle, não significa automaticamente “não use”. aprovação humana é proteção, não defeito.

Monitoramento depois do teste

O trabalho não termina quando o primeiro resultado funciona. Inicie acompanhamento, registre a versão aprovada e compare qualquer novo registro coletado antes de atualizar. Mudança de licença, mantenedor, dependência, rede, escrita ou aprovação humana pode alterar a decisão original. Defina uma frequência de revisão compatível com o impacto e remova componentes que perderam responsável ou utilidade.

Perguntas para a revisão humana

• A saída responde ao tarefa sem extrapolar o pedido?
• Existe evidência para fatos e recomendações?
• Uma ação externa é reversível e foi autorizada?
• O dado usado era necessário e permitido?
• O responsável consegue explicar, interromper e refazer o processo?

Se alguma resposta for não ou desconhecida, mantenha a execução assistida e reduza o escopo antes de aumentar autonomia.

Da prova individual para a empresa

Um teste local com dados fictícios pode continuar no Commons. A fronteira muda quando entram dados reais, múltiplas áreas, ações externas, autonomia, produção ou decisão operacional. Nesse ponto, defina responsável, política, logs, mudança, custo e resposta a incidente. A governança deve ser proporcional ao impacto e preservar experimentação reversível.

Recursos relacionados

Descobrir componentes · Analisar origem · Comparar alternativas · Gerar stack · Ler Trust Protocol · Avaliar a fronteira enterprise

Próximo passo operacional

Use esta orientação para analisar uma origem específica, comparar alternativas e montar uma stack com versão, permissões e pontos de aprovação humana documentados. Not-tested é evidência insuficiente, não reprovação.

Analisar origem · Comparar componentes · Montar stack · Governança empresarial