Antes de conectar um agente, liste o que ele pode ler, alterar e fazer em seu nome

Registre identidade real, recursos, ações e responsável pela revogação antes de conceder acesso.

Buda Team
← Voltar ao Blog
Antes de conectar um agente, liste o que ele pode ler, alterar e fazer em seu nome

A líder de compras quer comparar três propostas. A conta conectada também permite alterar pedidos e enviar emails. “Só rascunho” aparece no prompt, mas a credencial continua mais poderosa que a tarefa.

Nesse cenário fictício, falta um checklist de permissões do agente de IA: qual identidade, quais dados, quais ações e quem revoga. Revisar a comparação final pode detectar texto errado; não remove a capacidade de escrita.

Separe a tarefa em ações

Leia três cópias autorizadas e anonimizadas, entregue comparação e mantenha preços ausentes como desconhecidos. Sem contato com fornecedor, alteração de compras, envio ou pagamento.

AçãoNecessidade de negócioConfiguração a verificar
readTrês propostas nomeadasA conta também vê outros contratos?
draftDiretório de saída definidoQuem lê o resultado?
writeNão mudar registros oficiaisRole/scope do provedor exclui escrita?
sendSem email ou avisoLogin/token ainda permite enviar?
deleteNenhuma exclusãoPermissão real ainda permite apagar?

É uma matriz proposta, não interface nativa de ACL por ferramenta do Buda nem teste executado de escrita negada. Separe proibição de negócio de impedimento técnico.

Necessidades de ler e redigir contra capacidades de alterar, enviar e excluir

Registre a conta, não o segredo

access-inventory.csv inclui tarefa, ferramenta, identidade real, recursos, ações pretendidas, role/scopes reais, local da autenticação, concedente, revisor, prazo ou responsável pela revogação, evidência e estado.

Q-01: três propostas (fictício)
Identidade: conta de teste identificável de compras
Recursos: três cópias autorizadas; sem outros pedidos
Ações: read das entradas; draft local nomeado
Scope real: unknown; administrador confere no provedor
Autenticação: nome da variável/local de login, nunca valor
Responsáveis: administrador concede; compras confere recursos
Estado: aguardar scope; sem credencial de produção conectada

Para conta compartilhada, liste usuários e responsável. Nome visível não prova identidade autenticada. Navegador, token e integração podem representar contas distintas; examine cada caminho relevante.

unknown-scopes.md transforma incerteza em tarefa: sistema, conta, prova ausente, verificador e etapa suspensa. Uma leitura bem-sucedida não comprova ausência de escrita.

Valor mascarado não é isolamento de processos

A documentação de variáveis que você pode criar com Buda descreve variáveis por Agent, injetadas no computador em nuvem. Terminal, scripts, servidores e processos executados podem lê-las. Elas persistem após reinício do sandbox.

Mascarar a interface não impede todo script de ler. Não coloque tokens reais em chat, lista ou imagem, nem imprima variáveis sensíveis para provar conexão. Use configuração não sensível de role e evidências de scope.

Uma Session separa conversa, não arquivos e ambiente do mesmo Agent. Necessidades diferentes de dados ou credenciais exigem desenho de identidades e permissões pelo administrador, não apenas outra conversa.

O Drive distingue Agent Drive privado de Space Drive compartilhado. Uma pasta chamada approved não aplica ACL. Verifique compartilhamento antes de copiar dados.

Skill, ferramenta e autorização não são equivalentes

Na gestão de Skills, leia manifesto completo, origem e escopo. “Não enviar” é instrução de comportamento; não substitui OAuth scopes, roles e permissões do provedor.

Ferramenta listada não significa autenticação, e autenticação não significa privilégio mínimo. O administrador confirma o provedor; depois a equipe confere se o Skill respeita a tarefa. Não deduza controles arbitrários por ferramenta a partir dos nomes do manifesto.

Se o serviço não separa leitura de escrita, prefira exportação autorizada ou conta de teste restrita. Não conecte administrador irrestrito e chame o prompt de controle de acesso. Escrita futura precisa de escopo e autorização próprios.

Confira tanto o permitido quanto o negado

São verificações sugeridas, não testes de segurança executados. O administrador escolhe recursos sem dados sensíveis e procedimento seguro:

  1. Ler amostra permitida com identidade nomeada e conferir alcance.
  2. Testar escrita que deve ser negada num ambiente incapaz de prejudicar registro real. Se não for seguro, marcar não verificado, sem tentar em produção.
  3. Conferir caminhos alternativos, como login de navegador ou segundo token. Uma negativa não cobre todos.
  4. Registrar identidade, recurso, configuração e resultado, nunca segredo. Parar se a autoridade divergir do previsto.

Não expor segredo e validar autorização são requisitos distintos. Um não substitui o outro.

Instruções, visibilidade de ferramentas e autorização do provedor tratam de coisas diferentes

Revogar vai além de fechar a conversa

revocation-checklist.md nomeia donos e confirmação para token/role do provedor, variável do Agent, sessão de navegador e cópias distribuídas. Defina o que retirar e confira cada sistema.

Fechar Session ou cancelar tarefa não invalida credencial. Remover variável não comprova que processos existentes, logins e cópias sumiram. Retenção e limpeza seguem política da organização; o agente não deve apagar arquivos para simular conclusão.

Três arquivos para o administrador

Prepare inventário, desconhecidos e revogação sem segredos no workspace que você pode criar com Buda:

Use só documentação e configurações não sensíveis fornecidas. Separe ações da tarefa de autoridade real. Mantenha unknown e produza access-inventory.csv, unknown-scopes.md, revocation-checklist.md. Não leia/imprima segredos, conecte novas contas de produção, altere, envie ou exclua.

Gestor confirma necessidade, administrador confirma permissão e operador registra testes controlados. A mesma pessoa pode acumular papéis, mas as decisões continuam separadas.

Podemos tentar ler antes de saber o scope?

Teste o método com cópia anonimizada autorizada. Produção fica unknown até prova do administrador; leitura não aprova acesso.

Outra Session basta num Agent compartilhado?

Para discussão separada, talvez; para isolar arquivos, credenciais ou acesso, não. Confira identidade e recursos, criando Agent e conta restrita quando necessário.

Mascarar token torna qualquer Skill seguro?

Não. Leia manifesto e origem, confira ferramentas e dados necessários e não forneça credenciais dispensáveis ao ambiente.

Como reduzir acesso para só rascunhar?

Comece com cópias e saída nomeada, sem escrita de produção. Leitura ao vivo exige identidade e recursos restritos antes das verificações.

Pesquise e instale um Skill adequado no Marketplace do Buda AI. Confira o método antes de conceder permissão. O inventário útil justifica cada capacidade, seu alcance real e quem pode retirá-la.