Identidade de agentes de IA: permissões, aprovação por ferramenta e auditoria no Android

Por que o agente precisa de identidade antes de usar ferramentas

Imagine um pedido simples no telefone: resumir uma notificação, preparar uma resposta e abrir o app certo para revisão. Antes de qualquer ferramenta ser chamada, o sistema precisa saber quem pediu, qual sessão está ativa, qual agente está atuando, qual ferramenta foi escolhida e qual alvo será afetado. Identidade de agentes de IA não é um cartão de visita técnico; é a ligação entre uma intenção humana e uma ação executável.

Autenticação por si só não define escopo delegado. O usuário pode estar logado no telefone, mas isso não quer dizer que um agente possa ler todas as mensagens, enviar qualquer resposta ou alterar configurações sem uma decisão adicional. A identidade do agente precisa sobreviver a retries, handoffs e falhas: se a primeira tentativa não funcionou e o agente tenta outro caminho, a ação ainda deve estar vinculada à mesma sessão, ao mesmo patrocinador e ao mesmo objetivo.

A orientação da NVIDIA sobre governança de agentes autônomos em empresas, no texto governança de agentes autônomos em AI factories, destaca identidade, política assinada, revisão humana, logs centralizados, revogação e verificação contínua. O contexto ali é empresarial, mas a lição para o telefone é direta: uma ação precisa ser atribuível antes de ser poderosa. No Android, isso aparece como clareza para o usuário: qual agente está preparando a tarefa, em nome de quem, com qual ferramenta e com qual próximo passo.

Transforme identidade em permissões limitadas e revogáveis

Depois de identificar o agente, vem a pergunta de autoridade. Permissões de agentes de IA não devem ser um botão único de confiança. Um fluxo saudável passa por camadas: identidade da sessão, política do runtime, ferramenta habilitada, permissão Android quando necessária, validação de alvo, aprovação por consequência e capacidade de revogar.

Cada camada prova algo diferente. A identidade prova quem está agindo. A política decide se aquela classe de ferramenta é permitida. A habilitação local decide se a ferramenta está disponível para esse usuário. A permissão Android concede acesso técnico, como localização, notificações ou outro recurso do sistema. A validação de alvo confere destinatário, app, conta, arquivo, valor ou configuração. A aprovação confirma a consequência. A revogação encerra ou reduz autoridade quando o contexto muda.

A NVIDIA, em quatro formas de implantar agentes de IA com mais segurança, recomenda controles determinísticos fora do plano do modelo, ferramentas com privilégio mínimo, fontes de pacotes validadas e restrição de saída por padrão. Esse princípio é útil também no telefone: prompt não é sistema de permissão. O modelo pode raciocinar bem, mas a decisão de acesso precisa ficar em uma camada que consiga negar, registrar e recuperar.

Android permissions continuam importantes, mas não resolvem tudo. Uma permissão de calendário não aprova automaticamente convidar uma pessoa específica. Uma permissão de localização não aprova enviar coordenadas para um contato. Para aprofundar a diferença entre isolamento de ambiente e permissão no telefone, veja Sandbox de agentes de IA e permissões do telefone: por que limites ainda importam.

O que decidir e registrar na chamada de ferramenta

A fronteira mais útil para governança é a chamada de ferramenta. É ali que um plano vira tentativa de ação. Antes da chamada, o runtime deve decidir se a ferramenta está disponível, se o escopo é adequado, se os dados de entrada fazem sentido, se a ação exige aprovação e o que deve ser mostrado ao usuário. Depois da chamada, a trilha de auditoria de agentes deve registrar o resultado observado, não apenas a intenção.

Para uma leitura de baixo risco, como capturar o texto visível de uma tela para resumir, o registro pode ser leve: pedido, ferramenta de leitura, escopo da tela, política aplicada, sucesso ou erro. Para uma ação com efeito externo, como preparar envio de mensagem, o registro precisa mais contexto: destinatário proposto, texto preparado, aprovação solicitada, decisão do usuário, resultado do app e qualquer falha parcial. O payload sensível não precisa ser despejado em log completo para haver responsabilidade; muitas vezes basta registrar hash, metadado, estado e referência segura.

O registro deve incluir negações. Quando uma ferramenta foi bloqueada pela política, quando a permissão Android foi negada, quando o alvo estava ambíguo ou quando o usuário recusou aprovação, isso mostra que o controle está funcionando. Auditoria que só guarda sucessos cria uma história incompleta e dificulta recuperação.

Em termos práticos, uma trilha útil tem sete campos: pedido recebido, identidade da sessão, ferramenta selecionada, entradas normalizadas, decisão de política, aprovação quando exigida e resultado observado. Para detalhar como skills específicas ampliam ou limitam poderes do agente, a continuação natural é Segurança de habilidades de agentes de IA no celular.

Controles empresariais e controles Android são camadas diferentes

Há uma diferença importante entre um agente em ambiente empresarial gerenciado e um phone agent no Android. Em empresas, a arquitetura pode envolver workspace controlado, sandbox, restrição de rede, gestão de segredos, políticas centrais e revisão humana formal. No telefone, os controles passam por ferramentas suportadas, permissões Android, apps instalados, estado de tela, conta do usuário e aprovação contextual.

O artigo da NVIDIA sobre governança em AI factories separa apresentação de execução gerenciada e trata revisão, logs e revogação como partes do desenho. Essa referência ajuda a pensar a cadeia de controle, mas não transforma Android permissions em sandbox empresarial. Para uma visão mais próxima de agentes locais e ambientes gerenciados, consulte Segurança de agentes de IA empresariais: como avaliar agentes locais no celular.

Como a FoneClaw aplica controles globais e por ferramenta

Na FoneClaw, aplicamos essa cadeia no ponto em que ela afeta o usuário: a ação Android suportada. Um modelo compatível configurado dentro da FoneClaw fornece entendimento, raciocínio e planejamento. A FoneClaw decide como esse plano alcança ferramentas governadas, permissões solicitadas em contexto, aprovação por risco, resultado visível e recuperação quando algo não segue.

A base atual da FoneClaw adiciona gerenciamento por ferramenta, substituições de aprovação, recuperação de permissões e tratamento de falhas mais forte. Isso importa porque a governança não vive só em um texto de política; ela precisa aparecer no fluxo de uso. O usuário deve conseguir procurar uma ferramenta, ver se ela está habilitada, entender como a aprovação será tratada e recuperar uma tarefa quando a permissão está ausente.

Os modos globais de aprovação dão o primeiro enquadramento. Auto approve permite aprovar automaticamente dentro do escopo configurado. Follow tool policy segue a política definida para cada ferramenta. Deny all bloqueia chamadas de ferramenta, útil para pausa, investigação ou uso extremamente restrito. Nenhum desses modos é universalmente correto para todas as pessoas e tarefas; a escolha depende do risco, do ambiente e do quanto o usuário quer revisar.

Depois do modo global vêm os controles por ferramenta. A base atual da FoneClaw reforça busca, estado habilitado e substituições de aprovação, permitindo tratar uma ferramenta de leitura visível de modo diferente de uma ferramenta que comunica, altera configuração ou toca dados sensíveis. As ferramentas da FoneClaw incluem mais de 100 ferramentas integradas para ações Android suportadas, com rótulos de risco e aprovação dentro da experiência do produto.

Para o modelo completo de intenção, ferramenta, permissão e resultado no telefone, consulte Controle do celular por agente de IA: como funciona no Android. Neste guia, o foco é a fronteira de governança: qual ferramenta foi chamada, por que foi permitida, o que exigiu aprovação e como o histórico fica disponível depois.

Tabela prática de aprovação para ações de phone agent

Aprovação por ferramenta não deve ser pensada apenas por nome de categoria. O risco real depende do alvo, do payload, da conta, do momento e da reversibilidade. Ainda assim, uma tabela prática ajuda a configurar o primeiro conjunto de políticas antes de ajustes finos.

Ferramentas integradas e plugins também têm caminhos de confiança diferentes. Uma ferramenta integrada aparece dentro dos recursos governados da FoneClaw com rótulos de risco e aprovação. Um plugin precisa de caminho de confiança próprio, incluindo origem, instalação visível, permissões e manutenção. Agrupar tudo como ferramenta confiável apaga uma distinção que o usuário precisa ver.

A regra prática é calibrar pela consequência. Se a ação apenas organiza informação visível, a revisão pode ser leve. Se comunica, modifica, compartilha, apaga ou toca dados sensíveis, a aprovação precisa estar perto da execução e mostrar alvo e conteúdo suficientes para decisão.

Auditar, revogar e recuperar quando o escopo muda ou a ação falha

Governança termina mal quando só pensa no sucesso. Um phone agent precisa de saída operacional quando a ação falha, quando o usuário muda de ideia ou quando o escopo fica maior do que o pedido original. A base atual da FoneClaw reforça recuperação de permissões e tratamento de falhas justamente porque esses momentos são parte do uso real, não exceção rara.

Revogação pode acontecer em vários níveis. O usuário pode encerrar a sessão, trocar o modo global para Deny all, desabilitar uma ferramenta específica, remover uma aprovação especial, negar uma permissão Android, sair de uma conta conectada ou trocar credenciais. Nenhuma dessas ações deve apagar o histórico necessário para entender o que aconteceu antes. Revogar reduz poder futuro; auditoria preserva evidência útil.

A recuperação precisa mostrar o motivo da parada. Falhou porque a ferramenta estava desabilitada? A permissão foi negada? O app de destino mudou de tela? O usuário recusou aprovação? O endpoint não respondeu? Cada resposta leva a um caminho diferente: pedir permissão em contexto, abrir o app certo, oferecer rascunho manual, manter a tarefa pendente ou encerrar com explicação.

Também é importante registrar ações parciais. Se uma mensagem foi preparada mas não enviada, isso é diferente de envio concluído. Se uma configuração foi aberta mas não alterada, o resultado deve refletir essa fronteira. A confiança vem dessa precisão: identidade clara, permissão limitada, decisão por ferramenta, registro honesto, revogação compreensível e recuperação prática.