Refael Angel, Co-Fundador e CTO da Akeyless – Série de Entrevistas

Refael Angel, Co-Fundador e CTO da Akeyless, é um líder em segurança cibernética e engenharia de software com experiência profunda em segurança de nuvem, criptografia, autenticação de máquina e infraestrutura de empresa. Desde a co-fundação da Akeyless em 2018, ele ajudou a construir a empresa em torno da gestão moderna de segredos e segurança de identidade para ambientes nativos da nuvem. Antes da Akeyless, ele trabalhou como Engenheiro de Software Sênior em Segurança na Intuit (INTU ), onde construiu sistemas para gerenciamento de chaves de criptografia em nuvem pública e autenticação de máquina, ganhando experiência prática em AWS, Go, Python, Java, PHP, Bash, Linux, Git e Jenkins. No início de sua carreira, Angel ocupou funções de engenharia de software em 3D Systems (DDD ) e Cimatron, desenvolvendo aplicações CAD/CAM e baseadas em Windows usando C/C++, C#, WPF, MFC e padrões de design orientados a objetos.

Akeyless é uma empresa de segurança de identidade focada em proteger máquinas, agentes de IA e humanos por meio de uma plataforma nativa da nuvem construída em torno da criptografia de conhecimento zero. Sua plataforma reúne gestão de segredos, gerenciamento de chaves de criptografia, gerenciamento de ciclo de vida de certificado, acesso privilegiado e segurança de identidade de máquina, fornecendo às organizações uma forma unificada de gerenciar credenciais, chaves, certificados e acesso em ambientes híbridos, multi-nuvem, DevOps e de IA. A posição da empresa reflete uma mudança mais ampla na segurança cibernética: à medida que as cargas de trabalho, serviços e agentes de IA realizam cada vez mais o acesso ao sistema sem envolvimento humano direto, as empresas precisam de controles mais fortes em torno de identidades não humanas, credenciais de curta duração, rotação automatizada e governança em tempo de execução.

Você co-fundou a Akeyless em 2018 após construir sistemas de gerenciamento de chaves de criptografia e autenticação de máquina na Intuit. Qual lacuna na segurança de nuvem e gestão de identidade o convenceu de que era hora de iniciar a Akeyless, e como essa visão original evoluiu à medida que os agentes de IA surgiram como uma nova classe de identidades digitais?

Na Intuit, eu fazia parte da equipe que construía sistemas de gerenciamento de chaves de criptografia e autenticação de máquina em um momento em que a Intuit era uma das primeiras grandes empresas a migrar para a nuvem. O que ficou claro para mim foi que toda organização que adotasse a nuvem eventualmente enfrentaria o mesmo problema que estávamos resolvendo internamente: como gerenciar segredos e chaves em infraestruturas distribuídas e dinâmicas. Construir isso internamente consome enormes recursos de engenharia, e não faz sentido que cada empresa reinvente a roda. A resposta lógica era um modelo de SaaS.

O problema era a confiança. Esse é o material mais sensível que uma empresa possui, e nenhuma organização séria dará a uma terceira parte a capacidade de acessá-lo. Então, o requisito era quase contraditório: entregá-lo como SaaS para escala e simplicidade, mas tornar arquitetonicamente impossível para o fornecedor ever ver os dados do cliente. Essa tensão é exatamente o que deu origem à Criptografia de Fragmentos Distribuídos (DFC). A DFC permite que executemos um plano de controle de SaaS totalmente gerenciado enquanto o cliente mantém um fragmento que nunca possuímos, então somos matematicamente incapazes de acessar suas chaves. Isso se tornou a base do modelo SaaS mais Zero-Conhecimento que a Akeyless é construída.

A visão original era sobre segurança de acesso humano e de máquina na nuvem. Os agentes de IA são a extensão natural e mais extrema desse mesmo problema. Eles são identidades não humanas que operam em uma escala e velocidade que nenhum diretório foi projetado para, e a mesma fundação de Zero-Conhecimento e identidade centrada agora se estende diretamente a eles.

Você é creditado como o arquiteto por trás da tecnologia de criptografia de confiança zero patenteada da Akeyless. Quais foram os maiores desafios técnicos ao construir um modelo de segurança que pudesse eliminar suposições de confiança e permanecer prático para grandes empresas?

A parte mais difícil foi tornar “não confie em ninguém” prático em vez de acadêmico. A maioria dos esquemas de chave dividida ou compartilhamento de segredos ainda monta a chave completa em algum momento, geralmente dentro de um único processo, HSM ou enclave no instante de uma operação criptográfica. Essa janela breve é exatamente o que os atacantes, insiders mal-intencionados e cenários de compulsão legal visam.

Com a DFC, a chave nunca é montada, nem na criação, nem em repouso e nem durante o uso. Fragmentos são gerados independentemente em domínios de confiança separados, e operações criptográficas são executadas como um cálculo distribuído onde cada detentor de fragmento computa sua parte localmente e apenas resultados parciais são trocados. O desafio de engenharia foi alcançar isso com a latência, taxa de transferência e confiabilidade que as grandes empresas exigem em produção.

Um segundo desafio, e um dos mais significativos, foi permitir a atualização contínua dos fragmentos. Tivemos que ser capazes de substituir cada fragmento por um novo valor matemático, em cada localização, enquanto a chave mestra que os fragmentos representam permanece inalterada e o processo criptográfico nunca é interrompido. Isso adicionou uma camada de segurança substancial à solução. Porque, com a atualização, um atacante não pode mais coletar fragmentos pacientemente ao longo do tempo. Um fragmento capturado na semana passada é matematicamente não relacionado aos fragmentos que existem hoje, então é ruído em vez de um ponto de partida. Para aprender algo sobre uma chave, um adversário teria que comprometer todos os locais de fragmento simultaneamente, dentro de uma única janela de atualização, e esse requisito se torna exponencialmente mais difícil à medida que locais, domínios de confiança e frequência de atualização aumentam. Combinado com o limite de tudo ou nada, onde 100% dos fragmentos são necessários para revelar algo e qualquer subconjunto estrito vazia zero informações, a atualização transforma o modelo de segurança de uma garantia estática em uma garantia limitada no tempo.

Muitas organizações estão correndo para implantar agentes de IA, mas a segurança de identidade muitas vezes permanece como uma segunda consideração. Quais são os erros mais comuns que as empresas cometem ao dar acesso a agentes de IA a sistemas e dados sensíveis da empresa?

O maior erro é tratar um agente como uma conta de serviço e dar a ele uma chave de API estática e de longa duração. Essa credencial se torna um ativo permanente e colhível que fica dentro de um ator não determinístico e injetável por prompt.

Os outros erros comuns que vejo: conceder privilégios permanentes em vez de acesso apenas no momento necessário, confiar em permissões baseadas em papéis grosseiros que descrevem o que um agente pode alcançar, mas nunca o que ele pretende fazer, dar a agentes caminhos de rede diretos para bancos de dados e APIs, de modo que um comprometimento se torne um movimento lateral, e não ter uma corrente de auditoria que ligue a ação do agente à prompt humana e ao gatilho que a acionou. Cada um desses é uma tentativa de reutilizar controles da era humana em algo que não se comporta como um humano.

A Akeyless argumentou que os agentes de IA exigem um modelo de identidade fundamentalmente diferente do que os humanos ou as cargas de trabalho de máquina tradicionais. O que torna os agentes de IA singularmente difíceis de proteger em comparação com os quadros de IAM e PAM existentes?

O erro central é tratar os agentes de IA como um novo tipo de usuário, ou mesmo um novo tipo de conta de serviço, e supor que eles possam ser integrados e governados como identidades humanas. Isso é um erro de categoria, por várias razões conectadas.

As identidades dos agentes não são enumeráveis. A instância específica que você deseja governar geralmente não existe ainda, e, no momento em que existe, ela já desapareceu. Um agente pode surgir em um Lambda, executar por 800 milissegundos e desaparecer antes que qualquer scanner o note, ou criar cadeias de subagentes em VMs, contêineres e servidores sem estado que se completam em segundos. Registrar esses em um diretório é tratar fantasmas como residentes: no momento em que a entrada é comprometida, a entidade que a descreveu já desapareceu.

O âncora correto, portanto, não é o agente, mas a identidade da carga de trabalho que o tempo de execução emite, o papel de execução do AWS, o token de conta de serviço do Kubernetes, o SVID do SPIFFE. Essa identidade já existe, é atestada pela plataforma em que o agente é executado e desaparece quando o agente desaparece. Porque as identidades são efêmeras, as únicas entidades estáveis para escrever política entre são os métodos de autenticação e os sistemas-alvo, e não identidades nomeadas e escopos.

E é aqui que os quadros de IAM e PAM existentes se quebram mais decisivamente: RBAC e ABAC estáticos não podem conter um ator não determinístico. Um agente com um token perfeitamente dimensionado e um TTL perfeitamente aplicado ainda pode ser injetado por prompt, alucinar uma consulta destrutiva ou mudar de uma tarefa de leitura para uma tarefa de gravação na mesma sessão, sem violação de política visível na camada de autorização. RBAC e ABAC avaliam na autenticação, não depois, porque o que acontece depois é decidido por um LLM que olha para uma janela de contexto que o autor da política não pode ver.

Portanto, os agentes são singularmente difíceis porque são efêmeros, não determinísticos, multi-substrato e injetáveis por prompt, todos ao mesmo tempo. A camada ausente não é um diretório melhor. É uma política de execução consciente da intenção em cada ação, mediada por um gateway que verifica o que o agente está realmente fazendo contra o que disse que faria, antes que qualquer credencial seja cunhada.

Há uma discussão crescente em torno de “arquiteturas sem segredos” para sistemas de IA. Como você define autenticação sem segredos, e por que você acredita que credenciais estáticas e chaves de API estão se tornando insustentáveis na era dos agentes autônomos?

A autenticação sem segredos significa que o agente nunca segura uma credencial. Em vez de dar ao agente uma chave que ele deve armazenar e apresentar, o agente se autentica por meio de sua identidade de carga de trabalho nativa, e uma credencial de curta duração e apenas no momento necessário é injetada em uma sessão intermediada no momento da execução, e então destruída quando a sessão termina. O agente nunca a vê.

Credenciais estáticas e chaves de API estão se tornando insustentáveis por um motivo simples: um segredo que um agente segura é um segredo que um atacante pode roubar. Em um mundo onde o ator que segura a credencial pode ser injetado por prompt ou alucinar, uma chave de longa duração se torna um vazamento de chave potencial. Remova a credencial do agente e um agente comprometido não tem nada para vazar. Esse é o ponto de todo o que chamamos de SecretlessAI.

À medida que os agentes de IA ganham a capacidade de planejar, executar ações e interagir com vários sistemas de forma independente, quais novos vetores de ataque o preocupam mais nos próximos três a cinco anos?

Os vetores que me preocupam mais todos derivam dos agentes serem capazes de planejar e agir em sistemas independentemente. A injeção de prompt que sequestra a intenção de um agente no meio de uma tarefa é o mais claro, porque a identidade permanece válida mesmo enquanto o comportamento se torna malicioso. Além disso, eu me preocupo com a transferência de agente para agente, onde a autoridade é passada ao longo de uma corrente sem responsabilidade clara, movimento lateral por meio de agentes que têm alcance de rede direto e exfiltração de dados, onde um agente super-permissionado puxa muito mais do que sua tarefa exige.

A linha comum é que a credencial e o papel podem ser perfeitamente legítimos enquanto a ação não é. Defesas que apenas verificam permissão, e não propósito, não capturarão nenhum desses. É por isso que a execução consciente da intenção em um gateway, em cada ação, é o controle que acredito que importará mais.

À medida que as empresas começam a gerenciar milhões de identidades não humanas em toda a infraestrutura, como você vê a mudança no equilíbrio de prioridades de segurança?

Estamos nos movendo para um mundo onde a esmagadora maioria do acesso ao sistema é realizada por identidades não humanas, máquinas, cargas de trabalho e agora agentes, mas a maioria das ferramentas ainda assume um humano atrás do teclado. O resultado é segredos por toda parte, privilégios permanentes e identidades que ninguém pode rastrear completamente.

A mudança nas prioridades é de controles periódicos e humanos para execução contínua e em tempo de execução em escala de máquina. Quando você gerencia milhões de identidades não humanas, não pode confiar em matrícula, campanhas de certificação e revisões de acesso trimestrais. Você precisa de identidade efêmera por construção, zero privilégio permanente e política avaliada automaticamente em cada ação. A segurança de identidade humana não some, mas se torna uma fração menor da superfície, e a arquitetura precisa ser construída para a maioria não humana primeiro.

Pesquisas recentes sugerem que os agentes de IA podem já estar acessando informações além de suas permissões pretendidas. Quais controles de governança e em tempo de execução as organizações devem ter em vigor antes de permitir que os agentes operem autonomamente em ambientes de produção?

Antes que qualquer agente opere autonomamente em produção, eu gostaria de ter algumas coisas em vigor. Primeiro, nenhuma credencial permanente no agente, com acesso apenas no momento necessário e de curta duração injetado por sessão. Segundo, nenhum caminho de rede direto, então cada ação do agente é intermediada por um ponto de estrangulamento obrigatório em vez de alcançar bancos de dados e APIs diretamente. Terceiro, política de execução consciente da intenção que avalia o propósito de um pedido contra o prompt de origem antes que qualquer credencial seja cunhada, então um agente solicitado para analisar receita não pode emitir um comando destrutivo. Quarto, inspeção e mascaramento de resposta em sessão, para que dados sensíveis como PII e PHI sejam editados antes de entrarem na janela de contexto do agente. E quinto, um único registro de auditoria imutável que liga o prompt humano, a intenção classificada, o veredito da política, a sessão e a ação final.

Descoberta e visibilidade também importam, mas como entradas para a política, não como um pré-requisito para proteção. Você deve ser capaz de governar um agente na primeira vez que ele se autentica, mesmo se você nunca viu essa instância específica antes.

A indústria muitas vezes se concentra na segurança do modelo, mas menos atenção é dada à identidade, autorização e controle de acesso. Por que você acredita que essas áreas se tornarão alguns dos principais desafios de segurança da era de IA?

A segurança do modelo ganha as manchetes, mas um modelo perfeitamente alinhado ainda precisa agir no mundo real, e no momento em que age, ele precisa de acesso a sistemas e dados. É onde o acesso é que o dano real acontece. O risco se materializa na fronteira de autorização.

Autorização também é a parte mais difícil da segurança dos agentes, porque o ator é não determinístico e efêmero. Você não pode resolver isso puramente na camada do modelo, e você não pode resolver isso com papéis estáticos. Requer execução contínua e consciente da intenção em cada ação. É um trabalho de infraestrutura sem glamour, que é exatamente por que é menos discutido e exatamente por que será um dos problemas de segurança mais consequenciais dessa era.

Olhando para o futuro, você acredita que as empresas eventualmente exigirão uma camada de identidade dedicada para os agentes de IA, semelhante à forma como os provedores de identidade se tornaram essenciais para os usuários humanos, e como essa arquitetura futura pareceria?

Sim, mas não se parecerá com o modelo de provedor de identidade humano simplesmente rebrandado para agentes. Tentar construir um diretório de agentes é construir um diretório para fantasmas, identidades que desaparecem antes que você termine a matrícula.

A camada de identidade do agente que eu espero será ancorada na identidade da carga de trabalho que o tempo de execução emite, IAM da nuvem, tokens de conta de serviço do Kubernetes, federação OIDC e padrões como SPIFFE/SPIRE que já são comprovados em produção e multi-substrato. A autorização será expressa como relações entre métodos de autenticação e sistemas-alvo, e não entre identidades nomeadas e escopos. E o centro de gravidade será um plano de execução em tempo de execução, um gateway que intermediará cada ação, classificará a intenção, injetará credenciais efêmeras, mascarará respostas sensíveis e produzirá uma corrente de auditoria completa. A identidade ainda importa, mas cai no lugar atrás da execução, e não na frente. Essa camada de autoridade em tempo de execução, sentada na mesma plataforma que já governa o acesso humano e de máquina, é o que acredito que todas as empresas que executam agentes em produção acabarão precisando.

Obrigado pela grande entrevista, leitores que desejam aprender mais devem visitar Akeyless.