Identidade, permissões e auditoria de agentes de IA: um registro prático

Comece por um registro que possa ser conferido

Para revisar identidade, permissões e auditoria de agentes de IA, registre quem pediu, qual identidade executou, que acesso estava autorizado e o que realmente aconteceu. Uma resposta do agente dizendo “concluído” não substitui evidência no recurso afetado. Comece com cinco campos que permitam acompanhar uma ação do pedido ao resultado.

Exemplo ilustrativo de registro manual, não extraído de um produto: Ana pede que um agente leia um documento específico e proponha uma resposta, sem enviá-la. Os identificadores abaixo são referências escolhidas para o exemplo; não representam um formato nativo de exportação.

Separe a leitura da elaboração do rascunho mesmo quando ambas pertencem ao mesmo pedido. Para A-01, procure evidência de acesso ao documento autorizado. Para A-02, confira se existe uma proposta de resposta e se ela continua sem envio. Se o rascunho existir, mas não houver evidência suficiente da leitura, registre essa lacuna; não atribua sucesso às duas etapas automaticamente.

Um nome escrito na conversa identifica uma intenção, não autentica o agente. A credencial autentica o acesso; a permissão delimita o que ele pode fazer; a aprovação cobre a ação apresentada; o resultado mostra o que ocorreu. Solicitante, executor e aprovador podem ser diferentes. Guarde referências e dados necessários à revisão, sem copiar o documento inteiro ou segredos. Se a execução for negada ou falhar parcialmente, anote esse estado.

Defina a identidade e o acesso empresarial

O Microsoft Entra Agent ID oferece um exemplo concreto de autoridade para agentes. No acesso delegado, o agente age em nome de um usuário, dentro das permissões aplicáveis. No acesso de aplicativo, a identidade do aplicativo recebe permissões próprias, concedidas por um administrador. Em ambos os casos, conceder acesso ao recurso não equivale a aprovar cada mensagem enviada ou cada alteração feita depois.

Escolha a permissão conforme o recurso e a tarefa. Funções de recursos do Azure, funções de diretório e permissões do Microsoft Graph governam alvos diferentes. Para ler um documento e propor texto, não há razão para começar com uma função administrativa ampla ou acesso de escrita a toda a coleção. O Entra também restringe funções e permissões de API de alto privilégio para identidades de agentes.

Antes da concessão, identifique o recurso exato, a operação necessária e quem responde pelo acesso. Uma autorização de leitura não deve virar escrita apenas porque o agente também consegue redigir uma resposta. Se a tarefa passar a incluir envio, avalie o novo alcance e sua aprovação sem reutilizar a decisão anterior como autorização irrestrita.

Registre o responsável pela identidade e, quando a política exigir, o patrocinador e a duração prevista do acesso. Reveja concessões, conexões e credenciais sem uso quando a tarefa ou a equipe mudar. Uma chave de API, isoladamente, não organiza essas responsabilidades.

Para uma avaliação mais ampla de acesso e isolamento, consulte Segurança de agentes de IA empresariais: como avaliar agentes locais no celular. O exemplo do Entra descreve controles daquele ambiente, não uma integração empresarial da FoneClaw.

Reúna evidências de identidade e de ação

Os registros de entrada e auditoria do Microsoft Entra para agentes ajudam a relacionar identidades e eventos. Campos como agentType e blueprintId apoiam a identificação do tipo de agente e do blueprint de origem. Atividades do blueprint aparecem como eventos de aplicativo; identidades de agente, como eventos de entidade de serviço; contas de usuário do agente, como eventos de usuário.

Com acesso de, no mínimo, Leitor de Relatórios, é possível ir a Entra ID, Monitoramento e integridade, Registros de entrada e usar os filtros de agente. As consultas de registros de agente pelo Microsoft Graph descritas nessa documentação usam a rota /beta. Escolha o caminho compatível com as ferramentas e políticas da organização.

Um registro de entrada bem-sucedida comprova uma etapa de identidade, não que o documento foi lido corretamente, que a resposta foi salva ou que alguém a recebeu. Relacione o identificador da solicitação e a identidade executora ao registro da ação no aplicativo de destino. Para PED-01, associe recurso, operação e horários de A-01 e A-02 às evidências disponíveis.

Quando os sistemas fornecerem identificadores de correlação, preserve-os. Se não fornecerem, documente a associação manual e sua limitação. Apenas horários próximos não demonstram que dois eventos pertencem à mesma tarefa. Uma mesma identidade pode realizar várias operações; procure o alvo e a ação específicos antes de concluir.

Se faltar evidência no destino, marque o resultado como não verificado, mesmo com autenticação bem-sucedida. Defina quem pode consultar os registros, por quanto tempo serão mantidos e quais dados precisam ser ocultados conforme a política real. Logs de identidade não estabelecem, sozinhos, um histórico completo ou imutável das ações de negócio.

Registre sucesso, recusa, aprovação pendente e falha parcial

Os quatro registros abaixo são exemplos propostos para revisão manual. Em cada um, separe escopo autorizado, decisão de aprovação, tentativa e resultado observado. Não são resultados de testes nem estados automaticamente exportados pela FoneClaw.

Sucesso de leitura. PED-02 solicita consultar um recurso, sem alterá-lo. A identidade executora e a conexão autorizada ficam referenciadas; o escopo é somente leitura. Registre a regra de aprovação efetivamente aplicada, a tentativa A-03 e o resultado devolvido com seu horário. A conclusão pode ser “consulta concluída”, desde que a evidência corresponda ao recurso solicitado. Isso não permite afirmar que houve uma escrita nem reutilizar o resultado como estado atual indefinidamente.

Escrita aguardando aprovação. PED-03 solicita criar um compromisso, com destino e horários definidos. O acesso disponível permite a operação, mas a política ativa exige aprovação que ainda não ocorreu. Registre “aguardando aprovação; criação não confirmada”, com referência à ação apresentada. Ter credencial válida ou consentimento OAuth não satisfaz essa decisão. Após a aprovação, registre separadamente a tentativa e o resultado; “aprovado” não significa “executado”.

Ação recusada. PED-04 encontra uma ferramenta desabilitada ou uma decisão explícita de negar. Registre o motivo observado, a regra relevante e se houve tentativa no destino. Se a inspeção confirmar que o alvo permaneceu inalterado, anote essa observação. Não declare “nada mudou” apenas por existir uma mensagem de erro: a evidência precisa corresponder à etapa bloqueada. O próximo passo é revisar a necessidade do acesso, não contornar a recusa.

Escrita de resultado incerto. PED-05 recebe aprovação e inicia a criação, mas perde a resposta antes da confirmação. Registre “tentativa realizada; resultado não verificado”, em vez de sucesso ou falha total. Consulte o aplicativo de destino e procure o item pelos dados pretendidos. Se encontrar um item correspondente, confira seus campos antes de associá-lo ao pedido. Se a dúvida persistir, suspenda a repetição: uma nova tentativa pode duplicar uma escrita já concluída.

Preserve a sequência quando o estado mudar. Uma verificação posterior pode esclarecer a tentativa anterior, mas não deve apagar o fato de que ela ficou incerta naquele momento.

Faça as mesmas perguntas no telefone

Na FoneClaw, uma checagem simples é perguntar o estado atual da bateria. A ferramenta device_battery_status lê bateria e modo de economia de energia sem mudar ajustes. Para anotá-la manualmente, identifique quem pediu, a configuração de modelo, a ferramenta habilitada, a regra de aprovação aplicável e o estado devolvido pelo Android.

O catálogo informa risco e aprovação padrão; o modo global de aprovação e as substituições por ferramenta determinam o comportamento efetivo. A leitura de bateria pode seguir aprovação automática na política padrão. Confira a configuração ativa em vez de esperar uma confirmação em toda consulta.

Um evento de calendário muda o alcance. Como exemplo proposto, peça “reunião em 15 de outubro de 2026, das 14h às 14h30, com lembrete de dez minutos”, esclarecendo o calendário pretendido e o fuso do aparelho. Se início, fim ou lembrete estiverem ausentes, obtenha esses detalhes antes de chamar calendar_create_event. Não transforme uma data vaga em compromisso definido.

A criação tem efeito externo e aprovação exigida na política padrão; registre a decisão conforme os controles efetivos. Depois, use actualStart e actualEnd retornados para informar os horários criados e compare-os com o evento no calendário de destino. Confira também título e lembrete. Se houver divergência, não crie outro evento automaticamente.

Permissões do Android, ferramentas habilitadas e credenciais do provedor de modelo são controles diferentes. Uma ação local não significa que o contexto enviado ao modelo permaneceu no telefone. Consulte os recursos da FoneClaw para as capacidades disponíveis. Se uma habilidade adicional participar, Segurança de habilidades de agentes de IA no celular ajuda a revisar sua origem e alcance. A anotação sugerida continua sendo um método manual, não uma exportação imutável.

Teste o bloqueio e retire acessos sem uso

Faça uma verificação inofensiva na sua própria configuração: desabilite uma ferramenta de leitura que não esteja em uso, peça uma consulta limitada e confira o comportamento. O resultado esperado é recusa sem uma nova leitura bem-sucedida pela ferramenta bloqueada. Registre pedido, configuração alterada, resposta e observação. Esse é um procedimento proposto, não um resultado já medido.

Se a resposta mostrar um valor antigo, não o trate como nova consulta. Confira se houve execução ou apenas reutilização de contexto. Se o comportamento contradisser o bloqueio esperado, pare e investigue antes de testar ações com consequências. Reative apenas o acesso necessário, quando apropriado, e repita a consulta para comparar.

Ao retirar uma identidade ou conexão empresarial, confira novas solicitações ao recurso afetado, respeitando o comportamento de sessões e credenciais daquele sistema. Anote qual acesso foi retirado e qual teste sustenta a conclusão. Não generalize um bloqueio num recurso para todas as conexões. Troque credenciais expostas e revise concessões remanescentes com o responsável.

Revogar acesso futuro não desfaz uma alteração concluída. Antes de repetir uma escrita incerta, inspecione o destino e procure efeitos já existentes. Se precisar corrigir ou excluir algo, trate a correção como outra ação, com alvo, autorização e resultado próprios.

Por fim, reveja conexões sem uso, ferramentas habilitadas, substituições de aprovação e quem pode consultar os registros. Aplique retenção e ocultação de dados conforme a política da organização, sem guardar segredos por conveniência. Se informações preservadas pelo agente influenciarem decisões futuras, Envenenamento de memória de IA no celular: riscos e revisão trata dessa fonte de risco. Encerre a revisão registrando o acesso restante, o estado do destino e qualquer incerteza ainda aberta.