Agentes de IA também precisam perder acesso durante o trabalho

O acesso que ajuda em uma etapa pode se tornar risco na seguinte

Um agente de inteligência artificial pode precisar consultar documentos para compreender uma solicitação, acessar um sistema para preparar uma proposta e utilizar outro serviço para executar uma ação. O erro começa quando todas essas possibilidades permanecem disponíveis durante todo o trabalho.

A ferramenta necessária para pesquisar não é necessariamente a mesma que deve autorizar uma compra. O acesso útil para produzir um rascunho não deveria permanecer aberto quando o agente passa a enviar mensagens, alterar registros ou confirmar uma operação.

Mesmo quando o objetivo é legítimo, uma instrução ambígua, uma fonte manipulada ou uma interpretação incorreta pode levar o sistema a utilizar uma capacidade no momento errado. Quanto maior o conjunto de ferramentas disponível, maior é a quantidade de caminhos que precisam ser previstos, monitorados e interrompidos.

A segurança de um agente não depende apenas de decidir o que ele pode fazer. Depende também de definir quando pode fazer, por quanto tempo e sob quais condições aquela permissão deve desaparecer.

Uma atualização técnica revela uma questão de gestão

Em 24 de julho de 2026, a Anthropic lançou o Claude Opus 5 e apresentou, em beta, a possibilidade de alterar as ferramentas disponíveis no decorrer de uma conversa. A documentação descreve blocos capazes de adicionar ou remover ferramentas sem reconstruir desde o início todo o contexto da interação.

A funcionalidade foi apresentada como parte da infraestrutura para desenvolvedores. Seu significado empresarial, porém, é mais amplo. Ela torna operacional uma ideia importante: a autoridade de um agente pode mudar conforme o trabalho avança.

Em vez de entregar ao sistema um conjunto fixo de capacidades e esperar que ele escolha corretamente, a arquitetura pode liberar apenas o recurso necessário em cada fase. Depois que a etapa termina, o acesso pode ser retirado. Se surgir uma exceção, uma permissão diferente pode ser oferecida sob outra regra.

A novidade não elimina riscos nem garante que uma implementação seja segura. Ela oferece um mecanismo. A qualidade do controle continuará dependendo da forma como a empresa divide processos, identifica responsabilidades e decide quais ações exigem validação humana.

Permissão permanente é uma simplificação cara

Muitas automações são construídas com uma conta de serviço que recebe, desde o início, tudo o que o fluxo pode eventualmente utilizar. Isso simplifica a primeira integração porque reduz interrupções e evita pedidos adicionais de autorização.

A facilidade inicial cria uma dívida silenciosa. Se o agente puder consultar clientes, emitir documentos, enviar comunicações e alterar dados durante toda a execução, qualquer falha passa a carregar o potencial combinado dessas capacidades.

Também fica mais difícil entender uma ocorrência. A equipe precisa descobrir não apenas qual instrução foi interpretada de forma incorreta, mas por que uma ferramenta que não pertencia àquela etapa estava disponível. O desenho amplo de acesso transforma um problema localizado em uma investigação sobre o sistema inteiro.

O princípio do menor privilégio procura reduzir essa exposição ao conceder apenas o necessário para uma finalidade definida. Para agentes, esse princípio precisa ganhar uma dimensão temporal. Não basta limitar a lista de ferramentas. É preciso limitar a permanência de cada uma.

O processo precisa ter fronteiras antes de ganhar autonomia

Permissões dinâmicas só funcionam quando o processo possui etapas reconhecíveis. Se a empresa não sabe onde termina a análise e começa a execução, o sistema também não terá um ponto claro para trocar de autoridade.

Um fluxo comercial, por exemplo, pode ser separado em pesquisa do histórico, preparação de proposta, revisão das condições, envio ao cliente e atualização do sistema. Cada etapa utiliza informações e produz consequências diferentes.

Durante a pesquisa, o agente pode receber acesso somente de leitura. Na preparação, pode criar um documento provisório sem capacidade de enviá-lo. Depois da revisão, uma autorização específica pode liberar o envio. A atualização do sistema pode ocorrer apenas quando houver confirmação registrada.

Essa divisão não serve apenas à segurança. Ela melhora a operação porque torna visíveis os pontos de decisão, as evidências necessárias e os responsáveis por exceções. Ao desenhar o acesso do agente, a organização também esclarece o próprio trabalho.

Retirar uma ferramenta pode ser tão importante quanto adicioná-la

Projetos de automação costumam tratar novas integrações como progresso. Cada ferramenta adicionada amplia o que o agente consegue realizar e produz demonstrações mais impressionantes.

Uma arquitetura madura também celebra a remoção. Quando a pesquisa termina, o acesso a fontes sensíveis pode ser encerrado. Quando o documento é aprovado, a ferramenta de edição pode ser retirada. Depois que uma transação é concluída, a capacidade de repeti-la deve desaparecer.

Retirar acesso reduz a possibilidade de uma instrução posterior reutilizar uma capacidade fora de contexto. Também ajuda a impedir que informações obtidas em uma fase sejam combinadas com ações que não estavam previstas para elas.

A lógica se aproxima do que organizações já aplicam a pessoas e sistemas críticos: funções diferentes recebem privilégios diferentes, atividades sensíveis exigem separação e autorizações temporárias devem terminar quando a necessidade acaba. O agente não deve ser tratado como uma exceção a essas práticas.

O risco não vem apenas de uma intenção maliciosa

A OWASP descreve agência excessiva como a condição em que um sistema baseado em modelos recebe funcionalidades, permissões ou autonomia além do necessário. O dano pode surgir de uma entrada manipulada, mas também de uma saída ambígua, de uma interpretação incorreta ou de uma regra incompleta.

Esse ponto é importante porque segurança não pode depender da expectativa de que o agente compreenderá sempre a intenção correta. Um modelo pode agir de boa fé dentro de uma leitura equivocada do contexto.

Se uma mensagem recebida por e-mail for tratada como instrução confiável, o agente talvez tente utilizar uma ferramenta legítima para uma finalidade indevida. Se uma condição comercial estiver incompleta, pode aplicar uma ação válida ao cliente errado. Se o processo não distinguir rascunho de aprovação, pode transformar preparação em execução.

Permissões por etapa não corrigem a compreensão do modelo, mas reduzem as consequências disponíveis para um erro. O sistema continua precisando de validação de entradas, regras de negócio, registros e mecanismos de interrupção.

Como desenhar permissões que acompanham a tarefa

O primeiro passo é mapear as ações, e não apenas os sistemas. Consultar um cadastro, criar um registro, alterar uma condição e enviar uma comunicação são capacidades diferentes, mesmo quando acontecem dentro da mesma plataforma.

O segundo é relacionar cada ação a uma etapa e a uma finalidade. A empresa precisa explicar por que o acesso existe, qual evidência autoriza sua liberação e qual evento determina sua retirada.

O terceiro é separar leitura, preparação e execução. Sempre que possível, o agente deve produzir uma proposta de ação antes de receber autoridade para realizá-la. Processos de maior impacto podem exigir aprovação explícita de uma pessoa ou de outro controle independente.

O quarto é definir o comportamento diante de exceções. Se uma ferramenta não estiver disponível, o agente deve interromper, explicar o que falta e encaminhar a decisão. Não deve procurar um caminho alternativo capaz de contornar a restrição.

O quinto é registrar mudanças de autoridade. A organização precisa saber quais ferramentas estavam disponíveis, quando foram adicionadas ou retiradas, qual condição motivou a mudança e que ações ocorreram enquanto o acesso permaneceu ativo.

Supervisão humana precisa ocorrer no ponto certo

Manter uma pessoa no processo não significa exigir aprovação para cada leitura ou transformação. Esse desenho pode tornar a automação lenta sem melhorar o controle.

A supervisão deve se concentrar nas transições que alteram consequência, alcance ou reversibilidade. Sair da consulta para a alteração, do rascunho para o envio, da recomendação para a contratação e do teste para a produção são exemplos de mudanças que merecem atenção.

O NIST recomenda que riscos de sistemas de inteligência artificial sejam governados a partir do contexto, da finalidade e dos impactos possíveis. Em uma proposta de perfil de cibersegurança para IA, a instituição também destaca que agentes podem exigir políticas próprias de autorização e aplicação do menor privilégio.

Isso desloca a pergunta da liderança. Em vez de discutir apenas quanta autonomia o agente terá, é necessário decidir em quais momentos sua autonomia aumenta, diminui ou desaparece. A resposta deve acompanhar o impacto de cada etapa.

A arquitetura de acesso também é uma arquitetura de responsabilidade

Quando um agente mantém todas as ferramentas durante toda a tarefa, a responsabilidade fica difusa. Em caso de erro, é comum atribuir o resultado ao modelo, mesmo que o problema tenha começado na concessão ampla de acesso.

Permissões dinâmicas obrigam a empresa a declarar decisões. Alguém definiu que determinada ferramenta seria liberada, estabeleceu a condição para sua retirada e escolheu o controle necessário para uma ação sensível.

Essa clareza melhora auditoria, treinamento e melhoria contínua. Uma falha pode ser analisada dentro da etapa em que ocorreu, sem transformar toda a automação em uma caixa indecifrável.

O objetivo não é criar burocracia em torno de cada clique. É garantir que a autoridade técnica do agente corresponda à responsabilidade empresarial assumida naquele momento.

Conclusão

A possibilidade de adicionar e retirar ferramentas durante uma conversa parece uma atualização técnica, mas aponta para uma mudança importante na gestão de agentes. A autonomia não precisa ser um estado fixo.

Um agente pode pesquisar com liberdade, preparar com limites e executar somente depois de uma condição verificável. Também pode perder acesso assim que a finalidade for cumprida.

Na minha visão, empresas não deveriam perguntar apenas o que um agente é capaz de fazer. Deveriam perguntar por quanto tempo ele precisa conservar cada capacidade. Quando toda permissão permanece aberta por conveniência, a organização transfere ao modelo uma responsabilidade que deveria continuar no desenho do processo.

A automação mais confiável não é aquela que entrega todas as chaves ao agente. É aquela que abre a porta necessária, registra a passagem e fecha o acesso antes que a próxima etapa comece.