Como permitir que agentes de IA criem contas no seu app com segurança — Isabelle Williams, WorkOS

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: How to Let AI Agents Sign Up for Your App Safely — Isabelle Williams, WorkOS · Canal: AI Engineer · 18:20 · Assistir no YouTube

Tópicos: Agentes de IA, Cibersegurança e segurança de software, Open source e ecossistemas de software

Resumo

Isabelle Williams, da WorkOS, apresenta formas de permitir que agentes descubram um app, criem contas e atuem em nome de usuários sem abrir mão do controle de acesso. Ela explica o fluxo de acesso anônimo seguido da reivindicação das ações pelo usuário e o uso de ID-JAG para compartilhar identidade com consentimento. Para limitar os riscos, propõe emitir tokens próprios para agentes, com permissões restritas, auditáveis e revogáveis. As demonstrações usam um app de planejamento de viagens chamado Waypoint ou Waygo, conforme identificado na transcrição.

Pontos-chave

Um arquivo auth.md pode descrever para agentes como descobrir um app, criar uma conta e acessar uma API.
Agentes podem experimentar recursos em modo anônimo; depois, o usuário pode reivindicar as ações e associá-las à própria conta.
Com ID-JAG, um provedor de agentes pode compartilhar uma afirmação de identidade assinada após obter o consentimento do usuário.
O app continua responsável por verificar a afirmação, decidir se cria ou vincula uma conta e definir as permissões concedidas.
Não é recomendável entregar ao agente o token de usuário: tokens próprios para agentes facilitam atribuição, auditoria e revogação.
As permissões do token do agente podem ser limitadas à interseção entre as permissões do usuário e o teto definido no blueprint do agente.
A separação entre permissões do agente e do usuário permite que o agente execute algumas ações sem poder alterar configurações sensíveis, como orçamento e regras de aprovação.

Capítulos

Início	Capítulo	Resumo
00:01	Por que permitir que agentes usem o app	Isabelle apresenta o Waypoint e explica os desafios de deixar agentes descobrirem o produto, associarem-se a usuários e operarem com limites de segurança.
02:03	Acesso de agentes com auth.md	A apresentação descreve como o arquivo auth.md orienta agentes a experimentar a API anonimamente e, depois, transferir suas ações para uma conta de usuário.
05:09	Consentimento e identidade com ID-JAG	O fluxo de ID-JAG permite que o provedor do agente compartilhe uma afirmação assinada sobre o usuário, após consentimento, para que o app decida como conceder acesso.
12:00	Limites, auditoria e revogação de permissões	A demonstração mostra tokens próprios para agentes, com permissões definidas pelo cruzamento entre os acessos do usuário e o teto do blueprint.
17:16	Demonstração final e principais aprendizados	A palestrante resume como facilitar o acesso de agentes, vinculá-los a clientes e restringir suas ações com permissões revogáveis.

Citações

Não é feito para nós. É feito para o seu agente. — 02:34

Seu app está completamente no controle disso. — 06:43

Não quero simplesmente entregar ao agente o token de usuário do Jordan. — 13:34

Você pode auditar, revogar e limitar as permissões desse agente. — 17:16

Conceitos e entidades

Isabelle Williams (pessoa): Gerente de produto da WorkOS que apresenta formas seguras de integrar agentes a aplicações.
WorkOS (empresa): Empresa que oferece infraestrutura de autenticação e apresenta sua solução de autenticação para agentes.
Waypoint (conceito): App de planejamento de viagens usado nas demonstrações, embora a transcrição também o chame de Waygo.
Cursor (ferramenta): Ferramenta usada para criar o app de demonstração durante uma sessão de live coding.
auth.md (conceito): Arquivo em formato Markdown que descreve como agentes podem descobrir e acessar os recursos de uma aplicação.
ID-JAG (conceito): Padrão para transmitir uma afirmação assinada sobre a identidade de um usuário a uma aplicação, com uma audiência específica.
OAuth (conceito): Mecanismo de autorização usado no fluxo apresentado para conceder ao agente acesso à API em nome do usuário.
agent token (conceito): Token emitido para um agente com permissões próprias, limitadas e revogáveis.
agent blueprint (conceito): Configuração que define o teto de permissões disponível para um tipo de agente.

Tradução completa (pt-BR)

00:01 [música] >> Oi, pessoal. Meu nome é Isabel. Sou gerente de produto na WorkOS. Hoje, vou falar sobre como seu próximo usuário será um agent. Para falar brevemente sobre a WorkOS: fazemos infraestrutura para autenticação. Ajudamos você a criar apps, agents e APIs. Mais de 3.000 clientes confiam em nós, incluindo OpenAI, Propel e Cursor.

00:33 Certo. Para a apresentação de hoje, vou usar um app que programei ao vivo com Cursor. Ele se chama Waypoint. É um app de planejamento de viagens, tanto para uso individual quanto para viagens corporativas. E hoje vamos usar o Waypoint para ajudar a planejar nossa viagem ao AIE, em Nova York. Muito bem. Ao longo do último ano, mas especialmente nas últimas semanas, com Muse e Instinct e a ascensão dos agents pessoais, tenho pensado bastante no que isso significa para o Waypoint. A primeira coisa em que tenho pensado

01:03 é: como faço para deixar agents entrarem no meu app? Quando penso no plano de viagens pessoais do Waypoint, antes dos agents, é muito importante, do ponto de vista de crescimento impulsionado pelo produto, pensar em como usuários humanos descobrem meu aplicativo, se cadastram e chegam rapidamente àquele momento “aha”. Mas, quando penso em como uso agents pessoais, e em como acho que outras pessoas vão usá-los, se já não estiverem usando, é que elas vão delegar aos agents boa parte da pesquisa, da descoberta do produto, do início do uso do produto e de chegar

01:33 àquele momento “aha”. Então, estou pensando em como será muito importante permitir que agents façam isso com o Waypoint. Agora, quando avancei um pouco mais nessa reflexão, a pergunta seguinte foi: como conecto esses agents que estão começando a usar meu produto nesse modo a clientes reais? E, por fim, quando penso mais em como o Waypoint funciona para viagens corporativas de equipes, há aspectos de conformidade e risco financeiro. Então, é muito importante para mim

02:03 garantir que eu possa limitar o que um agent pode fazer. Também posso revogar o acesso quando precisar. Com essas três perguntas em mente, vamos ver como fiz isso com o Waypoint. A primeira coisa que estou pensando é em como deixar os agents entrarem. Se vocês acessarem este link aqui, ele termina em auth.md. Este é um link real. Vocês podem acessá-lo, mas ele não foi feito para nós. Foi feito para agents. auth.md é um protocolo aberto que descreve como agents podem

02:34 criar contas em aplicativos. auth.md é um arquivo Markdown que você hospeda junto com seu aplicativo. E, mais uma vez, você pode acessá-lo e lê-lo, mas ele não foi feito para nós. Foi feito para seu agent. É onde um agent pode descobrir como começar a usar seu aplicativo. Ele descreve os mecanismos para obter acesso, criar uma conta e poder chamar uma API de usuário. Uma coisa importante a lembrar sobre auth.md é que ele descreve o acesso

03:04 e as operações, mas quem as aplica é o seu aplicativo — neste caso, o Waypoint — por meio da API de autorização. Então, nesse arquivo auth.md sobre o Waypoint, que vou apresentar e demonstrar, há dois modos. O primeiro permite que agents experimentem meu aplicativo no modo anônimo. Quero que os agents possam fazer ações limitadas para comprovar que meu aplicativo tem valor, sem precisar se cadastrar e criar uma conta. Mas, voltando à segunda pergunta que fiz antes, quero muito que esses agents

03:36 ajam em nome dos usuários. Quero poder ampliar as ações disponíveis que ofereço a esses agents quando consigo vinculá-los a um usuário real. Então, vamos ver o primeiro mecanismo do protocolo auth.md e como isso pode acontecer. Esse fluxo começa permitindo que um agent experimente algumas coisas no modo anônimo; depois, um usuário entra, reivindica o que o agent fez e transfere essas ações para a conta do agent. A primeira parte desse protocolo é

04:07 permitir que um agent faça ações anônimas na minha API. Ao final, o agent recebe um access token e também algo chamado claim token, que permitirá que um usuário reivindique o que o agent fez e transfira isso para a conta desse usuário. Nesse fluxo, quando o usuário quiser assumir a propriedade do que o agent está fazendo, o agent pode fornecer um link e um código de uso único. O usuário acessa meu aplicativo, o Waypoint. Faz o cadastro, entra

04:37 e informa o código. A pessoa reivindicou o que o agent fez e transferiu isso para a própria conta. Por fim, usando OAuth, meu servidor de autorização pode emitir um access token em nome desse usuário para o agent, que vai usá-lo para chamar minha API. Isso permite que o agent faça coisas, mas talvez vocês tenham notado que há um link, um fluxo de cadastro, a inserção de um código e a verificação do meu e-mail. E, se vocês sabem alguma coisa sobre crescimento impulsionado pelo produto, sabem que é aí que se perde o usuário.

05:09 Mas o meu agent já não sabe quem eu sou? Quando vocês usam Claude Code hoje, ou usam Muse, vocês já estão conectados. E esse serviço fez alguma coisa para verificar que vocês são quem dizem ser, porque ele quer garantir que vocês provavelmente são pessoas reais. Então, verificou o e-mail de vocês ou algo do tipo. Se o agent sabe quem eu sou, por que o provedor do agent não pode simplesmente dizer ao meu aplicativo quem eu sou e me deixar entrar

05:42 sem que eu precise fazer nada manualmente? Bem, isso também é possível com AuthMode. Vou explicar esse protocolo e o padrão chamado ID-JAG em que ele se baseia, e mostrar uma pequena demonstração de como funciona. Para explicar, o fluxo começa com o agent descobrindo como se autenticar na sua API. Isso segue a terminologia padrão do OAuth para descobrir seu recurso protegido — sua API, seu servidor MCP — e seu servidor de autorização OAuth. E então as coisas ficam um pouco interessantes.

06:12 Seu agent vai até você, como usuário, e pede consentimento para compartilhar sua identidade e seu e-mail com o aplicativo Waypoint. Se você consentir, o agent vai até o provedor do agent. Então, seu agent do Claude vai até o Claude e diz: “Ei, me dê um ID-JAG”. Guardem isso por enquanto; já volto e explico o que é. O agent recebe o ID-JAG e o envia ao servidor de autorização da sua API. Seu aplicativo, seu servidor de autorização

06:43 vai verificar se esse ID-JAG é legítimo. Ele vai encontrar algumas informações sobre você dentro dele, e então seu app decide se vai criar uma conta para esse usuário, vinculá-la a uma conta existente e que tipo de acesso vai conceder ao agent no access token. Seu app tem controle total sobre isso. Por fim, com esse access token, o agent pode chamar sua API em nome do usuário. Eu disse algo, para usar um termo do Claude, um pouco “estruturalmente importante” nesse

07:14 ID-JAG. Alguém aqui já ouviu falar de ID-JAG? Estou vendo uma pessoa, e ela trabalha comigo, então é engraçado. Se vocês têm acompanhado o que Claude está fazendo, o que a Anthropic está fazendo com autorizações gerenciadas para empresas na especificação MCP, e o que a Okta está fazendo com acesso entre apps, tudo isso usa a mesma especificação, o mesmo protocolo chamado ID-JAG. Vou explicar o que é. ID-JAG significa Identity Assertion Joined Authorization Grant. É uma especificação da IETF. Na prática, um ID-JAG é uma

07:47 declaração da identidade de um usuário. Ela é assinada por um emissor. Nesse fluxo, o provedor do agent é o emissor. E é enviada para um público específico. Então, novamente, neste fluxo, o público específico é meu aplicativo. Vamos ver o que há dentro dela. No cabeçalho, ela informa que é do tipo ID-JAG, o algoritmo usado para a assinatura e a chave de assinatura. No payload, é onde as coisas ficam interessantes. Ele informa quem a emitiu,

08:17 que, neste caso, é o provedor do agent. Ele fornece informações sobre o usuário a partir do provedor do agent: o nome do usuário, o e-mail e se o e-mail foi verificado. Depois, informa para quem o token se destina. A audiência é meu aplicativo Waypoint, e um ID de cliente é um cliente conhecido pelo Waypoint. Por fim, informa por quanto tempo ele é válido. E, o mais importante, ele é assinado pela chave pública do emissor, o provedor do agent. Então, o servidor de autorização do Waypoint,

08:47 recebe esse JWT de ID. Ele vai verificar a assinatura. E cabe ao Waypoint decidir em que confiar nisso. Cabe totalmente ao Waypoint decidir se quer criar uma conta para esse usuário, que tipo de acesso quer conceder e quais escopos quer incluir no access token que devolve ao agent em nome desse usuário. Então, vamos ver como isso fica na prática. Vou fazer uma demonstração. Estou em um agent harness que criei aqui. Esse

09:19 agent harness consegue emitir JWTs de ID. Estou conectado a esse agent harness como Sam Rivera. Tenho um e-mail, e este é um usuário novo. O Waypoint não sabe nada sobre esse usuário. Nunca o viu antes. E vou dizer ao meu agent harness, vamos ver aqui. Planeje… preciso largar meu microfone.

09:54 Certo. Estou dizendo ao meu agent harness: quero que você planeje meu itinerário em Nova York, e quero poder compartilhá-lo com meus colegas de trabalho. Quero que você encontre uma ferramenta que faça o planejamento e facilite o compartilhamento, todas essas coisas. Então, meu agent harness está procurando ferramentas. Está encontrando outras ferramentas de planejamento de itinerários de viagem, como o Maple Itinerary, e não consegue acessar essa ferramenta porque ela exige cadastro pelo navegador. O TripIt precisa de uma chave de API, mas o Waygo permite que agents se cadastrem.

10:24 Então, ele me pediu consentimento: posso compartilhar seu nome e seu e-mail verificado com o Waygo? Vou dizer que sim. Aí o Waygo… o fluxo de autorização do Waygo também pediu outro consentimento para algumas permissões mais elevadas. Neste exemplo, o Waygo pode fazer reservas para jantar com o agent. Então, dou meu consentimento. E meu agent harness vai conversar com o Waygo sobre isso. Vamos ver o que ele faz.

10:56 Certo, minha identidade foi verificada. Minha conta no Waygo foi criada. Não precisei fazer nada. Foi tudo feito sem nenhuma intervenção minha. Ah, ele reservou uma mesa para jantar, e meu itinerário está pronto para ser compartilhado. Certo, olhem só. Aí está meu itinerário. Ele reservou um jantar para mim no Quality Bistro, que é muito bom. Se alguém já foi lá, eu recomendo. Ele me deu um link que posso compartilhar com meus colegas. E tudo isso foi feito sem nenhuma interação da minha parte.

11:29 Isso foi bem legal. A última coisa que vou dizer sobre o JWT de ID é que estou realmente confiante de que, nesta era em que agents acessam outras coisas, para podermos fazer isso de forma segura e confiável, tudo vai precisar ser construído com base em padrões abertos. Todos vamos precisar de padrões abertos para que agents se comuniquem com serviços, façam coisas, paguem e criem contas. Estou muito animada com boa parte do trabalho de padronização que tem sido

12:00 feito agora. Muitas coisas foram anunciadas só na última semana. Certo, vamos passar à última parte desta apresentação. Como posso limitar e revogar o que um agent pode fazer? Para mim, isso é muito importante no Waypoint, porque permito reservas de viagens corporativas. Quero que os funcionários responsáveis pelas reservas de viagem possam usar agents. Quero criar agents para eles. Mas, nesse caso, há dinheiro real da empresa em jogo. Preciso poder auditar.

12:31 Preciso garantir que o dinheiro não seja gasto de maneiras indevidas. Então, vou apresentar uma pessoa: Jordan. Jordan é responsável pelos fundos da empresa em que trabalha. Só Jordan pode aprovar o orçamento e as regras. Criei alguns agents no Waypoint para Jordan usar. O primeiro é somente de leitura. É o chatbot clássico que Jordan pode perguntar: “Ei, o que há de errado com o orçamento?” ou algo assim. Ele responde, mas não consegue fazer nada de verdade. Depois, criei um agent de fundos para Jordan.

13:03 Esse agent de fundos vai poder transferir dinheiro entre usuários. Digamos que um usuário esteja voando de São Francisco, e as passagens estejam muito caras em comparação com as do usuário que vem de trem de Boston. Jordan quer poder redistribuir os fundos, mas, desde que isso ocorra dentro do orçamento e das regras aprovadas, não precisa fazer isso manualmente. Pode usar o agent. Mas é muito importante para Jordan que o agent de fundos não saia do controle. Ele não pode alterar o orçamento. Não pode alterar as regras de aprovação para fazer as coisas funcionarem.

13:34 Então, como faço isso acontecer no meu aplicativo? Jordan aciona um agent. No backend do meu aplicativo, ele emite tokens para agents. Para mim, é muito importante não simplesmente entregar ao agent o token de usuário de Jordan. Há alguns motivos para isso. Um é auditoria e atribuição. Outro é revogação. Quero que Jordan possa revogar o agent. Quero poder — quero que meu aplicativo possa revogar o agent sem afetar a sessão nem o acesso de Jordan.

14:05 Por fim, quero poder limitar o que o agent pode fazer. Quero limitar os escopos no token. Configurei esses agents criando um modelo, ou como se fosse um teto de acesso, para o agent somente de leitura e para o agent de fundos. Quando Jordan os aciona, os escopos do token emitido para o agent correspondem à interseção entre as permissões de usuário de Jordan e os escopos definidos no teto do modelo do agent. Por fim, o agent pode chamar minha API com um token de acesso com escopo — desculpe, um

14:36 token de agent com escopo. Vou mostrar rapidamente como isso funciona e depois encerro com alguns códigos QR para vocês conferirem tudo isso. Estou no Waypoint como Jordan. Estou vendo as viagens da minha equipe. Tenho um orçamento para a equipe. Parece que há US$ 70 disponíveis. Vou iniciar meu agent somente de leitura. Certo, meu agent somente de leitura foi iniciado. Se eu olhar os detalhes da sessão, o token de usuário de Jordan de que falamos antes está

15:07 aqui à esquerda. Vejo que Jordan tem várias permissões. O modelo do agent somente de leitura está no meio. Ele tem apenas uma permissão. Há também algumas informações da sessão. E então temos o token do agent, emitido pelo meu aplicativo. O sujeito do token do agent é o ID do agent, então ele pode ser atribuído ao agent específico. Ele está agindo em nome de Jordan, o usuário, então também tenho essa informação nele. E as permissões são a interseção entre o token de usuário de Jordan

15:37 e o modelo do agent. Para ganhar tempo, vou pular o agent somente de leitura e passar diretamente para o agent de fundos, porque é um pouco mais interessante. Vou iniciar esse agent de fundos e pedir que corrija o orçamento de Alex.

16:08 Certo, Alex tem um déficit de US$ 250. Quer que eu redistribua os fundos? Sim, redistribua. É difícil fazer isso segurando um microfone. Muito bem, o agent de fundos conseguiu transferir US$ 70 para Alex, mas não consegue cobrir tudo, porque não há mais orçamento disponível. E o agent de fundos não pode alterar o orçamento, mas eu, como Jordan,

16:40 posso. Então, meu usuário ainda consegue alterar o orçamento com seu token de usuário. Vamos mudar para 2.000. Como usuário, consegui fazer isso. O agent não conseguiu. E então vou dizer a ele que aumentei o orçamento. Opa.

17:16 Certo, lá vamos nós. E então o agent conseguiu corrigir o orçamento do Alex. O que mostramos aqui, na prática, é como você pode incorporar agents à sua aplicação, estabelecendo um limite máximo para as permissões deles. Eles operam usando um token de agent com esse acesso restrito, em vez de usar o token do seu usuário ou uma API key. Assim, você pode auditá-lo. Sim, você pode auditá-lo, revogá-lo e garantir que as permissões desse agent sejam limitadas. Certo. Voltando aqui, acabei de mostrar essa demonstração. Então, três pontos principais: como

17:49 você pode permitir que agents acessem sua aplicação com um arquivo Auth MD, como pode conectá-los a um cliente usando o fluxo de declaração do usuário no Auth MD ou a declaração de identidade ID Jag e, por fim, como pode limitar as ações aplicando permissões e revogação. Vou terminar com alguns códigos QR. O da esquerda é do Auth MD; como eu disse, é um padrão aberto. E o da direita é o agent auth da WorkOS, que foi como consegui incorporar agents à minha aplicação com permissões limitadas, usando um token de agent.

18:20 E vou encerrar minha palestra por aqui. Muito obrigada a todos. Se alguém tiver alguma pergunta, ficarei feliz em conversar depois.

Transcrição original

[00:01] [music] >> Hi everyone. My name is Isabel. I’m a product manager at WorkOS. Today, I’m going to be talking about how your next user is an agent. Briefly on WorkOS, we do infra for auth. We help you build apps, agents, APIs. We’re trusted by over 3,000 customers including OpenAI and Propel and Cursor.

[00:33] Okay. For my presentation today, I’m going to be using an app that I live coded with Cursor. It’s called Waypoint. It is a travel planning app both for individual use and for company travel. And we’re going to use Waypoint today to help plan our trip to AIE in New York City. All righty. So, over the past year, but especially in the past few weeks with Muse and Instinct and the rise of personal agents, I’ve been thinking a lot about what this means for Waypoint. The first thing that I’ve been thinking

[01:03] about is how do I let agents into my app? So, when I think about the personal travel tier of Waypoint, before agents, it’s, you know, really important from like a product led growth perspective to think about how human users discover my application, get signed up, and get to that aha moment really quickly. But when I think about how I’m using personal agents, and how I think others are going to be using personal agents if they’re not already, is that they’re going to be turning over a lot of that research, product discovery, and getting started with the product, and getting to

[01:33] that aha moment totally over to their agents. So, I’m thinking about how it’s going to be really important that I let agents do this with Waypoint. Now, as I got a little further into that thinking, the next question that I have is how do I connect those agents that are getting started with my product in this mode to real customers? And then finally, as I think more about how Waypoint works for company travel for corporate teams. There are compliance and financial risk elements to that. So, it’s really important to me

[02:03] to make sure that I can limit what an agent can do. Um I can revoke it when I need to. So, with those three questions in mind, let’s talk through how I did them with Waypoint. So, the first thing that I’m thinking about, how to let agents in. Um if you go to this link here, um it ends in off.md. So, this is a real link. You can actually go to this, but it’s not meant for us. It’s meant for agents. Off.md is an open protocol um that um talks about how agents can

[02:34] register for accounts with applications. Off.md is a markdown file that you host with your application. And again, you can go to it and read it, but it’s not meant for us. It’s meant for your agent. It’s where an agent can discover how to get started with your application. It describes the mechanisms for getting access, for creating an account, um and being able to call an user API. One thing that’s important to remember with Off.md is that it describes access

[03:04] and operations, but your application, so in this case Waypoint, is the one that’s enforcing off theory API. So, in this Off.md file that I’m going to talk about for Waypoint and I’m going to demo, um there’s two modes to it. The first mode is allowing agents to um try my application in anonymous mode. So, I want agents to be able to take limited to prove that my application has value without having to sign up and create an account. But to the second question I posed earlier, I really want these agents to

[03:36] be acting on behalf of users. So, I want to be able to expand the available actions um that I give to these agents when I can tie them back to a real user. So, let’s jump into the first mechanism of the Off.md Off.md protocol for how that can happen. So, this flow goes from letting an agent try things out in an anonymous mode, and then a user coming in and claiming what that agent did and transferring the actions over to the agent account. So, the first part of this protocol is

[04:07] an agent being able to take anonymous actions at my API. So, in the end of this, the agent gets an access token, and then they get something that a claim token that eventually is going to let a user claim what the agent did and move it under that user’s account. So, the flow to this one, at some point when the user wants to take ownership of what their agent is doing, the agent can give them a link and a one-time code. The user comes over to my application, Waypoint. They sign up, they sign in,

[04:37] they enter the code. They’ve claimed what the agent has done, they’ve brought it under their account. And finally, using OAuth, my authorization server can issue an access token on behalf of that user to the agent, and the agent’s going to use that to call my API. So, this lets the agent do things, but you might have noticed there is a link and a sign-up flow and entering a code and verifying my email. And if you know anything about product-led growth, you know this is where you lose your user.

[05:09] But, doesn’t my agent already know who I am? Like, when you guys use Cloud Code today, when you use Muse, you’re signed in. And that service has done something to verify that you are who you say they are to you say you are because they care about ensuring that you are probably a real person. So, they verified your email or something to that extent. So, if the agent knows who I am, why can’t the agent provider just tell my application who I am and let me in

[05:42] without me having to take manual actions? Well, that’s also possible with AuthMode. So, I’m going to break down this protocol and the standard called ID Jag that it’s built on and I’ll show you a little demo of how this works. So, to break this down, this starts with your agent discovering how to authenticate with your API. This is like standard OAuth parlance of finding out about your protected resource, your API, your MCP server, um and your OAuth authorization server. And then things get a little fun.

[06:12] So, your agent is going to come to you as the user and ask for consent to share your identity and your email with the application Waypoint. If you consent, the agent goes to the agent provider. So, your you know, Claude agent goes to Claude and says, “Hey, give me an ID Jag.” Put a pin in that. I’ll come back to what that is in a second. So, the agent gets the ID Jag, sends the ID Jag over to your API’s authorization server. Your application, your authorization

[06:43] server is going to verify that that ID Jag is the real deal. It’s going to see some information on you inside of it and then your app is in control of deciding, am I going to create an account for this user? Am I going to link it to an existing account? What sort of access am I going to give back in the access token to this agent? Your app is completely in control of that. And so finally, with that access token, the agent can call your API on behalf of the user. So, I said something, to use a Claude term, a little bit load-bearing um in

[07:14] this ID Jag. Has anyone here heard of ID Jag? I see one person and he works with me, so that’s funny. Um so, if you’ve been following what Claude is doing, what Anthropic is doing with enterprise managed authorizations in the MCP spec, what Okta is doing with cross-app access, that’s using the same spec, the same protocol called ID Jag. Let me break down what that is. So, ID Jag, Identity Assertion Joined Authorization Grant. This is a spec in the IETF. Um effectively what an ID jag is is an

[07:47] assertion of a user’s identity. It’s signed by an issuer. So, in this flow, the agent provider is the issuer. And it’s sent for a specific audience. So, again in this flow, the specific audience is my application. And let’s break down what’s in this. Um in the header, it tells you that this is of type ID jag, the algorithm used for signing, and the signing key. In the payload, this is where things get interesting. It tells you who issued it,

[08:17] which in this case is the agent provider. It gives you information from the agent provider on the user. So, the user’s name, their email, whether the email was verified. And then it tells you who it’s for. So, the audience is my application Waypoint, and a client ID is a client that’s known to Waypoint. And then finally, it tells you how long it’s valid. And most importantly, it’s signed by the issuer, the agent provider’s public key. So, Waypoint, their authorization

[08:47] server, gets this ID jag. They are going to verify um the signature. And it’s up to Waypoint what they want to trust in this. It’s completely up to Waypoint if they want to create an account for this user, what sort of access they want to what sort of scopes they want to give in the access token that they hand back to the agent on behalf of this user. So, let’s see what that actually looks like in action. To give you a demo. Um so, I am in an agent harness that I built here. This

[09:19] agent harness is able to issue ID jags. I am logged in to this agent harness as Sam Rivera. I have an email, and this is a fresh user. It Waypoint doesn’t know anything about this user. It’s never seen this user before. And I am going to say to my agent Harness, um let’s see here. Plan I need to put down my mic.

[09:54] Okay. So, I’m telling my agent Harness, I want you to plan my itinerary for a New York City and I want to be able to share with my co-workers and I want you to find a tool that’s going to do the planning and make it easy to share, all that good stuff. So, my agent Harness is going and looking at tools. It’s finding some other travel itinerary planning tools like Maple itinerary, um and it can’t get through to there cuz it needs a browser sign up, TripIt needs an API key, but Waygo allows for agents to sign up.

[10:24] And so it asked me for consent. Can I share your name and verified email with Waygo? I’m going to say yes. And then Waygo and Waygo’s off and be filed also asked for some other consent for some more elevated permissions. In this example, it’s allowing Waygo to book dinner reservations with the agent. So, I give it my consent. And my agent Harness is going to talk to Waygo about this. Let’s see what it does.

[10:56] Okay, it’s verified my identity. It created my Waygo account. I didn’t have to do anything. Totally hands-off on my part. Oh, it booked a trip, dinner reservation, and my itinerary is ready to share. Okay, look at that. Um there’s my itinerary. It booked me dinner at Quality Bistro, which is quite good. If anyone has been there before, I would I would recommend it. Um it’s given me a link that I can share with my colleagues. And all that was done without any interaction on my part.

[11:29] So, that was pretty cool. Um what I’ll final thing I’ll say on the ID Jack part is that um, what I feel really confident in in um, kind of this era of agents accessing other things is that for us to be able to do this safely and securely and in a trusted manner, it’s going to all need to be built on open standards. Um, we are all going to need open standards for agents to talk to services to do things to pay to sign up for accounts. Um, so I’m really excited about a lot of the standard standardization work that’s been

[12:00] happening right now. A lot of things are announced like just over the past week. All right, moving on to the last part of this presentation. How can I limit and revoke what an agent can do? So, for me this is really important in Waypoint because I allow for corporate travel booking. And I want to let corporate employees responsible for travel booking um, use agents. I want to build agents for them. But with this, there’s real corporate money on the line. I need to be able to audit.

[12:31] I need to be able to make sure that money is not thrown around in ways that it shouldn’t be. So, introducing a persona here. Jordan, Jordan’s responsible for company funds at Jordan’s company. Um, Jordan’s the only one that can approve budget and approve her rules. Now, I’ve built a couple of agents into Waypoint for Jordan to use. The first one’s read only. It’s your classic chatbot that Jordan can ask, “Hey, what’s wrong with the budget?” or whatever. Um, and it’ll tell it, but it can’t actually do anything. But then I built Jordan a fund agent.

[13:03] This fund agent is going to actually be able to move funds around between users. Let’s say that one user is flying from San Francisco and flights are really expensive compared to the user coming in via train from Boston. And so Jordan wants to be able to move funds around, but as long as it’s happening within the budget and the approved rules, Jordan doesn’t need to manually do it himself. He can use the agent. But it’s really important to Jordan that the funding agent can’t go rogue. It can’t change the budget. It can’t change the approval rules to make things work.

[13:34] So, how do I make this happen within my application? So, Jordan invokes an agent. And on the back end of my app, my app issues agent tokens. So, it’s really important to me that I don’t just hand an agent Jordan’s user token. There’s a few reasons for this. One is auditing and attribution. Two is revocation. I want Jordan to be able to revoke the agent. I want to be able I want my application to be able to revoke the agent without impacting Jordan’s session and Jordan’s access.

[14:05] And then finally, I want to be able to limit what the agent can do. I want to limit the scopes in the token. So, the way that I’ve set these agents up is I’ve created a blueprint or like a ceiling of access for the read-only agent and for the fund agent. And when Jordan invokes them, um the agent token that’s issued for the agent, the scopes in it is the intersection of Jordan’s user permissions and the scopes in the ceiling of the agent blueprint. And so then finally, the agent can call my API with a scoped access uh sorry, a

[14:36] scoped agent token. So, I’ll just briefly show you what that is and then I’ll end with some QR codes here so you guys can check out um all of this stuff. So, I am in Waypoint as Jordan. I am looking at my team travel here. I have a team budget. There’s looks like $70 available. Start up my read-only agent. All right. So, my read-only agent is started. If I take a look here at the session details, what we were talking about earlier with Jordan’s user token, it’s

[15:07] here on the left. I can see that Jordan has a bunch of permissions. The agent blueprint for the read-only agent is in the middle. It only has one permission. Um it has some session session information. And then the agent token, it’s issued by my application. The subject of the agent token is the agent ID, so it’s attributable to the actual agent. It’s acting on behalf of Jordan the user, so I have that information in there as well. And the permissions are the intersection between Jordan’s user

[15:37] token and the agent blueprint. Um so I’m in the interest of time, I’m going to skip the read-only agent and just move over to the fund agent cuz it’s a little more interesting. So starting up this fund agent, I’m going to ask it to fix Alex’s budget.

[16:08] Okay, so Alex has a $250 shortfall. Um do you want me to rebalance funds? Yes, rebalance. Hard to do while holding a mic. All righty, so the funding agent was able to move $70 over to Alex, but they can’t fix all of it because there’s no more budget available left. And the funding agent doesn’t have the ability to change the budget, but I as Jordan

[16:40] do. So my user is still able with their user token to change the budget. Let’s change it to 2,000. So as the user I was able to do that. The agent couldn’t. Um and then so I’m going to tell it I increased the Oop. budget.

[17:16] Okay, there we go. And so the agent was able to fix Alex’s budget. So really what we showed here is that how you can build agents into your application um putting a ceiling on their permissions and they operate using an agent token with that scoped access instead of taking your user’s token or an API key. So you can audit it. It’s um yeah, you can audit it, you can revoke it and you can make sure that you limit the permissions of that agent. All righty. Coming back in here, I just showed that demo. Um so three takeaways here, um how

[17:49] you can let agents into your application with an Auth MD file, how you can connect them to a customer using the user claim flow in Auth MD or the ID Jag identity assertion, and then finally how you can limit actions by enforcing permissions and revocation. I’ll end with some QR codes. Um the one on the left for Auth MD, like I said, it’s an open standard. Um and the one on the right is WorkOS agent auth, which is how I was able to um build agents into my application with limited permissions using an agent token.

[18:20] And I will end my talk there. Thank you all so much. And if anyone has any questions, I’m happy to talk about it after.