Sean Blanchfield, Co-Fundador e CEO da Jentic – Série de Entrevistas

Sean Blanchfield, Co-Fundador e CEO da Jentic, é um empreendedor serial de tecnologia com décadas de experiência em construir empresas de software e infraestrutura em grande escala. Com sede em Dublin, ele atualmente lidera a Jentic, enquanto também serve no Conselho Consultivo de Inteligência Artificial da Irlanda, aconselhando o governo sobre políticas de inteligência artificial. No início de sua carreira, ele co-fundou a DemonWare, uma plataforma de serviços online em grande escala para principais editores de jogos de vídeo que foi posteriormente adquirida pela Activision Blizzard (ATVI ), e a PageFair, uma startup apoiada por venture capital que se concentra em análise de bloqueio de anúncios que foi adquirida pela Blockthrough. Ele também fundou ou liderou várias startups e continua a apoiar o ecossistema de startups da Irlanda por meio de iniciativas como a Techpreneurs.

Jentic está desenvolvendo uma camada de integração universal projetada para ajudar agentes de IA a interagir de forma segura com sistemas e APIs de empresas. A plataforma permite que as organizações conectem modelos de IA com ferramentas internas, serviços externos e fluxos de trabalho operacionais, mantendo governança, autenticação e supervisão. Ao transformar APIs fragmentadas em interfaces estruturadas que os agentes de IA podem usar de forma confiável, a Jentic visa ajudar as empresas a implantar automação impulsionada por IA em grande escala em ambientes de software complexos.

Você fundou e liderou várias empresas de tecnologia, desde a DemonWare (adquirida pela Activision Blizzard) até a PageFair e agora a Jentic, e também serve no Conselho Consultivo de Inteligência Artificial da Irlanda. O que o levou a voltar a construir na camada de infraestrutura novamente com a Jentic, e qual foi a lacuna que você viu no ecossistema de agentes de IA emergente que os outros estavam perdendo?

Na terceira vez que você nota um padrão, você tem que levar a sério. Na DemonWare, todos falavam sobre multiplayer online – mas o problema difícil era a infraestrutura de rede por baixo. A mesma coisa está acontecendo com os agentes de IA. Os modelos são notáveis. O gargalo é a camada de integração – sempre foi. Os agentes de IA funcionam em APIs, e essas APIs foram construídas para humanos: documentadas para humanos, seguras para humanos e estruturadas para humanos. Aponte um agente autônomo para essa infraestrutura, e ele se desintegra rapidamente. Os pilotos de IA de empresas não falham porque o modelo não entendeu a tarefa; eles falham porque o agente não pôde se conectar de forma confiável aos sistemas de que precisava. A IA geradora oferece uma nova maneira de resolver isso – tratando a integração como um problema de conhecimento, não como um problema de codificação. Essa percepção me atraiu.

Quando você começou a Jentic em 2024, a segurança do agente era a tese principal desde o início, ou o foco se tornou mais aguçado à medida que você observava como as organizações estavam implantando agentes autônomos em produção?

A primeira linha que eu puxei foi as credenciais. Eu imaginei agentes se proliferando, cada um precisando de credenciais para dezenas de sistemas, todos esses segredos fluindo para janelas de contexto de LLM, sendo exfiltrados – um grande problema. A resposta é a mesma que seria há vinte anos: centralizar a autenticação e autorização. Mas puxar essa linha levou diretamente ao próximo problema: se você centraliza usando ferramentas de integração tradicionais, você está de volta à terra de conectores estáticos, e os agentes não são estáticos. O que cimentou a visão foi perceber que a descoberta de capacidade deve estar fortemente acoplada ao controle de acesso – que um agente só deve ser oferecido uma capacidade se ele estiver autorizado a usá-la, e que o sistema que fornece a descoberta também pode ser o único ponto de aplicação e observabilidade.

A exposição recente de grandes números de instâncias de agentes que enfrentam a Internet destacou como a orquestração e as credenciais muitas vezes compartilham a mesma fronteira de confiança. Do seu ponto de vista, qual é o erro arquitetônico fundamental nesse modelo?

O erro é simples: o agente – um sistema que executa prompts de um LLM – também é o sistema que mantém as credenciais e faz as chamadas de API. Comprometa o agente e você obtém tudo o que ele poderia fazer. É o mesmo erro que cometemos na era inicial da web – servidores de aplicativos com acesso de superusuário ao banco de dados porque era conveniente. A Jentic se situa como uma camada entre o agente e as APIs que ele chama. O agente nunca mantém credenciais. Ele emite solicitações por meio de nossa camada de execução gerenciada, que injeta credenciais no lado do servidor, aplica políticas e registra cada chamada. E quando algo dá errado, há um único interruptor de matar – uma ação que para o acesso do agente a todos os sistemas conectados simultaneamente.

Você falou sobre separar a orquestração da execução para conter o raio de ação. Pode explicar em termos práticos como essa separação muda o perfil de risco quando uma instância é comprometida?

No modelo plano, o LLM raciocina sobre o que fazer e chama diretamente as APIs usando as credenciais que mantém. Comprometa a camada de raciocínio, e você controla a camada de execução. Com a separação, o LLM emite uma intenção – “chame a API de cobrança da Stripe com esses parâmetros” – uma camada de execução gerenciada valida essa solicitação contra a política, injeta a credencial no lado do servidor e faz a chamada. O LLM nunca toca a credencial. Na prática: o movimento lateral se torna muito mais difícil, o raio de ação é limitado pelo que a camada de execução permite para essa identidade de agente específica, e você obtém um interruptor de matar. Uma única alteração e o acesso do agente para todos os sistemas conectados para.

Em implantações de empresas reais, o que é a gestão de credenciais centralizada e a revogação instantânea, e como isso difere de como a maioria das equipes está lidando com chaves de API e tokens para agentes?

Hoje, a maioria das equipes tem um desenvolvedor provisionando chaves de API, armazenando-as em um arquivo .env e carregando-as no início do agente – muitas vezes diretamente na janela de contexto do LLM. Ninguém tem uma visão completa de quais agentes mantêm quais credenciais. Quando alguém deixa, as chaves que ele provisionou não são rotacionadas. Quando um agente se comporta de forma estranha, não há um rastro de auditoria para reconstruir o que aconteceu. Com a Jentic, o desenvolvedor nunca lida com credenciais brutais. Eles declaram o que o agente precisa, a plataforma provisiona acesso com escopo, e o agente chama por meio da nossa camada de execução sem nunca ver a chave subjacente. Isso significa que você obtém revogação instantânea por agente, a capacidade de pausar o acesso enquanto você investiga e um rastro de auditoria com data e hora de cada chamada de API. A diferença entre isso e “chave de API em um arquivo .env” é substancial.

Muitas equipes estão experimentando com estruturas de agentes em vendas, engenharia e ciência de dados. Quais são os erros de segurança mais comuns que você está vendo à medida que as organizações mudam da experimentação para a produção?

Os mesmos padrões se repetem: agentes superprivilegiados ainda executando com as credenciais de administrador com as quais foram prototipados; credenciais passadas em prompts ou janelas de contexto onde elas acabam em logs, telemetria e potencialmente dados de treinamento; credenciais compartilhadas entre várias instâncias de agente, então você não pode isolar um único ator ruim; nenhum interruptor de matar para parar um agente sem derrubar o sistema mais amplo; nenhum rastro de auditoria digno de nota; e injeção de prompt não levada a sério – mesmo que qualquer agente que leia e-mails, processe documentos ou navegue na web encontre conteúdo criado adversariamente. O fio comum é que essas equipes construíram para o caminho feliz e agora estão descobrindo que a produção é principalmente os caminhos infelizes.

A Jentic se posiciona como uma camada de execução gerenciada entre estruturas de agentes e sistemas externos. Como essa camada intermediária impõe governança sem desacelerar os desenvolvedores ou reduzir a flexibilidade do agente?

Em vez de conectar um agente a cinquenta diferentes APIs – cada uma com seu próprio esquema de autenticação, limites de taxa e peculiaridades – o desenvolvedor se conecta a um único endpoint. Esse endpoint expõe ferramentas para pesquisar nosso catálogo completo de capacidades de API, carregar detalhes e executar qualquer chamada. Isso maximiza a flexibilidade por meio de uma interface unificada para APIs ilimitadas, enquanto permite governança – quais agentes acessam quais APIs, sob quais condições, com quais limites – tudo gerenciado na plataforma, não no código do cliente. A camada de execução é um pass-through; os agentes ainda podem compor fluxos de trabalho de vários passos, encadear chamadas e lidar com erros dinamicamente. Governança sem atrito é difícil. O atalho é empurrar a carga para os desenvolvedores. A infraestrutura deve fazer o oposto – absorver essa complexidade para que os desenvolvedores não precisem.

Com malware de roubo de informações agora visando ativamente arquivos de configuração de agentes e credenciais armazenadas, você vê os atacantes mudando seu foco para a infraestrutura de IA como uma nova área de superfície de alto valor?

Absolutamente – e a lógica é óbvia. Um arquivo de configuração de agente é efetivamente uma superchave de serviço múltiplo: credenciais para sistemas de e-mail, CRMs, plataformas de cobrança, APIs internas e contas do GitHub. Uma corrida de infostealer bem-sucedida rende meses de acesso a todos os sistemas externos de uma empresa. Isso é um retorno dramaticamente maior do que visar qualquer serviço isoladamente. A outra dimensão é que os agentes que executam continuamente em produção são presenças credenciadas persistentes – não um usuário que faz login e sai. Um agente comprometido pode servir como um ponto de apoio de longo prazo, operando abaixo dos limites de detecção. A realidade desconfortável é que a superfície de ataque está evoluindo mais rapidamente do que as ferramentas de defesa. A Jentic pode reduzir significativamente a superfície de ataque de credenciais, mas não podemos evitar que um agente maluse o escopo que foi concedido. Esse problema mais difícil precisa ser resolvido no nível do modelo, com guardrails e detecção de injeção de prompt.

Além de qualquer estrutura específica, quais princípios de segurança mais amplos as organizações devem adotar se quiserem implantar IA agente de forma segura em escala?

A maioria das organizações gerenciadas não pode implantar sistemas não determinísticos em seus processos de negócios mais valiosos. Um banco ou seguradora não pode apontar um agente autônomo para seu sistema de cobrança e dizer “vamos descobrir”. Então, como você inova sem que sua postura de risco se torne um freio? A resposta é a sandbox. Crie um duplo digital de sua propriedade de API com a mesma estrutura e fluxos de trabalho, mas sem credenciais de produção ou consequências. Implantar agentes lá, deixá-los explorar, observar o que acontece. Os caminhos bem-sucedidos são capturados como automação de fluxos de trabalho estruturados e determinísticos usando Arazzo, a especificação de fluxo de trabalho aberta desenvolvida dentro da OpenAPI Initiative – auditável, repetível e revisável por qualquer equipe de conformidade. Isso significa que você pode se mover na velocidade da IA na sandbox e na velocidade da empresa em produção, e esses dois modos coexistem. Os outros princípios ainda se aplicam – privilégio mínimo, trilhas de auditoria, interruptores de matar, separação de orquestração da execução. Mas a sandbox é a resposta estrutural para a pergunta com a qual as equipes de empresas realmente se atolam: como experimentar com IA não determinística sem apostar sua postura de conformidade nisso? Você não implanta a não determinação. Você extrai valor dela sob condições controladas e implanta apenas as saídas determinísticas.

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