Um agente de inteligência artificial pode consultar documentos, abrir chamados, alterar configurações e acionar sistemas sem que uma pessoa aprove cada passo. Essa autonomia amplia a utilidade da tecnologia, mas exige uma resposta objetiva: quem autorizou o agente, com quais privilégios e sob a responsabilidade de quem?
A discussão deixou de ser apenas sobre a qualidade das respostas produzidas por modelos de linguagem. Quando uma aplicação passa a executar operações em nome de alguém, ela participa efetivamente dos processos da organização. Uma instrução aparentemente simples, como organizar os acessos de uma equipe, pode envolver consulta a dados pessoais, criação de permissões e chamadas a diferentes APIs. O resultado depende tanto da capacidade do modelo quanto das regras que limitam o que ele pode fazer.
Quando a autonomia encontra os privilégios corporativos
A gestão de identidades não humanas já faz parte da rotina de segurança: contas de serviço, aplicações, workloads e integrações precisam se autenticar e receber permissões. Agentes de IA pertencem a esse universo, mas apresentam uma diferença relevante. Em vez de seguir somente uma sequência predefinida, podem escolher ferramentas, interpretar respostas intermediárias e mudar a próxima ação durante a execução. Por isso, a autorização não deve depender exclusivamente do pedido inicial feito pelo usuário.
Agentes de IA não inventam esse problema, mas tornam o cenário mais difícil porque não executam apenas uma sequência rígida de passos. Eles podem escolher ferramentas, interpretar contexto, adaptar a estratégia e encadear ações com base no resultado anterior.
Uma automação tradicional costuma ter comportamento previsível. Um agente pode decidir que precisa consultar outra fonte, chamar uma segunda API ou tentar uma abordagem diferente. Essa flexibilidade é justamente o que o torna útil — e o que exige mais cuidado com privilégios.
Uma implementação aparentemente conveniente é reutilizar a sessão do funcionário que iniciou a tarefa. Se esse funcionário administra diversos sistemas, o agente pode herdar permissões que não têm relação com o trabalho solicitado. Imagine um assistente encarregado apenas de levantar informações sobre um incidente: se a integração lhe entrega um token com poderes de administração, uma decisão equivocada, uma instrução maliciosa recebida de um documento ou uma falha na lógica de execução pode transformar uma consulta em alteração de produção.
Se o usuário tem acesso administrativo a dez sistemas, o agente pode acabar herdando uma autoridade muito maior do que precisa para executar uma tarefa simples. Pior: depois fica difícil responder se uma mudança foi decidida diretamente pela pessoa ou executada automaticamente pelo agente com os privilégios dela.
Separar a identidade humana da identidade operacional do agente permite limitar a delegação à tarefa, aos recursos necessários e a um prazo definido. Essa separação facilita a revogação e evita que uma automação continue utilizando os privilégios amplos de seu proprietário.
Outro erro comum é considerar que, se o usuário abriu a conversa autenticado, todas as ações posteriores estão implicitamente autorizadas. Isso pode funcionar para leitura simples. Fica frágil quando o agente passa a modificar dados, enviar mensagens, alterar configurações ou executar ações financeiras.
Cada ferramenta deve validar a identidade e o escopo no momento em que é chamada. O modelo pode decidir que deseja executar uma ação; a infraestrutura é que precisa decidir se aquela ação está permitida.
Notícias Relacionadas
Quem responde pelas decisões e pelos acessos do agente?
Suponha que um agente altere uma regra de firewall, envie um arquivo a um terceiro ou desative uma conta em produção. Depois do fato, a organização precisa reconstruir o que aconteceu sem depender da memória de quem usou a ferramenta.
Uma trilha adequada deveria responder, pelo menos, quem iniciou a tarefa, qual agente executou a ação, que identidade foi usada, qual ferramenta foi chamada, quais dados estavam disponíveis, qual política autorizou a operação e qual foi o resultado.
Um registro isolado da conversa não resolve esse problema, assim como o log da API, sozinho, não explica por que ela foi chamada. É necessário correlacionar o pedido original, a identidade do agente, as decisões de autorização, as chamadas efetivamente realizadas e seus resultados. Sem essa ligação, a investigação precisa reconstruir o episódio a partir de fragmentos de sistemas diferentes, justamente quando o tempo de resposta é mais importante.
Há ainda um ponto de governança que parece banal até o primeiro problema: quem é responsável pelo agente?
A responsabilidade também precisa ser atribuída. Assim como aplicações corporativas possuem responsáveis técnicos e de negócio, agentes precisam de alguém que aprove seu propósito, conheça os dados utilizados e revise periodicamente as integrações e permissões. Sem esse vínculo, um agente pode permanecer ativo após mudanças de equipe e conservar acessos que já não fazem sentido.
Sem dono claro, o agente tende a permanecer ativo, acumular integrações e sobreviver a mudanças de equipe. É exatamente o mesmo padrão que transformou contas de serviço esquecidas em uma das maiores dores de IAM.
Como conceder autonomia sem entregar privilégios excessivos
- Identidade própria por agente ou função. Evitar contas genéricas compartilhadas e reaproveitamento silencioso da sessão humana.
- Escopos mínimos. Um agente que lê calendário não precisa de permissão para apagar arquivos, administrar usuários ou publicar código.
- Credenciais de curta duração. Segredos permanentes são difíceis de rotacionar e fáceis de esquecer.
- Delegação explícita. Registrar qual usuário, processo ou aplicação autorizou aquela execução.
- Approval gates. Ações destrutivas, administrativas, financeiras ou de grande impacto merecem uma segunda confirmação.
- Auditoria ponta a ponta. Não basta registrar apenas o prompt ou apenas a API. A cadeia precisa ser reconstruível.
- Revogação simples. A organização deve conseguir retirar o acesso do agente rapidamente, sem desmontar manualmente várias integrações.
Arquiteturas multiagente acrescentam outra camada. Um agente principal pode delegar tarefas a outros componentes, cada um com ferramentas e identidades diferentes. Nesse cenário, a pergunta deixa de ser apenas “quem é o agente?” e passa a incluir “quem delegou autoridade a quem?”.
Um exemplo é o agente encarregado de preparar um relatório que solicita a outro agente uma consulta a dados financeiros. Se o segundo componente possui acesso irrestrito e aceita qualquer pedido do primeiro, a separação de funções existe apenas no desenho. A proteção exige verificar a autorização do solicitante original, limitar o escopo da delegação e registrar a relação entre os dois agentes.
Autonomia exige identidade verificável
Tratar agentes de IA como simples ferramentas de software funciona enquanto eles só produzem texto. Quando passam a agir, precisam entrar no mesmo modelo de confiança aplicado a qualquer outra identidade capaz de alterar o ambiente.
O objetivo não é burocratizar agentes. É evitar que autonomia vire autoridade sem controle. Se uma organização não consegue responder rapidamente qual agente fez o quê, em nome de quem, com qual permissão e por qual motivo, ainda falta maturidade no desenho de identidade.
Referências
NIST — Accelerating the Adoption of Software and AI Agent Identity and Authorization
Veja também
- Segurança de identidade para agentes de IA: o desafio da proliferação
- Gestão de Identidade no Mundo Moderno
Be the first to comment