Durante anos, os líderes de segurança cibernética se preocuparam com senhas roubadas.
Agora considere um cenário diferente.
Um atacante descobre uma aplicação de IA voltada para a Internet. Uma falha de software desativou inadvertidamente a autenticação que a protege. O atacante entra, instrui um agente de IA em execução no servidor a revelar uma chave API e, em seguida, usa essa chave por três semanas.
O resultado?
Aproximadamente $600,000 em créditos de modelo de IA não autorizados consumidos.
Foi o que aconteceu com a organização sem fins lucrativos de avaliação de IA Metr, de acordo com um relatório recente da DataBreachToday.
Felizmente para a Metr, o desenvolvedor do modelo forneceu esses créditos sem custo, então a organização não recebeu uma conta de $600,000. A Metr também disse que sua investigação não encontrou evidências de que o invasor obteve qualquer coisa além de uma chave API fornecendo acesso a modelos publicamente disponíveis.
Mas acho que focar apenas no valor do dólar perde a história mais importante.
Uma chave API não é mais apenas um segredo.
Em uma empresa orientada por IA, as credenciais representam cada vez mais Autoridade, Capacidade e Poder Econômico.
E isso significa que precisamos começar a tratar a identidade da máquina com a mesma seriedade que historicamente reservamos para a identidade humana.
O ataque não começou Com Algumas técnicas exóticas de IA
Um dos aspectos mais interessantes deste incidente é o quão comum eram seus começos.
De acordo com Metr, um pesquisador estava executando agentes de IA em um servidor de nuvem pessoal. Um aplicativo nesse servidor era acessível a partir da internet e deveria exigir a autenticação do Google.
Mas uma falha de software desativou a autenticação.
A aplicação tinha sido construída usando AI-assisted "codificação vibe" e permaneceu exposto à internet pública por vários dias. Metr suspeita que um invasor pode ter descoberto enquanto pesquisava sites relacionados à IA recém-registrados para exibir credenciais do modelo-provedor.
Uma vez dentro, o atacante teria instruído um agente de IA em execução no servidor para divulgar a chave API da Metr. O atacante também instalou uma chave SSH para manter o acesso.
Há algo quase irônico nessa sequência.
Uma aplicação de IA ajudou a criar o ambiente.
Uma falha de autenticação abriu a porta.
Um agente de IA foi convidado a revelar a credencial.
E a credencial de máquina roubada forneceu a capacidade econômica.
Não foi simplesmente um ataque de IA.
Foi a Falha de confiança que ocorre dentro de um ambiente de IA.
E eu acredito que vamos ver muitas mais variações desse problema.
Precisamos parar de pensar na identidade como exclusivamente humana
Quando a maioria dos executivos ouve “segurança de identidade”, eles ainda pensam naturalmente nas pessoas.
Empregados.
Clientes.
Administradores.
Empreiteiros.
usuários privilegiados.
Mas a população de identidade corporativa está mudando rapidamente.
As aplicações têm identidades.
APIs têm credenciais.
As contas de serviço têm privilégios.
As cargas de trabalho autenticam-se a outras cargas de trabalho.
Os agentes de IA interagem cada vez mais com aplicativos, bancos de dados, serviços em nuvem e outros agentes.
E ao contrário de um funcionário humano que eventualmente vai para casa à noite, as identidades das máquinas podem operar continuamente e em velocidade extraordinária.
Isso muda as consequências potenciais da confiança extraviada.
Uma conta de funcionário comprometida pode permitir que um invasor execute quaisquer ações que o funcionário esteja autorizado a realizar.
Uma credencial de máquina comprometida pode potencialmente permitir que sistemas automatizados executem ações autorizadas milhares ou milhões de vezes.
O problema de identidade não desapareceu.
Tornou-se velocidade de máquina.
Autenticação é apenas o começo
Há outra lição aqui que eu acredito que é particularmente importante.
Muitas vezes falamos sobre autenticação como se a autenticação bem-sucedida completasse a decisão de segurança.
Não tem.
Autenticação respostas:
Quem és tu?
Respostas de autorização:
O que você tem permissão para fazer?
Mas em um ambiente de IA, precisamos cada vez mais de perguntas adicionais:
Que recursos estão solicitando acesso?
Com que serviço se comunica?
Que autoridade lhe foi delegada?
Qual é o objetivo do pedido?
Até quando essa autoridade deve existir?
Quanto pode consumir?
E em que ponto um ser humano deve ter que aprovar o que acontece a seguir?
Essa última pergunta vai se tornar particularmente importante.
A IA expande drasticamente o que o software pode fazer de forma autônoma.
Portanto, a segurança tem que se tornar muito mais deliberada sobre O que o software deve ser permitido fazer de forma autônoma.
$600,000 é uma história de autorização
Considere a chave API roubada em si.
Uma vez que o atacante o possuía, a chave aparentemente forneceu autoridade suficiente para consumir aproximadamente US $ 600,000 em créditos modelo ao longo de três semanas.
Por que essa atividade não foi imediatamente interrompida?
Metr explicou que suas avaliações normalmente consomem um grande número de tokens e rotineiramente geram erros de limite de taxa e API. Seu monitoramento também não mostrou todos os pedidos rejeitados. E como os créditos do modelo foram fornecidos gratuitamente, não havia limite de gastos para acionar um alerta ou interromper a atividade.
Isso é fascinante do ponto de vista da segurança.
A atividade poderia esconder, pelo menos temporariamente, o comportamento interno que não era necessariamente incomum para o meio ambiente.
A credencial era utilizável.
O serviço aceitou.
O consumo continuou.
O que leva a uma pergunta desconfortável:
Deve a posse de uma credencial de máquina válida conferir automaticamente tudo o que a credencial é tecnicamente capaz de fazer?
Em um ambiente cada vez mais autônomo, eu não acho que a resposta pode sempre ser sim.
Privilégio mínimo está prestes a se tornar muito mais importante
A resposta de Metr é instrutiva.
Após os incidentes, a organização disse que formalizou revisões de segurança para pesquisadores que colocam aplicativos na internet pública e adicionou alertas de gastos às chaves do API.
Também isolou aplicações voltadas ao público de sistemas internos, expandiu o registro e o monitoramento, encurtou vidas de credenciais, reduziu permissões, contratou um lead de segurança e fechou a infraestrutura legada que aumentou sua superfície de ataque.
Essas não são apenas medidas de limpeza.
Eles apontam para a arquitetura que as empresas precisarão cada vez mais à medida que a adoção da IA acelera:
Credenciais de curta duração.
Permissões de escopo.
Isolamento.
Monitoramento contínuo.
Limites de uso.
Context-aware autorização.
aprovação humana para ações consequenciais.
Em outras palavras:
Dê às máquinas autoridade suficiente para realizar a tarefa, não autoridade suficiente para se tornar o incidente.
Agentes da IA nos forçarão a separar identidade Da Autoridade
É aqui que eu acredito que a conversa de IA se torna particularmente interessante.
Suponha que um funcionário autorize um agente de IA a realizar uma tarefa.
Isso cria várias identidades e relações de confiança simultaneamente.
Há o humano.
Aí está o agente.
Há o serviço que o agente está tentando acessar.
A credencial está sendo usada.
Há a autoridade delegada pelo humano ou organização.
E há a ação que o agente quer realizar.
Essas coisas não podem simplesmente entrar em colapso em:
"A credencial é válida, portanto prossiga."
A credencial pode ser válida enquanto o contexto estiver errado.
O agente pode ser legítimo enquanto a ação solicitada é inadequada.
O ser humano pode ser autorizado enquanto o agente tiver recebido privilégios excessivos.
O destino pode ser autêntico, enquanto a quantidade gasta é anormal.
Ou, como Metr experimentou, uma credencial legítima poderia simplesmente ter caído nas mãos de outra pessoa.
A identidade nos diz quem ou o que está agindo. A confiança determina se devemos permitir o que acontece a seguir.
Isso é maior do que o gerenciamento de chave API
Seria fácil ler este incidente e concluir que as organizações simplesmente precisam proteger melhor as chaves API.
Eles têm.
Mas acho que essa interpretação é muito estreita.
Este incidente aponta para uma transição muito maior que ocorre em toda a segurança da empresa.
Estamos nos movendo de um ambiente dominado por Identidades humanas utilizando aplicações para um povoado por humanos, aplicativos, APIs, cargas de trabalho e agentes autônomos agindo em nome um do outro.
Isso significa que nosso modelo de confiança tem que evoluir com eles.
Na Identité®, temos argumentado que a confiança digital moderna precisa responder mais do que uma única pergunta no login.
É cada vez mais necessário considerar:
Identidade + Autenticação + Destino + Intenção + Contexto + Autorização
O Full Duplex Authentication® faz parte dessa filosofia mais ampla porque a confiança não deve simplesmente fluir em uma direção. A parte que solicita a autenticação também importa.
Mas a IA amplia ainda mais o desafio.
Quando as máquinas começam a agir por nós, também temos que estabelecer quem autorizou a máquina, qual autoridade foi delegada, onde essa autoridade pode ser exercida, quanto tempo ela deve existir e quando um ser humano precisa retornar à decisão.
Isso não é apenas uma autenticação mais forte.
Essa é uma arquitetura diferente para a confiança.
A IA mais perigosa pode ser a IA que autorizamos
As discussões de segurança cibernética sobre inteligência artificial se concentram no que os atacantes farão com a IA.
Melhor phishing.
Reconhecimento mais rápido.
Descoberta automatizada de vulnerabilidades.
Representação mais convincente.
Essas ameaças são reais.
Mas há outro problema de segurança da IA em desenvolvimento dentro de nossas próprias organizações.
Estamos rapidamente dando às máquinas credenciais, acesso e autoridade porque isso cria uma enorme produtividade.
E devemos.
O objetivo não deve ser impedir que os agentes de IA atuem.
Deve ser para garantir que sua autoridade seja proporcional à tarefa, limitada em duração e difícil de herdar ou roubar.
Porque a próxima chave API comprometida pode não fornecer acesso a $600,000 em créditos de modelo livre.
Pode autorizar transações financeiras.
Acesse os registros dos clientes.
Modificar os sistemas de produção.
Mova dados sensíveis.
Fluxos de trabalho de gatilho.
Ou instruir outro agente de IA para agir.
As consequências econômicas do comprometimento da identidade da máquina serão cada vez mais determinadas não apenas pelo fato de o atacante obter uma credencial.
Eles serão determinados por Quanta autoridade lhe atribuímos.
Os líderes de segurança da pergunta devem estar perguntando
O incidente de Ther nos dá um vislumbre útil de um futuro que chega mais rápido do que muitas organizações imaginam.
A questão da segurança já não é simplesmente:
“Como autenticamos nosso povo?”
Está a tornar-se:
Como estabelecer e governar a confiança entre pessoas, máquinas e agentes autônomos?
Isso nos obriga a pensar de forma diferente sobre autenticação, autorização, intenção, contexto, privilégio e identidade em si.
Porque em uma empresa orientada por IA, uma credencial pode não mais simplesmente desbloquear uma conta.
Pode desbloquear a capacidade.
E quando a capacidade pode operar de forma autônoma, contínua e à velocidade da máquina, as consequências de confiar na identidade errada podem escalar tão rapidamente.
Quanto mais autoridade damos às máquinas, mais deliberadamente devemos controlar quem, ou o que, é permitido exercê-lo.
Os atacantes não precisam derrotar todos os controles de segurança.
Eles só têm que se tornar alguém, ou algo assim, esses controles foram ensinados a confiar.
E na era da IA, "alguma coisa" pode se tornar a palavra mais importante nessa frase.