Uma empresa havia integrado a API de inferência de IA de um fornecedor aos seus fluxos de trabalho de ciência de dados, oferecendo aos seus analistas e cientistas de dados acesso programático ao modelo de linguagem do fornecedor para apoio à pesquisa e processamento de documentos. O portal do desenvolvedor do fornecedor emitia chaves de API que autenticavam o acesso ao ponto de extremidade de inferência. As chaves eram geradas por projeto em um portal de autosserviço e não estavam sujeitas aos controles padrão de gestão de credenciais da empresa, que se aplicavam a credenciais de infraestrutura, mas não haviam sido estendidos às chaves de API de IA. Um cientista de dados que trabalhava em um projeto de prova de conceito incorporou a chave de API em um notebook Jupyter para simplificar o fluxo de desenvolvimento. O notebook foi enviado para um repositório do GitHub compartilhado com colegas para colaboração. O repositório estava configurado como público por padrão: o desenvolvedor pretendia torná-lo privado, mas não o fez antes de enviar o notebook com a chave incorporada. Um bot de varredura de credenciais descobriu a chave exposta em seis semanas e começou a usá-la para fazer chamadas de inferência ao modelo de IA do fornecedor. O operador do bot consumiu uma parcela significativa da cota mensal de limite de requisições da empresa, gerou cobranças de API na conta da empresa e teve acesso aos padrões das consultas enviadas ao modelo, o que potencialmente revelava os temas de pesquisa e os fluxos de processamento de documentos da empresa. O modelo de IA do fornecedor não foi violado. A chave de API da empresa, gerada pelos canais normais, gerenciada fora do programa de gestão de credenciais e exposta por meio de um fluxo de desenvolvimento padrão, era toda a superfície de ataque.
O que é, de fato, a exposição de chaves de API de IA?
A exposição de chaves de API de IA é o risco de segurança criado quando credenciais que autenticam o acesso a APIs de modelos de IA (chaves emitidas por portais de desenvolvedores de fornecedores de IA, pontos de extremidade de inferência e infraestrutura de disponibilização de modelos) são geradas, gerenciadas, armazenadas e usadas fora do programa de gestão de credenciais estabelecido pela empresa. A proliferação de chaves de API de IA por meio de portais de autosserviço para desenvolvedores, ambientes de notebooks de ciência de dados e ferramentas de desenvolvimento com IA criou uma nova categoria de credenciais à qual as empresas nem sempre estenderam suas práticas padrão de higiene de credenciais.
O caminho de exposição pelo fluxo de trabalho dos desenvolvedores é o principal mecanismo de risco. As chaves de API de IA são frequentemente usadas em contextos exploratórios e de desenvolvimento (notebooks de ciência de dados, projetos de prova de conceito, prototipagem rápida), nos quais o fluxo de desenvolvimento prioriza a velocidade de iteração em detrimento da higiene de segurança. Incorporar credenciais em notebooks Jupyter, configurá-las em arquivos de ambiente enviados ao controle de versão e compartilhar diretórios de projetos que contêm credenciais por meio de ferramentas de colaboração são padrões comuns em fluxos de trabalho de ciência de dados que criam riscos sistemáticos de exposição de credenciais.
O ponto cego da categoria de credenciais de IA é a lacuna de governança. Os programas corporativos de gestão de credenciais normalmente tratam das credenciais de infraestrutura (chaves de acesso de provedores de nuvem, credenciais de bancos de dados, tokens de contas de serviço) por meio de políticas, ferramentas e monitoramento. As chaves de API de IA emitidas por portais de desenvolvedores de fornecedores muitas vezes ficam fora do escopo desses programas porque não são credenciais de infraestrutura no sentido tradicional. Elas são emitidas por um canal diferente (o portal do desenvolvedor do fornecedor), usadas em um contexto diferente (notebooks de ciência de dados, e não infraestrutura de produção) e gerenciadas por pessoas diferentes (cientistas de dados e analistas, e não equipes de TI). O ponto cego do programa de gestão de credenciais é a credencial do portal do fornecedor de IA.
A variação do raio de impacto entre provedores de IA é uma dimensão importante. A consequência de uma chave de API de IA exposta varia significativamente conforme o fornecedor e o escopo de permissões da chave. Uma chave com acesso apenas a chamadas de inferência expõe a empresa a abuso de custos de API e à divulgação de padrões de consulta. Uma chave com acesso ao ajuste fino de modelos expõe a empresa a treinamento não autorizado de modelos na infraestrutura do fornecedor. Uma chave com acesso às APIs de gestão de dados do fornecedor pode expor dados de treinamento ou dados organizacionais armazenados com o fornecedor. Entender o escopo de permissões das chaves de API emitidas é essencial para avaliar a consequência da exposição.
Por que isso importa
A exposição de chaves de API de IA é importante para TPRM porque as relações da empresa com fornecedores de IA, cada vez mais numerosas à medida que a IA é incorporada às funções de negócio, geram uma população crescente de credenciais que autenticam o acesso a recursos sensíveis de IA e podem expor o modelo do fornecedor aos padrões de consulta e aos dados da empresa. Cada relação com fornecedor de IA que gera chaves de API fora do programa de gestão de credenciais da empresa é um risco sistemático de exposição de credenciais.
Onde a maioria das equipes erra
A falha mais recorrente é estender a governança da gestão de credenciais às credenciais de infraestrutura e tratar as chaves de API de fornecedores de IA como fora do escopo do programa, porque elas são emitidas por portais de desenvolvedores de fornecedores, e não provisionadas pela TI, e porque os principais usuários são cientistas de dados, e não engenheiros.
- Chaves de API de fornecedores de IA fora do programa de gestão de credenciais
- Emissão de chaves pelo portal do desenvolvedor não acompanhada pela TI nem pela segurança
- Ambiente de notebooks de ciência de dados não coberto pela política de higiene de credenciais
- Escopo de permissões das chaves não avaliado: o que a chave pode acessar além da inferência
- Varredura de credenciais não aplicada aos repositórios de projetos de IA
Como é uma boa prática
Programas maduros de segurança de credenciais de IA estendem explicitamente a governança da gestão de credenciais às chaves de API de fornecedores de IA, incluindo o rastreamento da emissão, o armazenamento em infraestrutura aprovada de gestão de segredos, políticas de rotação e a varredura automatizada de repositórios de desenvolvimento em busca de credenciais de IA expostas.
- Registro de chaves de API de IA: todas as chaves acompanhadas com responsável, escopo e data de expiração
- Integração com gestão de segredos: chaves de IA armazenadas em cofre, e não em notebooks ou arquivos de configuração
- Varredura automatizada de credenciais: repositórios verificados em busca de chaves de API de IA expostas
- Delimitação de permissões das chaves: permissões mínimas necessárias para o caso de uso de cada chave
- Política para o fluxo de trabalho de desenvolvimento: requisitos de manuseio de chaves de API de IA em ambientes de ciência de dados
Ferramentas
Varredura de credenciais: GitHub secret scanning, GitLeaks, TruffleHog para detecção de chaves de API de IA
As ferramentas de varredura de credenciais detectam chaves de API e segredos em repositórios de controle de versão. A maioria das principais ferramentas de varredura inclui padrões de detecção para os formatos de chave de API dos principais fornecedores de IA: OpenAI, Anthropic, Cohere, Hugging Face. Para profissionais de TPRM, perguntar se os repositórios de desenvolvimento do fornecedor passam por varredura automatizada em busca de credenciais de API de IA expostas é uma pergunta específica sobre exposição de credenciais.
Gestão de segredos: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault para armazenamento de credenciais de IA
As plataformas de gestão de segredos oferecem armazenamento centralizado, rotação e registro de acesso para credenciais, incluindo chaves de API de IA. Para profissionais de TPRM, perguntar se as chaves de API de IA do fornecedor são armazenadas em uma plataforma de gestão de segredos, e não na configuração da aplicação, em notebooks ou em arquivos de ambiente, é uma pergunta específica sobre higiene de credenciais.
Desafios de governança
O desafio de governança na gestão de chaves de API de IA é a tensão com a cultura dos desenvolvedores. Os fluxos de trabalho de ciência de dados e de engenharia de ML tradicionalmente operam com mais informalidade na gestão de credenciais do que a engenharia de produção: a natureza exploratória do trabalho gera pressão por conveniência em detrimento da higiene. A solução de governança são ferramentas que tornem a gestão segura de credenciais o caminho de menor resistência: a injeção de segredos nos ambientes de desenvolvimento, que elimina a necessidade de incorporar credenciais em notebooks ou arquivos de configuração.
- Estenda explicitamente a política de gestão de credenciais às chaves de API de fornecedores de IA
- Implemente a varredura automatizada de chaves de API de IA em todos os repositórios de desenvolvimento
- Exija gestão de segredos para credenciais de IA: nada de incorporá-las em notebooks ou arquivos de configuração
- Acompanhe a emissão de chaves de API pelos portais de desenvolvedores: notifique a equipe de segurança sobre a geração de novas chaves
- Restrinja as chaves de API de IA às permissões mínimas necessárias
Se você faz parte de uma equipe pequena
Execute uma varredura de credenciais em todos os repositórios onde ocorre desenvolvimento de ciência de dados e de IA, procurando especificamente os formatos de chave de API de cada fornecedor de IA que a empresa usa. A maioria das principais ferramentas de varredura tem padrões para chaves da OpenAI, Anthropic, Cohere e Hugging Face. Essa única varredura revelará se credenciais de IA foram enviadas ao controle de versão. Em seguida, peça aos seus fornecedores de IA que listem todas as chaves de API ativas emitidas para a sua organização: comparar essa lista com o que o seu inventário de credenciais contém revelará chaves que as equipes de TI e de segurança não estão acompanhando.
- Execute uma varredura de credenciais em todos os repositórios de projetos de ciência de dados e de IA
- Peça aos fornecedores de IA que listem todas as chaves de API ativas emitidas para a sua organização
- Compare a lista de chaves do fornecedor com o inventário de credenciais da empresa
- Exija gestão de segredos para todas as credenciais de API de IA
O que exigir
Pergunte diretamente:
“Vocês podem fornecer uma lista de todas as chaves de API atualmente emitidas para a nossa organização, incluindo o escopo de permissões e a data do último uso de cada uma? E vocês têm monitoramento que alertaria a nossa equipe de segurança se uma chave emitida para nós fosse usada a partir de um endereço IP fora da faixa de rede esperada?”
O que esperar como evidência
- Inventário de chaves de API ativas da organização
- Escopo de permissões de cada chave emitida
- Capacidade de alerta sobre uso anômalo de chaves
- Processo e prazo de revogação de chaves
Um fornecedor que confirma a autenticação por chave de API deve ser questionado sobre o inventário de chaves ativas. A autenticação confirma que o mecanismo funciona. O inventário de chaves revela se aquilo que ele autentica está sob o controle da empresa.
Como comprovar
- Registro e inventário de chaves de API de IA
- Registros de varredura de credenciais dos repositórios de projetos de IA
- Implementação de gestão de segredos para credenciais de IA
- Registros de escopo e rotação de chaves
Principal conclusão
Portal do desenvolvedor. Chave de API. Notebook Jupyter. Repositório público no GitHub. Bot de varredura de credenciais. Seis semanas. A chave seguiu o caminho normal da emissão à exposição sem acionar nenhuma detecção no programa de gestão de credenciais da empresa, porque as chaves de API de IA emitidas por portais de desenvolvedores de fornecedores estavam fora do escopo do programa. As credenciais de infraestrutura são gerenciadas. As chaves de fornecedores de IA são credenciais de fluxos de trabalho de ciência de dados às quais o programa não foi estendido. A varredura encontra as chaves expostas. O registro acompanha as chaves emitidas. A plataforma de gestão de segredos impede a incorporação. A delimitação de escopo limita o raio de impacto quando a exposição ocorre apesar da prevenção. Os quatro são necessários para fechar a lacuna entre o portal do desenvolvedor e o repositório público.