O que a investigação afirma sobre CARLIY0S
Em 21 de outubro de 2026, a Straiker publicou uma investigação sobre CARLIY0S, um sistema que, segundo a empresa, teria sido usado por operadores associados ao CyberCartel para coordenar atividades contra mais de 400 alvos financeiros na América Latina. Entre os tipos de organizações visadas, a investigação menciona bancos e provedores de pagamento. Esse número se refere a alvos; não demonstra que mais de 400 instituições tenham sido invadidas com sucesso.
Segundo a Straiker, a investigação se baseou no acesso a uma cópia de sistemas e materiais de trabalho atribuídos ao grupo, incluindo arquivos de configuração, scripts, infraestrutura e uma base de dados chamada FinancialSoft. Isso constitui evidência direta do que havia naquele ambiente, mas o relatório não apresenta uma verificação independente de cada ataque nem identifica as organizações afetadas. Por isso, as atribuições e o alcance devem ser entendidos como conclusões da empresa, e não como confirmação pública de responsabilidade ou de danos em cada instituição.
A cobertura do caso também destaca essa limitação: os nomes dos bancos não foram divulgados, e não é possível determinar publicamente quais instituições da região teriam sofrido uma intrusão. As fontes fornecidas tampouco apresentam uma lista verificável que associe cada um dos mais de 400 alvos a um acesso bem-sucedido, à extração de dados ou a perdas financeiras.
Uma cadeia de ferramentas, não um único agente autônomo
A Straiker apresenta CARLIY0S como uma estrutura distribuída que combinava operadores humanos, scripts, ferramentas de segurança e modelos comerciais. O sistema teria usado o PentAGI, uma estrutura para testes automatizados de segurança, além de componentes que permitiam compartilhar informações e delegar tarefas. É mais preciso descrevê-lo como uma operação assistida e coordenada por IA do que como um agente que atuou sozinho.
O relatório atribui funções distintas a vários modelos. Claude aparece em uma configuração de agentes com tarefas de análise, geração de código ou avaliação de alternativas; um modelo seria usado para coordenar atividades no Cursor. Grok é associado a tarefas de coleta e classificação de informações, enquanto Kimi aparece em configurações de contingência. A documentação de configuração, por si só, não comprova que cada modelo tenha sido executado com sucesso em todas as etapas ou contra todos os alvos.
O relatório também descreve ferramentas convencionais para automatizar interações na web, analisar tráfego e sincronizar dados entre máquinas. Os modelos poderiam contribuir com análises ou sugestões, mas o acesso aos sistemas e a execução dependiam de ferramentas, credenciais, scripts e infraestrutura. Portanto, não é possível inferir a capacidade efetiva de cada etapa apenas pela existência de uma configuração de IA.
Funções atribuídas a cada componente
A tabela resume o que a Straiker afirma ter observado nos materiais atribuídos ao sistema; ela não demonstra que todas as funções tenham sido concluídas em todos os ataques.
| Componente | Função descrita | Limite das evidências |
|---|---|---|
| Claude | Análise, debate de opções e coordenação de tarefas em configurações com vários agentes. | Os arquivos de configuração não comprovam que tenha sido acionado com sucesso em cada operação. |
| Grok | Mineração ou coleta de dados que alimentariam a FinancialSoft. | A existência de cinco “Grok miners” não comprova a origem ou o uso de cada registro. |
| Kimi | Modelo alternativo ou de contingência em determinados fluxos. | Uma configuração de contingência não demonstra que tenha sido ativada em cada caso. |
| Scripts e ferramentas | Automação da navegação, do tratamento de dados e da conexão com outros sistemas. | A presença desses componentes de software não confirma, por si só, o sucesso de uma intrusão. |
| Operadores humanos | Definição de objetivos e supervisão da operação descrita. | A investigação não quantifica com precisão a intervenção humana em cada etapa. |
O que os registros mostram — e o que não permitem concluir
Na cópia que a Straiker afirma ter examinado, a FinancialSoft continha 4.493 registros. A descrição inclui dados de contas financeiras, endereços de e-mail, senhas, chaves de API e outros materiais sensíveis. Entre as contagens divulgadas estão 2.911 endereços de e-mail e 903 números de conta. Esses números são atribuídos ao inventário examinado; não medem quantas pessoas foram afetadas nem confirmam que todos os dados eram válidos ou tenham sido usados.
O relatório também menciona credenciais relacionadas à infraestrutura de pagamentos, incluindo informações que poderiam estar ligadas ao SPEI, o sistema mexicano de pagamentos interbancários. A exposição de credenciais pode aumentar o risco de acessos não autorizados ou fraude, mas não basta para demonstrar que transferências foram realizadas, que contas de clientes foram acessadas ou que as credenciais ainda estavam ativas.
A empresa afirma ter anonimizado as organizações e sanitizado materiais sensíveis na publicação. Assim, o leitor não pode verificar a identidade das instituições nem confirmar publicamente o estado de cada conta ou chave mencionada. A quantidade e a natureza dos registros justificam atenção defensiva, mas não devem ser convertidas em uma afirmação de prejuízos concretos.
Resposta dos provedores e alcance das medidas
A Straiker afirma ter compartilhado indicadores relevantes com os provedores de modelos. Segundo a empresa, a Anthropic revogou uma credencial comprometida usada para acessar o Claude. A Straiker também informou que a xAI havia sido notificada e estava examinando a atividade associada a cinco “Grok miners”. Essas medidas se referem ao acesso a serviços específicos; não comprovam que toda a infraestrutura atribuída ao grupo tenha sido desativada.
O material fornecido não documenta medidas concretas adotadas por bancos latino-americanos para bloquear agentes de IA, nem identifica instituições que estejam implementando controles específicos. Portanto, não é possível afirmar que bancos da região tenham estabelecido um bloqueio geral a agentes de terceiros por causa deste caso. Essa questão deve ser distinguida das restrições preventivas descritas em outros mercados, que não comprovam uma resposta das instituições latino-americanas.
Do ponto de vista defensivo, o caso aponta áreas que as instituições podem revisar: credenciais expostas, permissões de API, acessos a portais administrativos, atividades incomuns e conexões com serviços externos. São frentes de defesa pertinentes diante de riscos de acesso e automação, mas não representam uma garantia de detecção nem uma lista de medidas cuja implementação tenha sido confirmada nos bancos envolvidos.
O que revisar diante de uma possível exposição de credenciais
Estas etapas são critérios gerais de resposta; as fontes disponíveis não confirmam que uma instituição específica as tenha aplicado neste caso.
- 01Identificar quais credenciais ou chaves são consideradas expostas e a quais sistemas elas dão acesso.
- 02Revogar ou substituir as credenciais afetadas e verificar se houve acessos ou usos incomuns.
- 03Examinar registros de autenticação, atividade de API e alterações nos sistemas conectados.
- 04Limitar as permissões ao necessário e separar funções de consulta daquelas que permitem executar operações.
- 05Acompanhar os provedores e serviços externos envolvidos na resposta.
O que muda — e o que não muda — para a segurança da IA
A relevância do caso não depende de um modelo ter atuado com autonomia geral. A investigação descreve uma combinação de modelos comerciais, ferramentas automatizadas, scripts, infraestrutura compartilhada e operadores. Esse conjunto pode ajudar a organizar tarefas e ampliar o alcance de uma operação, mas o relatório não permite concluir que a IA tenha substituído os atacantes ou escolhido e executado sozinha cada ação.
As evidências apresentadas pela Straiker constituem um estudo de caso baseado em materiais que a empresa atribui ao ambiente de trabalho dos operadores. Por si só, não são uma medição independente da frequência de ataques com agentes, nem comprovam que a mesma arquitetura produza resultados equivalentes em outros grupos ou setores. A presença de uma configuração de modelo também não prova que o modelo tenha gerado uma intrusão bem-sucedida.
A conclusão prática é mais restrita: instituições financeiras devem considerar que ferramentas de IA podem fazer parte de fluxos de trabalho ofensivos que já utilizam software e infraestrutura tradicionais. A resposta não se limita a bloquear um modelo: também envolve proteger credenciais, limitar permissões, observar o comportamento de contas e APIs e verificar incidentes com registros técnicos. As fontes fornecidas não permitem atribuir uma nova medida regulatória ao caso nem descrever uma política comum dos bancos latino-americanos.
Questões em aberto
- As organizações visadas não foram identificadas publicamente, por isso não é possível verificar quais sofreram acessos bem-sucedidos.
- Não há uma correspondência verificável entre os mais de 400 alvos e o número de instituições invadidas, os dados extraídos ou os prejuízos.
- A presença de configurações de modelos nos materiais atribuídos ao grupo não comprova que cada modelo tenha sido executado com sucesso em todas as etapas.
- As fontes fornecidas não confirmam quais medidas específicas os bancos latino-americanos implementaram para detectar ou bloquear agentes de IA.
Continue a explorar
Fontes consultadas
Correções e transparência
Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.
Propor uma correção