Orientação da CISA sobre tokens de IA alerta que o uso pode se tornar um ataque

A CISA e agências de cibersegurança aliadas alertam que o consumo de IA pode se tornar uma ameaça à segurança antes mesmo de um sistema ficar indisponível. A orientação da CISA sobre tokens de IA aborda ataques de denial-of-wallet, um abuso deliberado que eleva as cobranças de uma organização baseadas no uso. Sua importância vai além de contas inesperadas: limites de gastos e capacidade esgotada também podem interromper trabalhos que dependem de IA.

A cobertura de cibersegurança de outubro da ExecutiveGov datou a matéria em 23 de outubro de 2026. A tensão central é simples. Empresas querem sistemas de IA que continuem funcionando em tarefas complexas, mas a atividade contínua também consome recursos. Um sistema que persiste de forma confiável em uma tarefa não autorizada ou desperdiçadora cria um problema diferente de confiabilidade.

Essa preocupação já aparece no framework de segurança da OWASP e na documentação de segurança empresarial da Microsoft. A orientação a leva para uma discussão sobre aquisição e resiliência operacional. Compradores corporativos, desenvolvedores e equipes de segurança agora enfrentam uma pergunta comum: quem decide quando um fluxo de trabalho de IA já fez o suficiente e quem pode interromper seus gastos?

A orientação da CISA sobre tokens de IA relaciona gastos à continuidade do serviço

A mudança mais relevante é tratar o consumo de IA como uma dependência operacional que merece supervisão de segurança.

A publicação conjunta, disponível por meio do Canadian Centre for Cyber Security, tem o título AI token consumption. Tokens são unidades de informação que modelos de IA processam ou geram. Eles ajudam a medir o uso, embora a relação entre contagens de tokens, trabalho computacional e cobranças dependa do serviço.

A publicação distingue o prejuízo financeiro do esgotamento de acesso. Ataques de denial-of-wallet aumentam deliberadamente os custos baseados no uso. Ataques de denial-of-tokens consomem alocações ou acionam limites, interferindo no acesso legítimo. Os resultados se sobrepõem, mas não são intercambiáveis.

A orientação também identifica causas operacionais comuns de esgotamento, incluindo demanda legítima e aplicações ineficientes. Ela recomenda que as organizações compreendam o consumo e os termos de serviço antes de firmar acordos com fornecedores. Para operadores de infraestrutura crítica, a preocupação inclui a continuidade quando as capacidades de IA se degradam ou ficam indisponíveis.

Esse enquadramento importa porque uma salvaguarda financeira pode se tornar, ela própria, uma restrição de disponibilidade. Interromper o consumo protege um orçamento, mas uma interrupção indiscriminada pode afetar trabalhos importantes. Manter o consumo preserva temporariamente o acesso, mas deixa a organização exposta a mais despesas.

A implicação prática é um conflito entre objetivos concorrentes. Finanças quer exposição previsível. Operações quer acesso confiável. Equipes de produto querem concluir tarefas com sucesso. Segurança quer conter comportamentos suspeitos. Uma implantação de IA precisa de uma forma explícita de resolver esses objetivos quando entram em choque.

Considere um assistente corporativo de documentos, usado para perguntas rotineiras e investigações operacionais urgentes. Ambas as atividades podem depender da mesma conta de modelo subjacente. Uma tarefa de segundo plano desperdiçadora se torna relevante caso consuma recursos necessários para a investigação urgente.

Esse exemplo não estabelece que alguma organização específica tenha sofrido tal incidente. Ele mostra por que a localização do limite de gastos importa. Um limite aplicado a uma conta inteira produz consequências diferentes de um limite aplicado a um fluxo de trabalho individual.

Isso também muda como uma demonstração bem-sucedida deve ser interpretada. Uma demonstração estabelece que um assistente pode concluir tarefas selecionadas sob condições selecionadas. Ela não estabelece como o serviço se comporta quando a demanda muda, as dependências falham ou a atividade permitida se torna excessiva.

Para compradores, isso cria uma lacuna entre evidências de capacidade e evidências operacionais. As primeiras respondem se o sistema consegue realizar o trabalho. As últimas respondem se a organização consegue continuar a usá-lo em condições adversas.

A orientação da CISA sobre tokens de IA torna mais difícil deixar essa segunda pergunta fora do processo de compra. A questão deve estar ao lado da disponibilidade do serviço, das expectativas de recuperação e da responsabilidade por falhas.

A pressão recai sobre compradores que não conseguem ver cargas de trabalho individuais

Uma conta agregada de IA não consegue explicar se um fluxo de trabalho individual merece continuar em execução.

A pressão imediata recai sobre organizações que adquirem capacidades de IA por meio de aplicações, integrações e serviços compartilhados. Seu desafio é conectar o consumo a uma finalidade de negócios. Sem essa conexão, um total crescente de uso oferece pouca ajuda durante um incidente.

Uma tarefa excepcionalmente cara pode ser legítima. Ela pode envolver uma análise difícil, uma grande coleção de documentos ou tentativas repetidas de resolver evidências conflitantes. O mesmo padrão de gastos também pode refletir uma integração quebrada ou abuso deliberado.

Essa ambiguidade torna julgamentos simples pouco confiáveis. Alto consumo não estabelece intenção maliciosa. Baixo consumo não estabelece comportamento seguro. A pergunta relevante é se a atividade permanece autorizada, proporcional e útil.

Por isso, as equipes de compras precisam de evidências sobre limites de controle, em vez de linguagem tranquilizadora sobre monitoramento. Um painel pode mostrar um problema sem impedi-lo. Um alerta pode notificar alguém que não tem autoridade ou meios técnicos para intervir.

A documentação da Microsoft sobre consumo ilimitado de IA descreve o esgotamento de recursos por meio de prompts exigentes, solicitações repetidas e atividade excessiva de agentes. Ela recomenda controles em chamadas ao modelo e serviços posteriores, incluindo cotas, contenção e limites para a expansão de agentes. A Microsoft também observa que incidentes maliciosos amplamente divulgados continuam limitados.

Essa última ressalva é importante para compradores. Um modelo de ameaça crível sustenta a preparação, mas não justifica tratar todo aumento de custos como um ataque. Boas decisões de compra exigem a distinção entre um mecanismo demonstrado e a prevalência medida de incidentes.

A posição da Microsoft também oferece uma comparação útil com o framework de segurança de aplicações da OWASP. A Microsoft descreve controles em um contexto de segurança empresarial. A OWASP classifica a vulnerabilidade de consumo subjacente entre aplicações. Essas perspectivas reforçam o problema sem estabelecer que um fornecedor específico o tenha resolvido.

A implicação comercial é que os fornecedores precisarão explicar cada vez mais o alcance de seus controles. Uma restrição se aplica a um cliente, departamento, aplicação ou trabalho individual? Um operador consegue isolar um trabalho suspeito preservando atividades não relacionadas?

Essas perguntas também afetam a responsabilização dentro da organização compradora. Uma equipe financeira pode ser responsável pelo orçamento, enquanto a engenharia é responsável pela integração. A segurança pode receber alertas sem ser responsável pelo contrato. Uma transferência de responsabilidade não resolvida pode deixar todos informados e ninguém responsável por interromper o fluxo de trabalho.

Para desenvolvedores, a visibilidade do consumo passa a fazer parte do diagnóstico do comportamento da aplicação. Saber que uma conta gastou mais diz menos do que saber qual trabalho repetiu uma ação malsucedida. Evidências úteis devem conectar a tarefa, seu progresso e os recursos que consumiu.

Para trabalhadores do conhecimento, as consequências aparecem como respostas atrasadas, pesquisas interrompidas ou assistentes indisponíveis. Eles raramente controlam a alocação de recursos subjacente. Sua experiência depende de decisões tomadas por compras e engenharia muito antes da interrupção.

Equipes que revisam essas dependências podem manter contratos aprovados, decisões de arquitetura e procedimentos de incidentes em uma base de conhecimento técnico pesquisável. A documentação apoia uma resposta coordenada, embora não possa substituir controles aplicados pela aplicação.

Autonomia útil e consumo limitado seguem em direções diferentes

A principal troca envolve permitir que um sistema continue um trabalho útil e impedir que ele continue indefinidamente.

Um agente de IA é um software que usa um modelo para selecionar ações ao longo de uma tarefa. Isso pode facilitar a delegação de trabalhos difíceis. Também significa que a solicitação original não necessariamente descreve todas as ações subsequentes.

Um usuário pode autorizar uma investigação sem saber quais pesquisas, documentos ou serviços externos o agente precisará. Um limite restritivo corre o risco de interromper prematuramente um trabalho útil. Um limite aberto deixa a organização aceitando consequências que não especificou plenamente.

A categoria de consumo ilimitado da OWASP identifica o uso descontrolado de modelos como uma fonte de degradação do serviço e prejuízo econômico. Seus exemplos incluem solicitações excessivas e consultas que demandam muitos recursos. O framework recomenda proteções em camadas, incluindo gerenciamento de recursos, tempos limite, monitoramento e degradação gradual, ou seja, funcionalidade reduzida que preserva um serviço útil.

Essa perspectiva torna a questão mais ampla do que o tamanho de um prompt. Uma instrução curta pode iniciar um fluxo de trabalho complexo. Contar apenas as solicitações recebidas diz pouco sobre tudo o que a aplicação faz depois de aceitá-las.

Um assistente de pesquisa ilustrativo pode pesquisar uma coleção de documentos, examinar passagens conflitantes e solicitar mais evidências. Cada ação pode ser razoável individualmente. A questão de negócios é se a sequência ainda avança a investigação autorizada.

É aqui que a conclusão da tarefa e a continuação da tarefa divergem. A atividade contínua pode parecer produtiva em uma interface mesmo quando o trabalho subjacente deixou de progredir. Um fluxo de atualizações de status não estabelece que a próxima ação merece mais recursos.

A mesma tensão aparece na recuperação de erros. Repetir uma ação malsucedida às vezes resolve um problema temporário. Repetir uma ação que não pode ter sucesso apenas prolonga a falha. Uma aplicação precisa de uma forma de distinguir essas situações usando evidências além da disposição do modelo de tentar novamente.

Essa distinção também deve moldar a forma como as organizações avaliam a autonomia. Menos intervenção humana não é automaticamente melhor se os operadores perderem a capacidade de entender o que continua em execução. Mais intervenção não é automaticamente mais segura se aprovações rotineiras se tornarem interrupções sem sentido.

Uma avaliação útil pergunta quais evidências permitem que o fluxo de trabalho prossiga. Ele obteve novas informações? Uma dependência mudou? Ele concluiu um resultado intermediário significativo? Essas são perguntas analíticas sobre progresso, e não alegações de que algum produto atual as responda de forma confiável.

A responsabilidade também se estende além do fornecedor do modelo. Uma aplicação decide que trabalho solicitar, quais ferramentas expor e como lidar com tarefas inacabadas. Essas decisões afetam a exposição mesmo quando o modelo subjacente se comporta como previsto.

Isso explica por que não se pode presumir que trocar de modelo resolverá o problema. Um modelo menos intensivo em recursos pode reduzir a despesa de cada ação. Ele não estabelece que a aplicação escolherá um número apropriado de ações.

Portanto, a orientação da CISA sobre tokens de IA integra uma conversa mais ampla sobre autoridade delegada. Autorizar um sistema de IA a perseguir um objetivo deve incluir um limite definido em torno dos recursos que ele pode comprometer.

O difícil problema de design é preservar uma margem de decisão útil dentro desse limite. As empresas precisam de flexibilidade suficiente para trabalhos complexos, juntamente com uma explicação confiável do que acontece quando o limite é atingido.

O Software ao Redor do Modelo Determina o Limite de Gastos

O julgamento de um modelo e a permissão de um aplicativo para gastar são decisões separadas.

O aviso sobre estruturas de IA agêntica da Australian Signals Directorate, publicado em 11 de setembro de 2026, chama a atenção para o software ao redor do modelo. Uma estrutura é a camada de software que conecta um modelo a ferramentas, dados, memória e controles de execução.

O aviso argumenta que as organizações devem avaliar essa camada como uma fonte distinta de risco operacional e de segurança. Sua ênfase inclui permissões, monitoramento, supervisão e as formas como os modelos interagem com sistemas conectados. Isso oferece uma contraparte arquitetural útil à orientação sobre tokens.

A distinção importa porque um assistente pode recomendar uma ação sem ter autoridade para executá-la. O aplicativo ao redor do modelo determina se a ação ocorre. A mesma separação pode se aplicar à autorização de consumo adicional de recursos.

Nessa perspectiva, um limite de gastos deve ser uma decisão do aplicativo que o modelo não possa simplesmente contornar pela conversa. Pedir que um modelo permaneça econômico é diferente de impor uma restrição aplicável. O primeiro expressa um objetivo; o segundo altera o comportamento permitido.

Uma pesquisa submetida em setembro acrescenta uma preocupação técnica mais específica. Um preprint sobre estado faturável persistente examina conteúdo de ferramentas externas retido entre interações de agentes. Os autores relatam que conteúdo retido pode se tornar entrada faturável recorrente quando solicitações posteriores o incluem novamente.

O estudo testa ataques e defesas no lado do host em fluxos de trabalho controlados. Suas conclusões dizem respeito ao tratamento de informações retidas, e não constituem evidência de comprometimento disseminado em empresas. Como preprint, ele merece escrutínio e replicação independente antes de conclusões amplas sobre riscos de implantação.

Ainda assim, a pesquisa destaca uma distinção importante entre aceitar informações e pagar repetidamente para processá-las. Uma resposta de ferramenta pode permanecer em um fluxo de trabalho após o fim de sua finalidade imediata. Portanto, decisões de retenção merecem atenção juntamente com decisões de acesso.

Uma investigação documental ilustrativa torna a questão concreta. Um assistente recupera um relatório extenso para responder a uma pergunta restrita. Se o aplicativo continuar fornecendo esse relatório durante ações de acompanhamento não relacionadas, o processamento contínuo precisará de sua própria justificativa.

Simplesmente apagar tudo não é uma resposta geral adequada. O assistente pode precisar de evidências anteriores para resolver contradições ou explicar sua conclusão. A questão arquitetural é quais informações continuam necessárias e como o aplicativo torna esse julgamento visível.

É também nesse ponto que comparações entre provedores se tornam mais significativas. Compradores podem comparar o tratamento dado ao histórico de tarefas, à intervenção e ao comportamento de reinicialização. Um contexto disponível mais longo, isto é, as informações que um modelo pode considerar durante uma solicitação, não resolve essas questões operacionais.

Da mesma forma, trocar de provedor cria uma nova dependência em vez de eliminar a necessidade de governança. O serviço receptor pode tratar informações de maneira diferente. Uma alternativa que preserva a disponibilidade ainda precisa ser avaliada quanto à correção, permissões e exposição de recursos.

A implicação central é o controle organizacional. As empresas devem entender quais decisões pertencem ao modelo, quais pertencem ao aplicativo e quais exigem autoridade humana. Confundir essas responsabilidades torna mais difícil investigar tanto gastos excessivos quanto interrupções desnecessárias.

O Alerta É Crível, mas a Prevalência de Ataques Continua Incerta

Um caminho de ataque plausível não estabelece com que frequência invasores o exploram nem quanto dano causam.

As fontes disponíveis sustentam tratar o consumo excessivo como uma preocupação de segurança e resiliência. Elas não fornecem uma medida abrangente de incidentes maliciosos de negação de carteira em empresas. Essa incerteza deve permanecer visível na cobertura do alerta.

A distinção importa porque várias falhas diferentes podem produzir sintomas semelhantes. Uma solicitação maliciosa, um defeito de software e uma tarefa legítima inesperadamente difícil podem aumentar o consumo. Um pico de gastos, por si só, não pode determinar qual explicação está correta.

Chamar todo pico de ataque distorceria os relatórios de incidentes. Chamar todo pico de demanda comum obscureceria abusos. As organizações precisam de evidências suficientes no nível da tarefa para investigar antes de escolher qualquer uma das interpretações.

Também há um limite importante para alegações sobre controles de proteção. Um limite configurado mostra que uma configuração existe. Ele não estabelece com que rapidez a aplicação ocorre, qual atividade abrange ou se trabalhos dependentes continuam em outros lugares.

Um alerta representa uma alegação ainda mais restrita. Ele estabelece que o sistema pode notificar alguém sob condições especificadas. Os compradores ainda precisam entender atrasos de notificação, responsabilidades de escalonamento e as ações disponíveis após a notificação.

Da mesma forma, uma demonstração bem-sucedida de contenção deve ser interpretada dentro das condições testadas. Interromper uma carga de trabalho artificial prova algo útil sobre esse teste. Isso não estabelece automaticamente proteção contra todos os fluxos de trabalho, integrações ou padrões de abuso.

A questão cética mais forte diz respeito às consequências para o negócio. Um controle que interrompe consumo excessivo ainda pode interromper trabalho legítimo. Avaliar a proteção, portanto, exige examinar tanto a exposição evitada quanto o trabalho que essa proteção bloqueia.

Essa troca se torna especialmente importante quando as organizações usam taxas de conclusão para avaliar assistentes. Interrupções agressivas podem reduzir a conclusão bem-sucedida. A continuidade permissiva pode melhorar a conclusão aparente enquanto aumenta a exposição. Uma comparação significativa precisa considerar ambos os resultados.

Outra incerteza diz respeito a onde começa e termina a responsabilidade contratual. Um provedor pode fornecer monitoramento enquanto o cliente configura a aplicação. Um fornecedor de aplicativos pode depender do serviço de modelo de outra empresa. Os compradores devem evitar inferir responsabilidade a partir do nome de um recurso.

A própria orientação também deve ser descrita com precisão. Uma publicação de cibersegurança não é automaticamente uma nova exigência legal. Qualquer alegação sobre obrigações obrigatórias exigiria uma autoridade aplicável e separada. As fontes aqui estabelecem orientação e preocupações técnicas, e não um prazo universal de conformidade.

Para equipes de produto, a resposta razoável é uma validação proporcional. Elas podem examinar se tarefas representativas permanecem úteis sob limites realistas. Também podem testar se tarefas suspeitas ou com falhas são interrompidas sem desabilitar trabalhos não relacionados.

Para os leitores, o padrão de reportagem deve permanecer igualmente disciplinado. Exija distinções claras entre controles recomendados, comportamento testado de forma independente e incidentes verificados. Essas categorias respondem a perguntas diferentes, e tratá-las como intercambiáveis torna as decisões de compra menos confiáveis.

A orientação da CISA sobre tokens de IA é relevante sem exigir alegações exageradas. Ela identifica uma dependência que as organizações podem examinar agora, enquanto deixa a frequência e a gravidade da exploração no mundo real em aberto para evidências adicionais.

Observe a Aplicação, o Isolamento de Cargas de Trabalho e os Testes Independentes

As próximas evidências devem mostrar se as organizações conseguem conter trabalho excessivo enquanto preservam o serviço legítimo.

Nos próximos meses, os sinais mais úteis dirão respeito ao comportamento operacional, e não a promessas gerais sobre uma IA mais segura. A publicação cria uma base clara para fazer perguntas mais específicas. Ela não estabelece que provedores ou compradores já as tenham respondido.

O primeiro sinal é uma documentação mais clara do comportamento de aplicação. Observe fornecedores distinguindo notificações de restrições e explicando exatamente onde cada restrição se aplica. Isso fortaleceria a tese de que a governança de consumo está se tornando uma capacidade de produto utilizável.

O sinal oposto enfraqueceria essa avaliação. Se a documentação continuar descrevendo orçamentos sem explicar a intervenção, os compradores ainda terão dificuldade para estimar a exposição. Um recurso deve ser avaliado por seu efeito operacional, incluindo o que permanece permitido depois de sua ativação.

O segundo sinal é evidência de isolamento de cargas de trabalho em requisitos de compra e testes de aceitação. Isolamento de cargas de trabalho significa restringir uma tarefa problemática sem interromper desnecessariamente outras tarefas. A evidência relevante mostraria atividade crítica continuando enquanto atividade de menor prioridade ou suspeita é interrompida.

Isso sustentaria a conexão da orientação entre controles de consumo e continuidade. Uma paralisação em toda a conta ainda pode ser apropriada em algumas circunstâncias. No entanto, apresentar esse comportamento como equivalente à contenção seletiva ocultaria uma diferença relevante.

O terceiro sinal são testes independentes que combinam contenção com conclusão útil de tarefas. Observe avaliações que publiquem suas premissas de carga de trabalho e expliquem por que tarefas interrompidas foram paradas. Resultados sólidos mostrariam exposição limitada juntamente com conclusão confiável de trabalho autorizado.

Resultados que medem apenas o consumo reduzido deixariam uma lacuna importante. Gastar menos é fácil se um assistente recusa trabalho suficiente. O teste difícil é verificar se os limites preservam a finalidade comercial para a qual o sistema foi adquirido.

Esses sinais também criam uma forma prática de comparar ofertas concorrentes. Os compradores podem examinar a aplicação documentada, o comportamento de isolamento e os resultados avaliados de forma independente. Isso produz uma avaliação mais útil do que depender apenas de alegações sobre capacidade de modelo.

Para desenvolvedores, a implicação imediata é tornar o comportamento operacional revisável. Uma tarefa deve ter uma finalidade identificável, um responsável e uma condição de interrupção compreensível. Essas propriedades tornam falhas mais fáceis de diagnosticar e alegações de compra mais fáceis de testar.

Para líderes empresariais, peça à equipe responsável por um serviço de IA que rastreie uma tarefa representativa desde a autorização até a conclusão ou interrupção. Identifique quem é responsável pelo limite de recursos, quem pode intervir e que trabalho não relacionado permanece disponível depois disso. Solicite evidências de um teste real em vez de aceitar um painel como resposta. Use a orientação da CISA sobre tokens de IA para estruturar essa revisão em torno da continuidade dos negócios, bem como dos gastos. Em seguida, compare o comportamento observado com o acordo de serviço e as responsabilidades internas. Se essas versões divergirem, resolva a divergência antes de expandir a implantação. A decisão de delegar trabalho deve vir acompanhada de uma resposta clara sobre quem pode interrompê-lo.