Jacob Ideskog, CTO da Curity – Série de Entrevistas

Jacob Ideskog é Especialista em Identidade e CTO da Curity. A maior parte do seu tempo é dedicada a soluções de segurança em APIs e na Web. Ele tem experiência tanto no design quanto na implementação de soluções OAuth e OpenID Connect para grandes empresas e também para pequenas startups.

Curidade é uma plataforma moderna de gerenciamento de identidade e acesso (IAM) construída em torno do Curity Identity Server, uma solução baseada em padrões projetada para proteger a autenticação e autorização de aplicativos, APIs e serviços digitais em escala. Ela oferece suporte a protocolos como OAuth 2.0 e OpenID Connect para centralizar fluxos de login, aplicar políticas de acesso refinadas e emitir tokens seguros para usuários humanos e clientes de máquina, incluindo APIs e serviços. A plataforma foi projetada para flexibilidade e escalabilidade, permitindo que as organizações a implementem em ambientes de nuvem, híbridos ou locais, integrem-se a sistemas existentes e ofereçam experiências de usuário seguras e perfeitas sem depender de infraestrutura de segurança personalizada.

Você dedicou grande parte da sua carreira à construção de sistemas de identidade e segurança de APIs, desde a cofundação da Curity até a sua atuação como CTO durante a ascensão da nuvem e, agora, da IA. Como essa trajetória moldou sua visão de que os agentes de IA devem ser tratados como identidades digitais de primeira classe, e não apenas como mais um software?

Em todas as áreas da tecnologia em que trabalhei, um problema sempre ressurge. Seja na computação em nuvem ou agora na IA, se um software estiver agindo em nome de uma pessoa ou de outro sistema, você terá um problema de identidade.

Com a adoção em massa da IA ​​agente, esse problema se agrava. Seu comportamento não é mais rigidamente programado e eles operam com um nível de autonomia nunca antes visto pelas empresas. Os agentes de IA tomam decisões, acessam APIs e encadeiam ações em diversos sistemas — muitas vezes sem supervisão humana direta. Esse comportamento cria desafios de identidade e acesso que são fundamentalmente diferentes dos softwares tradicionais.

Tratar os agentes de IA como identidades digitais de primeira classe é a única maneira de lidar adequadamente com isso. Se as organizações os tratarem como apenas mais um processo ou conta de serviço, perderão visibilidade e controle muito rapidamente – e isso é a receita para uma crise de segurança.”

Muitas empresas estão entusiasmadas com a IA agente, mas ainda estão presas na fase de experimentação. Com base no que você observa em implementações reais, quais são as lacunas mais comuns de identidade e governança que impedem as organizações de escalar agentes com segurança?

A maior parte da experimentação ocorre em ambientes isolados que ignoram o que acontece em grande escala. Durante os projetos-piloto iniciais, as equipes costumam fornecer aos agentes chaves de API amplas, credenciais compartilhadas ou permissões irrestritas na nuvem apenas para dar início ao projeto.

Essa abordagem falha no momento em que os agentes são implantados além dos projetos-piloto. Isso ocorre porque as equipes de segurança não conseguem ver quais dados um agente acessou, suas ações ou se ele pode ou excedeu seu escopo pretendido, seja acidentalmente ou maliciosamente. Esses pontos cegos tornam impossível governar os agentes com segurança, e é por isso que muitas organizações têm dificuldade em ir além dos projetos-piloto.

Você argumentou que diretrizes rígidas são essenciais para a IA ativa. Como seria um "bom" design de identidade para agentes de IA na prática, e onde as empresas geralmente erram?

Um bom design de identidade começa com o princípio do menor privilégio e permissões vinculadas a intenções explícitas. Cada agente de IA deve ter sua própria identidade, permissões de escopo restrito e relações de confiança claramente definidas (regras explícitas sobre com quais sistemas ele pode interagir). Fundamentalmente, o acesso deve ser limitado a um propósito específico, restrito no tempo e fácil de revogar.

O erro das empresas reside na reutilização de contas de serviço existentes ou na suposição de que os agentes internos estão seguros por padrão. Essa suposição não se sustenta diante de ameaças reais. Atores maliciosos buscam ativamente justamente esses pontos fracos, e agentes de IA aumentam drasticamente o potencial de impacto quando o design de identidade é falho.

A Curity trabalha há muito tempo com padrões como OAuth e OpenID Connect. Quão importantes são os padrões de identidade abertos para tornar a IA orientada a agentes interoperável e segura em ambientes empresariais complexos?

Padrões abertos são absolutamente essenciais. As empresas já operam com estruturas de identidade complexas que abrangem plataformas em nuvem, serviços SaaS e APIs internas. A IA agética apenas adiciona mais complexidade.

Sem padrões, cada agente se torna uma integração independente e uma exceção permanente de segurança. Com padrões como OAuth e OpenID Connect, os agentes podem ser autenticados, autorizados e auditados como qualquer outra carga de trabalho. Essa é a única abordagem capaz de facilitar a escalabilidade segura em ambientes corporativos reais.

Identidades não humanas estão se tornando mais comuns, desde contas de serviço até identidades de máquinas. O que torna os agentes de IA fundamentalmente diferentes das identidades não humanas anteriores do ponto de vista da segurança?

A principal diferença entre os agentes de IA modernos e as identidades não humanas (INHs) mais antigas reside na autonomia. Uma conta de serviço tradicional executa exatamente o que seu código lhe instrui, estando estritamente vinculada à sua tarefa. Um agente de IA interpreta instruções, adapta seu comportamento e realiza ações que nunca foram explicitamente programadas – tudo isso aumentando o potencial de perigo caso não haja mecanismos de proteção adequados.

Um pequeno erro de identidade ou de acesso pode rapidamente se transformar em uma catástrofe, pois um agente pode agir com rapidez e em vários sistemas. Do ponto de vista da segurança, isso representa um risco significativo.

Qual a importância dos registros de auditoria e do registro baseado em identidade para a governança de IA ativa, especialmente em setores regulamentados?

Os registros de auditoria não devem ser um "recurso desejável". Eles precisam ser incorporados desde o início. Em ambientes regulamentados, espera-se que as organizações respondam a perguntas simples, porém cruciais: a que esse agente acessou, quando isso aconteceu e quem o autorizou?

O registro baseado em identidade é a única maneira confiável de obter esse nível de responsabilização. Ele também desempenha um papel fundamental na resposta a incidentes. Sem um contexto de identidade claro, é quase impossível saber se um problema foi causado por um agente com comportamento inadequado, uma identidade comprometida ou simplesmente um prompt incorreto.

Quais riscos reais você prevê quando as organizações implantam agentes de IA com privilégios excessivos ou monitoramento inadequado em produção?

Um risco comum é a agregação silenciosa de dados. Um agente com privilégios excessivos pode extrair informações confidenciais de vários sistemas (registros de clientes, documentos internos, logs) e, em seguida, expor esses dados por meio de prompts, resumos ou integrações externas.

Outro risco reside em agentes com acesso administrativo realizarem alterações significativas em alta velocidade, causando danos muito maiores do que um ser humano jamais conseguiria em um curto período de tempo. Isso pode incluir a modificação de recursos na nuvem, a desativação de controles de segurança ou o acionamento de fluxos de trabalho automatizados sem supervisão.

Esses incidentes podem ser maliciosos, mas não necessariamente. Um agente com privilégios excessivos ou mal monitorado pode simplesmente estar operando com base em premissas desatualizadas ou incorretas, amplificando erros em vários sistemas antes que alguém perceba.

Mas, da perspectiva de um atacante, uma identidade de agente comprometida é extremamente valiosa. Ela permite a movimentação lateral entre APIs e serviços, muitas vezes com um nível de acesso que nenhum usuário humano jamais teria. Sem controles e monitoramento de identidade robustos, as organizações geralmente só descobrem essas falhas depois que danos reais já foram causados.

Para empresas que estão passando de projetos-piloto para implantações reais de agentes, quais decisões sobre identidade e acesso devem ser tomadas antecipadamente para evitar reformulações dispendiosas posteriormente?

As organizações devem decidir desde o início como as identidades dos agentes são atribuídas, como as permissões são aprovadas e como o acesso é revisto ao longo do tempo, definindo os limites de identidade antecipadamente.

Implementar controles de identidade retroativamente é quase sempre problemático. Os agentes geralmente estão profundamente integrados aos fluxos de trabalho usando credenciais compartilhadas ou funções amplas, portanto, restringir o acesso posteriormente quebra as premissas nas quais o sistema se baseia. Isso acaba causando falhas nos fluxos de trabalho e mina a confiança na tecnologia. É muito mais barato, sem mencionar muito mais seguro, projetar identidades, escopos e limites de acesso adequados desde o início.

Em que situações a integração de identidade se torna um gargalo com mais frequência na implementação de IA orientada a agentes, e quais são as melhores práticas para reduzir esse atrito?

A gestão de identidades pode se tornar um gargalo, mas apenas quando é tratada como uma reflexão tardia. As equipes se concentram primeiro em construir recursos impressionantes para os agentes, apenas para depois perceberem que precisam ser integrados a sistemas IAM, gateways de API e plataformas de registro para serem verdadeiramente seguros.

A melhor abordagem é começar com uma compreensão clara e a implementação adequada das plataformas de identidade e, em seguida, projetar agentes que se integrem a elas. As organizações devem reutilizar os padrões e a infraestrutura existentes em vez de ignorá-los; cortar custos inevitavelmente causará problemas mais tarde. Quando a identidade é integrada desde o início, a implementação é acelerada em vez de atrasada.

Para líderes de segurança e engenharia que desejam adotar IA ativa, mas estão preocupados com governança e riscos, que conselhos você daria ao planejarem seu roteiro?

Diminua o ritmo o suficiente para estabelecer as bases corretamente. Os agentes de IA devem ser tratados como identidades, portanto, é necessário aplicar a mesma governança que se espera para humanos e insistir na visibilidade desde o início. Se uma organização fizer isso, a expansão da IA ​​assistida por agentes se torna um exercício de segurança, e não um salto de fé cego e arriscado.

Obrigado pela ótima entrevista, os leitores que desejam saber mais devem visitar Curidade.