Gerenciamento de Chaves e Segurança Operacional para Pagamentos em Criptomoedas

A maioria dos grandes incidentes de 2025-2026 pode ser rastreada, em última análise, até chaves ou assinaturas — uma ferramenta de assinatura comprometida, uma chave de administrador vazada ou um operador vítima de phishing. (Analisamos esses casos separadamente em nosso artigo sobre hacks recentes em pagamentos cripto.) O fio condutor tende a estar em algum ponto de como as chaves são autorizadas, armazenadas ou usadas para assinar.

O problema é que multisig, MPC, carteiras quentes/frias e HSM são discutidos como se fossem opções no mesmo nível, e confundi-los transforma a seleção em uma bagunça. Na verdade, são três dimensões independentes, e uma configuração real de gerenciamento de chaves é uma combinação das três. Este artigo percorre cada uma delas, depois aborda a arquitetura híbrida, a infraestrutura de assinatura e os padrões operacionais que a sustentam, além da superfície operacional mais ampla ao redor — isolamento de API e infraestrutura, pessoas e fornecedores, domínios e identidade, e o risco mais recente e menos compreendido: Agentes de IA com acesso aos seus fundos.

Chaves Privadas, Frases-Semente e Por Que "Está no Meu Dispositivo" Não É Segurança

No cerne de tudo isso está a chave privada: uma cadeia de números aleatórios criptográficos. Quem a detém pode assinar transações e movimentar os fundos no endereço correspondente. É o controle definitivo sobre os fundos de um endereço — e o ponto único de risco definitivo.

Uma frase-semente (geralmente 12 ou 24 palavras, o padrão BIP-39) é uma codificação legível por humanos dessa chave privada. A regra "Hierárquica Determinística" (HD) deriva milhares de chaves privadas e endereços a partir de uma única frase-semente. Isso torna uma frase-semente pelo menos tão sensível quanto uma chave privada individual, possivelmente mais: vazar uma chave privada faz você perder um endereço; vazar a frase-semente faz você perder toda a carteira.

Aqui está um equívoco comum que vale nomear diretamente: alguns presumem que, enquanto o dispositivo de assinatura e a carteira estiverem em suas próprias mãos e a chave estiver offline, nada pode dar errado. O problema é que chaves privadas e frases-semente em carteiras de software e hardware comuns podem ser exportadas. Qualquer pessoa com acesso interno ao dispositivo ou a um backup pode exportar e copiar a chave privada e, então, controlar os fundos de qualquer lugar — sem nunca tocar naquele dispositivo "próprio".

Portanto, "a chave está no meu próprio dispositivo" não equivale a "ninguém mais pode pegá-la." O que realmente importa é se a chave privada pode ser exportada. Como você verá abaixo, o HSM é a única opção que bloqueia a exportação em nível de hardware.

Três Dimensões Independentes, Não Um Espectro

Antes de escolher uma configuração, ajuda separar as três perguntas que você está realmente respondendo.

Modelo de Autorização: Single-Sig, Multisig ou MPC/TSS

Single-sig significa que uma única chave privada controla tudo — a configuração mais simples e o maior ponto único de falha.

Multisig requer M de N chaves privadas independentes para assinar juntas (por exemplo, 3-de-5), com cada signatário detendo uma chave privada completa e independente. Em cadeias que suportam contratos inteligentes, o multisig de contrato (Safe é o padrão de fato) implementa essa lógica em um contrato, com assinaturas e regras de limiar publicamente verificáveis na cadeia — ao custo de maior gas por transação e uma edição na configuração do contrato toda vez que você altera os signatários. Há também uma fraqueza facilmente ignorada aqui: a infraestrutura de assinatura para multisig de contrato ainda é imatura. Uma chamada execTransaction do Safe frequentemente aparece em uma carteira de hardware como uma longa cadeia de calldata, então os signatários têm dificuldade em ver o que estão realmente aprovando, e o suporte do ecossistema para Clear Signing e análise de transações ainda é limitado. Essa é exatamente a superfície de ataque explorada no incidente Bybit, razão pela qual empresas que adotam multisig de contrato frequentemente precisam trazer análise de transações e verificação cruzada de terceiros para preencher a lacuna. Cadeias como Bitcoin, por outro lado, suportam multisig nativamente na camada de script, sem dependência de contrato.

MPC (assinaturas de limiar, TSS) não é "cortar uma chave privada completa em pedaços." O MPC real usa geração distribuída de chaves (DKG): a chave é distribuída desde o momento em que é criada, cada parte detém um compartilhamento de chave independente, e nenhuma chave privada completa existe em nenhum momento. Cada parte computa uma assinatura parcial a partir de seu compartilhamento, e essas assinaturas parciais são combinadas por um protocolo criptográfico em uma única assinatura padrão — uma computação, não uma concatenação de cadeias de bytes — de modo que o resultado é indistinguível na cadeia de uma assinatura ordinária. O custo de gas é normal, a compatibilidade entre cadeias é boa, e mudar os signatários ou o limiar não requer tocar em um contrato.

Vale distinguir MPC/TSS de um método mais antigo e facilmente confundido: Shamir Secret Sharing (SSS). O SSS corta uma chave privada completa já existente em n pedaços; para assinar, pedaços suficientes são reunidos e a chave privada completa é reconstruída na memória antes de assinar — e esse momento de reconstrução é o ponto único de falha. O TSS nunca reconstrói; a chave privada completa nunca aparece. É isso que o torna mais seguro que o SSS.

Tanto o multisig quanto o MPC eliminam o risco de ponto único, apenas por mecanismos diferentes. O multisig é múltiplas chaves completas mais verificação na cadeia: transparente, mas custoso e difícil de rotacionar signatários. O MPC é múltiplos compartilhamentos de chave mais combinação fora da cadeia de assinaturas parciais: flexível e barato, mas a coordenação depende da sua infraestrutura.

Proteção de Hardware: Software, Carteira de Hardware, TEE ou HSM

Armazenamento em software mantém a chave privada em um servidor ou software — a opção mais conveniente e a mais frágil. Uma carteira de hardware (Ledger, Trezor e similares) mantém a chave em um chip seguro, assina dentro do dispositivo e nunca deixa a chave sair.

TEE (Ambiente de Execução Confiável) — como Intel SGX, AWS Nitro ou Apple Secure Enclave — cria uma região de memória isolada e criptografada em uma CPU de uso geral, onde chaves e computação de assinatura ficam fora do alcance até mesmo de um invasor com acesso root ao sistema operacional. Situa-se entre software e HSM: forte isolamento lógico, bom desempenho e capaz de executar código arbitrário (incluindo protocolos MPC), embora sua resistência física à adulteração e certificação de conformidade fiquem aquém do HSM. Essa também é a forma mais comum de armazenar compartilhamentos de chave MPC — gerados pelo DKG dentro do enclave e nunca removidos dele. A Fireblocks, por exemplo, distribui compartilhamentos de chave MPC em enclaves SGX em múltiplas nuvens.

HSM (Módulo de Segurança de Hardware) é hardware resistente à adulteração de nível empresarial que atende a certificações como FIPS 140-2/3, com resistência física à adulteração e apagamento automático em caso de intrusão. Sua garantia mais forte: a chave privada é gerada dentro do hardware, marcada como não exportável e fisicamente não pode sair. É isso que o separa fundamentalmente de software e carteiras de hardware, e é por isso que o HSM é adequado para a custódia de chaves privadas completas de alto valor.

Essa dimensão é ortogonal ao modelo de autorização acima: cada chave completa em um multisig pode residir em uma carteira de hardware ou em um HSM, enquanto cada compartilhamento MPC geralmente reside em um enclave TEE.

Temperatura dos Fundos: Quente, Morna ou Fria

Essa dimensão não se importa com como a chave é armazenada — apenas com o quanto a chave privada está exposta à internet, ou seja, com que rapidez e automaticamente o dinheiro pode se mover.

Carteiras quentes estão sempre online, usadas para pagamentos instantâneos e pagamentos automáticos — as mais rápidas e de maior risco, geralmente contendo apenas um dígito percentual do total de fundos. Carteiras mornas estão online, mas com a chave privada isolada em um ambiente protegido (um serviço de assinatura dedicado ou HSM), exigindo um humano no ciclo de assinatura; essas lidam com a liquidação operacional do dia a dia. Carteiras frias são totalmente offline e air-gapped, usadas para armazenamento de longo prazo de grandes reservas — maior segurança, mais lentas para usar, e geralmente contendo a maior parte dos fundos.

Para ser claro, temperatura é fundamentalmente sobre a exposição online da chave privada e com que facilidade os fundos se movem; frequência de transferência e participação nos fundos são consequências disso, não a definição. Essa dimensão também é ortogonal às duas primeiras: uma carteira fria pode usar multisig mais HSM, e uma carteira quente pode usar MPC.

Junte as três e você terá o quadro completo: modelo de autorização, proteção de hardware e temperatura dos fundos são independentes, e uma configuração real de gerenciamento de chaves combina as três.

Configurações Comuns de Gerenciamento de Chaves

Veja como a indústria comumente combina as três dimensões:

O objetivo da seleção é estratificar por temperatura dos fundos e usar a melhor combinação em cada camada. Carteiras quentes precisam de velocidade, portanto prefira MPC. Carteiras frias precisam de estabilidade e auditabilidade, portanto prefira multisig mais HSM. Governança e privilégios de contrato precisam de transparência e responsabilidade, portanto prefira multisig de contrato mais timelock.

Arquitetura Híbrida Recomendada pela BlockSec

A BlockSec recomenda uma arquitetura híbrida estratificada por temperatura.

Carteiras quentes/mornas: assinatura MPC. Elimina o ponto único de falha de uma chave privada, mantém a latência de assinatura baixa e é adequada para pagamentos de alta frequência. Os compartilhamentos devem ser distribuídos por diferentes locais físicos e domínios de segurança.

Carteiras frias: controle multipartidário mais auditabilidade na cadeia, adequado para grandes reservas. Qual implementação usar depende da capacidade operacional on-chain da sua equipe — há dois caminhos:

• Para máxima transparência, com operações on-chain maduras: use multisig de contrato (ex.: 3-de-5 do Safe), onde as regras de limiar e cada assinatura são publicamente verificáveis na cadeia. No Bitcoin, use multisig nativo da camada de script, com cada signatário protegendo sua própria chave em um HSM ou carteira de hardware. Observe que as ferramentas de análise de assinatura para multisig de contrato ainda são imaturas, portanto a equipe precisa adicionar verificação cruzada por conta própria — as operações aqui não são leves.
• Para equipes menos fluentes em execução on-chain que desejam menos complexidade operacional: use assinatura de limiar MPC com compartilhamentos em um TEE e, em seguida, traga um terceiro independente como co-signatário para executar uma verificação de segurança de transação antes de cada assinatura. Isso evita a lacuna de ferramentas do multisig de contrato e integra a verificação independente de terceiros diretamente no limiar de assinatura.

Atualizações de contrato e mudanças de política: multisig mais timelock. Qualquer operação que altere privilégios requer aprovação de múltiplas pessoas e um atraso de tempo.

Alguns parâmetros são importantes independentemente do caminho escolhido. Use pelo menos 3 signatários, com um limiar de pelo menos 50%, mas abaixo do total — evite N-de-N, pois um único signatário inacessível bloquearia a assinatura e travaria os fundos, e se cada signatário for indispensável, cada um se torna um alvo crítico para coerção ou sequestro. Um limiar abaixo do total deixa redundância e reduz o valor de atingir qualquer signatário individualmente. Cada signatário também deve usar um endereço novo e dedicado em cada multisig, nunca compartilhado com outros multisigs ou carteiras pessoais, e os signatários devem ser diversos em geografia, função organizacional e entidade legal — com dispersão aumentando conforme o nível de risco da carteira aumenta.

Esse nível de risco deve vir de uma classificação formal: avalie cada carteira pelo seu impacto financeiro nos negócios, dependência de protocolo e risco reputacional, e mapeie cada classificação para um limiar, fluxo de aprovação e densidade de monitoramento diferentes. Revise a classificação a cada 6 meses e imediatamente após uma grande mudança de TVL, uma atualização de contrato ou um incidente de segurança.

Blind Signing e Isolamento do Ambiente de Assinatura

Blind signing significa que sua ferramenta de assinatura mostra um hash de calldata — não o que a transação realmente faz. Não é um risco hipotético: no momento da assinatura, o signatário não consegue entender o significado real de uma transação pela interface, e essa lacuna foi uma causa direta do incidente Bybit, onde o front-end ou back-end usado para assinatura foi comprometido e os signatários aprovaram uma transação maliciosa sem qualquer bug nos próprios contratos.

Bloquear as três dimensões acima só funciona se o processo de assinatura ao redor delas for igualmente endurecido. Alguns padrões se aplicam independentemente da configuração:

• Hardware de assinatura obrigatório. Todas as operações de multisig em produção devem usar uma carteira de hardware com tela grande o suficiente para exibir o resumo completo da transação e suportar Clear Signing, proteção por PIN com verificação de integridade de firmware, e uma cadeia de suprimentos limitada ao fabricante ou revendedores autorizados — verifique a autenticidade no recebimento.
• Ambiente de assinatura fisicamente isolado. A assinatura deve ser executada em dispositivos air-gapped, não compartilhando a rede de escritório do dia a dia; operações de alto valor justificam dispositivos de assinatura dedicados. Implante o serviço de assinatura em um domínio de segurança independente, fisicamente isolado da lógica de negócios e do front-end. Os nós de assinatura não devem ser diretamente expostos à internet pública — conecte-se a eles apenas via VPN ou linha privada. Os logs de operação de assinatura devem ser armazenados separadamente, não modificáveis pelo sistema de negócios.
• Verificação independente de transações. Verifique o conteúdo da transação por um canal independente antes de assinar — um terminal dedicado, um dispositivo de hardware ou um serviço terceirizado de simulação/risco de transações. Essa verificação é melhor feita por um terceiro independente, não apenas pelo seu próprio front-end ou back-end — confiar apenas em sistemas internos é em si um ponto único de falha. Uma vez que o front-end ou back-end interno seja comprometido, como no caso Bybit, o que o signatário vê na tela são informações falsas adulteradas, e verificar você mesmo contra você mesmo não é verificação alguma. O caminho de pagamento especialmente precisa dessa linha de defesa independente.
• Clear Signing e verificação cruzada. Use ferramentas que analisam a semântica da transação, para que o signatário veja "transferir 1.000 USDC para 0x1234..." em vez de uma cadeia de calldata, e faça verificação cruzada de parâmetros-chave — ID da cadeia, endereço de destino, calldata, valor, nonce e tipo de operação — como idênticos em pelo menos duas ferramentas ou interfaces independentes.
• Verificação dupla humana mais automatizada. Um motor de regras automatizado faz a triagem inicial, e um humano confirma grandes transações antes de elas serem enviadas.
• Zero trust e backups. Implante o serviço de assinatura, a lógica de negócios e a interface front-end em diferentes domínios de segurança, e mantenha alternativas para a UI de assinatura primária, RPC e explorador de blocos, para que uma única falha de fornecedor ou serviço não possa bloquear a assinatura de emergência.

Padrões Operacionais de Multisig

As escolhas de chave e limiar só chegam até certo ponto. Alguns padrões operacionais são igualmente importantes.

Registro de multisig. Mantenha um único registro de cada multisig, com cada entrada incluindo pelo menos: endereço, cadeia, limiar de assinatura, classificação de risco, finalidade, endereços dos signatários, contratos controlados, funções na cadeia e data da última revisão. Mudanças sensíveis à segurança devem atualizar o registro em 24 horas, mudanças de rotina em 3 dias.

Gerenciamento do ciclo de vida dos signatários. Verifique endereços antes da integração fazendo o endereço prospectivo assinar uma mensagem específica, verificada com uma ferramenta independente. Defina SLAs para remoção dos privilégios de um signatário que sai ou é removido por classificação de risco — urgente em 48-72 horas, crítico em 7 dias, todo o resto em 14 dias. Execute uma revisão trimestral de acesso para confirmar que cada signatário ainda controla sua chave e atualize o treinamento dos signatários pelo menos anualmente, cobrindo verificação de transações, procedimentos de emergência e defesa contra engenharia social/phishing, com uma avaliação prática posteriormente.

Proteção de frase-semente e backup. Nenhum armazenamento digital de qualquer tipo — sem drives em nuvem, álbuns de fotos ou documentos. Armazene backups dispersos em diferentes localizações geográficas, recuperáveis em caso de desastre natural, roubo e operador desaparecido. Nenhum ponto único deve conter as informações completas de recuperação.

Comunicações seguras. Coordene entre signatários usando canais primários e de backup em plataformas diferentes, cada um aplicando MFA, criptografia de ponta a ponta e associação somente por convite. Antes de assinar, verifique a identidade de um signatário por um canal independente — uma videochamada, uma senha e um segundo canal autenticado — para evitar que uma conta de mensagem instantânea sequestrada se passe por um signatário.

SLA de resposta a emergências. Defina tempos de resposta dos signatários por gravidade do incidente, por exemplo urgente em menos de 2 horas, sensível ao tempo 2-12 horas, rotina 24-48 horas. Teste a acessibilidade dos signatários trimestralmente, não apenas no papel, e execute pelo menos um exercício de emergência completo por ano, cobrindo cenários como uma chave vazada, um signatário inacessível, um canal de comunicação comprometido e operações de protocolo de emergência.

Monitoramento on-chain de multisig. Monitore mudanças de signatário/limiar, transferências acima do limiar, lacunas de nonce, interações com endereços desconhecidos, transações com falha, mudanças de Module/Guard e saldos anormais de carteiras proponentes. A própria infraestrutura de monitoramento precisa ser resistente à adulteração.

Segurança de API

A segurança de API é a primeira linha de defesa do seu backend de pagamento. Isso significa autenticação por chave de API mais assinatura HMAC ou FIDO2/WebAuthn, limitação de taxa para prevenir força bruta e abuso, proteção DDoS via serviço CDN/WAF, validação rigorosa de cada parâmetro de entrada para prevenir injeção e auditoria de log para que cada chamada de API produza uma trilha de auditoria completa.

Os ambientes de assinatura precisam ser isolados de tudo isso, não apenas protegidos por isso — razão pela qual o serviço de assinatura pertence ao seu próprio domínio de segurança, conforme abordado acima.

Segurança Operacional: Pessoas, Fornecedores e Auditorias Independentes

Vários grandes incidentes em 2026 envolveram engenharia social — recrutamento falso, personificação de suporte de TI e troca de rosto por IA, entre outros. Defender-se disso exige três níveis trabalhando juntos.

Treinamento e avaliação vêm primeiro: todos com acesso a sistemas de assinatura, credenciais de produção ou operações sensíveis completam treinamento de segurança na integração, atualizam anualmente e atualizam o conteúdo em 30 dias após qualquer mudança de processo.

A separação de funções é igualmente importante: iniciação, aprovação e execução não podem ser feitas pela mesma pessoa, e contas de administrador não podem pagar diretamente. Operações de alta sensibilidade, como assinatura, devem usar dispositivos dedicados — com criptografia de disco completo, bloqueio automático — com carteiras de hardware mantidas em um cofre quando não estiverem em uso, e todo acesso remoto roteado por uma VPN.

Terceiros precisam da mesma disciplina. Faça due diligence antes de selecionar um fornecedor, revise o status de conformidade e segurança dos principais fornecedores anualmente e conceda acesso de terceiros com escopo claro, finalidade e data de expiração — revogados imediatamente quando isso expirar ou o projeto terminar. Verifique a identidade do pessoal terceirizado de forma independente antes de conceder qualquer acesso.

Nada disso deve depender apenas de autoavaliações internas. Execute avaliações de segurança independentes de terceiros regularmente, cobrindo pelo menos testes de penetração, exercícios de red team e auditorias de código e contratos inteligentes. Corrija as descobertas uma a uma e verifique o encerramento na próxima rodada de avaliação.

Segurança de Desenvolvimento e Infraestrutura

Vários grandes incidentes de pagamento e cripto nos últimos anos remontam a um processo de desenvolvimento comprometido — com os próprios contratos e a lógica de assinatura perfeitamente corretos. Isso significa que a camada de desenvolvimento e infraestrutura merece a mesma atenção que a camada de assinatura, em quatro áreas.

O isolamento do ambiente de desenvolvimento mantém contas de desenvolvimento separadas de contas privilegiadas (assinatura, gerenciamento de nuvem), mantém credenciais de produção fora do alcance do ambiente de desenvolvimento e coloca ferramentas e extensões de desenvolvimento em uma lista de aprovação.

Seus repositórios de código e cadeia de suprimentos precisam de proteção de branch, commits assinados e revisão multipessoal no branch principal. Extraia dependências apenas de repositórios oficiais com versões fixadas e verificações de typosquatting, e execute varredura automática de segredos que revoga e rotaciona qualquer chave exposta imediatamente.

Em CI/CD, as mudanças de configuração de pipeline precisam de aprovação multipartidária e controle de versão, com builds reproduzíveis. Segredos vão por um gerenciador dedicado como Vault ou um KMS em nuvem — segredos de produção nunca devem ser diretamente acessíveis a humanos — e SAST mais varredura de dependências são pré-condições para implantação, não extras opcionais.

Para infraestrutura e nuvem, conceda acesso privilegiado via provisionamento just-in-time, aprovação multipartidária e limites de tempo. Mantenha contas break-glass para emergências, mas alerte em cada uso. Execute logs de auditoria completos, alertas em tempo real sobre operações de administrador e backup e recuperação de desastres regularmente praticados.

Domínio, DNS e Identidade: A Superfície de Ataque Subestimada

Domínio e DNS são uma superfície de ataque gravemente subestimada em cripto — muitos incidentes de phishing e roubos remontam a uma conta de registrador comprometida ou DNS sequestrado. Proteger os domínios onde os usuários iniciam operações de fundos importa tanto quanto proteger o próprio ambiente de assinatura.

Gerencie sua conta de registrador como uma conta de alto privilégio: aplique MFA com chave de hardware e exija segunda confirmação fora de banda para mudanças críticas como transferências, exclusões ou alterações de servidor de nomes. No lado de DNS e e-mail, habilite DNSSEC em domínios críticos, use CAA para limitar quais CAs podem emitir certificados e configure SPF/DKIM/DMARC (p=reject) em todos os domínios de envio — defina domínios não remetentes para rejeitar e-mail explicitamente também, para prevenir spoofing.

Monitore continuamente para mudanças de registro DNS, delegação de servidor de nomes e emissão anômala no log de Transparência de Certificados, usando infraestrutura de monitoramento que não dependa do domínio que está sendo monitorado. Documente seu processo de tratamento para sequestro de domínio e transferência não autorizada, pratique-o anualmente e defina avisos de expiração em camadas mais renovação automática para que um domínio vencido não se torne um ponto de entrada.

Identidade e contas são o ponto de entrada para quase todo movimento lateral. Um inventário completo de contas organizacionais, mais um padrão rigoroso de MFA, importa mais do que qualquer defesa de ponto único.

Comece com um inventário de contas: registre cada conta organizacional — mídias sociais, e-mail, SSO/IdP, registrador, plataformas de custódia, repositórios de código, raiz de nuvem, principais SaaS — com um proprietário claro e revise-as regularmente. Aplique MFA resistente a phishing com chaves de hardware FIDO2/WebAuthn em contas de alto privilégio e nunca confie em SMS ou voz como fator primário — troca de SIM, SS7 e phishing por voz conseguem contorná-los. Esta é a defesa mais eficaz contra tomada de conta.

Aplique um gerenciador de senhas com senhas fortes e únicas, proíba logins compartilhados e restrinja e-mail de recuperação e telefone ao domínio organizacional — mantenha códigos de recuperação em armazenamento seguro, não em e-mail pessoal ou na nuvem. Quando alguém sai, revogue todos os seus acessos em 24 horas e rotacione quaisquer credenciais compartilhadas que eles tocaram, e continue executando monitoramento comportamental e de vazamento de credenciais em contas de alto privilégio enquanto estiverem ativas.

Por Que a Arquitetura de um Agente de IA É Insegura por Design

Empresas de pagamento usam cada vez mais ferramentas de IA e Agentes para aumentar a eficiência de desenvolvimento e operacional — mas isso abre uma nova superfície de ataque que, mal gerenciada, ameaça diretamente os fundos.

Aqui está a parte fácil de ignorar: um Agente de IA não é apenas um modelo que responde perguntas. É uma máquina que pode ler conteúdo externo, chamar ferramentas, manter credenciais e executar ações. A raiz do risco é que ele trata texto lido de conteúdo não confiável como instruções a serem executadas.

Isso significa que um invasor não precisa de nenhuma vulnerabilidade e nenhuma conta roubada. Esconder uma única frase em um documento, uma página da web, um comentário de código ou uma descrição de PR pode sequestrar o comportamento do Agente para vazar dados ou realizar ações não autorizadas. Isso é chamado de injeção de prompt, e em 2026 foi demonstrado que escala diretamente para execução remota de código — a Microsoft demonstrou um único prompt lançando um programa na máquina que executa um Agente, e GitHub Copilot, Cursor e infraestrutura MCP cada um divulgou vulnerabilidades de RCE classificadas com CVSS 9.6 ou superior.

Fica pior para qualquer coisa privilegiada. Um Agente de desenvolvimento ou operações herda por padrão o acesso a arquivos, privilégios de shell e chaves de banco de dados de seu operador. Um estudo de 2026 cobrindo agentes de codificação mainstream descobriu que todos podiam ser quebrados por injeção de prompt, com uma taxa de sucesso de ataque adaptativo acima de 85%. Qualquer Agente que processe entrada não confiável deve ser tratado como um potencial insider com suas credenciais — e a cadeia de suprimentos é um elo de alto risco também: em março de 2026, uma dependência de gateway de IA envenenada ficou em um repositório público por 3 horas e foi baixada quase 47.000 vezes.

Como Obter Eficiência de Agente de IA Sem Perder o Controle dos Fundos

A abordagem é colocar o Agente sob as mesmas restrições que você aplicaria a código não confiável, em cinco controles:

• Execução isolada — execute a execução de ferramentas do Agente em um sandbox, para que a injeção de prompt não possa alcançar o shell real, chaves de produção ou o ambiente de assinatura.
• Menor privilégio — conceda às ferramentas do Agente, chaves de banco de dados e serviços MCP apenas o mínimo necessário para uma única operação, nunca uma credencial de "acesso total".
• Um portão humano em operações de fundos — para qualquer coisa envolvendo transferências, assinatura ou mudanças de privilégio, o Agente só pode propor, nunca executar automaticamente. A aprovação humana independente se aplica aqui também, o mesmo princípio por trás da verificação de assinatura abordada acima.
• Separe instruções confiáveis de dados não confiáveis — faça isso no nível da arquitetura e não espere que o modelo "os distinga por conta própria".
• Bloqueio da cadeia de suprimentos — aplique as mesmas verificações de fixação de versão e proveniência às dependências relacionadas a IA que você aplica aos seus repositórios de código regulares.

Essas restrições não precisam permanecer teóricas. O Web3 Companion de código aberto da BlockSec é uma implementação de referência de uma carteira agêntica segura (licença MIT, prévia de pesquisa). Ele permite que um Agente de IA ajude um usuário a preparar transações on-chain mantendo chaves privadas e autorização final completamente fora do alcance do Agente. Seu modelo de ameaça trata o próprio Agente como não confiável — o sistema inteiro precisa garantir que mesmo um Agente totalmente comprometido não possa mover os fundos do usuário.

A arquitetura repousa em três pontos. Isolamento de chave significa que apenas um módulo de assinatura independente (um processo Go separado) pode tocar a chave privada — o Agente obtém um ID de intenção de transação, pode solicitar uma assinatura, mas nunca vê uma chave. As chaves são armazenadas com criptografia de envelope (AWS KMS ou AES-256 local), e o texto simples existe na memória apenas pelo instante da assinatura, então é zerado.

Antes da transmissão, uma transação passa por quatro camadas em sequência, cada uma assumindo que a anterior falhou: simulação de transação (decodificação de calldata, previsão de reversões), pontuação de risco de contraparte, limites de política rígida em Go puro (cap por transação, orçamento diário, lista de permissões — nenhuma das quais o Agente pode modificar) e, finalmente, confirmação humana por passkey, uma impressão digital WebAuthn ou varredura facial que um ataque somente de software não pode falsificar. Chave, política e passkey formam três fronteiras de confiança independentes, de modo que violar uma deixa as outras duas intactas.

Um Agente de IA pode genuinamente aumentar a eficiência, mas não deve ter controle exclusivo sobre fundos e assinatura. Coloque-o em um sandbox com menor privilégio como assistente e deixe que humanos tomem a decisão final sobre fundos e assinatura.

Juntando Tudo

O gerenciamento de chaves não é uma decisão — são três, tomadas de forma independente e depois combinadas: quem precisa assinar, onde a chave ou compartilhamento reside fisicamente e quanto está exposta à internet. Acertar a combinação para cada camada de fundos, apoiá-la com infraestrutura de assinatura endurecida e mantê-la unida com os padrões operacionais acima é como a BlockSec enquadra o fechamento das lacunas por trás da maioria dos incidentes relacionados a chaves e assinaturas de 2025-2026. E porque a superfície agora se estende além das chaves — para APIs, pessoas, fornecedores, pipelines de código, domínios, identidade e Agentes de IA — cada um desses precisa do mesmo tratamento: assuma que a camada anterior falhou e mantenha um humano no ciclo onde quer que os fundos possam se mover.

Para o quadro completo de onde o gerenciamento de chaves e a segurança operacional se encaixam ao lado do restante do programa de conformidade de um sistema de pagamento, baixe nosso playbook de segurança e conformidade de pagamentos cripto (PDF).

Perguntas Frequentes

Qual é a diferença real entre MPC e multisig? Multisig é múltiplas chaves privadas completas, cada uma verificada separadamente na cadeia — transparente, mas custoso e difícil de rotacionar signatários. MPC (assinaturas de limiar) são múltiplos compartilhamentos de chave gerados de forma que nenhuma chave privada completa exista jamais; assinaturas parciais são combinadas fora da cadeia em uma única assinatura — flexível e barato, mas dependente da sua infraestrutura de coordenação.

Shamir Secret Sharing (SSS) é o mesmo que MPC? Não. SSS divide uma chave privada completa já existente em pedaços e reconstrói a chave completa na memória para assinar, o que torna o momento de reconstrução um ponto único de falha. O MPC real (TSS) nunca reconstrói uma chave privada completa — cada parte apenas computa uma assinatura parcial a partir de seu próprio compartilhamento.

Qual é a diferença entre um TEE e um HSM? Um TEE (como Intel SGX, AWS Nitro ou Apple Secure Enclave) é uma região isolada e criptografada em uma CPU de uso geral que pode executar código arbitrário, incluindo protocolos MPC — forte isolamento lógico, mas resistência física à adulteração e certificação mais fracas do que um HSM. Um HSM é hardware dedicado resistente à adulteração onde a chave privada é gerada internamente, marcada como não exportável e fisicamente não pode sair.

O que é uma carteira morna e como ela é diferente de quente ou fria? Uma carteira morna está online, mas mantém a chave privada isolada em um ambiente protegido (um serviço de assinatura dedicado ou HSM) e requer um humano no ciclo de assinatura, usada para liquidação operacional do dia a dia — situando-se entre uma carteira quente sempre online e automatizada e uma carteira fria totalmente offline e air-gapped.

O que a BlockSec recomenda especificamente para armazenamento frio? Depende da capacidade operacional on-chain da equipe: equipes com operações on-chain maduras podem usar multisig de contrato (ex.: 3-de-5 do Safe) com a chave de cada signatário em um HSM ou carteira de hardware; equipes que desejam menos complexidade operacional podem usar assinatura de limiar MPC com compartilhamentos em um TEE mais um co-signatário terceirizado independente para verificações de segurança de transação.

O que é blind signing e por que é perigoso? Blind signing ocorre quando uma interface de assinatura mostra apenas um hash de calldata em vez do que a transação realmente faz. O signatário não pode verificar o significado real do que está aprovando, o que foi uma causa direta do incidente Bybit.

Agentes de IA podem ser confiados com operações de pagamentos cripto? Não com controle exclusivo. Um Agente de IA só deve ter permissão para propor operações de fundos, nunca executá-las automaticamente — transferências, assinatura e mudanças de privilégio precisam de aprovação humana independente, com o Agente rodando em um sandbox com menor privilégio.

O que é injeção de prompt e quão sério é? Injeção de prompt esconde instruções em conteúdo não confiável — um documento, página da web, comentário de código ou descrição de PR — que sequestra o comportamento de um Agente de IA. Em 2026, escalou para execução remota de código em vulnerabilidades divulgadas que afetam ferramentas de codificação mainstream, classificadas com CVSS 9.6 ou superior.

Qual é a defesa mais eficaz contra tomada de conta? MFA resistente a phishing — aplicar chaves de hardware FIDO2/WebAuthn em contas de alto privilégio e nunca depender de SMS ou voz como fator primário, já que troca de SIM, SS7 e phishing por voz conseguem contornar esses canais.