Como os agentes de IA criam novos riscos de segurança empresarial? Entenda as chamadas de ferramentas e os limites de permissão

Em 3 de novembro de 2026, a Binance divulgou uma Declaração de investigação preliminar sobre o incidente de segurança ocorrido em 29 de outubro. A declaração revelou que invasores comprometeram os dispositivos de engenheiros com malware e usaram ferramentas internas de IA para ampliar ainda mais seu acesso. De acordo com a declaração, o ataque envolveu, em última instância, acesso não autorizado ao serviço interno de assinatura de carteiras, afetando aproximadamente US$ 6,34 bilhões em ativos digitais. No entanto, a declaração não divulgou a arquitetura completa das ferramentas internas de IA, nem confirmou que o ataque explorou vulnerabilidades em um modelo de linguagem de grande porte ou envolveu injeção de prompt.

Esse incidente levanta uma questão importante de segurança empresarial: quando um Agente de IA pode acessar mais ferramentas internas e sistemas sensíveis, como as empresas devem distinguir entre permissões de processamento de informações e permissões operacionais reais? Partindo de como os Agentes de IA chamam ferramentas, este artigo explica limites de permissão, injeção de prompt, gerenciamento de credenciais e riscos de movimentação lateral, além de analisar os controles de segurança que as empresas podem adotar.

Principais pontos

• Os Agentes de IA podem fazer mais do que gerar texto. Eles também podem executar código, ler arquivos, acessar APIs ou operar sistemas internos empresariais por meio de chamadas de ferramentas.

• A declaração de investigação preliminar da Binance, divulgada em 3 de novembro de 2026, afirmou que os invasores usaram dispositivos comprometidos de engenheiros e ferramentas internas de IA para obter mais acesso a dispositivos e permissões de outros engenheiros.

• Um dos principais riscos de segurança dos Agentes de IA é converter informações de ambientes externos ou de baixa confiança em ações com privilégios reais de execução.

• Injeção de prompt, resultados maliciosos de ferramentas, permissões excessivas e vazamento de credenciais podem se agravar mutuamente. No entanto, nem todo ataque envolvendo ferramentas de IA é um ataque de injeção de prompt.

• As empresas precisam tratar os Agentes de IA como entidades de execução de software com identidades e permissões específicas, controlando riscos por meio do princípio do menor privilégio, isolamento de ferramentas, aprovações de operações e mecanismos de auditoria.

Como os Agentes de IA diferem dos chatbots de IA tradicionais?

Os chatbots de IA tradicionais realizam tarefas principalmente ao receber a entrada do usuário e gerar respostas em texto. Mesmo que um modelo possa fornecer código, analisar arquivos ou explicar etapas operacionais, geralmente ele não consegue modificar diretamente um banco de dados empresarial, implantar uma aplicação ou chamar um serviço interno sem estar conectado a um ambiente de execução real.

A diferença dos Agentes de IA é que eles podem conectar decisões geradas pelo modelo a ferramentas externas. Por exemplo, desenvolvedores podem configurar um Agente com ferramentas de busca de código, execução de terminal, consulta a banco de dados e gerenciamento de repositórios Git. Quando um usuário envia uma tarefa, o Agente pode primeiro recuperar arquivos relevantes, depois chamar ferramentas para obter informações e, em seguida, decidir o que fazer com base nos resultados. Com as permissões adequadas, um Agente pode até criar commits de código, acionar testes ou executar processos de implantação.

Esse modelo transforma um Agente de IA de uma simples ferramenta de geração de informações em um sistema de software com determinadas capacidades operacionais. O próprio Agente pode não ter privilégios independentes de administrador, mas pode obter a capacidade de acessar sistemas externos por meio da autorização do usuário, contas de serviço, Tokens de API ou outras credenciais de identidade.

Portanto, a segurança de Agentes de IA não pode ser avaliada apenas pela precisão das respostas do modelo. Mesmo que o conteúdo gerado pelo modelo não contenha erros evidentes, o Agente ainda pode realizar operações além das expectativas do usuário se as permissões de suas ferramentas estiverem configuradas de forma inadequada. As empresas precisam se concentrar não apenas no que a IA gera, mas também no que ela pode ler, no que pode chamar e em quais operações podem realmente alterar o estado do sistema.

Como os Agentes de IA chamam ferramentas?

A chamada de ferramentas é um mecanismo importante pelo qual os Agentes de IA interagem com sistemas externos. Os desenvolvedores normalmente fornecem ao modelo os nomes, as descrições funcionais e as estruturas de parâmetros das ferramentas disponíveis. O modelo então determina se deve chamar uma determinada ferramenta com base na tarefa atual. A execução real geralmente é realizada pelo ambiente de execução ou pela aplicação do Agente, após o que os resultados da ferramenta são fornecidos ao modelo para processamento adicional.

Por exemplo, um Agente interno de desenvolvimento empresarial pode ser capaz de ler repositórios de código, consultar logs de erros e executar testes. Quando um usuário pede que ele investigue um problema em um serviço, o Agente pode chamar uma ferramenta de consulta de logs para localizar o problema, ler o código relevante e então gerar recomendações de modificação. Se a empresa também conceder permissões de escrita de código ou implantação, o Agente poderá passar de assistência analítica para a realização de operações reais.

Os riscos da chamada de ferramentas vêm principalmente de duas áreas.

• O Agente pode receber permissões de execução excessivas. Por exemplo, ele pode precisar apenas ler logs, mas também ter a capacidade de modificar configurações do ambiente de produção.

• O Agente pode processar conteúdo não confiável de páginas externas, comentários de código, e-mails ou resultados de ferramentas. Se o sistema não distinguir adequadamente esse conteúdo da autorização real do usuário, informações externas poderão influenciar chamadas de ferramentas subsequentes.

Isso significa que as empresas não podem simplesmente tratar chamadas de ferramentas geradas pelo modelo como operações confiáveis. Cada chamada de ferramenta que envolva dados sensíveis ou alterações no sistema exige verificação independente de permissões. O modelo pode enviar uma solicitação de execução, mas a permissão da solicitação deve ser determinada por políticas explícitas de segurança.

Por que os Agentes de IA podem ampliar a superfície de ataque de uma empresa?

Os sistemas tradicionais de segurança empresarial geralmente estabelecem controles de acesso em torno das identidades dos funcionários, servidores, aplicações e limites de rede. Funcionários diferentes têm permissões de sistema distintas, enquanto serviços críticos podem restringir o acesso por meio de credenciais e regras de rede separadas. Quando os Agentes de IA se conectam a sistemas empresariais, eles criam efetivamente novos caminhos automatizados de acesso.

Por exemplo, um Agente de desenvolvimento pode se conectar simultaneamente a um repositório Git, uma base de conhecimento interna, uma plataforma de nuvem e um sistema de gerenciamento de tarefas. Para concluir tarefas entre sistemas, desenvolvedores podem configurar vários Tokens de API ou contas de serviço. Se essas credenciais não forem estritamente restringidas, um invasor que obtenha controle do ambiente de execução do Agente ou de uma identidade relacionada poderá usar essas capacidades de acesso para alcançar mais sistemas.

Outro problema é a velocidade operacional. Normalmente, os funcionários precisam fazer login manualmente em várias plataformas para concluir uma série de operações, enquanto um Agente de IA pode chamar ferramentas continuamente em pouco tempo. A automação não é inerentemente insegura. No entanto, sem limites de taxa, detecção de anomalias e aprovação para operações de alto risco, instruções incorretas ou maliciosas podem ser executadas rapidamente.

Portanto, os Agentes de IA ampliam não apenas o número de interfaces de software, mas também as relações de permissão que conectam diferentes sistemas. As empresas precisam avaliar quais recursos cada Agente pode acessar, se ele pode atravessar diferentes domínios de segurança e se existem caminhos de ferramentas de baixo risco para sistemas de alto risco.

Por que a injeção de prompt pode afetar chamadas de ferramentas de Agentes de IA?

A injeção de prompt refere-se a um ataque no qual um invasor insere conteúdo semelhante a instruções em dados que um modelo pode ler, tentando alterar a tarefa que o modelo deve executar. Em chatbots comuns, esses ataques podem resultar em respostas incorretas ou divulgação de informações. Em Agentes de IA com capacidade de chamada de ferramentas, eles também podem afetar operações reais.

Por exemplo, uma empresa pode usar um Agente de IA para organizar automaticamente relatórios de problemas em um repositório de código. Se um invasor puder controlar o conteúdo de um relatório, poderá inserir instruções disfarçadas de requisitos de manutenção do sistema, induzindo o Agente a ler arquivos adicionais ou chamar ferramentas não relacionadas. O risco real não é o Agente ler o relatório, mas sim ele tratar conteúdo não confiável no relatório como uma instrução com autoridade de execução.

Esses ataques são comumente conhecidos como injeção indireta de prompt. Um invasor não precisa enviar comandos diretamente ao usuário do Agente. Em vez disso, pode influenciar o Agente por meio de páginas da web, documentos, comentários de código, resultados de busca ou resultados de ferramentas. A OWASP lista injeção de prompt, abuso de ferramentas, escalonamento de privilégios e divulgação de informações sensíveis como riscos de segurança importantes para Agentes de IA.

No entanto, a injeção de prompt deve ser diferenciada de ataques tradicionais de malware. Se um invasor já assumiu o controle do computador de um engenheiro por meio de código malicioso e depois usa credenciais existentes para acessar sistemas internos, o fato de o caminho do ataque ter envolvido uma ferramenta de IA não significa necessariamente que ocorreu uma injeção de prompt. Os dois mecanismos podem aparecer juntos, mas são tecnicamente diferentes.

Quais riscos para ferramentas de IA e gerenciamento de permissões o incidente de segurança da Binance revela?

Em sua declaração de investigação preliminar divulgada em 3 de novembro de 2026, a Binance revelou um ataque em vários estágios que evoluiu do comprometimento de um dispositivo de funcionário ao abuso do sistema interno de assinatura de carteiras. De acordo com a declaração, em setembro, os invasores induziram um engenheiro de software a baixar um repositório contendo código malicioso por meio de uma falsa entrevista de emprego. O código malicioso foi executado durante a configuração do ambiente e estabeleceu canais de comunicação controlados pelos invasores ao substituir componentes de ferramentas de desenvolvimento e usar outros métodos.

Em 20 de outubro, os invasores usaram o computador comprometido de um engenheiro e ferramentas internas de IA para obter controle de dispositivos de outros engenheiros. Eles também descobriram um Token de permissão de implantação de contêineres no dispositivo de um engenheiro de operações de carteiras. Em 29 de outubro, os invasores usaram as credenciais relevantes para implantar contêineres e acionar scripts maliciosos, chegando finalmente ao processo de operação de assinatura de carteiras.

Da perspectiva da arquitetura de segurança, esse incidente reflete pelo menos três questões que merecem análise. Primeiro, dispositivos de desenvolvedores podem se tornar pontos de entrada para sistemas internos de alto valor. Segundo, quando ferramentas internas de IA, ambientes de implantação e permissões de funcionários estão conectados, invasores podem explorar essas conexões para ampliar seu acesso. Por fim, se operações de alto risco não tiverem verificação independente de permissões suficiente, os invasores poderão converter as permissões internas obtidas na capacidade de realizar operações reais com ativos.

É importante ressaltar que a Binance não divulgou a implementação específica de suas ferramentas internas de IA. Portanto, é impossível confirmar se as ferramentas eram Agentes de IA com capacidades autônomas de planejamento ou concluir que o ataque envolveu MCP, injeção de prompt ou uma vulnerabilidade em um modelo específico. O incidente mostra que ferramentas de IA podem fazer parte de um caminho de ataque complexo, mas não prova, por si só, que um Agente de IA foi a causa raiz do ataque.

Qual é o limite de permissão de um Agente de IA? Por que o princípio do menor privilégio é tão importante?

Um limite de permissão define quais recursos uma entidade de software pode acessar, quais operações pode realizar e em quais condições pode obter permissões adicionais. Para um Agente de IA, o limite de permissão envolve não apenas o próprio modelo, mas também o ambiente de execução do Agente, interfaces de ferramentas, identidade do usuário, contas de serviço e sistemas externos.

O princípio do menor privilégio exige que um sistema conceda apenas as permissões necessárias para concluir a tarefa atual. Por exemplo, um Agente responsável por analisar logs de servidores normalmente precisa acessar apenas dados de log específicos. Ele não deve poder excluir bancos de dados, modificar ambientes de produção ou transferir ativos digitais automaticamente. Se uma tarefa realmente exigir uma operação de alto risco, o Agente deverá obter permissão temporária por meio de um mecanismo independente de autorização.

A OWASP lista a autonomia excessiva como um risco importante em aplicações de modelos de linguagem de grande porte. A questão central não é que o modelo tenha capacidades de chamada de ferramentas, mas que o sistema tenha concedido ao modelo funções desnecessárias, permissões excessivas ou capacidades autônomas de operação sem restrições. Quando o modelo é influenciado por entradas incorretas, injeção de prompt ou resultados maliciosos de ferramentas, essas permissões podem aumentar os danos potenciais.

Portanto, as empresas precisam colocar verificações de permissão em um ambiente de execução confiável, em vez de apenas dizer ao Agente, por meio de um prompt de sistema, para não realizar operações perigosas. Mesmo que um modelo solicite incorretamente acesso a uma ferramenta sensível, o serviço de backend deve ser capaz de rejeitar a solicitação não autorizada com base na identidade, no escopo do recurso e no tipo de operação.

Quais novos desafios de segurança protocolos de conexão de ferramentas, como MCP, podem criar?

O Model Context Protocol (MCP) é um protocolo aberto para conectar aplicações de IA a ferramentas externas e recursos de dados. Por meio do MCP, os desenvolvedores podem conectar Agentes de IA a sistemas de arquivos, bancos de dados, repositórios de código e outros serviços sem precisar projetar um método de integração completamente diferente para cada ferramenta.

Esse método de conexão padronizado pode melhorar a eficiência de desenvolvimento, mas também significa que os Agentes podem acessar múltiplos sistemas externos com mais facilidade. Se uma empresa não gerenciar Servidores MCP, definições de ferramentas e permissões de acesso, ela poderá enfrentar problemas como permissões excessivas de ferramentas, descrições maliciosas de ferramentas, comprometimento de serviços de terceiros ou exposição acidental de informações sensíveis.

Por exemplo, um Agente de desenvolvimento pode precisar ler um repositório de código, mas não ter necessidade de acessar o sistema de pagamentos da empresa. Se os dois tipos de ferramentas estiverem configurados no mesmo ambiente de execução e usarem credenciais compartilhadas com permissões de alto nível, um Agente originalmente destinado a auxiliar no desenvolvimento poderá obter capacidades operacionais não relacionadas à sua tarefa.

A OWASP recomenda estabelecer um mecanismo de auditoria para Servidores MCP conectados a ferramentas de programação com IA, restringir as ferramentas que podem ser chamadas e verificar se as definições de ferramentas contêm instruções maliciosas. Agentes que executam código também devem usar medidas como sandboxing, restrições de acesso à rede e gerenciamento independente de credenciais.

O MCP em si não constitui uma vulnerabilidade de segurança. O que precisa ser avaliado é a implementação das ferramentas, a autenticação, a configuração de permissões e como o conteúdo externo afeta o comportamento do Agente após a conexão do protocolo.

Como as empresas devem proteger as identidades e permissões de acesso dos Agentes de IA?

As empresas devem primeiro estabelecer um sistema de identidade identificável e auditável para Agentes de IA. Aplicações tradicionais normalmente usam contas de serviço ou Chaves de API para acessar outros sistemas. No entanto, as operações de Agentes de IA podem envolver autorização do usuário, tarefas automatizadas e múltiplas ferramentas simultaneamente. Portanto, as empresas precisam distinguir claramente entre a identidade do usuário, a identidade do Agente e as permissões reais de execução.

Por exemplo, um funcionário que pede a um Agente para recuperar um relatório interno não significa que o Agente possa usar sua conta de serviço para ler outros arquivos aos quais o funcionário não está autorizado a acessar. Um projeto de autorização adequado deve verificar tanto se o usuário solicitante está autorizado a acessar o recurso de destino quanto se o Agente tem permissão para realizar a operação correspondente. Isso ajuda a evitar que o Agente contorne os controles de acesso existentes porque seu serviço de proxy tem privilégios mais elevados.

Em fevereiro de 2026, o National Cybersecurity Center of Excellence (NCCoE), vinculado ao National Institute of Standards and Technology (NIST), publicou um documento conceitual sobre identidade e autorização de software e Agentes de IA. O documento discutiu questões como reconhecimento de identidade do Agente, autenticação, autorização, credenciais temporárias, permissões delegadas e auditoria. Isso reflete como a segurança de Agentes de IA está se expandindo de controles sobre a saída do modelo para uma estrutura completa de gerenciamento de identidade e acesso.

Em implementações reais, as empresas podem usar credenciais de acesso de curta duração e restringir permissões a tarefas, recursos e períodos específicos. Aprovação independente e verificação secundária também devem ser exigidas para atividades de alto risco, como implantações em produção, operações financeiras e alterações de permissões. Dessa forma, mesmo que o ambiente de execução do Agente seja comprometido, um invasor pode não conseguir obter diretamente credenciais de longa duração e alto privilégio.

Como as empresas podem reduzir os riscos de segurança das chamadas de ferramentas de Agentes de IA?

As empresas podem estabelecer proteções em quatro áreas: permissões de ferramentas, ambientes de execução, operações sensíveis e monitoramento de comportamento.

• As empresas devem restringir as ferramentas que um Agente pode usar com base nos requisitos de negócios. Um Agente que apenas recupera informações não precisa de capacidades arbitrárias de execução de código, e um Agente usado para revisão de código não deve receber automaticamente permissões de implantação em produção. Para ferramentas com capacidades de escrita, as empresas podem restringir ainda mais caminhos de arquivos, tabelas de banco de dados, tipos de operação de API e escopos de acesso.

• Ferramentas de alto risco devem ser executadas em ambientes isolados. A execução de código, a instalação de pacotes de terceiros e o processamento de páginas externas podem introduzir conteúdo não confiável. Portanto, as empresas podem usar contêineres ou outras tecnologias de sandbox para restringir o acesso a sistemas de arquivos, redes e recursos do sistema. O isolamento reduz a probabilidade de que um ataque a uma única ferramenta afete outros sistemas.

• As empresas devem exigir aprovação humana para operações irreversíveis. Operações como excluir dados importantes, modificar permissões, implantar serviços em produção ou transferir ativos não devem ser concluídas automaticamente apenas porque o Agente considera a tarefa razoável. As diretrizes de segurança do Agent Framework da Microsoft também recomendam determinar se a confirmação humana é necessária com base no impacto, na sensibilidade dos dados e na reversibilidade da operação.

• Por fim, as empresas precisam estabelecer mecanismos contínuos de auditoria que registrem quais ferramentas o Agente usou, quais recursos acessou, se ocorreram solicitações anormais de permissão e se os resultados reais de execução corresponderam à tarefa autorizada. Para chamadas repetidas de ferramentas com falha, acesso anormal a dados e grandes volumes de operações em um curto período, as empresas podem combinar detecção baseada em regras com análise comportamental para identificar riscos potenciais.

Essas medidas não podem garantir a eliminação completa dos riscos de segurança de Agentes de IA. No entanto, podem reduzir o escopo do impacto após um ataque bem-sucedido e aumentar a probabilidade de que comportamentos anormais sejam detectados e tratados.

Por que a segurança de Agentes de IA está se tornando uma questão importante para a infraestrutura Web3?

A combinação de Agentes de IA e infraestrutura de blockchain atribui implicações mais diretas à chamada de ferramentas e ao gerenciamento de permissões para a segurança de ativos. Em cenários empresariais tradicionais, um Agente pode executar código, enviar e-mails ou modificar um banco de dados. Em cenários Web3, um Agente também pode se conectar a carteiras, consultar ativos on-chain, chamar contratos inteligentes ou iniciar solicitações de transação.

Por exemplo, um Agente usado para gerenciar automaticamente ativos on-chain pode precisar consultar saldos, analisar o mercado e fornecer recomendações de negociação com base nas configurações do usuário. Se ele também receber capacidades de assinatura de transações ou chamada de contratos inteligentes, as empresas devem definir claramente quais operações podem ser executadas automaticamente, quais exigem confirmação do usuário e como limitar o valor por transação, o escopo de ativos e o período de validade da autorização.

Nesse processo, Chaves de sessão, contas inteligentes e mecanismos granulares de autorização podem fornecer diferentes formas de gerenciamento de permissões. No entanto, sua segurança específica depende de como são implementados. As Chaves de sessão podem limitar determinadas permissões operacionais a um período ou escopo específico, enquanto contas inteligentes podem restringir o comportamento de transações por meio de regras de contrato. Ainda assim, riscos de segurança podem surgir se as condições de autorização forem amplas demais, a lógica de validação contiver falhas ou o ambiente de execução for comprometido.

Portanto, o desenvolvimento de Agentes de IA para Web3 não pode se concentrar apenas na eficiência da negociação automatizada ou dos pagamentos on-chain. Ele também deve abordar verificação de identidade, delegação de permissões, aprovações de transações e revogação de autorizações. Para sistemas de IA conectados a ativos reais, o limite de segurança deve abranger todo o processo, desde as decisões do modelo até as chamadas de ferramentas, construção de transações, verificação de assinaturas e execução on-chain.

Conclusão

Os Agentes de IA estão mudando a forma como as empresas usam a inteligência artificial. À medida que os modelos se conectam a repositórios de código, APIs internas, bancos de dados e ferramentas de automação, os sistemas de IA deixam de ser apenas pontos de entrada para processamento de informações. Eles estão se tornando cada vez mais entidades de execução de software com capacidades operacionais reais.

A investigação preliminar da Binance sobre o incidente de segurança divulgado em 3 de novembro de 2026 indica que ferramentas internas de IA podem ter aparecido em um caminho de ataque complexo. No entanto, as informações disponíveis são insuficientes para provar que o incidente foi causado diretamente por uma vulnerabilidade de Agente de IA ou por injeção de prompt. A lição mais importante é que as empresas precisam reavaliar as relações de acesso entre ambientes de desenvolvimento, ferramentas de automação e sistemas de alto privilégio.

No futuro, a segurança de Agentes de IA dependerá não apenas de os modelos conseguirem identificar instruções maliciosas, mas também de as empresas conseguirem estabelecer mecanismos confiáveis de autenticação de identidade, princípio do menor privilégio, isolamento de ferramentas e aprovação independente. Somente ao separar adequadamente as capacidades de tomada de decisão da IA das permissões reais de execução, as empresas poderão controlar riscos potenciais enquanto melhoram a eficiência da automação.

Perguntas frequentes

Por que os Agentes de IA têm mais riscos de segurança do que chatbots comuns?

Os Agentes de IA podem acessar dados empresariais, executar código ou modificar sistemas por meio de chamadas de ferramentas. Em comparação com chatbots que apenas geram texto, seus erros ou comportamentos manipulados podem ter consequências operacionais reais.

O que é chamada de ferramentas de um Agente de IA?

A chamada de ferramentas refere-se a um Agente de IA solicitar que um programa ou serviço externo execute uma operação com base nos requisitos de uma tarefa, como consultar um banco de dados, ler um arquivo, chamar uma API ou executar código.

A injeção de prompt sempre pode controlar um Agente de IA?

Não necessariamente. O sucesso da injeção de prompt depende do projeto do sistema, do comportamento do modelo e dos controles de segurança. Mesmo que um invasor influencie a saída do modelo, a verificação independente de permissões pode impedir operações não autorizadas de ferramentas.

O incidente de segurança da Binance prova que os Agentes de IA têm vulnerabilidades?

Não. A investigação preliminar da Binance confirmou que o caminho do ataque envolveu ferramentas internas de IA, mas não divulgou evidências técnicas suficientes para estabelecer a existência de uma vulnerabilidade de Agente de IA ou de injeção de prompt.

O MCP aumenta os riscos de segurança de Agentes de IA?

O MCP pode ajudar aplicações de IA a se conectarem a ferramentas externas, mas os principais riscos de segurança decorrem da implementação das ferramentas, das permissões de acesso e do tratamento de conteúdo não confiável. Autenticação adequada, auditoria de ferramentas e restrições de permissões podem reduzir esses riscos.

Como as empresas devem restringir as permissões de Agentes de IA?

As empresas podem usar o princípio do menor privilégio, credenciais temporárias específicas para tarefas, aprovações independentes de operações, isolamento em sandbox e auditoria de chamadas de ferramentas para garantir que os Agentes realizem apenas operações explicitamente autorizadas.