Segurança de chaves de API de IA
Mantenha suas chaves de provedor fora das suas aplicações. Dê a cada aplicação, agente e ferramenta uma chave do gateway do INFRO, com botão de desligar, lista de permissões de IP, limites de modelos e limite de gastos, cada um verificado antes de o seu provedor ser chamado.
4 verificações
Em cada requisição, antes de o seu provedor ser chamado.
32 redes
Por chave na lista de IPs permitidos, IPv4 ou IPv6, em todos os planos.
Sem deploy
Para desativar uma chave vazada. Toda requisição com ela é recusada.
AES-256-GCM
Em cada chave do provedor que você conecta. Ela nunca é mostrada de novo.
Onde ficam as chaves de provedor
A mesma chave de provedor costuma estar em cinco lugares, e qualquer cópia pode gastar de toda a conta. Com o INFRO, a chave de provedor fica selada em um só lugar e cada aplicação, agente e ferramenta tem a própria chave do gateway. Escolha onde o vazamento acontece.
sk-proj-••••7Hc2Copiada em 5 lugaressk-proj-••••7Hc2Vazou aquisk-proj-••••7Hc2Mesma chavesk-proj-••••7Hc2Mesma chavesk-proj-••••7Hc2Mesma chavesk-proj-••••7Hc2Mesma chavesk-proj-••••7Hc2Protegida no INFROsk_infro_••••a91f$50 por dia203.0.113.0/24Vazou, contidask_infro_••••3c7e$10 por dia203.0.113.64/27Não afetadask_infro_••••5d20$5 por diaExpira em 30 diasNão afetadask_infro_••••8b14$20 por diaSomente AnthropicNão afetadask_infro_••••e602$15 por mês1 modeloNão afetadaQuatro verificações
Cada verificação recusa com seu próprio código documentado, para que seus logs digam exatamente o motivo, e cada uma é ajustada pelo console ou pela API sem deploy. As quatro estão em todos os planos.
Esta chave está ativa?
Desligue uma chave pelo console ou pela API e toda requisição com ela é recusada. O segredo, os limites e o histórico dela são mantidos; ligá-la de novo restaura a mesma chave.
403 key_disabledDocumentação
A chamada vem dos seus servidores?
Até 32 endereços IPv4 ou IPv6 ou faixas CIDR por chave, comparados com o endereço de cliente que a borda da Cloudflare informa, nunca com X-Forwarded-For. Sem um endereço confiável, a requisição é recusada.
403 ip_not_allowedDocumentação
Este modelo é permitido?
Aprove os modelos que uma organização, projeto ou chave pode chamar e os provedores que uma chave pode alcançar. Cada chave pertence a um ambiente e nunca alcança uma conexão fora dele.
403 model_not_allowedDocumentação
O limite dela cobre esta requisição?
Um limite diário, semanal, mensal ou vitalício por chave, ao lado de orçamentos por organização, projeto e membro. Uma requisição que o limite não consegue cobrir é recusada antes de o provedor ser chamado.
402 key_budgetDocumentação
Tetos de gastos
Uma chave vazada, um agente preso em loop, um cliente automatizando o uso do seu plano gratuito: cada um para em um teto do seu próprio tamanho em vez de atingir todo o seu orçamento. Cada teto aplicável é verificado antes de o seu provedor ser chamado, contando o pior caso das requisições já em andamento.
Os tetos se somam
Uma requisição precisa caber em todos os tetos que se aplicam a ela. O mais apertado decide, então um teto pequeno no lugar certo detém um problema muito antes do teto da organização.
A chave para em $50 no dia. Todas as outras chaves continuam atendendo.
| Teto | Período | Como funciona | Recusada com | Plano |
|---|---|---|---|---|
| Organização | Meta mensal e teto rígido | A meta alerta; o teto rígido alerta ou bloqueia. Somente o proprietário o define. | 402 organization_budget | Todos os planos |
| Projeto | Mensal | Alertar ou bloquear, com alertas nos seus próprios limiares. | 402 project_budget | Todos os planos |
| Membro | Mensal | Alertar ou bloquear, para a atividade de uma pessoa. | 402 member_budget | Todos os planos |
| Chave do gateway | Diário, semanal, mensal ou vitalício | Sempre bloqueia. Um limite vitalício nunca é reiniciado. | 402 key_budget | Todos os planos |
| Cliente final | Diário, semanal ou mensal | Uma regra para todo cliente, por organização ou projeto, com exceções que o seu backend define. | 402 end_user_budget | Team e superiores |
Testado sob cargaEm um teste em sandbox, um teto bloqueante de $1 se manteve em 12 de 12 execuções com até 500 requisições simultâneas (o teste e seu método). Os tetos contam a estimativa do INFRO do custo do provedor, não a fatura do seu provedor, e um modelo sem preço conhecido é recusado sob um teto bloqueante, a menos que você o permita; por isso, mantenha também um limite de gastos no provedor. Documentação de controles de gastos
Uma chave vazou
Para uma chave do gateway do INFRO. Se vazou uma chave de provedor, exclua-a primeiro no provedor: é a única coisa que a interrompe.
curl -X PATCH https://api.infro.io/manage/v1/gateway_keys/$KEY_ID \
-H "Authorization: Bearer $INFRO_MANAGEMENT_TOKEN" \
-H 'If-Match: "7"' \
-H "Content-Type: application/json" \
-d '{"disabled": true}'
# Every request with the key: 403 key_disabled
# Its secret, limits and history are kept.As mesmas três mudanças estão na página da chave no console. Com a API de gerenciamento, uma mudança exige a versão que você leu por último (If-Match), para que duas pessoas contendo o mesmo incidente não sobrescrevam uma à outra.
Em vez disso, vazou uma chave de provedor?
Segredos em prompts
As pessoas colam arquivos .env em chats e agentes os leem a partir de shells. No plano Business, os guardrails verificam prompts, chamadas de ferramentas e respostas em busca de formatos de segredos e, então, bloqueiam a requisição, substituem a ocorrência por [SECRET] ou a sinalizam, antes de o seu provedor ser chamado.
A detecção é baseada em padrões: ela reconhece estes formatos e nada mais, então não detecta chaves de acesso secretas da AWS, senhas e formatos que não conhece. Cada ocorrência é contada no registro da requisição. Documentação de guardrails
Agentes, ferramentas e pessoas
Claude Code, Codex e os SDKs de agentes chamam /v1/messages e /v1/responses do INFRO com uma chave do gateway em vez da sua chave da Anthropic ou da OpenAI. Dê uma a cada desenvolvedor ou agente, com limite de gastos, validade e uma lista de permissões de rede; revogá-la não afeta mais ninguém.
Registre cada servidor MCP uma única vez com seu token. O INFRO o adiciona em cada chamada, então nenhum agente, prompt ou arquivo de configuração o guarda, e cada chave do gateway recebe apenas as ferramentas que lhe foram concedidas.
Dois fatores com app autenticador, passkeys e chaves de hardware, uma lista de sessões que você pode encerrar e uma configuração da organização que exige dois fatores de todos os membros. Login único SAML ou OIDC e SCIM a partir do plano Business.
As chaves que guardamos
Uma plataforma que armazena chaves de provedor é exatamente o que os ataques de outubro visaram, então as mesmas perguntas valem para nós. Estes controles são as declarações do próprio Trust Center, palavra por palavra.
O que o INFRO não pode fazer
Uma chave de provedor obtida do INFRO, ou de qualquer outro lugar, pode ser usada diretamente no provedor, fora de todos os limites do INFRO. Conecte chaves com escopo restrito ao próprio projeto ou workspace, com um limite de gastos definido no provedor: é o controle que se mantém mesmo se nós falharmos. O que ainda não está implementado está listado no Trust Center.
Outubro de 2026
Nos dois casos, a orientação foi a mesma: substituir a chave, excluir a antiga no provedor e ver o que ela fez. Quanto menos lugares uma chave de provedor ocupa, menos rotações um vazamento custa; as chaves que você distribui devem ter limites que você ajusta sem deploy.
O que a Railway disse
An unauthorized party may have accessed encrypted customer environment variables and, for some of them, obtained the decrypted contents, in a series of attacks aimed at compromising AI inference providers.
O que fazer
Troque toda variável que a Railway guardava, começando pelas chaves de provedores de IA: substitua, exclua a chave antiga no provedor, faça o deploy e revise o uso da chave antiga.
Railway breach: what happened and what to doRevisado em 22 de outubro de 2026
O que a OpenCode disse
A breach related to a large-scale distillation attack affected 1.4% of OpenCode Console users, those with external AI providers linked, and provider keys saved in a workspace may have been exposed.
O que fazer
Crie uma substituta com escopo, revogue a chave antiga no provedor e revise o uso no provedor a partir de 16 de outubro.
OpenCode Console breach: what happened and what to doRevisado em 21 de outubro de 2026
Cada resumo vem da divulgação da própria empresa, conforme citada em nossa análise. Os dois incidentes estavam em aberto quando foram escritos; as análises são revisadas semanalmente e registram cada mudança em suas notas de revisão.
Guias práticos
Perguntas frequentes
Crie uma chave substituta no provedor, exclua lá a chave vazada, faça o deploy da substituta e depois revise o uso da chave antiga no provedor durante todo o tempo em que ela poderia ter sido usada. Excluir a chave no provedor é o que a interrompe; nada que uma aplicação ou um gateway faça consegue recolher uma chave roubada. Depois, dê à substituta um limite de gastos no provedor e mantenha-a fora de código, de apps cliente e de ambientes compartilhados.
Suas aplicações guardam chaves de gateway do INFRO em vez das suas chaves de provedor. Cada chave de gateway pode ser desligada (403 key_disabled), limitada a até 32 redes (403 ip_not_allowed), restrita a modelos e provedores aprovados e ter um limite de gastos diário, semanal, mensal ou vitalício (402 key_budget). Toda verificação roda antes de o seu provedor ser chamado, em todos os planos, e nenhuma exige deploy. Uma chave de gateway vazada é um problema delimitado que você pode desligar; uma chave de provedor vazada alcança toda a conta do provedor.
Sim. Os orçamentos se aplicam por organização (uma meta mensal que alerta e um teto rígido que alerta ou bloqueia), por projeto e por membro (mensal) e por chave de gateway (diário, semanal, mensal ou um limite vitalício que nunca reinicia). A partir do plano Team, os limites de clientes finais restringem cada um dos seus próprios clientes por dia, semana ou mês, com exceções para clientes específicos. Cada teto aplicável é verificado antes de o seu provedor ser chamado, contando o pior caso das requisições já em andamento, e uma requisição recusada é um 402 que nomeia o teto. Os tetos contam a estimativa do INFRO para o custo do provedor, não a fatura do seu provedor, então mantenha também um limite de gastos no provedor.
Sim: você conecta as suas próprias chaves de provedor uma vez e o INFRO as usa para atender as suas requisições. Cada uma é criptografada com AES-256-GCM sob uma chave mantida como segredo do Worker fora do banco de dados, com a organização e a conexão vinculadas, de modo que uma cópia do banco de dados sozinha não abre nada. Nenhuma tela do console, endpoint ou exportação devolve uma credencial salva; o console mostra os últimos quatro caracteres. As chaves de gateway são armazenadas apenas como digest SHA-256.
Sim. O INFRO governa apenas o tráfego que passa por ele. Uma chave de provedor tirada de qualquer lugar, inclusive do INFRO, pode ser usada diretamente contra o provedor, fora de todos os limites do INFRO. Conecte chaves com escopo no próprio projeto ou workspace, com um limite de gastos definido no provedor: esse limite vale mesmo que nós falhemos. No plano Business, a reconciliação com acesso ao uso ativado informa o uso de uma chave conectada que não passou pelo INFRO.
A OpenCode disse em 17 de outubro de 2026 que uma violação relacionada a um ataque de destilação em larga escala afetou 1,4% dos usuários do Console dela, aqueles com provedores de IA externos vinculados, e que chaves de provedor salvas em um workspace podem ter sido expostas. A Railway disse em 21 de outubro de 2026 que uma parte não autorizada pode ter acessado variáveis de ambiente criptografadas de clientes e decifrado algumas delas, em ataques voltados a comprometer provedores de inferência de IA. Nos dois casos o conselho é o mesmo: substitua a chave, exclua a antiga no provedor e revise o uso dela. O INFRO tem uma análise de cada caso, escrita apenas a partir das declarações das próprias empresas.
No plano Business, os guardrails verificam prompts e respostas em busca de formatos OpenAI, Anthropic, Chave de API do Google, ID de chave de acesso da AWS, Token do GitHub, Token do Slack, Chave live do Stripe e Chave do INFRO, JWTs e chaves privadas PEM e bloqueiam a requisição, substituem o trecho por [SECRET] ou a sinalizam antes que o seu provedor a veja. A detecção é por padrões: ela não percebe formatos que não conhece, como chaves secretas de acesso da AWS e senhas.
Não pelo INFRO. Eles chamam /v1/messages e /v1/responses do INFRO com uma chave de gateway, de modo que cada desenvolvedor ou agente pode ter a própria chave com limite de gastos, expiração e, opcionalmente, uma lista de redes permitidas, e revogá-la não afeta o acesso de mais ninguém. Um agente ainda pode ler qualquer chave deixada no mesmo shell, então remova chaves de provedor brutas dos ambientes de desenvolvimento.
LLMjacking é o uso de credenciais roubadas de nuvem ou de APIs de IA para chamar modelos de linguagem hospedados às custas da vítima, seja para uso do próprio atacante, seja para revender o acesso. A defesa é a de qualquer credencial que pode gastar dinheiro: manter chaves de provedor fora do código e de apps cliente, dar a cada chave um limite de gastos, acompanhar o uso por chave e poder desligar uma chave sem fazer deploy.
Todos os planos incluem desligar uma chave, redes permitidas, limites de modelos e provedores, limites de gastos, rotação e expiração, login em dois fatores e passkeys e o log de auditoria. Os alertas de gastos vão por e-mail em todos os planos e, a partir do plano Startup, para o Slack e para webhooks assinados. Guardrails, SSO e SCIM, reconciliação de custos com detecção de bypass e o gateway MCP estão no plano Business.
Conformidade, a lista completa de controles e o que ainda não está implementado estão no Trust Center. Encontrou uma vulnerabilidade? Escreva para security@infro.io.
Começar
Seus provedores, seus contratos, suas chaves, selados em um só lugar. Cada chave que você distribui, limitada e com botão de desligar. 0% de margem sobre os gastos com modelos.