Fraud prevention combines rules, AI and behavioral analytics to stop scams, reduce false declines and keep automated decisions explainable through human review.
Recentemente, fizemos uma postagem sobre tokenomics e ataques de “negação de carteira” (denial of wallet): um novo tipo de ataque DDoS que busca gerar gastos excessivos com tokens de IA. Antes de começarem a proteger os processos de IA de seus colegas contra essa nova ameaça, os profissionais de segurança precisam considerar que as próprias atividades do departamento de segurança da informação também podem ser alvo desse tipo de ataque. Como as equipes de segurança estão testando e implementando ativamente diferentes formas de automação baseada em IA, a ameaça de interferência externa destinada a paralisar o sistema de defesa pode afetar diretamente seus próprios processos e tecnologias.
A Elastic estima que, conforme a arquitetura do SOC baseado em agentes, a triagem de um único alerta de um host pode custar US$ 0,69 com um conjunto de agentes especializados ou US$ 3,42 com um agente de uso geral capaz de executar 14 tipos diferentes de tarefas.
No entanto, esses valores médios ocultam uma enorme variação nos custos. A qualquer momento, o processamento inicial de um alerta simples (como, por exemplo, mil tokens) pode desencadear uma investigação sobre o processamento de milhões de entradas de registro, chamadas de API, e de outros dados relacionados, consumindo milhões de tokens em questão de minutos.
A própria Elastic reconhece que utiliza o modelo Claude Sonnet 4.6 em seu SOC. Isso levanta uma questão imediata: o que acontece quando o orçamento se esgota ou os filtros de segurança do modelo são acionados? No pior cenário, o SOC baseado em IA aciona uma “orquestra de agentes” para investigar eventos suspeitos que se assemelham a movimentos laterais na infraestrutura. O agente faz uma chamada à API da Anthropic, mas o orçamento mensal do departamento já se esgotou, e a API retorna erros. A investigação fica paralisada, e a equipe só percebe o problema meio dia depois. Além disso, se os “filtros de segurança” de um grande provedor de IA, que estão em constante mudança, classificarem as solicitações do SOC como maliciosas, o mesmo poderá ocorrer mesmo que ainda haja orçamento disponível. Isso ficou evidente na experiência da Hugging Face ao investigar a invasão de sua infraestrutura pela OpenAI.
É claro que um invasor tem interesse em provocar esse tipo de situação. O invasor pode aumentar diretamente os custos da equipe de defesa ao inserir prompts maliciosos nos dados que ela processa, como registros DNS TXT, cabeçalhos HTTP, comentários no código e nomes de arquivos, sabendo que esses prompts serão analisados pelos sistemas de segurança da informação. No ataque GhostJacking, registros do WAF são usados como vetor para a injeção de prompts. Em outro método, apresentado em um estudo acadêmico, pesquisadores conseguiram atacar as própriasproteções de segurança dos LLMs, aumentando a latência das solicitações em 148 vezes e o consumo de tokens em 63 vezes. Em teoria, o sistema continua funcionando normalmente, mas o processamento dos alertas fica muito mais lento e os custos associados aumentam significativamente.
O perigo das falhas silenciosas
Em sistemas baseados em agentes, o esgotamento do orçamento nem sempre gera um erro explícito com a mensagem “limite de solicitações excedido” e um alerta imediato aos responsáveis. Em determinadas configurações, pode ocorrer degradação silenciosa: quando uma solicitação ao modelo excede o tempo limite, o sistema muda automaticamente para um modelo mais barato, reduzindo a qualidade das respostas e interrompendo a execução de subagentes e tarefas periódicas. Enquanto isso, a equipe de segurança pode passar horas acreditando que tudo continua funcionando normalmente.
Como controlar os custos da IA na cibersegurança
Gerenciar os custos, é claro, não se resume a “evitar gastos excessivos”. O setor já caiu nessa armadilha ao implementar soluções SIEM: quando as empresas passaram a pagar de acordo com o volume de telemetria coletada, começaram a restringir seletivamente a coleta de registros, nem sempre de forma eficaz. Como resultado, surgiram pontos cegos na detecção de ameaças. O mesmo pode acontecer com os tokens, mas de forma mais rápida e em maior escala. Uma política de redução de custos mal planejada pode comprometer a profundidade das investigações e a qualidade das respostas. Sem uma política desse tipo, a decisão sobre o que cortar ficará a cargo do analista de plantão às 3h da manhã, e não do arquiteto ou do CISO durante a fase de projeto do sistema. Outra possibilidade é que o próprio fornecedor do sistema imponha limites automaticamente.
Alguns princípios simples ajudam a evitar aumentos previsíveis de custos e a gerenciar melhor situações realmente imprevisíveis.
Não recorra à IA para analisar informações que podem ser verificadas por meio de consultas convencionais. Tarefas repetitivas e previsíveis devem continuar sendo executadas da maneira tradicional, com regras e consultas a dados. Essas regras e consultas podem ser desenvolvidas com o auxílio da IA, mas devem funcionar de maneira determinística. O modelo deve ser usado apenas quando for realmente necessário avaliar uma situação ambígua.
Estabeleça limites rigorosos e emita alertas imediatos aos usuários sempre que forem ultrapassados. Combine diferentes tipos de limite, como limites por tarefa, limites diários e assim por diante. Os alertas de violação dos limites devem chegar imediatamente tanto aos analistas de plantão quanto aos responsáveis por todo o sistema.
Defina com antecedência o que fazer quando um limite for atingido. A decisão entre interromper o processo para economizar, mesmo que isso reduza o controle, ou continuar e arcar com os custos deve ser tomada antes que ocorra um incidente.
Restrinja as permissões dos agentes e as ferramentas às quais eles têm acesso. Quanto mais restrito o conjunto de ações, melhor será seu desempenho em tarefas específicas. Isso também reduz as oportunidades de elevar os custos e a probabilidade de exploração por agentes externos.
Examine rigorosamente os dados externos não confiáveis. Solicitações, consultas, mensagens, comentários e campos técnicos de texto livre, como registros DNS, cabeçalhos HTTP e nomes de arquivos, podem servir tanto para injetar prompts maliciosos quanto para sobrecarregar deliberadamente o sistema. Limite o tamanho desses dados e monitore a carga de trabalho que geram.
Para evitar interrupções causadas por provedores externos e manter o controle total sobre os dados da organização, avalie a possibilidade de usar modelos locais implantados na própria infraestrutura, pelo menos nas atividades de segurança da informação. Embora não sejam os modelos mais avançados, sua especialização e seu ajuste fino com dados da empresa podem garantir bom desempenho e reduzir o risco de falhas inesperadas.
Em arquiteturas mais complexas, os LLMs podem ser divididos em níveis de gravidade. A primeira linha de defesa, responsável por roteamento, filtragem de ruído e enriquecimento de dados é tratada localmente por modelos compactos. Isso reduz significativamente a imprevisibilidade dos custos. O segundo nível conta com um modelo local de maior porte, responsável pelo trabalho analítico principal: correlacionar eventos, testar hipóteses e reconstruir o cenário do incidente. Esse modelo também não gera custos por solicitação, mas tem capacidade limitada, o que pode causar gastos além do orçamento, sobrecargas e acúmulo de eventos em filas. Apenas casos excepcionais e realmente complexos são encaminhados a modelos avançados na nuvem, de preferência com a aprovação explícita de um analista. Nesse modelo, ainda há custos variáveis, mas eles ficam restritos a poucos casos. Cada encaminhamento é uma decisão consciente, e não uma consequência inesperada de um script executado durante a noite.
Na prática, essa abordagem reproduz o modelo clássico de SOC em vários níveis: a primeira linha faz a triagem, e a terceira conduz as investigações. A diferença é que essas funções são desempenhadas por modelos, e não por pessoas.
In Meta commercial terms changes slated to kick in on October 30, the company will shift the liability for any mistakes made by its AI models to its enterprise customers. The new language also makes those IT executives responsible for anything done by a partner or contractor.
The changes also finally put a stake into the heart of robots.txt, with Meta granting itself the right to grab, and use for its own purposes, any content associated with a Meta account.
The language allows Meta to “use automated software such as web scrapers, bots, robots, spiders, crawlers, and user agents and create test credentials to access, index, cache, analyze, collect, retrieve, or crawl the domains, web pages, or URLs, and any content available through them, that are associated with your products or services,” according to the new language on its website on Monday. Meta also wants to be able to “periodically pull updates from such domains, web pages, or URLs in order to provide, develop, improve, research, and maintain advertising and business products including business, commercial and related products to help you create and deliver ads and other commercial content.”
Consultants said the three biggest concerns they had about the changes were the web scraping, data ownership, and AI liability transfer.
Web scraping and data ownership
However, Meta emailed a statement to CIO.com late Monday suggesting that it was rethinking its position on web scraping. Saying that Meta wanted “to clarify” the web scraping changes, Emil Vazques, a Meta public affairs manager, said, “the crawling terms we consolidated only applied to our ads and business products and we’ve clarified that in the terms themselves. It does not change how Meta uses web crawlers. As always, content owners can use robots.txt to signal their preferences. This is not about scraping news sites, and these updates don’t give us new rights that supersede those preferences.”
As of Monday evening, New York time, the proposed document’s wording had yet to be altered to reflect this, but Vazques said that a change was coming soon.
The data ownership issue sets Meta apart from other AI vendors in that it wants to train its models on anything it encounters. Then again, the nature of Meta businesses focuses on advertising and would therefore be expected to seek more data control.
The new proposed phrasing, which Meta could alter before it takes effect later this month, said that using any Meta product grants Meta “a license to content that is covered by intellectual property rights like photos or videos you share, post, or upload on or in connection with our Meta Company Products. That license applies to content you or someone on your behalf, such as your agency that places an ad for you or your service provider that manages your Page content for you, makes available on or in connection with any Meta Company Products. Without limiting anything in our terms and for clarity, Meta may use such content … to provide, develop, improve, research, and maintain Meta Company Products.”
AI liability
But the change that prompted the most raised eyebrows involved AI liabilities.
The proposed language said, “AI features may make mistakes and may not always produce accurate, complete, or suitable results,” and customers “are solely responsible for and assume any and all risks associated with such AI features and any resulting content.”
That AI clause, said Frank Dickson, principal analyst at Dickson Research, “turns accountability upside down. Meta builds the AI features, admits they ‘may make mistakes’ and then assigns ‘any and all risks’ to the business.”
Mike Wilkes, enterprise CISO at Aikido Security, agreed that the move is perplexing.
“The new AI provisions shift substantial responsibility for inaccurate or unsuitable outputs onto customers. That makes no sense,” he said. “As an example, the ASPCA is going to be liable for Meta creating unsuitable results when they ask Meta to create an image of a dog. Only Meta has control of the model being used to create that image. I see a very high flight risk among enterprise customers when platforms impose such onerous terms and conditions around content usage.”
The October 30 date that the US-based Meta chose is ironic. That is the day before Halloween, which is known as mischief night in the US, when children play pranks on their neighbors. Given that, Dickson said, the date for these changes is appropriate: “Meta is handing out the tricks and keeping the treats.”
He added that the data grab is frightening. “What Meta wants is content: what a business posts, uploads, or shares on or in connection with Meta’s products,” he noted. “The trouble is the phrase ‘in connection with,’ which can stretch as far as Meta needs it to. The list of ‘Meta Company Products’ lives on a separate page that Meta can revise at will. The license grows every time that list does.”
And, Dickson noted: “Meta may use the content to ‘provide, develop, improve, research, and maintain’ its products. Those five verbs cover nearly everything a technology company does.”
‘Legal sophistry’
One of the obvious defensive measures for an enterprise is to sever all relations with Meta. But beyond the pragmatic difficulties of doing that, given the powerful market share enjoyed by Facebook, WhatsApp, Instagram and Threads, such a move may not even solve the problem. That is because Meta made other contract changes in July that make Meta licenses “perpetual” and that said, “this license survives termination of these terms by any party for any reason.”
That, said Noah Kenney, principal consultant at Digital 520, means that the “the general content license ends when content is deleted from Meta’s systems,” not when the enterprise ends a contract.
One additional twist to the new language is that Meta had recently tweaked it to no longer explicitly say that it would train it models on enterprise data. But Thomas Randall, a research director at Infotech, said that the wording change made by Meta amounted to legal sophistry. “The revised version drops the word ‘train’ and states that collection is just for developing and maintaining advertising and business products, alongside protecting Meta products’ integrity and security.”
But dropping the word “train” is “not a substantive fix,” he pointed out. “The revised terms are still flexible enough to cover most AI work. When combined with other aspects of the revised terms — continued use equals consent, broad indemnity, AS-IS disclaimer, and Meta’s freedom to discontinue products without notice or liability — this is a one-way street. The difference between ‘train Meta products’ and ‘developing and maintaining Meta products’ is a matter of how you pronounce tomato.”
Could force IT strategy changes
In addition, Aman Mahapatra, chief strategy officer for technology consulting firm Tribeca Softech, stressed that this contract could be an industry admission that robots.txt no longer delivers any meaningful protections. Agentic systems had already made robots.txt close to irrelevant.
“October 30 ends a thirty-year assumption that robots.txt protects what you publish. It never did,” Mahapatra said. “It was a courtesy convention the web agreed to honor, and Meta’s own framing of robots.txt as a place for site owners to register preferences tells you exactly how it will be weighed against a signed contract.”
Mahapatra said the language in the new Meta commercial terms could force a significant change in IT strategy.
“‘On your behalf’ extends the license to whatever your agencies and vendors upload. ‘Associated’ extends the crawl to domains nobody has defined, including the ones where marketing pages sit beside product documentation, research, and investor materials,” Mahapatra said. “Most CIOs cannot tell me how many Meta pages, ad accounts, and WhatsApp numbers carry their brand, because marketing and agencies own them and IT never inventoried them.”
A judge ordered Abdulrahman Alfozan to remain in custody, likening the Saudi government’s offer to secure the former OpenAI engineer’s release to a “blank check.”
In the west the technology comes with at least some effort to provide security and a benign intent – not so from China
There is much to fear from artificial intelligence developed in China and handed to businesses and governments in the west almost free of charge.
Every month Chinese AI developers such as DeepSeek and Xiaomi dispatch the latest versions of their “open-weight” models that allow users to take the core software and use it without paying an expensive ongoing licence.
Whether it was youngsters proving their skills or state sabotage, Europe’s most hacked country was left with a mountain of waste after food began cooking in freezers
Shortly before midnight last Sunday, the digital thermostats controlling hundreds of supermarket cold aisles across France began to flicker and rise.
In a “bizarre and unprecedented” cyber-attack, hackers had remotely overridden the temperature settings on thousands of freezers, fridges and chiller cabinets pushing them from as low as -27C (-16.6F) to well over 50C (122F).
Chatbot prompts reveal the engineer’s alleged efforts to set up a covert listening device days before one was found in a meeting room used by high-level executives.
Google seems to be making a strategic play to control the AI infrastructure layer, not just roll out another shiny new agent.
At its Gemini at Work 2026 event this week, the tech giant unveiled what it calls a “single, universal agent” and API in Gemini that can be kicked off from a simple prompt box. Like other available agents, it is plugged into skills, tools, and enterprise systems, can answer questions, create media, and write and run code, return finished work via of documents, inboxes, and developer environments, and spin up sub-agents to help it do its job.
But Google isn’t just looking to go toe-to-toe with existing offerings, or trying to convince enterprises its models are qualitatively and quantitatively superior, said independent tech analyst Carmi Levy.
“Instead, it’s trying to establish itself as the gatekeeper of the new enterprise operating system, powered by whatever underlying model makes the most sense,” he said.
‘Omnipresent access,’ orchestration capabilities
Google says its Gemini agent works autonomously from a single interface, and can function as a personal assistant or team member, akin to a project manager or analyst. Coworker agents can perform tasks across days, sessions, and shifting responsibilities; they have dedicated identities, and are given their own @agents.company.com emails and persistent storage.
However, Google says, they only have access to specifically-defined data and channels. Enterprise-dictated security, governance, and cost controls are built-in.
“You give it objectives, not instructions,” Google Cloud CEO Thomas Kurian said in his keynote. “Work now starts in the prompt window.”
The agent runs in the cloud and has “omnipresent access,” meaning it can work on nearly any device, including iOS and Android phones or Windows and Mac desktops, he said. It can also be accessed through any channel, including command line interfaces (CLIs), Google Workspace, Microsoft 365, or Slack channels, and when integrated into third-party apps. When needed, it also works as a headless agent, or even without a dedicated user interface.
Working autonomously, the Gemini agent can spin up temporary or job-specific underlying agents and communicate and coordinate workflows with them to orchestrate multi-step tasks. These include parallel and sequential steps that might run for hours or days, Google said.
Notably, the agent is given the flexibility to choose which model should drive different workflows, to improve quality and reduce cost; right now, those models include the Gemini family and Claude, but Google says it will soon expand capabilities to other leading private and open models.
This is important because the leading model changes every few months, Kurian noted, and “the best model for the task is not always the largest one.”
Choice a ‘unique value proposition’
Mahmoud Ramin, a research director at Info-Tech Research Group, noted that Google’s announcement does not create a whole new category, since OpenAI, Anthropic, Microsoft, and Meta have already positioned multiagent capabilities in their platforms.
What is interesting with Gemini, though, is that not only can it operate directly in multiple Google products like Gmail, Drive, Sheets, and Slides, it also connects to external systems. It is, of course, a good fit for those already using the Google environment, he noted, and the strongest use cases are around repetitive tasks and information synthesis, such as that described in the research performed by project managers, analysts, and marketing specialists.
Levy agreed that Google’s unique value proposition revolves around choice. “It separates the agent from the underlying model, and allows enterprises to use whatever model makes sense for a given workload,” he said.
Its role-based agents are also “compellingly unique,” because they allow enterprises to create agents optimized for specific roles; meanwhile, more granular permission-setting addresses growing concerns about automated bots going off the rails.
While OpenAI and Microsoft have made similar claims, Google is “arguably leading the conversation around identity, audit trails, and who, or what, is ultimately responsible for workflows,” Levy said.
Google and others looking to be ‘gatekeepers’
As the AI industry pivots beyond mere chatbots toward its “inevitably agentic future,” the role of companies like Google, OpenAI, Anthropic, Microsoft, and others in the role of gatekeepers comes into sharper focus, Levy noted. The defining layer has shifted from operating systems to browsers, apps, cloud platforms, and now large language models (LLMs).
In the agentic rush, key players are racing to establish their role in enterprise workflow infrastructure. “The agent layer could be the ultimate prize of the AI era, and it largely explains why every vendor announcement seems to essentially claim the same thing,” Levy said.
But Google has to convince IT decision makers that its agentic roadmap is better than the competition’s; this means shifting the AI conversation to autonomy, rather than just basic tasks.
Like virtually every other vendor’s agent, Google’s Gemini agent can write an email, tweak a spreadsheet, and build a presentation. “However,” Levy said, “whether CIOs and CISOs can trust it to run mission critical business processes indefinitely without doing something stupid enough to generate damaging headlines is another story altogether.”
“Will enterprises care? If they’re already heavily invested in Google’s workplace stack, this could be an easier sell in the C-suite,” he noted.
Raising important governance questions
Info-Tech’s Ramin noted that whatever platform enterprises choose, the front-and-center focus going forward should be who controls AI agents.
“As organizations unleash the power of agent autonomy, it raises the pivotal and non-negotiable requirement of enforcing governance,” he said, noting that with basic AI systems, risk is “much more contained” compared to that of an autonomous agent that has access to multiple business systems and can communicate with other agents.
In the latter case, enterprises should significantly enforce guardrails, including permissions, identity, human oversight, and system audits, he said. They should “clearly outline which decisions the agent is allowed to make, what data should be accessed, and how performance will be monitored.”
Há pouco tempo, muitas empresas começaram a implementar agentes de IA em uma ampla variedade de fluxos de trabalho. Rapidamente, o custo de uso desses agentes se tornou uma questão urgente para as empresas. Além disso, a questão vai muito além do departamento financeiro. Além das preocupações orçamentárias, surgiram problemas de confiabilidade, estabilidade operacional e até de segurança da informação. Isso ocorre porque o custo de automatizar um mesmo processo varia significativamente entre implementações, é imprevisível e pode ser afetado por fatores externos.
Além disso, para um agente malicioso, qualquer processo automatizado com IA e vulnerável a influências externas é, na prática, um alvo conveniente para o “novo tipo de ataque DDoS”. Relatórios de erros de aplicativos, avaliações de produtos ou solicitações de suporte técnico podem, assim como qualquer outro dado externo processado pela empresa com IA, ser usados em um ataque para aumentar o consumo de tokens (fragmentos de palavras que são a unidade básica de entrada e saída de um LLM).
Um ano de crescimento explosivo… nas contas
Em 2026, grandes empresas gastaram pela primeira vez muito além do orçamento destinado a seus sistemas de IA. A Uber já havia gasto todo o orçamento anual até abril, enquanto uma empresa não identificada não definiu limites de gastos para o Claude e gastou US$ 500 milhões em um único mês. Embora os provedores de IA anunciem regularmente preços mais baixos e modelos mais eficientes, a transição de chatbots para sistemas agênticos que operam de forma contínua e autônoma aumenta o consumo de tokens em centenas ou milhares de vezes. Ao mesmo tempo, o modelo de “assinatura fixa de US$ 20 ou US$ 100” para empresas é coisa do passado. Todos os principais provedores estão migrando clientes corporativos para o modelo de pagamento conforme o uso.
Como resultado, as empresas estão enfrentando um problema já conhecido pelos setores de armazenamento em nuvem e telecomunicações. Sem sistemas especializados de contabilização e gerenciamento de custos, uma organização só descobre quanto um determinado processo ou projeto custou depois de concluí-lo. Nos setores de telecomunicações e nuvem, esse problema acabou sendo resolvido com o desenvolvimento de sistemas sofisticados de faturamento, e os clientes desses setores até adotaram o termo especializado FinOps. No caso da IA, esse processo ainda está em estágio inicial. Além disso, a natureza probabilística da IA generativa torna esse problema ainda mais difícil de resolver.
Consumo imprevisível de tokens
Para entender por que os custos aumentam tão rapidamente e são tão difíceis de prever e controlar, precisamos lembrar como funciona um modelo de linguagem e o que o transforma em um agente de IA. O modelo não armazena informações de estado. Em outras palavras, não retém informações entre as interações. A cada nova etapa, todo o histórico de trabalho de uma determinada tarefa (o contexto) precisa ser reenviado ao modelo: o prompt inicial, o raciocínio anterior, o conteúdo dos arquivos lidos e as respostas de todas as ferramentas. A cada etapa, essa “recapitulação” fica mais longa, especialmente se a tarefa envolver loops iterativos. Se uma etapa falhar, a resposta não for clara ou uma ferramenta retornar um erro, o agente simplesmente tenta novamente, aumentando ainda mais o tamanho do contexto. E, se a tarefa for executada por vários agentes, que dividem o trabalho entre si e trocam resultados, esse volume aumenta proporcionalmente ao número de agentes. Como resultado, o consumo de tokens não aumenta gradualmente, mas em saltos, e é quase impossível prevê-lo no início da tarefa.
Ao executar duas sessões diferentes de um agente de IA para resolver exatamente a mesma tarefa (dois tíquetes de suporte técnico, duas tarefas de análise e assim por diante), a quantidade de tokens consumidos pode variar. A diferença pode chegar a 30 (!) vezes. Isso depende do número de etapas, erros e tentativas necessárias para concluir a tarefa. O aumento do consumo de recursos não depende necessariamente da complexidade da tarefa. Há casos conhecidos em que a IA ficou presa em um “loop de raciocínio” e desperdiçou uma quantidade absurda de recursos em tarefas triviais.
Três gerações de IA em sistemas corporativos consomem recursos de maneiras completamente diferentes:
Machine learning clássico (ML). Normalmente, trabalha com dados bem estruturados e não exige muitos recursos computacionais. O consumo de recursos é previsível e baixo. É um item de orçamento fixo;
Um chatbot ou outro assistente de IA baseado em LLM. Ele consome tokens, mas o ritmo é definido por uma pessoa: o funcionário inicia a tarefa manualmente, avalia o resultado e interrompe o processo. O custo aumenta aproximadamente de acordo com o número de usuários ativos e pode ser estimado com base no número de licenças;
Um agente autônomo de IA. Uma pessoa define um objetivo e deixa o sistema trabalhar sozinho. O próprio sistema decide o que fazer e quantas etapas são necessárias. O custo continua aumentando até que a tarefa seja considerada concluída, sem um limite previsível.
Tokenomics em ataques: Denial of Wallet, o novo DDoS
Como as chamadas a LLMs são significativamente mais caras que as chamadas de software convencionais, automatizar tarefas corporativas rotineiras pode sair muito caro. Por exemplo, o Gartner estima que resolver uma única solicitação de suporte ao cliente usando um LLM custa aproximadamente US$ 3. É fácil imaginar como invasores poderiam bombardear uma empresa com milhares de solicitações longas e sofisticadas geradas por um LLM barato, causando um prejuízo financeiro significativo. Como o processo é automatizado, as anomalias podem não ser detectadas imediatamente.
Se um invasor souber qual sistema de agentes e qual LLM são usados em um processo de negócios, poderá realizar um ataque mais preciso e causar danos significativamente maiores. Os autores do estudo GitInject estimaram que um invasor capaz de criar incidentes no GitHub em uma organização que usa agentes de IA para análise de erros pode, com um único ataque (antes da ação dos mecanismos de defesa do GitHub), causar até US$ 111 em prejuízos e consumir 400 minutos do GitHub Actions da conta da vítima. Naturalmente, esse ataque pode ser repetido várias vezes, sem nenhum custo para o invasor.
O maior risco, embora seja difícil quantificá-lo em termos financeiros, vem de ataques que induzem os LLMs a um raciocínio excessivo. No artigo OverThink, os autores demonstraram como uma tarefa formulada de maneira inofensiva, quando enviada a um modelo de linguagem, produz um resultado correto, mas, nesse processo, consome 46 (!) vezes mais tokens do que deveria. Além disso, todas as tarefas testadas pelos pesquisadores passaram pelos filtros de segurança existentes.
Na nova versão do guia OWASP Top Risks for Language Models, esse problema alcançou a mais alta prioridade já registrada: o consumo ilimitado de tokens agora é classificado como LLM06:2026 e, entre suas variantes, o ataque de “denial of wallet” (negação de carteira), que esgota o orçamento da vítima para o uso de LLMs, é explicitamente destacado.
Como evitar ser vítima do “novo DDoS”
Antes de tudo, é preciso abandonar o princípio de “usar IA só por usar IA”. Não faz sentido delegar todas as tarefas a agentes autônomos. É recomendável analisar periodicamente o custo-benefício do uso de inteligência artificial.
Além disso, você deve limitar as permissões e o conjunto de ferramentas disponíveis para um agente autônomo de IA. Quanto menos ações o sistema puder executar, mais eficiente será em tarefas específicas, menos oportunidades terá de aumentar os custos e menor será a chance de alguém conseguir “manipulá-lo” para gastar tokens desnecessariamente.
Também recomendamos definir limites rígidos para o consumo de tokens e configurar um sistema de notificações para alertar as pessoas quando esses limites forem ultrapassados. Também é recomendável definir vários limites simultaneamente: por tarefa, por dia e assim por diante. Os alertas de limite excedido devem ser enviados imediatamente ao especialista responsável pelo sistema, para que ele decida se o processo deve continuar ou ser interrompido.
Verifique rigorosamente os dados externos não confiáveis. Qualquer informação processada pela IA que venha de fontes externas, como solicitações, consultas, mensagens, comentários ou campos técnicos que possam conter texto arbitrário (registros DNS, cabeçalhos HTTP, nomes de arquivos), pode não apenas levar à injeção de prompt, mas também aumentar deliberadamente a carga de trabalho. É recomendável limitar o tamanho desses dados e monitorar a carga que geram.
Calcule o custo unitário do trabalho e compare as faturas do fornecedor com seus próprios dados. O custo por análise, solicitação ou verificação é a única maneira de entender pelo que você está pagando e identificar erros nas faturas.
The theft of FBI employee data by hacking group ShinyHunters, and the subsequent shutdown of the FBI’s Peoplesoft-based jobs portal, is causing concern for enterprise users of the Oracle product, with analysts recommending extreme measures in response.
Law enforcement has made some progress in its pursuit of the cyber criminals involved, but there has still been no official word from either the FBI or Oracle about Peoplesoft’s alleged involvement.
On Saturday, Reuters reported that a suspected member of ShinyHunters had been arrested in Jordan and has been cooperating with law enforcement to help identify other member of the group. The arrest comes a week after the arrest of another suspected ShinyHunters member by the Dutch National Police. In a video about that arrest, an FBI official warned gang members that arrests have a way of changing who is willing to talk, concluding, “You know how to find us, and we know how to find you.” Before the arrests, the gang told The Register it had discovered a new PeopleSoft zero-day hole and leveraged it to break into an FBI system, stealing information on all FBI employees. The FBI has since confirmed the breach without providing details.
Oracle did not respond to a request for comment on the alleged new vulnerability.
Significant risk exposure for enterprises
Analysts and consultants played up the risk exposure from the potentially new vulnerability even as they sharply played down the implications of the arrest.
Frank Dickson, principal analyst at Dickson Research, recommended that PeopleSoft users take immediate action.
“If it is a new flaw, the patch is necessary but not sufficient. PeopleSoft customers should pull the Environment Management Hub and the Integration Broker off the public internet,” he said. “Doing so does not break normal user sessions.”
He also encouraged users to quickly implement many of the recommendations from Google unit Mandiant’s report late last month on PeopleSoft security issues, especially “hunting for the web shells and outbound traffic Mandiant describes.”
“For PeopleSoft shops, the to-do list is short,” Dickson said. “Apply Oracle’s patch. Disable or remove the Environment Management Hub if you do not use it. Search your logs for encoded variants of the PSEMHUB path, not just the literal string. If you find a web shell, treat the server as compromised and rotate every credential it could read.”
This is a dangerous situation, he said: “An unpatched PeopleSoft flaw is a Sword of Damocles over every PeopleSoft shop
But despite the extreme risk, even after the patch was released, rather than applying it, some organizations have opted for other mitigations. “Many organizations chose to block the vulnerable endpoint with web application firewall rules rather than patch,” Dickson said. “The attackers walked past those rules by changing a single character in the web address, writing ‘%50’ in place of the letter ‘P.’”
Could signal a bigger problem
However, IDC Research Director Philip Harris encouraged CISOs to view the FBI’s confirmation of its breach with caution, given the attack vector was not revealed.
“ShinyHunters says it used a second, previously undocumented PeopleSoft preauth RCE zero-day, distinct from the CVE-2026-35273 flaw exploited in the earlier campaign,” he said. Yet, he pointed out, “no CVE has been assigned to it, it has not appeared on CISA’s Known Exploited Vulnerabilities catalog and Oracle has not commented on it. Every outlet covering this is explicit that the zero-day claim comes only from the threat actor, not from independent forensic confirmation or from Oracle. That distinction matters.”
But if the hole is as the group has suggested, Harris said it signals a much bigger problem.
“Assuming it is real, this would mean PeopleSoft has a second critical, unpatched preauth RCE in the same window as CVE-2026-35273, a pattern of recurring critical exposure rather than one isolated bug,” he said. “ShinyHunters’ own claim that they are already using it against other, unnamed Fortune 500 targets would mean every PeopleSoft customer is currently exposed to an unpatchable, undisclosed flaw with no vendor guidance to act on, a meaningfully worse position than the WAF-bypass story, since there is no mitigation to attempt while waiting on Oracle to confirm something it has not acknowledged.”
Jeff Valdes, a director at consulting firm Acceligence, added that Oracle’s silence is unwarranted.
“I think customers reasonably want more communication from the vendor,” he said. “They want to understand whether Oracle’s original guidance remains sufficient, whether there are additional mitigations customers should implement, whether Oracle is seeing anything through its own support organization that changes the risk picture, and whether there are configurations or architectural choices that materially increase exposure. Those are operational security questions that can be addressed without discussing attribution, arrests, investigative techniques or anything else that might interfere with an FBI investigation.”
Shares in fashion company fall nearly 10% after its app systems are accessed by ‘unidentified third party’
Asos is investigating unauthorised access to its app system after shoppers received a notification claiming hackers had “fully compromised” its data.
The online fashion retailer said basic personal information including name and contact details might have been accessed by an unidentified third party but it did not believe payment card records or passwords had been compromised.
Entrar
