Quem está fazendo esta solicitação? Introdução à autenticação de agentes — Kamil Potrec, Keycard

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Who Is Making This Request? Agent Auth 101 - Kamil Potrec, Keycard · Canal: AI Engineer · 18:12 · Assistir no YouTube

Tópicos: Agentes de IA, Cibersegurança e segurança de software, Segurança de IA

Resumo

Kamil Potrec apresenta os desafios de autenticação e autorização de agentes, que podem agir com credenciais de usuários ou contas de serviço sem que fique claro quem iniciou cada ação. Ele explica por que credenciais persistentes, permissões excessivas e SDKs, por si só, não resolvem o problema, e defende identidades próprias para agentes, delegação explícita, credenciais temporárias e políticas auditáveis. Gateways podem manter credenciais fora do alcance dos agentes e permitir revogação e controle das solicitações, embora tragam custos e complexidade. A palestra conclui que a autenticação de agentes é necessária e que as soluções devem usar padrões abertos e ser implementadas com segurança.

Pontos-chave

As credenciais de usuários repassadas a agentes não identificam claramente se uma ação foi iniciada pela pessoa ou pelo agente.
Contas de serviço podem acumular permissões excessivas, enquanto credenciais estáticas são difíceis de revogar e podem ser abusadas.
Sistemas de autenticação de agentes precisam oferecer identidades próprias, delegação explícita, credenciais temporárias e com escopo limitado, políticas e auditoria.
A diversidade de APIs, agentes, sistemas legados e fluxos de delegação torna difícil implantar uma solução uniforme em escala.
SDKs ajudam a compartilhar implementações, mas não garantem adoção ampla, cobrem todos os ambientes ou mantêm credenciais fora do alcance dos agentes.
Um serviço de autorização em tempo de execução e gateways podem armazenar e intermediar credenciais sem expô-las aos agentes.
Gateways podem verificar solicitações em tempo real, permitir revogação imediata e restringir ações, mas adicionam latência, complexidade e um alvo centralizado.
O palestrante recomenda usar padrões abertos, verificar a segurança do código e não depender de LLMs para implementar corretamente esses controles.

Capítulos

Início	Capítulo	Resumo
00:01	Credenciais e identidade nas interações com agentes	A palestra apresenta como usuários, agentes, servidores MCP e serviços remotos trocam credenciais e como isso dificulta atribuir as ações.
03:06	Riscos de credenciais e permissões excessivas	Um exemplo de solicitação sobre uma fatura mostra a ambiguidade entre a intenção do usuário e a ação do agente, além dos riscos de credenciais persistentes.
05:11	Requisitos para autenticação de agentes em escala	O palestrante propõe credenciais dinâmicas e descreve os desafios de identidade, delegação, federação, sistemas legados, políticas e auditoria.
09:52	Fluxo de autenticação e limites dos SDKs	A apresentação percorre as etapas de validação e aplicação de políticas e explica por que SDKs não resolvem todos os desafios, inclusive a exposição de credenciais.
12:28	Credenciais protegidas por gateways	Gateways e um serviço de autorização podem intermediar credenciais, viabilizando controles e revogação, mas também introduzem custos e dificuldades operacionais.
16:06	Keycard e recomendações finais	Potrec apresenta as capacidades oferecidas pela Keycard e recomenda autenticação obrigatória, padrões abertos e revisão de segurança.

Citações

Quem está fazendo esta solicitação? Foi Alice ou foi o agente? — 03:38

Podemos emitir credenciais dinâmicas, com escopo para aquela interação específica e limitadas à ferramenta que as usou. — 05:41

O desafio é tirar todos esses tokens do alcance do agente. — 12:28

A autenticação de agentes não é mais opcional. — 17:10

Conceitos e entidades

agent authentication (conceito): Processo de verificar a identidade de um agente antes de permitir que ele obtenha credenciais ou acesse serviços.
authorization (conceito): Definição e aplicação das ações que um agente ou usuário tem permissão para realizar.
OAuth (conceito): Tecnologia mencionada como meio de solicitar autorização e emitir credenciais dinâmicas para interações específicas.
workload identity federation (conceito): Mecanismo citado para autenticar agentes e estabelecer confiança entre sistemas.
MCP (conceito): Protocolo cujos servidores podem intermediar o acesso de agentes a APIs, bancos de dados e outros sistemas.
Gateway (conceito): Componente intermediário que pode autenticar chamadas, aplicar políticas e inserir credenciais sem revelá-las ao agente.
Keycard (empresa): Empresa em que Kamil Potrec trabalha e que apresenta uma plataforma para capacidades de autenticação e autorização de agentes.
Kamil Potrec (pessoa): Palestrante da apresentação sobre requisitos de autenticação e autorização para agentes.
agentbaseline.org (ferramenta): Site indicado pelo palestrante como fonte de uma implementação de referência para as capacidades discutidas.

Tradução completa (pt-BR)

00:01 [música] >> Oi, pessoal. Meu nome é Kamil. Trabalho na Key Card, em uma equipe de produto. Hoje vou falar com vocês sobre os requisitos de autenticação e autorização de agents. Temos mais ou menos 18 minutos. Não é nem de longe suficiente para abordar esse tema. Então, meu objetivo hoje é dar uma visão geral de alto nível do que é necessário para fazer isso, de como resolver esses problemas e

00:32 dar contexto para vocês virem fazer perguntas no estande. Estamos lá embaixo. Então, seja qual for a pergunta que vocês tiverem, fiquem à vontade para falar comigo no final ou procurar o Peter. Ele tem todas as respostas. Vamos começar com este diagrama bem simples. Vocês provavelmente já estão familiarizados com isso, de outras palestras sobre agents e como eles se comunicam com servidores MCP e outros agents. Mas o que as pessoas geralmente não discutem é como esses agents e usuários se comunicam entre si, como autorizam e fazem requisições. Então, o que encontramos e vemos

01:03 com frequência é que os usuários obtêm algum tipo de credencial de acesso. Elas podem ser chamadas de tokens de acesso pessoal ou simplesmente tokens. E representam uma credencial opaca que identifica esses usuários e permite que o agent decida se vai executar essa ação ou não. Se o agent estiver rodando localmente, às vezes essa etapa é ignorada e nada mais acontece. Quando uma requisição chega aos agents, eles precisam das próprias credenciais para sequer executar as ações, certo? Por exemplo, o que geralmente precisam é de uma chave de API para se comunicar com o provedor do modelo, o que permite que façam o raciocínio.

01:33 Então, sempre que o modelo de LLM decide executar algumas ações, ele costuma chamar ferramentas. Para fazer essas chamadas de ferramentas, muitas vezes usamos servidores MCP remotos. E, para nos comunicar com eles, esperamos precisar de outras credenciais. Há algumas opções que vimos no setor. Às vezes, os agents simplesmente usam os tokens PAT da Alice ou dos usuários e os encaminham. Às vezes, têm as próprias chaves estáticas e, felizmente, vemos cada vez mais o uso de credenciais dinâmicas que

02:04 são geradas. Mas, quando o servidor MCP recebe esse token, geralmente identifica o usuário como a identidade que está agindo com ele. Portanto, o servidor MCP não sabe se quem está executando a ação é um agent, a CLI da Alice ou qualquer outra ferramenta. Os servidores MCP costumam ser usados para encapsular uma infraestrutura existente. Se você tem APIs internas, bancos de dados ou até sistemas externos que não são compatíveis com agents, pode usar servidores MCP para representar essa comunicação e otimizar essa interação. Mas, para

02:35 fazer isso, esses servidores MCP geralmente precisam ter acesso a esses serviços de backend e agir em nome de vários usuários. Então, não podem simplesmente usar o token de bot de um único usuário, porque isso limitaria o escopo. Muitas vezes, usam contas de serviço, que acabam agregando permissões para que esses servidores possam se comunicar. E isso não é novidade. Já vimos esse padrão no passado, na comunicação entre serviços, em softwares SaaS tradicionais. Mas o que há de diferente nos agents?

03:06 Eles não são softwares determinísticos, certo? Então, quando a resposta volta para o agent e ele vê alguns dados, envia esses dados de volta ao modelo, que decide o que fazer com eles em seguida. Neste caso, estamos usando um exemplo abstrato de um serviço de faturamento. Imagine que o agent recebe uma solicitação para consultar a fatura mais recente. Ele recebe uma fatura que diz que está pendente e deveria ser enviada ao usuário. O agent, de forma maliciosa ou apenas tentando ajudar demais, decide enviar essa fatura a um usuário. Aí surge a pergunta: quem está fazendo essa solicitação? Foi

03:38 a Alice ou foi o agent? Não sabemos. Na prática, não há nada que permita determinar isso. E o que mais há de errado com esse cenário? Há muitos problemas com essas credenciais espalhadas por aí. Quando os usuários usam esses tokens de acesso, eles não ficam realmente associados a nada. Então, é muito fácil para a Alice pegar esse token e colocá-lo no próprio computador, e aí você perde toda aquela infraestrutura corporativa que poderia protegê-lo contra abusos. Não há uma maneira fácil de

04:10 revogar essas credenciais, então elas ficam por aí e podem ser usadas indevidamente. À medida que os agents querem fazer mais coisas, damos a eles mais credenciais, e eles começam a acumulá-las. E, novamente, como não são determinísticos, não sabemos realmente o que vão fazer com essas chaves de acesso. Por fim, chegamos ao velho problema das contas de serviço. Mais uma vez, são apenas um conjunto de permissões com privilégios excessivos. E a realidade é que aceitávamos o status quo no setor antes dos agents, porque confiávamos que o software seria lançado de maneira segura. Achávamos que era algo de que

04:40 os desenvolvedores cuidariam. Então, aceitávamos o risco. Os agents mudaram tudo isso, porque agora vivemos em um mundo em que há outro ator que pode agir em nosso nome. Sempre uso esta analogia: em quase todas as empresas em que trabalhei, tínhamos essa coisa de andar por aí e ver se algum colega tinha deixado o laptop desbloqueado. Aí íamos ao Slack e escrevíamos: “Hoje eu pago donuts para todo mundo”. Na época, sabíamos que isso não era uma boa ideia. Então, fazíamos essa brincadeira. Bloqueávamos a máquina e nunca mais fazíamos isso. Mas os agents fazem basicamente isso o tempo todo. Simplesmente os deixamos à solta com nossas

05:11 credenciais, e eles fazem isso o tempo todo. Então, precisamos de uma solução melhor para isso. E, curiosamente, a tecnologia para resolver alguns desses problemas existe há muitos, muitos anos. Só não tínhamos incentivo para dedicar tempo a descobrir como implementá-la corretamente. Então, em vez de a Alice tentar descobrir onde obter tokens de acesso — o que também é uma experiência de usuário terrível —, dá para pensar: “Por que preciso ir buscar essas credenciais?”. Por que não teríamos agents que basicamente anunciam como obter acesso a eles e, então, incorporam na capacidade do cliente a solicitação dessa autorização a algum sistema externo. Aí podemos emitir essas credenciais dinâmicas, com escopo restrito àquela interação específica e limitadas à ferramenta que as utilizou. Quando o uso termina, elas deixam de valer. OAuth é uma tecnologia que nos permite fazer isso. E, pensando bem, resolvemos há muito tempo a autenticação para usuários, mas, no caso dos softwares, decidimos que isso não era realmente um requisito. Precisamos mudar isso e também usar as tecnologias disponíveis para fazer os agents se autenticarem antes de

05:41 à capacidade do cliente de solicitar essa autorização a algum sistema externo. E então podemos emitir esse tipo de credenciais dinâmicas, com escopo limitado a essas interações específicas e à ferramenta que as estiver usando. E, quando termina, acabou. E o OAuth, como tecnologia, nos permite fazer isso. E, quando pensamos nisso, resolvemos a autenticação de usuários há muito tempo, mas, no caso de software, decidimos que isso não era realmente um requisito. Mas precisamos mudar isso e também usar as tecnologias que temos à disposição para fazer com que os agents se autentiquem antes de nós

06:13 emitirmos qualquer credencial para eles. Podemos usar coisas como federação de identidade de workload. Há outros mecanismos: você pode usar autenticação com chave privada, certificados, autorização baseada em URL. O mecanismo em si não importa, contanto que você o use e faça os agents se autenticarem nos sistemas. E, curiosamente, depois que fizer isso, é só repetir o mesmo padrão. Em vez de dar contas de serviço aos agents e adicionar permissões persistentes a essas contas, por que eles não determinam, toda vez que quiserem se comunicar com algum servidor remoto, qual autorização é necessária, vão até esse serviço remoto, obtêm o token e seguem em frente? E [fungada] a única diferença entre os agents e o software tradicional, como mencionei, é esse ciclo de raciocínio. Se tirar isso da equação, tanto o software legado quanto o agent são simplesmente software. Então, novamente, você pode reutilizar o mesmo padrão para a aplicação que está escrevendo agora; nada muda, e dá para reimplementar toda a stack dessa forma. Parece simples. Então, por que não fizemos isso antes? Bem,

06:44 a autorização ser necessária, acessar esse serviço remoto, obter o token e seguir em frente. E [ri] a única diferença entre os agents e o software tradicional que mencionei é esse ciclo de raciocínio. Se você o retirar da equação, tanto o software legado quanto o agent são apenas software. Então, de novo, você pode simplesmente reutilizar o mesmo padrão para a aplicação que está escrevendo agora; nada muda, e você pode reimplementar toda a stack dessa forma. Então, parece fácil. Por que não fizemos isso antes? Bem,

07:15 Tudo isso fica muito, muito, muito mais complicado quando pensamos nesse problema em escala. Não existe uma única API que usamos; temos centenas de APIs, e elas usam maneiras diferentes de autenticar usuários. Por trás dessas APIs, sempre há algum tipo de servidor de autorização que precisa autenticar o usuário. Então, na imagem anterior, tínhamos um bloco contra o qual precisaríamos nos autorizar. Agora temos clientes que precisam fazer isso em centenas desses serviços. E não existe apenas um tipo de agent. Vamos ter agents que você compra, como o seu cloud code, e um agent que

07:47 você cria. Às vezes, não será possível alterar esse software, então precisamos encontrar uma maneira de fazer isso. E não há apenas um salto. Agora precisamos processar esse fluxo de delegação e verificar como todos esses agents vão se comunicar com outros agents e quantos saltos pode haver nesse ciclo. E, por fim, o maior problema que temos é atribuir quem decidiu realizar essa ação. Agora temos milhares de usuários que precisam consentir com essas ações arbitrárias realizadas por agents. Em escala, precisamos resolver todos esses problemas juntos para tornar

08:18 isso útil para nós. Então, em resumo, se quisermos ter um sistema adequado de autenticação de agents, o que precisamos oferecer? Primeiro, precisamos de identidades de agent. Precisamos de um sistema que emita essas identidades para cada agent. Isso talvez precise ser feito até por sessão. Mas isso deve ser separado de quem o iniciou. Depois, precisamos conseguir expressar essa semântica de delegação. Precisamos poder dizer quais usuários estão autorizados a realizar ações com esses agents e quais agents podem agir em nome de outros usuários. Precisamos de um sistema que possa emitir credenciais com escopo definido e de curta duração

08:51 para tudo o que fazemos. E não pode haver uma chave mestra que nos permita fazer isso. Segundo, como mencionei, já temos cerca de 100 sistemas diferentes. Não podemos simplesmente esperar que vamos reescrevê-los todos. Os LLMs são rápidos, mas não tão rápidos. Então, precisamos conseguir estabelecer uma confiança federada entre identidades nesses sistemas e permitir que confiem uns nos outros quando trocarem esses sistemas. E, novamente, sempre teremos software legado. Não dá para simplesmente esperar que ele passe a oferecer suporte a OAuth

09:21 em breve. Então, precisamos ter uma camada adaptável, um broker, que permita trocar com segurança essas credenciais legadas no momento em que forem necessárias. E, por fim, precisamos conseguir expressar isso com políticas. Alguém precisa poder especificar quais ações exigem aprovação humana e quais agents podem ser executados automaticamente. E as coisas vão dar errado. Então, para podermos aprender a melhorar as coisas, precisamos de auditoria. Precisamos poder dizer quem autorizou essa solicitação e quem tornou isso possível.

09:52 Então, há muitas etapas para fazer isso direito. O que quero mostrar aqui é que, se considerarmos uma única interação entre um agent e um servidor MCP para fazer isso funcionar, teremos um cliente e um servidor. O servidor precisa publicar essas informações. Os clientes precisam poder descobri-las. Então, os agents precisam obter essas credenciais. Precisam conseguir se autenticar nesse servidor remoto. Quando isso acontece, o servidor MCP precisa validar se

10:23 essas credenciais foram assinadas corretamente. Precisa verificar se o emissor é confiável. Precisa validar esses tokens. Depois, há alguma política que precisa ser aplicada. É preciso garantir que as regras mais recentes estejam em vigor. Quando isso acontece e eles se comunicam com um sistema externo, talvez precisem obter credenciais adicionais para se comunicar com ele. E, por fim, precisamos garantir que cada uma dessas ações seja registrada no log de auditoria. Mãos ao alto: quem acha que os LLMs conseguem fazer isso perfeitamente todas as vezes?

10:54 Certo. Acho que estamos todos de acordo. Isso não é simples, mas já resolvemos problemas semelhantes antes, certo? Escrevemos bibliotecas compartilhadas, middleware e SDKs para implementar essas coisas uma vez, verificar com um grupo maior de pessoas se elas estão sendo realizadas adequadamente e reutilizá-las o tempo todo. Isso parece uma solução para o que queremos fazer aqui. Mas quais são os problemas dos SDKs? Hoje em dia é fácil escrevê-los, mas é preciso fazer com que todos os adotem, certo? Se houver lacunas

11:25 na adoção, então de que adianta ter SDKs? Depois, é preciso escrevê-los para cada linguagem que você usa. E os LLMs provavelmente são bons em escrever em algumas dessas linguagens, mas provavelmente não nas mais antigas que você tem no sistema. E o que fazer com seus cloud codes, seu code X, que você não pode simplesmente modificar? Os SDKs também não ajudam muito nesse caso. E, se houver bugs — porque os LLMs cometem erros e nós escrevemos código com bugs —, para corrigi-los, não basta corrigir o SDK: também é preciso rastrear onde ele é usado e quais sistemas o consumiram.

11:58 E, por fim, os quatro problemas anteriores já existiam, então não são novidade. Mas os agents têm um problema adicional. Como eu disse, eles agem e tentam ser otimistas demais, ou podem ser manipulados para fazer coisas, e demonstraram muita persistência ao tentar contornar nossos controles. Então, confiamos mesmo apenas em código do lado do cliente para gerenciar essas credenciais com segurança? Claro, eles podem armazená-las em cache e guardá-las corretamente, mas, se descobrirem que há uma credencial que podem usar, desde que ela esteja no próprio ambiente de execução deles, temos um

12:28 problema. Então, os SDKs claramente não vão resolver esse problema por vários motivos e, além disso, não resolvem o problema de ocultar as credenciais dos agents. Se considerarmos esta imagem, o desafio que queremos enfrentar é tirar todos esses tokens do alcance do agent. O que podemos fazer? Vamos tentar tirar todas essas credenciais desse ambiente de execução e colocá-las em algum tipo de enclave seguro. Assim, podemos ter nosso sistema de autorização em tempo de execução, um serviço de armazenamento seguro que possa guardar

12:59 e intermediar todas essas credenciais. E o outro problema é como vamos usá-las. Os gateways são algo que já usamos no passado e podem resolver esse problema para nós. Assim, os agents podem se comunicar com o gateway e solicitar um destino específico para falar com o GitHub, por exemplo. O gateway pode autenticar quem está fazendo a chamada, falar com nosso serviço de autorização em tempo de execução, validar se as políticas estão em vigor e buscar a credencial específica. Depois, pode simplesmente inseri-la no caminho da solicitação e encaminhá-la

13:30 ao GitHub. Isso nos dá uma camada física de controle, na qual não há como esse agent obter a credencial, a menos que aja de maneira muito determinista e tente invadir nosso gateway ou, pior ainda, nosso serviço de autorização. Mas, o mais importante, conseguimos mais algumas propriedades com isso. Mesmo que usemos credenciais de curta duração, elas terão algum prazo de validade, certo? E ainda não descobrimos como revogá-las adequadamente em sistemas distribuídos. Mas, se usarmos gateways e

14:01 force toda a sua comunicação a passar por esse ponto, você pode revogar o acesso instantaneamente, porque o gateway consegue verificar cada solicitação em tempo real. Além disso, os agents farão coisas demais. Muitos desses serviços legados não conseguirão limitar o acesso adequadamente. Eles terão tokens que permitem permissões de administrador, leitura ou escrita, mas isso não é bom o suficiente, certo? Queremos poder dizer: “Ei, você pode ler meus e-mails, mas não pode enviar e-mails.” Com os gateways, como podemos interceptar e, mais importante, inspecionar todas as solicitações,

14:32 podemos restringir essa solicitação. Podemos dizer: “Para esta solicitação específica, sim, vamos usar uma credencial segura, mas, se você tentar enviar uma solicitação, simplesmente vamos bloqueá-la.” Também temos mais observabilidade porque o gateway está no caminho da rede; conseguimos ver exatamente o que acontece com todas as solicitações, sem precisar mudar nada nos nossos serviços downstream. Mas nada na vida é de graça. Então, os gateways também trazem alguns desafios. Ao adicionar mais um salto à sua

15:02 chamada, se você se preocupa muito com a latência, isso vai aumentá-la um pouco. Bem, você precisa obrigar todos os seus agents a se comunicarem com o seu gateway. Se eles puderem ignorá-lo porque você não tem controles de rede fortes, isso não vai ajudar. Além disso, alguns agents querem executar ferramentas localmente, então você não estará realmente se protegendo contra isso. O gateway não resolve o seu problema de identidade. Sim, os agents ainda precisam obter algum tipo de credencial de autenticação e apresentá-la ao gateway para que as solicitações sejam autenticadas corretamente.

15:35 Você também está criando um grande alvo nessa única coisa, porque agora estamos dizendo que todas as credenciais vão passar por ela. Então, algumas pessoas vão tentar hackeá-la. Há muitas complexidades técnicas na construção de gateways. Algumas pessoas também os chamam de proxies. TLS é uma delas. Se você tentar interceptar isso e trabalhar com todos esses sistemas, pode ter alguns problemas. E, por fim, se você estiver executando um sistema distribuído, com todos esses desenvolvedores criando agents, eles precisam descobrir como

16:06 vão configurar as rotas, as políticas e os conectores em todos esses gateways, certo? Alguém ainda precisa decidir se o agent A pode se comunicar com o agent B por meio do gateway. E, em segundo lugar, alguém precisa operá-lo. Então, esses são todos os problemas que temos com gateways. O que fazemos na Keycard é pensar em todos esses problemas o tempo todo. Não achamos que faça sentido todo mundo replicar todas essas funcionalidades. Por isso, criamos um único plano de controle que permite

16:39 dar identidades aos seus agents. Emitimos tokens e fazemos federação com tudo o que você já tem. Fornecemos políticas e auditoria para todas as suas solicitações. Você pode obter de nós todos os SDKs de cliente que permitem fazer injeção e descoberta. Fornecemos SDKs de serviço para que você não precise se preocupar com a forma como eles são autenticados. Também oferecemos um gateway, caso você realmente queira esses controles, mas, fundamentalmente, você pode trazer todos esses componentes para nós e escolher quais dessas

17:10 funcionalidades precisa para criar o seu sistema, porque você pode estar criando um aplicativo de chat. Pode estar criando uma plataforma completa de orquestração. Não temos uma opinião rígida sobre o problema que você está tentando resolver com agents. Estamos apenas tentando ajudar você a resolvê-lo de forma segura. Então, se você levar algo desta palestra e quiser conversar conosco, a autenticação de agents não é mais opcional. Sim, conseguimos sobreviver sem isso por décadas, mas os agents provaram recentemente que não são confiáveis. A realidade é complexa.

17:41 Então, mesmo que você se proponha a criar alguns desses componentes, use padrões abertos e garanta a interoperabilidade com outros sistemas, porque não vamos vencer esse jogo jogando sozinhos. E, realmente, não faça isso de qualquer jeito, porque os LLMs não vão conseguir implementar isso por você. E, seja lá o que fizer, verifique se o código escrito para implementar essas funcionalidades é seguro. Obrigado. Se quiser saber mais sobre nós, venha ao estande. Somos a Keycard AI. Confira também o agent

18:12 baseline.org. Recentemente, lançamos uma implementação de referência de uma software factory com todas as funcionalidades que vocês viram aqui. Assim, vocês podem aprender e trabalhar conosco para descobrir como resolver esses problemas. É isso. >> [aplausos]

Transcrição original

[00:01] [music] >> Uh hi everybody. My name is Kamil. I work at Key Card in a product team. I’ll be talking to you today about agent authentication authorization requirements. We have around 18 minutes ish. That’s nowhere close to be able to cover this topic. So, my goal today is to give you kind of high-level overview of what’s required to do this, how to kind of solve these problems, and

[00:32] give you context to come and ask us questions at the booth. We downstairs. So, just whatever questions you have, feel free to grab me at the end or go find Peter. He has all the answers. We’re going to start with this fairly simple diagram. You’re probably familiar with this in any of the talks you have about agents and how they communicate with MCP servers and other agents around. But, what usually people don’t talk about is how are these agents and users communicate with each other, how do they authorize and make requests. So, what we come across and what we see

[01:03] often is that users obtain some sort of access credential. They they might be called personal access tokens or just tokens. And they kind of represent opaque credential identifying these users and letting the agent decide if they’re going to perform this action or not. If your agent is running locally, sometimes this step is skipped and nothing else happens. When a request comes to the agents, they need to credentials of their own to even perform the actions, right? Like the common thing that they need is an API key to talk to the model provider that allows them to kind of do the reasoning.

[01:33] So, whenever the kind of LLM model decides to do some actions, they often call tools. When we need to do those tool calls, often we use remote MCP servers to perform them. And in order to communicate with them, hopefully, we need another credentials to do that. And we have couple of options that we’ve seen in the industry. Sometimes the agents will just use Alice’s or like users PAT tokens and pass them through. Sometimes they will have their own static keys and luckily enough uh uh we see more and more use of all of kind of

[02:04] dynamic credentialing that happens there. But whenever MCP server receives that token they usually just kind of see the user as the identity that acts with it. So MCP server doesn’t really know if it’s like an agent running it, is it like Alice’s CLI or is it like any other tool that does it? MCP servers are often used to kind of enclose existing infrastructure. So if you have like internal APIs, databases, even external systems that are not kind of agent friendly, we can use MCP servers to represent that communication and optimize that interaction. But in

[02:35] order to do that these MCP servers often need to have access to these back-end services and act kind of act for multiple users. So they cannot just use one user’s bot token because that will be limited to that scope. They they often use service accounts and those service accounts kind of become aggregator of permissions so that these servers can communicate. Um And this is nothing new. We’ve seen this pattern in the past in kind of service-to-service communication in your traditional SaaS software. However, what’s what’s different about agents?

[03:06] They’re not deterministic software, right? So whenever the request comes back to the agent and it sees them some data, it will send it back to the model and it will decide to to do what it wants to do to do with it next. In this case we’re using an abstract example of invoicing service. So imagine the agent receives a request to go and look at the recent invoice. It gets it back an invoice says I’m pending, it should be sent to the user. An agent either maliciously or is just too helpful decides to go and send this invoice to a user. Now the question becomes who is making this request? Was

[03:38] this Alice or was this the agent? We don’t know. There’s nothing to determine that in reality. Um So what else is wrong with this picture? Um there’s a lot of issues with having all of these credentials laying around. So whenever users use these access tokens, they’re not really attributed to anything. So Alice can quite easily take this uh token and put it on her own personal machine uh and then you kind of lose all of that uh corporate infrastructure that might protect it from abuse. Um there is no easy way to

[04:10] revoke these credentials, so they kind of lay there and can be abused. Um agents as uh they want to do more things, we give them more credentials and they start aggregating them. And again, because they kind of non-deterministic, we don’t really know what they’re going to do with those access keys. And finally, we arrive at the old problem of service accounts. Again, they’re just over-privileged bucket of permissions um and uh re- reality is like we’ve been okay with the status quo uh in the industry before agents because we kind of relied on the software being released in a secure way. We thought about it as something that

[04:40] developers take care of. So, we kind of accepted the risk. Agent changed all of that because now we live in a world where there is this other actor that can behave on behalf of you. I always use this analogy uh like in almost every company I worked at, uh we have this thing when we would walk around and see if one of your colleagues left the laptop unlocked and we would go to the Slack and be like, “I’m buying donuts for everybody today.” And back then we knew that that is not a good thing. So, that we we played this game. We would lock the machine down uh and then we would never do it again. But agents are basically doing this all the time. We just let them run rampant with our

[05:11] credentials and do this all the time. So, um we need a better solution to do this. And uh funnily enough, technology to solve some of these problems existed for many, many years. We just didn’t have incentive to kind of um spend time how to implement this properly. Um so, instead of Alice uh going trying to figure out where to get access tokens, uh which is also terrible user experience. You can kind of think like, “Why why do I need to go and fetch these credentials?” Um why wouldn’t we have agents um that basically can advertise how to get access to them and then embed

[05:41] into the client’s ability to go and request that authorization from some external system. And then we can issue this kind of dynamic uh credentials that are scoped to that specific interactions, that limited to the tool that was using it. Uh and whenever it’s done, it’s finished. And OAuth as a technology allows us to do this. Um and when you think about this, um we kind of solved authentication for users um a long time ago, but then for software, we decided that that’s not really a requirement. Um but we need to change this and we need to also use technologies that we have available to us to make agents authenticate before we

[06:13] issue them any credentials. So, we can use things like workload identity federation. There’s other mechanism, you can use private key authentication, you can use certificates, you can you can use URL based authorization. The mechanism doesn’t really matter as long as you use it and make agents authenticate to the systems. And funnily enough, once you do that, then you can just kind of repeat the same pattern. Instead of giving these agents kind of service accounts and adding like persistent permissions to the service accounts, why don’t they just every single time they want to talk to some remote server kind of determine what

[06:44] authorization is required, go to this remote service, obtain the token, and go forth. And [snorts] um the only difference between agents and traditional software that we have that I mentioned is that reasoning loop. If you take that out of equation, both the legacy software and agent is just software. So, again, you can just reuse the same pattern for the application that you’re writing now, and nothing changes, and you can kind of go and re-implement the entire stack this way. So, that sounds easy. So, why we didn’t do this before? Well,

[07:15] all of this kind of becomes way way way tricky to do when we think about this problem at scale. There isn’t like one API that we have, there’s like hundreds of APIs that we have, and they use different ways to authenticate users. Behind those APIs, there’s always some sort of authorization server that needs to authenticate the user. So, in a previous picture we had we had like one block that we would have to authorize against. Now you have clients who need to do this across like hundreds of these services. And there isn’t like one agent type. We’re going to have like uh agents that you buy, so your cloud code, agent that

[07:47] you build. Sometimes you won’t be able to like change that software, so we need to find a way to how we’re going to do this. And and there isn’t like one hop. So, now we need to process this kind of delegation flow and verify how all these agents going to talk to other agents and how many hops there can be in that loop. And finally, like the biggest problem that we have is the attribution of like who decided to make this action. So, we now have like thousands of users who need to consent to these arbitrary actions that agents are doing. So, at scale, now we have to solve all of these problems all together in order to make

[08:18] something useful um for us. So, in summary, um if we want to have a proper agent authentication system, what do we need to deliver? So, first of all, we need agent identities. We need a system that’s going to issue these identities per agent. Uh then that might be even be per session. Um but that must be separate from whoever launched it. Then we need to be able to express this delegation uh semantics. So, we need to be able to say which users are authorized to perform actions with these agents, which agents can act on behalf of other users. We need to have a system that can uh issue scoped and short-lived

[08:51] credentials for everything that we do. Um and there cannot be like any master key that allows us to do this. Um Second, as I mentioned, there’s like 100 different systems that we already have. We cannot magically hope we can rewrite them all. LM are fast, but not that fast. Uh so, we need to be able to build a federated trust of identities across them and allow to trust each other when they exchange these systems. And again, we’re going to have legacy software forever. Um you won’t be able to kind of go and hope that they will be supporting OAuth

[09:21] anytime soon. So, we need to be able to kind of have an adaptive layer, a broker, that allows us to securely exchange those legacy credentials just in time. Um and finally, you need to be able to express this with policies. Um someone needs to be able to write which uh actions need human approval, which agents can run automatically. Um and things will go wrong. So, um in order for us to learn uh how to improve things, we need audit. Um we need to be able to say who authorized this request and who made this possible. Um

[09:52] So, um there’s a lot of steps to actually get this right. So, um what I want to show you here is just like if you take one interaction between agent and MCP server just to get this working, um you will have a client and a server. Um server needs to be be to publish this information. Cli- clients need to be able to discover it. Then the agents need to be able to obtain these credentials. They need to be able to authenticate themselves to this remote server. Um then when that happens, uh the MCP server has to be able to validate if

[10:23] those credentials been been correctly signed. They need to check if the issue is trusted. They need to verify those tokens. Um then there is some policy that needs to come into action. They need to enforce if the latest rules uh are in play. Um once that happens, and they communicate to external system, uh they might need to obtain additional credentials to talk to it. Uh and finally, we need to make sure that every single one of these actions is captured in the audit log. Um Raise of hands, who thinks LLMs can do this uh every single time perfectly?

[10:54] All right. Uh I think we’re all in agreement. Um so, this is not simple, but we have solved similar problems before, right? Like we’ve written shared libraries, we’ve written middleware, we’ve written SDKs in order to kind of write these things once, verify with a larger group of people if those performing um appropriately, and kind of reuse them all the time. Um which sounds like a solution to what we want to do here. Um but what are the problems with SDKs? So, um it’s easy to write them these days, but you need to get them adopted by everybody, right? Like if you have gaps

[11:25] in your uh adoption, then well, what’s good are your SDKs? Um then you need to write them for every single language that you have. And LLMs are probably good at writing some of these languages, but probably not the older ones that you have in your system. Uh and then what do you do about your cloud codes, your code X that you cannot go and modify, right? Like SDKs won’t help you there too much. Um then if you’re going to have bugs because a LLMs make bugs, we write bugs. Um in order to fix that, you not only have to fix the SDK, but then you need to track where is this SDK used, and which one of the systems consumed it. Um

[11:58] And then finally, so all of these previous four problems existed before, so that’s nothing new. But agents have additional problem. As I said, they kind of act um and trying to be too optimistic, or they can be kind of manipulated do things, and they proved to be very persistent in trying to bypass our controls. So, um do we really trust with using just kind of client-side code to be able to manage these credentials securely? Of course, they can cache them, they can store them properly, but if they figured out that there is credential that they can use, as long as it’s within their own kind of execution environment, we have a

[12:28] problem. So, SDKs clearly are not going to solve this problem for many reasons, and additionally, they don’t solve the problem of hiding credentials from agents. So, if we take this picture, um the challenge that we want to do is to get all of these tokens out of the reach of the agent. So, what can we do? Well, let’s try to move all of these credentials out of this execution environment and put them in some sort of secure enclave. So, we can have our kind of runtime authorization system, vaulting service, that can store

[12:59] and kind of broker all these credentials. And then the other problem is now how are we going to make use of them? So, gateways are something we’ve used in the past, and they can solve this problem for us. So, agents can communicate to the gateway, can request specific target to talk to GitHub, for example, and a gateway can authenticate who’s calling it, talk to our runtime authorization service, validate that policies are in place, and fetch the specific credential. And then they can simply inject them into the request path and send it

[13:30] forward to GitHub. And what that gives us is now we have like a physical control layer where there’s simply no way for this agent to obtain this credential unless it’s going to be very deterministic and go try to hack our gateway, or even worse, our authorization service. But what most importantly, we get couple more properties out of this. Even if you use short-lived credentials, they will have some sort of expiry time, right? And we still haven’t figured out how to do revocation probably across distributed systems. But if you use gateways and you

[14:01] force all of your communication through that point, you can have instantaneous revocation because gateway can check every single request on the fly. Additionally, agents will do too much. A lot of these legacy services won’t be able to scope access properly. They will have tokens that allow you either admin, read, or write permissions, but they’re not good enough, right? Like we want to be able to say, “Hey, you can read my email, but you cannot send my email.” With the gateways, because we can intercept and more importantly introspect all of the requests,

[14:32] we can attenuate that request. We can say, “For this specific request, yes, there is a secure credential we’re going to use, but if you’re trying to send request, we’re just going to block it.” We also get more observability because the gateway is on a network path, we can see exactly what happens for all the requests, and we don’t need to change anything in our downstream services. But, there’s nothing for free in life. So, gateways also come with some challenges. While you’re adding another hop to your

[15:02] call, so if you’re really careful about your latencies, that’s going to add some to it. Um Well, you need to force all your agents to talk to your gateway. If they can go bypass it if you don’t have strong network controls, then that’s not going to help you. Additionally, some agents want to have kind of local tool execution, so you’re not really guarding against that. There’s nothing gateway does about your identity problem. Yes, agents still need to get some sort of authentication credentials and present it to the gateway in order to have a correct authenticated requests.

[15:35] You’re also putting a big target on this one thing that you’re creating because now what we’re saying is like every single credential will go through it. So, well, some people will go try try to hack it for you. There’s a lot of technical complexities with building gateways. Some people call them proxies as well. TLS is one of those things. If you try to intercept that and try to work with all of these systems, you might run into some problems. And finally, if you’re running distributed system, you have all of these developers building agents, they need to figure it out how

[16:06] they’re going to configure the the routes, the policies, the connectors in all of those gateways, right? That still someone has to say if agent A can talk to agent B via the gateway. And two, someone has to run it. Um, so these are all the problems we have with gateways. Um, so what we do at Keycard, we think about all of these problems all the time. Um, so we don’t think uh it’s it’s sensible for everybody to replicate all of these functionalities. So, we’ve built a single control plane um that allows you

[16:39] to both give your agents identities. We issue tokens uh in and federate with everything that you have going on. Um, we provide you policies and audit um to all of your requests. Um, you can get from us all of the client SDKs that allow you to do uh injection and discovery. We provide you with service SDKs that you don’t have to worry about how they’re being authenticated. Um, we also give you gateway uh if you really want to have those controls, but fundamentally um you can bring all of these components to us um and kind of pick and choose which one of

[17:10] these capabilities you need to build your system because you might be building a chat application. You might be building a complete uh orchestration platform. Um, we are fairly unopinionated on the problem you’re trying to solve with agents. We’re just trying to help you solve these in a secure fashion. Um, so if you take anything out of this talk uh and want to come talk to us, um agent off isn’t an option optional anymore. Uh yes, we kind of managed to survive without this for decades, but uh agents proved themselves recently that uh they cannot be trusted. Uh reality is messy.

[17:41] So, even if you go on a mission of trying to build some of these components, uh make sure that you use open standards uh and to be interoperable with other systems because um we’re not going to win this game uh by playing uh alone. Uh and then really really don’t yellow it uh because LLMs won’t be able to implement this for you. Um, and make sure that whatever you do, check if the code written to implement these uh capabilities is secure. Um, thank you. Um, if you want to find out about us, come to the booth. We’re Keycard AI. Uh also check out agent

[18:12] baseline.org. We have recently uh kind of released uh a software uh factory reference implementation of all of the capabilities that you’ve seen here. So, you can kind of learn and come and work with us on the how to solve this problems. That’s it. >> [applause]