A agência de IA já está agindo no seu nome — e a pergunta que ninguém ainda consegue responder direito é: como provar que você autorizou isso?
Imagine que você pediu para um agente de inteligência artificial encontrar uma camisa por menos de R$ 150, mas deixou bem claro: não compre nada. O agente encontra a camisa. E faz a compra assim mesmo. Quando você vai contestar a cobrança, cada empresa envolvida mostra o seu pedaço da história: a loja diz que o pedido veio da sua conta, o provedor do agente mostra que a instrução era só pesquisar, e o serviço de pagamento confirma a transação. Cada registro pode estar correto. Mas nenhum deles conecta a cobrança à tarefa que você realmente deu: pesquisar, mas não comprar.
Esse cenário não saiu de um roteiro de ficção científica. É uma lacuna técnica e legal real, que já está se formando enquanto agentes de IA ganham cada vez mais autonomia para agir em nosso nome em sistemas diferentes, de empresas diferentes, sem que exista uma cadeia verificável de autorização que atravesse tudo isso. E o problema fica bem mais sério quando a gente para de falar de camisa e começa a falar de transferências de valores, pedidos médicos ou apelações de benefícios. Mas vamos por partes. 👇
O que muda quando um agente age no seu lugar
Um chatbot tradicional sugere uma camisa e espera. Um agente de IA pode usar a sua conta, contatar outros serviços e concluir a transação sozinho. Uma única frase dispara uma sequência de ações espalhadas por sistemas operados por empresas diferentes. E aqui está o ponto crítico: cada empresa só consegue verificar a parte que ela mesma enxerga. Resolver uma disputa exige uma resposta que atravesse todas elas ao mesmo tempo: este agente, agindo por esta pessoa, executou esta ação dentro dos limites desta tarefa?
Uma agência de IA é, basicamente, a capacidade que um sistema de inteligência artificial tem de agir de forma autônoma para concluir tarefas em nome de uma pessoa. Isso vai muito além de responder perguntas ou gerar textos: o agente pode acessar sistemas externos, preencher formulários, interagir com APIs, realizar buscas e, dependendo das permissões concedidas, fechar negócios e executar transações reais. O que era ficção científica há cinco anos está acontecendo agora, em produção, com usuários reais, dinheiro real e consequências reais.
Quando um humano realiza uma compra, existe uma cadeia clara de responsabilidade: a pessoa escolhe, confirma, paga e recebe. Se algo der errado, a contestação tem um caminho definido. Mas quando um agente de IA realiza essa mesma sequência, espalhando decisões por vários sistemas ao mesmo tempo, a cadeia de responsabilidade se fragmenta de um jeito que a maioria das empresas e reguladores ainda não sabe como reconectar.
Um projeto de lei aponta para o problema
Nos Estados Unidos, um projeto de lei recente colocou o dedo exatamente nessa ferida. O senador Mark Warner, da Virgínia, apresentou em julho de 2026 a chamada AI AGENT Act (S. 5051). O texto define um agente de usuário custodial como aquele autorizado a agir por uma pessoa de forma transparente, documentada, limitada e revogável, e exige que esses agentes mantenham registros em tempo real das ações executadas em nome dos usuários.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
A proposta também orienta o NIST — o Instituto Nacional de Padrões e Tecnologia dos EUA — a identificar protocolos ou desenvolver padrões técnicos para verificar que um usuário delegou autoridade a um agente, além de manter registros auditáveis das ações que esse agente executa. Parece a solução perfeita, certo? Mas tem um detalhe importante.
O projeto não exige expressamente uma cadeia de evidências verificável que atravesse os diferentes sistemas envolvidos, do momento em que o usuário inicia a tarefa até o resultado final. No cenário da camisa, essa cadeia precisaria ligar a instrução do usuário ao agente, as ações do agente e os registros mantidos pela loja e pelo serviço de pagamento. Sem essa ligação completa, cada empresa continua enxergando só o próprio pedaço.
Autorização e transação: onde o sistema quebra
O conceito de autorização dentro de sistemas digitais tradicionais é relativamente simples: você clica em confirmar, digita uma senha, lê um código de verificação. Existe um momento claro em que a sua intenção vira uma ação registrada. Com agentes de IA autônomos, esse momento some. A autorização pode ter acontecido semanas antes, como parte de uma permissão ampla concedida a um aplicativo, ou pode ter sido delegada a outro agente dentro de uma cadeia de sistemas que o usuário nem sabia que existia.
Muitos sites usam o OAuth, um protocolo de segurança padrão da indústria para delegar autorização de acesso a serviços online sem expor senhas. Ele gera um token de acesso que o aplicativo apresenta para entrar em um serviço protegido. O problema é que essa autorização permanente pode ter sido aprovada bem antes da tarefa atual. O aplicativo ainda consegue apresentar um token válido que permite finalizar a compra hoje, mesmo quando a instrução do momento diz apenas para pesquisar, e não comprar.
Ou seja: a loja vê um token utilizável e conclui a transação. A restrição específica daquela tarefa — não comprar — fica presa lá dentro do provedor do agente e nunca chega até quem processa o pagamento. Uma transação executada por um agente percorre vários sistemas independentes: o modelo de linguagem que decidiu, a API que enviou o comando, o sistema do fornecedor que recebeu o pedido, o gateway que processou o valor. Cada um tem seus próprios registros, mas eles não conversam entre si de forma estruturada o suficiente para responder à pergunta mais básica: o usuário de fato autorizou isso, nessas condições, com esse escopo?
E isso não é hipotético. Pesquisadores de segurança já demonstraram como agentes de IA podem ser manipulados por ataques de injeção de prompt, onde um conteúdo malicioso encontrado durante a navegação altera as instruções que o agente estava seguindo. Nesse cenário, a transação acontece, o registro mostra que o agente agiu dentro das permissões, mas a autorização real nunca existiu — e provar isso depois, sem uma cadeia auditável, é quase impossível.
A evidência precisa viajar junto com a ação
Para que esse tipo de responsabilização funcione de verdade, cinco coisas precisariam estar no lugar ao mesmo tempo: uma ligação verificável entre a conta do usuário, o agente naquele momento específico e a tarefa; limites específicos daquela tarefa; uma conexão verificável ao longo de toda a transação; uma checagem antes de cada ação; e registros cuja alteração posterior possa ser detectada. A boa notícia é que sistemas de pagamento já começaram a montar essas peças.
O primeiro registro identifica a conta autenticada que aprovou a tarefa e o agente que recebeu a autoridade. A loja não pode confiar apenas no nome do provedor do agente. O provedor liga conta, agente e tarefa em um registro de autorização e assina digitalmente, permitindo que loja e serviço de pagamento verifiquem quem emitiu e se aquilo foi adulterado.
O provedor também preserva o pedido original e o converte em limites que outros sistemas conseguem aplicar. Para a tarefa da camisa: pesquisar por 15 minutos, sem compra, sem passar o poder de compra para outro agente. Antes de o agente começar, o usuário vê e aprova essa versão estruturada. Se a tradução estiver errada, dá para comparar a regra com as palavras que a originaram.
A referência de tarefa que conecta tudo
Uma forma de criar essa ligação é fazer uma referência de tarefa viajar junto com cada requisição. Ela é única para um único trabalho, não carrega nome, número de conta ou qualquer identificador direto, e aparece no registro de todas as empresas participantes. Engenheiros já usam algo parecido, o identificador de rastreamento, para correlacionar eventos de uma mesma operação enquanto ela transita entre serviços.
Essa referência liga registros espalhados a um único trabalho, mas não confere autoridade por si só. Por isso ela precisa estar amarrada à regra aprovada pelo usuário dentro do registro assinado digitalmente pelo provedor. Como até um identificador aleatório pode conectar atividades entre serviços, o ideal é que ele tenha vida curta e seja visível apenas para as empresas que participam daquela tarefa específica.
Checar a regra onde o dinheiro se move
Alguém então precisa validar a regra exatamente no ponto onde o dinheiro circula. No momento do checkout, a loja valida o registro de autorização assinado e avalia a compra proposta contra ele. Uma proibição de comprar barra a transação mesmo quando o aplicativo tem acesso mais amplo à conta. Uma transferência bancária ou a liberação de registros médicos poderia disparar uma confirmação nova. E qualquer autoridade repassada a outro agente teria que manter a mesma referência de tarefa e permanecer dentro do limite original.
Depois da decisão, o sistema da loja registra o agente, a referência da tarefa, a regra avaliada, o horário, a decisão e o resultado. O serviço de pagamento guarda a mesma referência, e o provedor mantém a instrução e a regra aprovada. Cada empresa mantém um registro à prova de adulteração, para que mudanças posteriores possam ser detectadas. E o usuário recebe um recibo em linguagem simples: seu agente pesquisou em três lojas e tentou finalizar a compra. A compra foi bloqueada porque comprar não estava autorizado.
O que já está sendo construído — e o que ainda falta
O Agent Payments Protocol, ou AP2, do Google, já atende a alguns desses requisitos. Ele cria registros capazes de mostrar os limites aprovados pelo usuário e as informações apresentadas a cada participante quando uma transação é contestada. O AP2 mostra como a evidência poderia viajar entre sistemas. O que ele ainda não resolve é quem arca com o prejuízo, nem por quanto tempo cada empresa deve guardar essa evidência e como recuperá-la depois.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
O NIST, por sua vez, está revisando comentários sobre um documento conceitual publicado em fevereiro de 2026 sobre identidade e permissão de agentes. Ele pergunta como um agente pode provar sua autoridade, conectar essa autoridade a uma pessoa e produzir registros verificáveis. Mas o esforço inicial proposto cobre apenas agentes que operam dentro das organizações, onde há mais controle e visibilidade. Agentes vindos de fontes externas não confiáveis ficaram fora dessa primeira etapa, embora o documento diga que agentes públicos ou individuais podem ser tratados mais adiante.
E é justamente aí que mora o problema mais espinhoso. Os agentes de consumo que atravessam fronteiras entre empresas representam exatamente o caso que o NIST adiou. Cada companhia mantém seus próprios identificadores, sua própria linguagem de autorização e suas próprias regras de retenção. Uma disputa pode ficar sem solução mesmo quando cada empresa apresenta seus registros exatamente como foram armazenados.
Do ponto de vista regulatório aqui no Brasil, a situação é igualmente complexa. O Marco Civil da Internet, a LGPD e até o regulamento europeu de IA estabelecem princípios importantes sobre responsabilidade e transparência, mas nenhum deles foi desenhado pensando em agentes autônomos que tomam decisões em cadeia e executam transações sem intervenção humana direta em cada etapa.
Por que isso importa muito mais do que uma camisa de R$ 150
Uma disputa por uma camisa de R$ 150 até dá para ignorar sem grandes traumas. Mas os registros podem falhar exatamente da mesma forma quando um agente movimenta R$ 200 mil, submete uma apelação de benefício ou solicita a renovação de uma receita médica em seu nome. Nesses casos, pode até ser fácil provar que o agente teve acesso ao serviço. Provar se você autorizou ou não aquele agente a fazer exatamente o que ele fez em seu nome é uma história completamente diferente.
A assimetria de informação aqui é enorme: quem constrói o agente sabe exatamente o que ele pode fazer, e quem usa muitas vezes não tem a menor ideia. Isso torna a autorização um ato que precisa ser muito mais granular, revisável e rastreável do que o modelo atual de aceite único permite. Algumas iniciativas já caminham nessa direção, como o protocolo MCP da Anthropic e discussões no âmbito do W3C sobre identidade de agentes, mas o ecossistema ainda está longe de qualquer convergência real.
O caminho mais realista no curto prazo não é esperar por uma solução técnica universal ou por uma regulação abrangente. É combinar pressão do mercado — usuários e empresas exigindo transparência nas ações dos agentes — com a adoção voluntária de boas práticas por parte dos desenvolvedores, como registros detalhados de ação, escopos de permissão bem definidos e mecanismos de reversão acessíveis. Não é a solução ideal, mas é o que está dentro do alcance agora. E enquanto ela não chega, entender que esse problema existe já é um passo importante — porque só começa a ser resolvido aquilo que primeiro foi claramente visto. 👁️
