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

Jacob Ideskog é um especialista em identidade e CTO da Curity. A maior parte do seu tempo é gasta trabalhando com soluções de segurança no espaço de API e Web. Ele trabalhou com o design e implementação de soluções OAuth e OpenID Connect para grandes empresas e startups.

Curity é 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 garantir a autenticação e autorização seguras para aplicativos, APIs e serviços digitais em larga escala. Ela suporta protocolos como OAuth 2.0 e OpenID Connect para centralizar fluxos de login, impor 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 é projetada para flexibilidade e escalabilidade, permitindo que as organizações implantem em nuvem, híbrida ou ambiente local, integrem com sistemas existentes e forneçam experiências de usuário seguras e sem interrupções sem depender de infraestrutura de segurança personalizada.

Você passou grande parte da sua carreira construindo sistemas de identidade e segurança de API, desde co-fundar a Curity até liderá-la como CTO durante o surgimento da nuvem e agora da IA. Como essa jornada moldou sua visão de que os agentes de IA devem ser tratados como identidades digitais de primeira classe, e não apenas como outro pedaço de software?

Em todos os campos de tecnologia que trabalhei, um problema sempre ressurge. Seja computação em nuvem ou agora IA, se o software age em nome de uma pessoa ou outro sistema, você tem um problema de identidade.

Com a adoção em massa de IA agente, esse problema é agravado. O comportamento deles não é mais rigidamente programado e eles operam com um nível de autonomia que as empresas nunca viram antes. Os agentes de IA tomam decisões, chamam APIs e encadeiam ações em vários sistemas – frequentemente sem supervisão humana direta. Esse comportamento cria desafios de identidade e acesso que são fundamentalmente diferentes dos tradicionais softwares.

Tratar os agentes de IA como identidades digitais de primeira classe é a única maneira de abordar isso adequadamente. Se as organizações os tratam como apenas outro processo ou conta de serviço, elas perdem visibilidade e controle rapidamente – e isso é uma receita para uma crise de segurança.”

Muitas empresas estão animadas com a IA agente, mas permanecem presas na experimentação. A partir do que você vê em implantações reais, quais são as lacunas de identidade e governança mais comuns que impedem as organizações de escalonar agentes com segurança?

A maioria da experimentação acontece em ambientes de areia isolados que ignoram o que acontece em escala. Durante os primeiros pilotos, as equipes frequentemente dão aos agentes chaves de API amplas, credenciais compartilhadas ou permissões de nuvem em branco apenas para colocar as coisas em andamento.

Essa abordagem desmorona no momento em que os agentes são implantados além dos pilotos. Isso ocorre porque as equipes de segurança não podem ver quais dados um agente acessou, suas ações ou se ele pode ou ultrapassou seu escopo pretendido; seja acidentalmente ou com má-fé. Esses pontos cegos tornam impossível governar os agentes com segurança, o que é por que muitas organizações lutam para ir além dos pilotos.”

Você argumentou que guardrails estritos são essenciais para a IA agente. O que “bom” design de identidade parece para os 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 estreitamente definidas e relações de confiança claramente definidas (regras explícitas para quais sistemas ele é permitido interagir). Fundamentalmente, o acesso deve ser vinculado a um propósito, restrito no tempo e fácil de revogar.

Onde as empresas erram é reutilizando contas de serviço existentes ou supondo que os agentes internos são seguros por padrão. Essa suposição não se sustenta contra ameaças do mundo real. Atores mal-intencionados ativamente procuram exatamente esses pontos fracos, e os agentes de IA aumentam dramaticamente o raio de explosão quando o design de identidade é frouxo.”

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

Os padrões abertos são absolutamente críticos. As empresas já executam tecidos de identidade complexos que abrangem plataformas de nuvem, serviços SaaS e APIs internas. A IA agente apenas adiciona mais complexidade.

Sem padrões, cada agente se torna sua própria integração e uma exceção de segurança permanente. 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 que pode facilitar a escalabilidade segura em ambientes empresariais reais.”

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

A principal diferença entre os agentes de IA modernos e as identidades não humanas (INH) mais antigas é a autonomia. Uma conta de serviço tradicional faz exatamente o que seu código diz para fazer, rigidamente vinculada à sua tarefa. Um agente de IA interpreta instruções, adapta seu comportamento e toma ações que nunca foram explicitamente programadas – aumentando o perigo potencial se não houver guardrails apropriados.

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

Quão importantes são os registros de auditoria e o registro baseado em identidade para governar a IA agente, especialmente em setores regulamentados?

Os registros de auditoria não devem ser “bons para ter”. Eles precisam ser construídos desde o início. Em ambientes regulamentados, as organizações são esperadas para responder a perguntas simples, mas críticas: o que esse agente acessou, quando aconteceu e quem o autorizou?

O registro baseado em identidade é a única maneira confiável de obter esse nível de responsabilidade. Ele também desempenha um papel fundamental na resposta a incidentes. Sem um contexto de identidade claro, é quase impossível saber se um problema veio de um agente mal comportado, uma identidade comprometida ou simplesmente um prompt ruim.

Quais riscos do mundo real você vê surgindo quando as organizações implantam agentes de IA superprivilegiados ou mal monitorados em produção?

Um risco comum é a agregação silenciosa de dados. Um agente superprivilegiado pode puxar informações sensíveis de vários sistemas (registros de clientes, documentos internos, logs) e expor esses dados por meio de prompts, resumos ou integrações externas.

Outro risco é os agentes com acesso administrativo fazendo mudanças significativas em velocidade de máquina, causando muito mais danos do que um humano poderia em um curto período de tempo. Isso pode incluir modificar recursos de nuvem, desabilitar controles de segurança ou acionar fluxos de trabalho automatizados sem supervisão.

Esses incidentes podem ser mal-intencionados, mas não precisam ser. Um agente superprivilegiado ou mal monitorado poderia simplesmente estar operando com suposições desatualizadas ou incorretas, ampliando erros em vários sistemas antes que alguém note.

Mas, do ponto de vista de um atacante, uma identidade de agente comprometida é extremamente valiosa. Ela permite movimento lateral em APIs e serviços, frequentemente com um nível de acesso que nenhum usuário humano seria concedido. Sem controles de identidade fortes e monitoramento, as organizações frequentemente só descobrem essas falhas após danos reais terem sido feitos.”

Para as empresas que estão migrando de pilotos para implantações reais de IA agente, quais decisões de identidade e acesso devem ser tomadas cedo para evitar redesenho caro mais tarde?

As organizações devem decidir cedo como os agentes são emitidos identidades, como permissões são aprovadas e como o acesso é revisado ao longo do tempo, definindo limites de identidade antecipadamente.

Trazer controles de identidade de forma retroativa é quase sempre problemático. Os agentes são frequentemente incorporados profundamente em fluxos de trabalho usando credenciais compartilhadas ou papéis amplos, então restringir o acesso após o fato quebra suposições que o sistema depende. Isso eventualmente causa falhas de fluxo de trabalho e mina a confiança na tecnologia. É muito mais barato, não mencionando mais seguro, projetar identidades, escopos e limites de acesso adequados desde o início.

Onde a integração de identidade mais frequentemente se torna um gargalo ao implantar IA agente, e quais são as melhores práticas para reduzir a fricção?

O gerenciamento de identidade pode se tornar um gargalo, mas apenas quando é tratado como uma afterthought. As equipes se concentram em construir capacidades de agente impressionantes primeiro, apenas para mais tarde perceber que precisam ser integradas com sistemas IAM, gateways de API e plataformas de logging para serem verdadeiramente seguras.

A melhor abordagem é começar com uma compreensão clara e uma implementação adequada de plataformas de identidade, e então projetar os agentes para se encaixar nelas. As organizações devem reutilizar padrões e infraestrutura existentes em vez de contorná-los; cortar essa esquina inevitavelmente causará problemas mais tarde. Quando a identidade é construída desde o início, ela acelera a implantação em vez de desacelerá-la.

Para líderes de segurança e engenharia que desejam abraçar a IA agente, mas estão preocupados com a governança e o risco, que conselho você daria enquanto planejam sua estratégia?

Desacelere apenas o suficiente para obter as fundações certas. Os agentes de IA devem ser tratados como identidades e, portanto, você precisa aplicar a mesma governança que espera dos humanos e insistir na visibilidade desde o início. Se uma organização fizer isso, então a escalabilidade da IA agente se torna um exercício de segurança, não um salto cego e arriscado de fé.

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