CEO da Microsoft defende “travão de emergência” para modelos avançados de IA: o que as equipas de segurança cripto devem aprender

Satya Nadella, CEO da Microsoft, terá defendido que as empresas devem tratar modelos de IA poderosos como potenciais ameaças internas, e não como simples ferramentas inofensivas de produtividade. A mensagem central é simples, mas importante: as organizações devem partir do princípio de que modelos avançados podem ser comprometidos, limitar o seu alcance desde o início e manter um “travão de emergência” controlado por humanos, capaz de pausar ou desligar agentes autónomos de IA enquanto estão em operação.

Para a indústria cripto, este alerta está longe de ser abstrato. À medida que agentes de IA começam a interagir com carteiras, contratos inteligentes, sistemas de negociação, operações de DAOs, fluxos de apoio ao cliente, ferramentas de compliance e análises on-chain, a pergunta já não é se a IA pode melhorar as operações em blockchain. A questão é quanta autoridade deve ser delegada à IA antes de o risco se tornar inaceitável.

Num setor em que uma única fuga de uma chave privada, uma assinatura maliciosa ou uma interação defeituosa com um contrato inteligente pode causar perdas irreversíveis, a proposta de Nadella merece atenção especial.

Por que os “kill switches” de IA são ainda mais importantes em cripto

Falhas em software tradicional muitas vezes podem ser revertidas, corrigidas ou compensadas por processos internos. Em cripto, é diferente. Transações on-chain são, na maioria dos casos, definitivas. Depois que os fundos são enviados para um endereço controlado por um atacante, a recuperação é incerta e frequentemente impossível sem a cooperação de corretoras, bridges, empresas de análise ou autoridades policiais.

Isso torna agentes autónomos de IA especialmente sensíveis em ambientes Web3. Um modelo de IA com permissão para assinar transações, rebalancear ativos de tesouraria, implantar contratos inteligentes, interagir com protocolos DeFi ou gerir credenciais operacionais pode tornar-se um alvo de alto valor.

Um agente de IA comprometido pode não se parecer com um hacker convencional. Pode agir através de APIs normais, fluxos de trabalho aprovados ou prompts aparentemente legítimos. É por isso que a mentalidade de “assumir que já houve uma violação” se torna cada vez mais relevante. Estruturas de segurança como o NIST AI Risk Management Framework destacam governação, mapeamento, medição e gestão de risco ao longo de todo o ciclo de vida da IA. Para equipas cripto, esses princípios devem ser estendidos ao acesso a carteiras, à aprovação de transações e à execução de contratos inteligentes.

A nova superfície de ataque: agentes de IA com permissões on-chain

Em 2025, agentes de IA estão a tornar-se mais capazes e mais integrados em fluxos financeiros. Em cripto, podem ser usados para:

• Monitorizar riscos em contratos inteligentes e alertar equipas sobre atividades anormais
• Executar estratégias de trading em corretoras descentralizadas
• Gerir resumos de propostas de DAOs e recomendações de governação
• Automatizar relatórios de tesouraria e fluxos contabilísticos
• Ajudar utilizadores a interpretar transações de carteira antes da assinatura
• Detetar domínios de phishing, contratos maliciosos e aprovações suspeitas de tokens

Estes casos de uso são valiosos. Mas também criam uma nova categoria de risco: sistemas de IA capazes de influenciar ou iniciar ações com impacto financeiro real.

Injeção de prompts, envenenamento de dados, abuso de ferramentas, manipulação de modelos e plugins comprometidos já não são preocupações meramente teóricas. O OWASP Top 10 for Large Language Model Applications destaca riscos como injeção de prompts, tratamento inseguro de outputs, excesso de autonomia e divulgação de informações sensíveis. Cada um deles torna-se mais perigoso quando ligado à infraestrutura cripto.

Por exemplo, um agente de IA que resume uma proposta de DAO pode ser manipulado por conteúdo malicioso incorporado em documentos externos. Uma IA de apoio ao cliente pode ser enganada para revelar detalhes operacionais. Um bot de trading pode reagir a sinais de mercado envenenados. Um modelo assistente de carteira pode classificar incorretamente uma aprovação maliciosa como segura.

Quanto maior for a autonomia de um sistema de IA, mais importante se torna definir claramente o que ele não pode fazer.

“Não depender de um único modelo” também se aplica a decisões em blockchain

A recomendação atribuída a Nadella de não depender de um único modelo para decisões críticas é altamente relevante para a segurança cripto. Em sistemas blockchain, decisões críticas podem incluir:

• Se uma transação deve ser assinada
• Se uma interação com contrato inteligente é segura
• Se uma votação de DAO contém riscos ocultos de governação
• Se um endereço está associado a atividade suspeita
• Se uma transação automatizada de tesouraria deve avançar

Nenhum modelo isolado deve ser tratado como autoridade incontestável para esse tipo de decisão. Uma arquitetura mais segura usa várias camadas de validação.

Por exemplo, antes de um agente de IA recomendar a assinatura de uma transação, o sistema poderia comparar a sua conclusão com uma descodificação determinística da transação, bases de dados de endereços conhecidos, simulações de contratos inteligentes, motores de pontuação de risco e revisão humana para transferências de alto valor. Se os sinais forem contraditórios, a ação padrão deve ser parar, não prosseguir.

Isto é especialmente importante porque modelos de IA podem soar confiantes mesmo quando estão errados. Em cripto, confiança não é um controlo de segurança.

Registos imutáveis combinam naturalmente com a segurança Web3

Outra recomendação essencial é preservar registos resistentes à adulteração sobre o comportamento de agentes de IA. Isto está muito alinhado com os princípios da blockchain.

Equipas cripto devem manter logs detalhados que mostrem:

• A que dados o agente de IA teve acesso
• Que ferramentas ou APIs foram chamadas
• Que prompts ou instruções influenciaram a ação
• Que transação foi recomendada ou iniciada
• Quem aprovou a execução final
• Se algum alerta de risco foi ignorado

Nem todos os logs pertencem à blockchain. Dados operacionais sensíveis não devem ser expostos publicamente. Mas compromissos criptográficos, trilhas de auditoria baseadas em hashes e carimbos temporais seguros podem ajudar a provar que os registos não foram alterados após um incidente.

Esta abordagem pode ser útil para corretoras, custodiantes, equipas DeFi, tesourarias de DAOs e operadores empresariais de blockchain. Quando algo corre mal, as equipas precisam de mais do que uma explicação vaga. Precisam de uma linha do tempo fiável que mostre como uma decisão foi tomada.

Auditorias independentes devem ir além dos contratos inteligentes e incluir fluxos de IA

Auditorias de contratos inteligentes já são prática comum em projetos Web3 sérios, mas a IA introduz uma camada adicional que também precisa de revisão. Se um agente de IA pode influenciar governação, movimentação de ativos, compliance ou alertas de risco apresentados ao utilizador, então o próprio fluxo de IA passa a fazer parte do perímetro de segurança.

Uma revisão independente deve analisar:

• Permissões do modelo e limites de acesso
• Desenho dos prompts e das instruções de sistema
• Fontes de dados usadas pelo modelo
• Permissões para chamada de ferramentas
• Modos de falha e procedimentos de contingência
• Requisitos de aprovação humana
• Planos de resposta a incidentes
• Sistemas de logging e monitorização

Isto não substitui auditorias de contratos inteligentes. É uma extensão do modelo de segurança. Numa stack cripto assistida por IA, tanto o código como os fluxos de tomada de decisão precisam de escrutínio.

A comunidade mais ampla de cibersegurança também tem reforçado princípios de desenvolvimento seguro desde a conceção. As orientações da iniciativa Secure by Design da CISA são especialmente relevantes para equipas que constroem sistemas em que configurações padrão, controlo de acesso e resiliência operacional importam desde o primeiro dia.

A divulgação de incidentes pode fortalecer todo o ecossistema cripto

Nadella também defendeu que as empresas devem divulgar falhas graves ou vulnerabilidades de segurança, incluindo causas e detalhes que possam ajudar outros a proteger-se. O setor cripto já aprendeu esta lição ao longo de anos de hacks a corretoras, exploits em bridges, falhas de oráculos e campanhas de phishing.

Quando as equipas partilham post-mortems de forma responsável, todo o ecossistema beneficia. Desenvolvedores corrigem vulnerabilidades semelhantes. Fornecedores de carteiras melhoram alertas. Investigadores de segurança refinam métodos de deteção. Utilizadores aprendem o que evitar.

Na era da IA, a divulgação de incidentes deve incluir novas categorias de informação:

• O agente de IA foi manipulado por injeção de prompt?
• Baseou-se em dados externos não confiáveis?
• As permissões eram demasiado amplas?
• O sistema não exigia aprovação humana para ações de alto risco?
• Os logs eram completos o suficiente para reconstruir o evento?
• O mesmo ataque poderia afetar outras aplicações cripto?

Este tipo de transparência pode ajudar a evitar falhas repetidas em DeFi, carteiras, provedores de infraestrutura e plataformas de trading.

Controlos práticos para equipas cripto que usam agentes de IA

Empresas cripto que adotam IA devem considerar um modelo de defesa em camadas. Os controlos abaixo podem reduzir o risco de falhas causadas por IA:

1. Limitar a autoridade sobre transações

Agentes de IA não devem ter poder irrestrito para assinar transações. Transações de alto valor, implantações de contratos, movimentos de tesouraria e ações de governação devem exigir aprovação humana e autenticação forte.

2. Usar permissões baseadas em políticas

Defina o que a IA pode e não pode fazer. Por exemplo, um agente pode ser autorizado a preparar uma transação, mas não a transmiti-la à rede; ou a analisar um contrato, mas não a aprovar uma permissão de token.

3. Adicionar um mecanismo de paragem de emergência

As equipas devem conseguir pausar imediatamente fluxos de IA se for detetado comportamento anormal. Isto inclui revogar chaves de API, congelar pipelines de automação, desativar o acesso a ferramentas e interromper ações agendadas.

4. Separar recomendação de execução

Um sistema de IA pode auxiliar na análise, mas a execução deve ficar a cargo de uma infraestrutura segura de transações com verificação independente.

5. Manter trilhas de auditoria resistentes à adulteração

Os logs devem ser completos, ter marcação temporal e estar protegidos contra modificações não autorizadas. Em sistemas sensíveis, verificações de integridade criptográfica podem ajudar a preservar evidências.

6. Exigir revisão humana para ações irreversíveis

Qualquer ação capaz de mover ativos de forma permanente, alterar a propriedade de contratos, atualizar a lógica de um protocolo ou modificar controlos de tesouraria deve envolver aprovação humana.

7. Testar contra prompts adversariais

As equipas de segurança devem avaliar se o modelo pode ser manipulado por textos maliciosos, documentos, websites, propostas de governação ou inputs de utilizadores.

O que isto significa para utilizadores individuais de cripto

Ferramentas de IA podem ajudar utilizadores a compreender transações complexas, detetar websites suspeitos e resumir informações de mercado. Mas os utilizadores não devem confiar cegamente em conselhos gerados por IA ao assinar transações de carteira.

Antes de aprovar qualquer transação, os utilizadores devem continuar a verificar:

• O endereço de destino
• O ativo e o montante
• As permissões de aprovação de tokens
• A identidade do contrato inteligente
• A rede e as definições de gas
• Se a ação corresponde realmente à sua intenção

A IA pode melhorar a experiência do utilizador, mas a segurança das chaves privadas continua a ser a base. Se um assistente de IA der uma orientação incorreta, a assinatura final continua a ser decisiva.

É aqui que carteiras de hardware continuam a desempenhar um papel importante. Uma carteira de hardware ajuda a manter chaves privadas isoladas de dispositivos ligados à internet, reduzindo a exposição a malware, sessões de navegador comprometidas e automação insegura. A OneKey, por exemplo, foi concebida com foco em autocustódia, verificação de transações e armazenamento seguro de chaves privadas, tornando-se uma proteção prática para utilizadores que navegam em ambientes cripto cada vez mais assistidos por IA.

O quadro geral: a autonomia da IA precisa de proteções nativas para cripto

A mensagem do “travão de emergência” de Nadella reflete uma mudança mais ampla na tecnologia: sistemas avançados de IA já não são apenas interfaces passivas de chat. Estão a tornar-se agentes capazes de planear, chamar ferramentas, aceder a dados e agir em diferentes sistemas digitais.

Para blockchain e criptomoedas, esta mudança cria tanto oportunidades como riscos. A IA pode tornar a Web3 mais segura ao melhorar a monitorização, a deteção de fraude, a revisão de código e a educação dos utilizadores. Mas, se agentes de IA receberem autoridade excessiva sem controlos adequados, também podem tornar-se um novo vetor de ataque para perdas de ativos.

O caminho certo não é rejeitar a IA. É desenhar sistemas de IA com limites rigorosos, verificações independentes, auditabilidade e capacidade de desligamento rápido.

Em cripto, a suposição mais segura é clara: qualquer sistema capaz de influenciar a movimentação de ativos deve ser tratado como parte da stack de segurança. E qualquer agente de IA com poder operacional deve ter um travão de emergência visível, testado e controlado por humanos.