Northflank vaza chaves de IA: como girar e pôr limite

A Northflank, plataforma de deploy de containers, bancos e aplicações de IA, avisou em 30 de outubro de 2026 que todos os clientes devem considerar as variáveis de ambiente guardadas nela como decifradas e girar todas as chaves. Horas depois, a própria empresa confirmou que clientes relataram uso não autorizado das chaves de API de IA cadastradas na plataforma. A história foi publicada pelo BleepingComputer em 31 de outubro, e o registro oficial está na página de status da Northflank.

Quem usa a Northflank tem trabalho imediato. Quem usa outra plataforma de deploy (Railway, Render, Fly, um painel próprio ou um GitHub Actions com secrets) tem um bom motivo para conferir hoje se conseguiria fazer o mesmo trabalho em uma hora: revogar cada chave de IA, colocar a nova no lugar, limitar quanto ela pode gastar e perceber quando alguém está usando por você.

O que a Northflank confirmou até agora

A linha do tempo abaixo segue a página de status, com os horários convertidos de UTC para o horário de Brasília (UTC-3):

• 30/10, 8h43: alerta de ameaça da Wiz, empresa de segurança em nuvem. Um minuto depois, engenheiros da Northflank começam a analisar.
• 30/10, entre 9h02 e 10h05: primeira correção de política de rede, mais duas rodadas de correções e pedido de apoio à equipe de resposta a incidentes da Wiz.
• 30/10, 10h40: primeiro aviso público: "Rotate environment variables immediately".
• 30/10, 10h58: o aviso endurece: "Assume all environment variables have been decrypted. Disable/rotate all keys."
• 30/10, 12h12: rotação de credenciais liberada para os add-ons de Postgres e MongoDB, recomendação de desligar a exposição pública dos add-ons e a frase "Multiple users are confirming that their AI keys have been used".
• 30/10, 20h38: a empresa pede que os clientes revoguem as chaves no provedor que as emitiu, gerem novas, atualizem os segredos e workloads e revisem os registros de uso e de cobrança dos provedores de IA.
• 30/10, 22h04: logs de auditoria ligados para todos os clientes, inclusive os do plano gratuito.
• 31/10: rotação liberada também para MySQL e Redis (10h34), MinIO (19h32) e RabbitMQ (20h31).

O que não foi divulgado até a noite de 31/10: como os atacantes entraram, quantos clientes foram afetados e se outras credenciais além das chaves de IA foram usadas. A orientação vale para os três lugares onde a Northflank guarda segredos: variáveis dos workloads, secret groups e global secrets.

A Northflank liga os relatos de abuso a um padrão maior. No relatório "Black October" for AI Developer Platforms, publicado em 30/10, a Wiz lista nove plataformas para desenvolvedores de IA com incidentes divulgados em outubro, entre elas Railway, OpenCode, Warp, Lightning AI e a própria Northflank. O ponto em comum, segundo a Wiz, é a caça às variáveis de ambiente, com foco nas que dão acesso a modelos de IA. O nome do golpe é LLMjacking: usar a chave de outra pessoa para consumir modelos caros ou revender o acesso.

Por que uma chave de IA roubada vira conta alta tão rápido

Uma senha de banco roubada exige que o atacante chegue ao banco. Uma chave de API de IA funciona de qualquer lugar da internet, e cada chamada vira cobrança na conta de quem é dono da chave. Os dois casos que a Wiz detalhou mostram o ritmo:

• A primeira chamada com cada chave roubada aconteceu em até 30 minutos depois do acesso indevido ao fornecedor, só para testar se a chave funcionava.
• Nos dias seguintes vieram poucas chamadas por dia, de um verificador que só conferia se a chave continuava válida.
• Depois veio a enxurrada: cerca de 800 mil chamadas ao Amazon Bedrock em 30 horas num caso, e cerca de 1,7 milhão em 13 horas no outro. Pelos preços de tabela, os dois casos juntos passaram de US$ 100 mil em uso, segundo a Wiz.

Há duas lições aqui. A primeira é que o intervalo entre o teste e a enxurrada é a sua janela para girar a chave. A segunda é que, no outro caso, a chave tinha permissões restritas: o atacante passou horas recebendo erro antes de achar o caminho que a política permitia, e parte das chamadas esbarrou na cota regional da conta. Permissão estreita e teto de gasto não impedem o roubo, mas encolhem o estrago.

Primeiro passo: saber quais chaves existem

Ninguém gira o que não sabe que tem. Antes de abrir o painel de cada provedor, faça o inventário. Na Northflank, isso significa olhar as variáveis de cada serviço e job, os secret groups e os global secrets. Fora dela, vale procurar nos arquivos .env dos projetos, que quase sempre espelham o que foi colado na plataforma.

O script abaixo percorre uma pasta, acha arquivos .env* e classifica cada variável pelo formato do valor, sem imprimir a chave inteira (só os quatro últimos caracteres, para você reconhecer qual é qual no painel do provedor):

#!/usr/bin/env python3
"""Lista as chaves de IA (e outros segredos) em arquivos .env, sem imprimir o valor."""
import pathlib, re, sys

PROVEDORES = [
    ("Anthropic", re.compile(r"^sk-ant-")),  # antes da OpenAI: também começa com sk-
    ("OpenAI", re.compile(r"^sk-(proj-)?[A-Za-z0-9_-]{16,}")),
    ("Google (Gemini)", re.compile(r"^AIza[0-9A-Za-z_-]{20,}")),
]
NOME_SEGREDO = re.compile(r"(KEY|TOKEN|SECRET|PASSWORD|PASS|_URL)$", re.I)

def classifica(nome, valor):
    for prov, padrao in PROVEDORES:
        if padrao.match(valor):
            return prov
    if NOME_SEGREDO.search(nome):
        return "outro segredo"
    return None

raiz = pathlib.Path(sys.argv[1] if len(sys.argv) > 1 else ".")
for arq in sorted(raiz.rglob(".env*")):
    for n, linha in enumerate(arq.read_text(errors="ignore").splitlines(), 1):
        if "=" not in linha or linha.lstrip().startswith("#"):
            continue
        nome, valor = (p.strip().strip('"\'') for p in linha.split("=", 1))
        tipo = classifica(nome, valor)
        if tipo:
            print(f"{tipo:16} {nome:22} {arq}:{n}  final ...{valor[-4:]}")

Num projeto de teste com uma API e um worker, a saída foi esta:

outro segredo    DATABASE_URL           proj/api/.env:1  final ...db/x
OpenAI           OPENAI_API_KEY         proj/api/.env:2  final ...7890
Anthropic        ANTHROPIC_API_KEY      proj/api/.env:3  final ...4321
Google (Gemini)  GEMINI_API_KEY         proj/worker/.env.production:1  final ...lmno
outro segredo    STRIPE_SECRET_KEY      proj/worker/.env.production:2  final ...e123

Na primeira versão, a ordem da lista estava invertida, e a chave da Anthropic apareceu como OpenAI, porque as duas começam com sk-. Por isso a Anthropic vem antes. O formato do valor não é uma garantia: provedores mudam prefixos e há chaves sem prefixo nenhum. Use a lista como ponto de partida e complete com o que está na plataforma. Se as chaves também passaram por pipelines, vale repetir o raciocínio de como checar se os secrets do GitHub Actions vazaram.

A ordem da troca

Em rotação de rotina, a sequência segura é criar a chave nova, colocar no lugar, conferir que a aplicação funciona e só então revogar a antiga. É o roteiro descrito em rotação que tem dois passos, e é também o que a documentação do Google recomenda para a chave do Gemini.

Num vazamento confirmado, com a própria plataforma dizendo para supor que as variáveis foram decifradas, a conta muda. Cada minuto com a chave antiga ativa pode ser cobrança de outra pessoa. Se o provedor mostra uso que você não reconhece, revogue primeiro e aceite alguns minutos de erro na aplicação. A ordem por prioridade fica assim:

1. Chaves que viram dinheiro direto: provedores de IA e meios de pagamento.
2. Credenciais de nuvem (AWS, Google Cloud, Azure), que abrem acesso a muito mais coisa, inclusive a modelos.
3. Senhas de banco e de filas, usando a rotação que a Northflank liberou para os add-ons.
4. Tokens de serviços menores, como e-mail transacional, monitoramento e webhooks.

Ao colocar a chave nova, não repita o caminho que expôs a antiga em outro lugar. Ela não deve ir para o histórico do Git nem para uma camada de imagem, como mostramos em segredo fora da imagem Docker.

Como girar, limitar e vigiar em cada provedor

Os quatro provedores mais comuns em aplicações brasileiras têm ferramentas parecidas, mas com diferenças que importam na hora do incidente. A figura abaixo compara os quatro, e os detalhes vêm em seguida, com o link para a documentação oficial de cada um. Os nomes das telas são os da documentação em inglês.

OpenAI

A chave é revogada na página de API keys do projeto. O guia de boas práticas de produção da OpenAI recomenda definir data de expiração ao criar a chave de projeto e manter um processo regular de rotação: criar a substituta, atualizar a aplicação e revogar a antiga depois de conferir que a nova funciona. Administradores podem impor um tempo máximo de vida para as chaves da organização ou do projeto.

Para gasto, a página de limites aceita alertas por valor em dólar e um limite rígido mensal, que para o tráfego da API quando o gasto chega ao teto. Cada projeto pode ter limites próprios, o que permite separar produção de testes. O uso aparece por chave na página Usage, com uma ressalva: chaves criadas antes de 20 de dezembro de 2023 não têm esse rastreio ligado por padrão.

Anthropic (Claude)

No Claude Console, a chave suspeita é apagada na página de API keys, no menu ao lado dela. O artigo de boas práticas de chaves da Anthropic manda revogar imediatamente ao suspeitar de vazamento e acompanhar as páginas Logs e Usage. A Anthropic também participa do programa de secret scanning do GitHub, que avisa quando uma chave aparece em repositório público.

Segundo a documentação de limites, cada nível de uso tem um teto mensal de gasto, e você pode definir um limite próprio menor na página Billing. Também é possível limitar gasto e taxa por workspace, exceto no workspace padrão. Uma dica prática: crie um workspace por aplicação ou ambiente, com chave própria e limite próprio, e deixe o padrão sem uso. Assim, uma chave roubada esbarra no teto daquele workspace.

Google (Gemini API)

A página de chaves do Gemini descreve o roteiro em caso de vazamento: gerar a substituta no Google AI Studio ou no console do Google Cloud, publicar a aplicação com ela, desativar a antiga depois de conferir a nova e auditar o uso e a cobrança no console. Desde 28 de maio de 2026, as chaves novas criadas no AI Studio são do tipo auth key, restritas por padrão à API do Gemini, e a documentação diz que a API recusa chaves padrão sem restrição. Se você ainda tem uma chave antiga sem restrição, esta é a hora de trocá-la.

A página de cobrança mostra tetos mensais por nível da conta e tetos por projeto, este último ainda experimental. A própria documentação avisa que os dados de cobrança podem levar cerca de 10 minutos para aparecer no AI Studio e que o gasto pode passar do teto nesse intervalo. Para alertas por e-mail, os orçamentos do Cloud Billing funcionam como aviso e, nos serviços compatíveis, como teto.

Amazon Bedrock

O Bedrock aceita chaves de API de dois tipos, explicados na documentação de chaves do Bedrock. As de curto prazo duram até 12 horas e são as recomendadas para produção. As de longo prazo criam um usuário IAM com política anexada e, segundo a AWS, servem só para exploração. Uma chave longa é desativada com aws iam update-service-specific-credential --status Inactive e apagada com delete-service-specific-credential. Se o que estava na plataforma de deploy era uma access key da AWS, a troca é no IAM, e a revisão precisa incluir tudo que aquela identidade podia fazer.

Toda chamada ao Bedrock fica registrada no AWS CloudTrail, e o alerta de gasto vem do AWS Budgets. Os casos da Wiz eram justamente de Bedrock, e no segundo deles a política que só permitia certos perfis de inferência atrasou o abuso em horas. Restringir modelos e regiões na política IAM é a versão AWS do teto de gasto.

Como perceber o abuso antes da fatura

O padrão descrito pela Wiz deixa rastros que dá para procurar no painel de uso de qualquer provedor:

• Chamadas fora do horário da aplicação. Uma API de atendimento que só trabalha em horário comercial não deveria gastar às 3h.
• Modelos que você não usa. Os atacantes testaram um catálogo inteiro de modelos, um por chamada. Se a sua aplicação só chama um modelo pequeno e o uso mostra o modelo mais caro do provedor, a chave não é mais só sua.
• Volume que não bate com o tráfego. Compare as chamadas ao provedor com as requisições que a sua aplicação recebeu no mesmo período. O log da aplicação ajuda aqui, desde que ele mesmo não grave a chave, como explicamos em log sem senha.
• Pedidos de cota e listagem de modelos. No caso do Bedrock, o atacante listou cotas e modelos por região antes da enxurrada. No CloudTrail, esse tipo de consulta vinda de um IP que não é o seu servidor é um alarme claro.

Uma chave por aplicação e por ambiente torna tudo isso possível. Com uma chave só para produção, homologação e o notebook de alguém, não há como saber de onde veio o gasto estranho, e girar a chave derruba todos ao mesmo tempo.

O que fazer hoje, se você usa a Northflank

1. Liste as chaves de IA e de pagamento dos workloads, secret groups e global secrets.
2. Abra o painel de uso de cada provedor e olhe os dias desde 30/10, inclusive os anteriores, porque a Northflank não informou quando o acesso começou.
3. Revogue no provedor, gere a nova e atualize o segredo na Northflank. Reinicie os serviços que leem a variável só na partida.
4. Use a rotação liberada para os add-ons de Postgres, MongoDB, MySQL, Redis, MinIO e RabbitMQ, e desligue a exposição pública onde estiver ligada.
5. Abra os logs de auditoria, agora disponíveis em todos os planos, e procure acessos que ninguém da equipe reconhece.
6. Se houve uso indevido, reporte ao suporte da Northflank e ao provedor da chave, como a empresa pediu. Guarde capturas do painel de uso: elas ajudam a contestar a cobrança.

Para quem não usa a Northflank, o exercício é o mesmo, só que sem a pressa. Escolha uma chave de IA da sua aplicação e cronometre quanto tempo leva para trocá-la sem derrubar nada. Se passar de uma hora, o problema não é a plataforma.

Este texto será atualizado se a Northflank publicar a causa do incidente ou o número de clientes afetados. Última conferência das fontes: 31/10/2026, 23h55 (horário de Brasília).