Execution Is the New Attack Surface: Survivability-Aware Agentic Crypto Trading with OpenClaw-Style Local Executors

Each language version is independently generated for its own context, not a direct translation.

Imagine que você construiu um carro de corrida incrível, dirigido por um piloto de Inteligência Artificial (IA) super inteligente. Esse piloto consegue ler notícias, analisar o mercado e tomar decisões de compra e venda em milissegundos. O problema é que, para o carro andar, você precisa entregar as chaves a ele.

Agora, imagine que esse piloto não é apenas um funcionário, mas um sistema que pode baixar "peças" e "habilidades" de uma loja online (como baixar um aplicativo no celular). Se alguém mal-intencionado colocar um vírus nessa loja, ou se o piloto ler um bilhete falso dizendo "venda tudo agora!", ele pode destruir sua conta financeira em segundos.

Este artigo, escrito por pesquisadores da True Trading e Inc4.net, apresenta uma solução para esse caos: o SAE (Execução Consciente da Sobrevivência).

Aqui está a explicação simples, usando analogias do dia a dia:

1. O Problema: O "Piloto" Está Descontrolado

Antes, a gente achava que o maior risco da IA era ela dar uma resposta errada (como dizer que 2+2=5). Mas no mundo do dinheiro, o risco real é a ação.

A Analogia: Imagine que você deixou um robô no controle do seu cofre. Se o robô ler um bilhete falso dizendo "abra o cofre e jogue o dinheiro na rua", ele vai fazer isso.
O Cenário: Com o surgimento de "Skills" (habilidades instaláveis) e sistemas como o OpenClaw, os robôs podem baixar novas ferramentas de terceiros. Se uma dessas ferramentas for maliciosa ou se o robô for enganado por um texto, ele pode fazer transações arriscadas demais, usar alavancagem (dinheiro emprestado) perigosa ou vender tudo no momento errado, liquidando sua conta.

2. A Solução: O "Guarda-Costas" (SAE)

Os autores propõem colocar um Guarda-Costas entre o cérebro do robô (que decide o que fazer) e o motor do carro (que executa a ordem na bolsa de valores).

Esse Guarda-Costas não tenta adivinhar se o robô está "certo" ou "errado" em sua lógica. Ele apenas verifica: "Isso é seguro para o cofre?"

O SAE funciona como um filtro de segurança que faz três coisas principais:

A. O "Filtro de Confiança" (O Chefe de Segurança)

O SAE pergunta: "Quem pediu essa ordem?"

Se a ordem veio de uma habilidade (skill) que você baixou de um lugar duvidoso, o Guarda-Costas fica mais rigoroso.
Se o robô está sob ataque (tentativa de invasão), o Guarda-Costas reduz o poder do robô automaticamente.
Analogia: É como um porteiro de boate. Se você chega com um amigo que ele não conhece (uma skill nova), ele não deixa você entrar com a chave mestra do cofre. Ele só deixa você entrar com uma chave pequena.

B. O "Limitador de Velocidade" (Orçamento e Freios)

Mesmo que o robô queira fazer uma aposta gigante (comprar muito Bitcoin com muito dinheiro emprestado), o SAE impõe limites.

Ele define um teto de velocidade (alavancagem máxima).
Ele define um teto de gastos (quanto do seu dinheiro pode ser usado).
Se o mercado está muito agitado (como uma tempestade), ele reduz ainda mais a velocidade, como um piloto que freia antes de uma curva perigosa.
Analogia: É como um limitador de velocidade no carro de um adolescente. Mesmo que ele pise no acelerador até o fundo, o carro nunca passa de 80 km/h.

C. O "Pausa para Pensar" (Cooldown)

Se o robô começar a tentar fazer muitas ordens muito rápido (como se estivesse em pânico ou sendo atacado), o SAE impõe uma pausa.

Analogia: É como um "respiro" forçado. Se você tentar apertar o botão de "comprar" 100 vezes em um segundo, o sistema bloqueia e diz: "Espere 2 minutos antes de tentar de novo". Isso evita que um erro ou um ataque destrua tudo em frações de segundo.

3. O Resultado: Sobrevivência em vez de Ganho Rápido

Os autores testaram isso usando dados reais da Binance (uma grande bolsa de criptomoedas) com Bitcoin e Ethereum.

Sem o Guarda-Costas (NoSAE): O robô, quando enganado ou em momentos de pânico, quase quebrou a conta (perda de 46% do dinheiro).
Com o Guarda-Costas (SAE): Mesmo quando o robô tentou fazer coisas perigosas, o Guarda-Costas o impediu. A perda máxima caiu para apenas 3%.

A grande sacada: O SAE não tenta fazer o robô ganhar mais dinheiro (não é um "gênio do mercado"). O objetivo dele é impedir que o robô se mate. Ele garante que, mesmo que o robô cometa um erro grave ou seja hackeado, você não perda tudo.

Resumo em uma frase

O SAE é como colocar um cinto de segurança e um airbag em um carro de corrida dirigido por uma IA: ele não faz o carro ir mais rápido, mas garante que, se o motorista (a IA) perder o controle ou for enganado, você sobrevive ao acidente com o dinheiro intacto.

Isso é crucial porque, no mundo das criptomoedas, um erro de execução pode apagar sua conta em segundos, e a única defesa real é ter um sistema que não confia cegamente no que a IA diz, mas verifica se a ação é segura antes de acontecer.

Each language version is independently generated for its own context, not a direct translation.

Título: A Execução é a Nova Superfície de Ataque: Trading Agente Cripto com Consciência de Sobrevivência e Executors Locais no Estilo OpenClaw

1. O Problema: A Mudança da Superfície de Ataque

O artigo identifica uma mudança crítica na segurança de agentes de IA: o foco de segurança está migrando da precisão das respostas ("respostas erradas") para as consequências da execução ("execução induzida por perdas").

Contexto: Com o advento de stacks de agentes estilo OpenClaw (que interceptam intenções de LLMs através de ferramentas e gateways) e marketplaces de habilidades como skills.sh, os agentes agora possuem capacidades de execução privilegiadas no mundo real.
Ameaça: A cadeia de suprimentos de habilidades (instalação de skills de terceiros) e a natureza não confiável de prompts de entrada transformam a execução em um vetor de ataque. Um prompt malicioso, uma skill comprometida ou manipulação narrativa podem levar a ordens de trading reais, irreversíveis e financeiramente catastróficas.
Vulnerabilidade Específica: Em mercados de futuros perpétuos de criptomoedas, erros de execução (como alavancagem excessiva, tolerância a slippage alta ou frequência de ordens) são amplificados pelas mecânicas de margem e taxas de financiamento, podendo levar a liquidações rápidas e perdas de cauda (tail losses) severas.
Hipótese Central: Deve-se assumir que a intenção upstream (do agente) e as habilidades instaladas são não confiáveis. A segurança não pode depender apenas do modelo de linguagem, mas deve ser imposta na "última milha" antes da execução na exchange.

2. Metodologia: Execução com Consciência de Sobrevivência (SAE)

Os autores propõem o SAE (Survivability-Aware Execution), um middleware de segurança projetado para ser implantado entre o motor de estratégia (LLM ou não) e o executor da exchange.

Arquitetura e Contrato de Execução:
O SAE opera através de um contrato de execução explícito com três componentes principais:

ExecutionRequest: A intenção bruta do agente (símbolo, alavancagem, notional, etc.).
ExecutionContext: O estado atual da conta, do mercado (volatilidade, regime) e, crucialmente, um Estado de Confiança ( $z_t$ ) que avalia a proveniência da habilidade e alertas de injeção.
ExecutionDecision: A decisão final do SAE: ALLOW (permitir), LIMIT (limitar/constranger) ou BLOCK (bloquear).

Mecanismos de Defesa (Invariáveis Não Bypassáveis):
O SAE impõe restrições que não podem ser contornadas pelo agente:

Orçamento de Exposição Baseado em Projeção: Ações solicitadas são projetadas matematicamente para um espaço viável de orçamento ( $F(B)$ ). Se um agente pedir 5x de alavancagem, o sistema projeta isso para o limite permitido (ex: 1x) sem rejeitar a intenção, apenas ajustando o parâmetro.
Restrições Temporais: Cooldowns (tempos de espera) e limites de taxa de ordens para evitar flooding ou churn rápido.
Ajuste Condicionado à Confiança: Os orçamentos são dinamicamente reduzidos se o estado de confiança for baixo (ex: habilidade de terceiros não verificada, alerta de injeção de prompt) ou se o regime de mercado for extremo.
Regras "Fora de Escopo" (Out-of-Scope): Definição estrita de ferramentas, mercados e símbolos permitidos. Qualquer violação é bloqueada ou rotulada.

Medição de Segurança: O "Delegation Gap" (DG):
Para quantificar a segurança, os autores definem o Delegation Gap (DG) como a perda esperada introduzida por ações executáveis que estão fora do escopo intencional do operador.

Utiliza uma Especificação de Política Intencional ( $S_t$ ) estruturada (não apenas linguagem natural) para definir o que é permitido.
Calcula métricas como taxa de ações fora de escopo e contribuição de perda dessas ações.

3. Contribuições Principais

Protocolo de Medição Operacional do DG: Uma metodologia para rotular deterministicamente ações como "fora de escopo" e medir o dano associado, permitindo testes reprodutíveis de segurança.
Contrato de Execução SAE: Um padrão de middleware compatível com OpenClaw e ecossistemas de habilidades, que transforma a segurança de "promessa" em "código executável" na última milha.
Algoritmos de Aplicação Robustos: Implementação de projeção baseada em orçamento e limites temporais que garantem limites teóricos de perda em um passo, independentemente da dinâmica de retorno do mercado.
Avaliação Reproduzível: Um relatório completo de backtesting em dados reais da Binance (BTCUSDT/ETHUSDT) com instrumentação de ataques, demonstrando ganhos estatisticamente significativos.

4. Resultados Experimentais

O estudo foi realizado em um replay offline de dados da Binance (futuros perpétuos USD-M, 15min, set-dez 2025), comparando o SAE contra um cenário sem proteção (NoSAE) e um sistema de risco estático tradicional (StaticOMS).

Principais Métricas de Desempenho (vs. NoSAE):

Drawdown Máximo (MDD): Redução drástica de 0.4643 para 0.0319 (redução de 93.1%).
Risco de Cauda (CVaR 0.99): A magnitude da perda de cauda caiu de $4.025 \times 10^{-3} $para$ \approx 1.02 \times 10^{-4}$ (redução de ~97.5%).
Perda por Delegation Gap (DG): Redução de 0.647 para 0.019 (redução de ~97.0%), indicando que ações maliciosas ou erradas deixaram de dominar as perdas.
Sucesso de Ataque (AttackSuccess): Redução de 1.00 (todas as tentativas de ataque passaram) para 0.728 (27.2% de redução), com Zero False Blocks (nenhuma ordem legítima foi bloqueada indevidamente nesta configuração).
Overhead de Latência: O SAE introduz uma latência mínima (de ~1.3ms para ~10ms no modo completo), um custo aceitável pela segurança.

Validação Estatística:
Testes de dependência (bootstrap de blocos, teste de Wilcoxon pareado) confirmaram que as melhorias na sobrevivência e na redução de ataques são estatisticamente detectáveis e não fruto de ruído aleatório.

5. Significado e Conclusão

O artigo estabelece que, na era dos agentes autônomos conectados a mercados financeiros, a segurança não pode ser apenas uma camada de "alinhamento de modelo".

Mudança de Paradigma: A segurança deve ser tratada como um problema de execução e sobrevivência. O SAE atua como um "cinto de segurança" que assume que a intenção do agente pode estar corrompida e impõe limites físicos e lógicos antes que qualquer ordem seja enviada à exchange.
Resiliência da Cadeia de Suprimentos: Ao tratar a instalação de habilidades de terceiros como um evento de alto risco e condicionar os orçamentos de trading à proveniência dessas habilidades, o SAE mitiga riscos que modelos puramente baseados em texto não conseguem ver.
Viabilidade Prática: Os resultados mostram que é possível obter ganhos massivos em sobrevivência (redução de perdas catastróficas) sem sacrificar a usabilidade (zero falsos positivos na configuração testada) ou a rentabilidade nominal em regimes normais.

Em suma, o SAE redefine a segurança de trading agêntico, propondo que a última milha de execução deve ser um contrato de segurança não bypassável, transformando a segurança de uma garantia qualitativa em uma métrica de sistema quantificável e reprodutível.