Saltar para o conteúdo principal
Uma chave apareceu em um commit público, um log de CI, um screenshot ou um breach de fornecedor. O relógio está correndo: qualquer um segurando aquela string sk-orca-… pode gastar seu saldo e dirigir seus agentes até você cortá-la. Esta página é o runbook de incidente — corte a credencial primeiro, depois audite o que ela fez — para clientes gerenciando suas próprias chaves no console. A mecânica do ciclo de vida (desabilitar vs. deletar, estados de chave, papéis) vive em Gerenciar chaves; esta página é a sequência sob ataque e, criticamente, o que verificar na trilha de auditoria uma vez que o sangramento parou.
Pare o gasto antes de investigar. Uma chave com escopo, com um limite credit_limit_usd e uma lista allow_ips, limita o dano, mas uma chave vazada sem limites pode queimar saldo por quanto tempo permanecer viva. Revogue primeiro; forense em segundo.

​
1. Revogue a chave de api vazada (faça isso primeiro)

Você tem dois movimentos de corte, ambos na tela Keys do console (/console/token). Ambos exigem o papel de Developer ou superior — a ação roda no seu token de sessão / acesso, nunca em uma chave de relay.

Desabilitar — pausa reversível

Vire o status da chave para Disabled. Toda requisição que ela faz é rejeitada imediatamente, mas a chave, seus limites, seus anexos de política e seu histórico de uso permanecem intactos. Use isto quando você precisa da config e dos logs preservados enquanto investiga.

Deletar — revogação permanente

Escolha Delete na chave. A credencial nunca pode autorizar uma requisição novamente e não é recuperável. Use isto uma vez que o vazamento está confirmado e você capturou o que precisa da trilha.
Um padrão comum: desabilite instantaneamente no momento em que você suspeita de exposição (contenção de latência zero, nada perdido), rode a auditoria em §3–§4, depois delete uma vez que você escopou o raio de explosão. Faça o que fizer, emita uma chave nova para a substituição — nunca re-habilite uma credencial que foi vista na natureza. A transição sem downtime está em Rotação de chave.
Desabilitar ou deletar entra em vigor na próxima requisição — não há redeploy e nenhum atraso de propagação.

​
2. Já que você está nisso, aperte a substituição

Um vazamento é o momento de corrigir o escopo que o deixou machucar. A chave de substituição deveria carregar a identidade mais estreita que a carga de trabalho de fato precisa, para que o próximo vazamento seja um não-evento:
Uma lista de permissão de IP significa que uma chave vazada é inútil de qualquer endereço que não o seu. Requisições de IPs não listados são rejeitadas na camada de auth antes de custar qualquer coisa.
Um limite de gasto (0 = ilimitado) limita o pior caso. Uma chave vazada com um teto semanal rígido não pode drenar o saldo do seu workspace.
Os limites de modelo impedem um ladrão de trocar sua chave barata para o seu modelo mais caro.
Uma expiração (-1 = nunca) significa que uma chave que escapa à sua atenção ainda para de autorizar por conta própria.
Veja a Checklist de menor agência para a postura completa de uma-chave-por-agente.

​
3. Audite os logs de requisição — o que a chave chamou?

Com a credencial cortada, escope o dano. Cada chamada de relay que essa chave fez é registrada nos logs de requisição do seu workspace, e cada linha carrega os campos que você precisa para reconstruir o incidente:
CampoO que ele diz a você
token_name / token_idQual chave — confirme que você está olhando a vazada.
ipO endereço de origem de cada chamada. Uma rajada de um IP que você não reconhece é a prova cabal.
modelo + usoQuais modelos foram atingidos e quanto custaram — sua exposição de gasto.
Filtre a visão de log para a chave vazada e ordene por tempo. Duas perguntas respondem “quão ruim é isso” mais rápido:
  1. Há tráfego de um IP que não é seu? Isso é uso indevido confirmado, não um alarme falso.
  2. O gasto ou o padrão de chamada teve um pico ao redor da janela do vazamento? Um salto súbito é a pegada do atacante.
Se a chave carregava uma lista allow_ips, chamadas de fora dela nunca autorizaram em primeiro lugar — então a ausência de linhas de IP estrangeiro é por si só um atestado de boa saúde. É exatamente por isso que fixar a origem (§2) transforma um vazamento em um não-evento.

​
4. Leia a trilha de política — o que ela tentou fazer?

Os logs de requisição dizem o que a chave chamou; os planos de política dizem o que ela tentou fazer o modelo dizer ou fazer, e se seus guardrails e firewall a pegaram. Ambos têm escopo de workspace. As correspondências de guardrail são legíveis por qualquer membro do workspace; a visão de Events / Runs do firewall exige o papel de Developer ou superior (as políticas e configurações de firewall permanecem abertas a cada membro).

Correspondências de guardrail

Toda vez que o tráfego da chave atingiu uma regra de guardrail, um registro de correspondência caiu em GET /api/guardrail/match — carregando o tipo de regra, action (block / mask / flag), stage e o detalhe ofensor. Filtre para a janela da chave vazada para ver que conteúdo ela empurrou (PII, segredos, tentativas de jailbreak).

Eventos de firewall

Cada chamada de ferramenta que a chave emitiu é um evento de firewall — allow, audit, deny, sanitize ou retido. Uma sequência de eventos deny é um agente que tentou algo que não tinha permissão. Consolide-os por run na visão Events / Runs.
Algumas especificidades que vale saber enquanto você lê a trilha:
  • As correspondências de guardrail registram a substring correspondida apenas se “Log raw content” estava ligado para aquele guardrail (está desligado por padrão) — então uma linha de correspondência pode mostrar a regra e a ação sem o texto bruto. O tipo / ação / stage estão sempre lá.
  • mark-fp em uma correspondência (POST /api/guardrail/match/:id/mark-fp, Admin) deixa você sinalizar um hit como falso positivo para que ele pare de distorcer sua visão de incidente — não o use para enterrar uso indevido real.
  • Os denies de firewall são pré-ferramenta. Um evento deny significa que a chamada de ferramenta do atacante foi bloqueada antes de chegar à ferramenta — o firewall já conteve aquela ação. O evento é sua evidência de que ela tentou.
Faça referência cruzada das três trilhas na mesma janela de tempo: um IP estrangeiro nos logs de requisição, um pico de correspondências de guardrail, e um cluster de eventos deny de firewall juntos pintam o quadro completo — o que o atacante tinha, o que ele tentou e o que foi parado.

​
5. Após o incidente

Reverifique a lista Keys: a chave vazada deveria ler Disabled ou ter sumido inteiramente. Se você só a desabilitou, agende o delete uma vez que você terminou a auditoria — veja Gerenciar chaves.
Mova o tráfego para a nova chave, com escopo mais apertado, antes de aposentar a antiga para que nunca haja um gap sem chave funcional. Transição completa: Rotação de chave.
Se a chave vazada não tinha allow_ips, nem credit_limit_usd, e model_limits amplos, esse é o achado real. Dê a cada agente sua própria chave estreitamente escopada — a Checklist de menor agência e Escopo & chaves percorrem toda a postura.

​
6. Relacionado

Gerenciar chaves

Desabilitar vs. deletar, estados de chave e os portões de papel por trás de cada ação.

Rotação de chave

A transição sem downtime de uma chave comprometida para uma limpa.

Lista de permissão de IP

Fixe uma chave aos seus endereços de origem para que um vazamento não possa ser usado em outro lugar.

Exfiltração de dados

A ameaça que uma chave vazada mais frequentemente alimenta, e como a superfície de egress do firewall a limita.
Toda a sequência é curta de propósito: revogue, depois audite. Quanto mais estreito o escopo de cada chave para começar, menor a auditoria que você tem de rodar — e mais rápido uma credencial vazada vai de emergência a nota de rodapé.