Como evitar custos descontrolados com credenciais de API de IA

Uma chave de API de IA não é apenas uma cadeia de início de sessão. É um caminho para capacidade de computação medida, e uma chave copiada pode continuar a autorizar pedidos muito depois de um atacante abandonar a aplicação onde foi exposta. Por isso, o controlo de custos faz parte da conceção de segurança de todos os sistemas de IA, incluindo ferramentas de investigação temporárias e protótipos internos.

A divulgação da METR de 2026 dá uma forma concreta a este risco. Um painel de agentes acessível pela internet tinha uma falha de autenticação fail-open, o que significava que a aplicação permanecia disponível quando o seu controlo de acesso falhava. A METR relatou que um atacante chegou ao painel, induziu um agente a revelar uma credencial de fornecedor de modelos, adicionou uma chave SSH para acesso persistente ao anfitrião e usou a credencial roubada durante três semanas. Os créditos consumidos foram avaliados em aproximadamente 600 000 dólares, embora a METR não tenha pago esse montante porque o fornecedor tinha fornecido os créditos gratuitamente.

A lição útil não é o valor que fez manchetes nem o estilo de desenvolvimento de uma aplicação. Vários controlos independentes não conseguiram deter o mesmo percurso. Um plano de prevenção duradouro pressupõe que uma interface, um anfitrião ou uma chave pode acabar por ser comprometido e limita o que pode acontecer em seguida.

Defina o raio de impacto antes de implementar um agente

Classifique uma aplicação de IA pelo que um utilizador não confiável poderia alcançar através dela, e não pelo facto de a equipa lhe chamar protótipo. Uma experiência torna-se operacionalmente relevante quando aceita tráfego da internet, consegue chamar um modelo pago ou escasso, alcançar dados não públicos ou invocar ferramentas com efeitos fora do seu próprio processo. Uma vida útil curta não reduz essas capacidades.

Crie um pequeno registo de implementação antes da exposição. Indique o proprietário, os pontos de extremidade públicos, a conta na nuvem, os modelos, as credenciais, os armazenamentos de dados, as permissões de ferramentas, o intervalo de utilização esperado, a data de expiração e o procedimento de encerramento. Este inventário torna experiências esquecidas detetáveis e dá a quem responde a incidentes um mapa fiável. Os serviços públicos devem executar-se num ambiente arquitetonicamente separado dos sistemas internos, para que um defeito num visualizador ou painel não crie uma rota para infraestrutura sensível.

A divulgação da METR descreveu uma segunda falha num visualizador público de transcrições: um mecanismo SQL só de leitura podia ser manipulado para expor dados de avaliação não publicados, e algum resultado sensível tinha entrado numa base de dados que deveria conter apenas resultados de modelos públicos. A METR afirmou que as provas disponíveis não indicavam que os atacantes tivessem descoberto a exploração ou acedido a informações não públicas. Ainda assim, o episódio mostra por que a classificação de dados pretendida não é suficiente. O isolamento tem de abranger onde os registos são guardados, como as consultas são delimitadas e se material restrito pode ser colocado num armazenamento de dados voltado ao público.

Defina uma regra fácil de aplicar: a exposição à internet ou o acesso a credenciais ativas desencadeia automaticamente uma revisão de segurança de base. A revisão pode ser leve, mas deve confirmar autenticação que nega por predefinição, alojamento gerido, propriedade identificada, registos, limites de credenciais e uma data de fim.

Mantenha os segredos brutos fora do alcance do agente

Uma aplicação pode precisar de autorização para chamar um modelo, mas o modelo não precisa de ler a credencial reutilizável. Guarde segredos fora de prompts, transcrições, ferramentas de inspeção do ambiente, ficheiros que o agente pode abrir e saída de comandos que o agente pode devolver. Instruções como "nunca revele esta chave" não são uma fronteira de segurança, porque um modelo de linguagem processa instruções não confiáveis e pode ser manipulado para divulgar informações acessíveis.

Coloque um intermediário ou serviço estritamente definido entre o agente e o fornecedor. O agente pede uma operação permitida; o intermediário guarda a credencial, valida o pedido, aplica a política, regista a utilização e devolve apenas o resultado necessário. Limite o intermediário a modelos e operações aprovados. Quando as funcionalidades do fornecedor o permitirem, emita credenciais separadas para cada aplicação e ambiente, reduza os âmbitos de permissão e use vidas úteis curtas.

Identidades separadas tornam tanto a contenção como a investigação mais fáceis. Se uma chave servir várias experiências, uma utilização elevada tem muitas explicações plausíveis e a revogação perturba trabalho não relacionado. Uma chave dedicada a uma carga de trabalho tem uma gama comportamental menor, um proprietário claro e um interruptor de corte prático. Credenciais de curta duração também reduzem o período em que um valor copiado permanece útil, enquanto permissões de âmbito estreito limitam o que o atacante pode fazer nesse período.

O acesso ao anfitrião precisa da sua própria fronteira. O atacante da METR adicionou uma chave SSH depois de entrar no sistema exposto, pelo que rodar apenas a credencial do fornecedor não teria removido a persistência. Monitorize alterações à configuração de acesso remoto, restrinja quem pode adicionar chaves e trate um novo método de acesso persistente como um incidente mesmo quando o consumo da API ainda parece normal.

Transforme orçamentos em limites de segurança aplicados

Um alerta de gastos é útil, mas um alerta é apenas um pedido para que uma pessoa investigue. Prefira um limite rígido do fornecedor ou do intermediário que rejeite mais utilização quando o orçamento aprovado se esgotar. Aplique limites a vários níveis quando disponíveis: organização, projeto, credencial da aplicação e janela de tempo. Só um teto mensal da conta ainda pode permitir um pico prejudicial no início do período.

Alguns fornecedores ou acordos de conta podem não disponibilizar um limite direto de gastos. A METR disse que não conseguia colocar um na chave afetada na altura, e os créditos doados eliminaram a fatura crescente que, de outro modo, poderia ter atraído atenção. Nessa situação, recrie a fronteira na camada de chamada. Um intermediário de credenciais pode contar pedidos ou tokens, aplicar subsídios diários e por execução, limitar a simultaneidade e suspender o acesso quando um limiar é ultrapassado. Capacidade concedida ou pré-paga deve ser tratada como um ativo com valor de substituição mesmo quando a faturação em dinheiro atual é zero.

Escolha limiares a partir do objetivo declarado da credencial. Uma avaliação agendada, um painel interativo e uma tarefa em lote não devem partilhar os mesmos limites. Defina um máximo esperado para uma única execução, um teto móvel horário ou diário e uma taxa máxima de pedidos falhados ou rejeitados. Documente quem pode aprovar um aumento temporário e quando essa exceção expira. Caso contrário, as substituições de emergência tornam-se silenciosamente o envelope operacional normal.

A aplicação deve falhar fechada. Se o serviço de autenticação, a verificação de política, o contador de utilização ou a consulta de aprovação estiver indisponível, o sistema deve negar ou restringir fortemente a operação protegida. Um serviço de monitorização degradado não deve converter silenciosamente uma credencial limitada numa ilimitada.

Detete comportamentos que uma fatura não consegue mostrar

Um volume elevado de tokens não é automaticamente suspeito em trabalho de investigação ou avaliação. A METR explicou que experiências legítimas podiam gerar utilização substancial, respostas de limitação de taxa e erros do fornecedor. O seu painel interno também não mostrava todos os pedidos de cada utilizador limitados por taxa durante o incidente. Essa combinação permitiu que atividade não autorizada se misturasse com ruído operacional familiar.

Crie linhas de base em torno da identidade e do objetivo, em vez de observar apenas o volume total da conta. Para cada credencial de aplicação, retenha a hora do pedido, o modelo, o resultado, a quantidade de tokens ou utilização, a carga de trabalho de origem e o proprietário responsável quando esses sinais estiverem disponíveis. Inclua tentativas falhadas e limitadas por taxa, porque o reconhecimento e o consumo tentado podem nunca aparecer nos totais de utilização bem-sucedida. Não coloque o segredo bruto nos registos.

Regras de anomalia úteis comparam o comportamento atual com o registo de implementação. Exemplos incluem atividade fora do horário da carga de trabalho, utilização sustentada depois de terminar uma experiência planeada, uma origem desconhecida, um modelo que a aplicação não estava aprovada para chamar, uma proporção invulgar de erros para sucessos ou uma alteração súbita na taxa de pedidos. Estes sinais são mais acionáveis do que um alerta genérico de "utilização elevada" porque explicam qual expectativa foi violada.

Ajuste os alertas sem eliminar provas importantes. Mensagens ruidosas de limitação de taxa devem ser agrupadas e resumidas, não omitidas do painel. O objetivo é um fluxo de alertas gerível, apoiado por eventos completos pesquisáveis. Cada alerta precisa de um responsável identificado, gravidade, prazo de investigação e caminho de escalonamento automático. Um aviso sem proprietário é apenas telemetria armazenada.

Conceba um painel de agentes para decisões

Um painel operacional útil deve responder rapidamente a quatro perguntas: qual credencial alterou o comportamento, o que está autorizada a fazer, quanto valor está atualmente em risco e qual ação irá contê-lo. Apresente utilização e falhas por credencial, aplicação, modelo e janela de tempo, em vez de apenas como um total de toda a organização. Mostre o consumo do limite rígido, exceções temporárias, idade da credencial, última rotação, proprietário e se a implementação associada continua aprovada.

Coloque juntos os sinais de segurança e custo. Um pico de erros do fornecedor, uma nova chave SSH, uma falha de autenticação e utilização contínua da API podem parecer menores em ferramentas separadas, mas formam uma cadeia clara de incidentes quando correlacionados. Preserve histórico suficiente para comparar o comportamento atual com o padrão normal da mesma carga de trabalho e reconstruir a sequência posteriormente.

O painel deve fornecer ou ligar diretamente a ações de contenção testadas: desativar a credencial da aplicação, parar a carga de trabalho, remover o acesso público e contactar o fornecedor. Controlos destrutivos precisam da autorização apropriada, mas não devem depender de encontrar um comando não documentado durante um incidente ativo. Registe quem tomou cada ação e quando.

Ensaie um exercício de resposta a credenciais

Execute um exercício de mesa ou controlado em torno de uma chave copiada. Comece com um sinal credível, como tráfego sustentado fora do horário mais erros repetidos de limitação de taxa. Peça a quem está de prevenção que identifique o proprietário, confirme a conta do fornecedor afetada, desative a credencial, pare ou isole a carga de trabalho e verifique persistência no anfitrião. A equipa deve então rodar credenciais relacionadas, preservar registos e uma imagem forense quando apropriado, notificar o fornecedor e determinar se dados ou outros sistemas estavam acessíveis.

A revogação é o primeiro passo de contenção, não o fim da investigação. A resposta da METR incluiu parar a instância comprometida, criar uma imagem forense, rodar credenciais, examinar e limpar o portátil do investigador, informar a empresa do modelo e usar assistência de segurança externa. A sequência exata variará, mas o princípio é estável: remover o acesso atual preservando provas suficientes para determinar como ocorreu o comprometimento e o que mais tem de mudar.

Meça o exercício pelo tempo decorrido e pelas informações em falta. Quanto tempo demoraram a descoberta, a procura do proprietário, a revogação, o isolamento do anfitrião e o contacto com o fornecedor? Que registos estavam incompletos? Quem respondeu conseguiu distinguir créditos concedidos de utilização faturada? Atualize o modelo de implementação, o painel e o manual operacional após cada exercício.

Lista de verificação de implementação

• Faça o inventário de cada serviço de agente voltado para a internet, do seu proprietário, data de expiração, ambiente de nuvem, credenciais, dados e ferramentas.
• Exija autenticação que nega por predefinição e uma revisão de base para exposição pública ou acesso a credenciais ativas.
• Mantenha os segredos do fornecedor fora de contexto legível pelo modelo, transcrições, ferramentas e ficheiros recuperáveis.
• Use credenciais por aplicação com o âmbito disponível mais estreito e uma vida útil prática.
• Encaminhe chamadas através de um intermediário quando os controlos diretos do fornecedor não puderem aplicar a política exigida.
• Defina tetos de utilização por execução e móveis; acrescente uma paragem rígida onde o fornecedor ou intermediário a suportar.
• Monitorize pedidos bem-sucedidos, falhados e limitados por taxa por credencial e carga de trabalho esperada.
• Alerte sobre incompatibilidades comportamentais, não apenas custo agregado ou volume de tokens.
• Correlacione a utilização de modelos com eventos de autenticação e persistência no anfitrião no painel de agentes.
• Dê a cada alerta um responsável, prazo, rota de escalonamento e ação de contenção testada.
• Ensaie a revogação de chaves, o isolamento da carga de trabalho, a preservação de provas, a notificação do fornecedor e a recuperação.
• Retire credenciais e pontos de extremidade públicos quando a experiência terminar e depois verifique que o tráfego parou.

O custo descontrolado de API é mais bem prevenido por limites sobrepostos. O isolamento de segredos bloqueia a extração fácil, identidades estreitas reduzem o raio de impacto, orçamentos aplicados limitam o consumo, a monitorização comportamental encurta a deteção e exercícios de resposta tornam a revogação rotineira. Nada disso depende de adivinhar corretamente como o próximo atacante entrará. Em conjunto, transformam uma chave roubada de um recurso sem limites num incidente contido e observável.