Autenticação para agentes: permita que a IA crie uma conta no seu produto com auth.md — Michael Grinich, WorkOS

Ver no idioma original →

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: Auth for Agents: Let AI Sign Up for Your Product with auth.md — Michael Grinich, WorkOS · Canal: AI Engineer · 20:53 · Assistir no YouTube

Tópicos: Agentes de IA, Cibersegurança e segurança de software, Engenharia de software com IA, Ferramentas de desenvolvimento com IA

Resumo

Michael Grinich argumenta que agentes de IA estão se tornando uma nova classe de consumidores, mas muitos serviços ainda não permitem que eles se cadastrem de forma autônoma. Os fluxos tradicionais de registro foram projetados para humanos e exigem etapas como preencher formulários, resolver CAPTCHA e verificar e-mail. Para enfrentar esse obstáculo, ele apresenta auth.md, uma especificação aberta que orienta agentes no processo de cadastro e pode incluir declarações de identidade e limites de acesso. A proposta busca facilitar o uso de serviços por agentes sem substituir os mecanismos existentes de API, MCP ou autenticação.

Pontos-chave

• Agentes capazes de executar tarefas por longos períodos estão transformando a engenharia de software e podem mudar outros setores.
• Para serem eficazes, agentes precisam de ambiente de execução, ferramentas, contexto, feedback e revisão humana.
• Serviços online podem precisar atender agentes como uma nova classe de consumidores, além das pessoas.
• Os fluxos de cadastro atuais pressupõem interação humana e dificultam o acesso autônomo de agentes.
• MCP ajuda agentes a se conectar a ferramentas e obter contexto, mas não resolve por si só o cadastro em serviços.
• auth.md é apresentado como uma especificação aberta para descrever como um agente pode se registrar legitimamente em um serviço.
• O processo pode incluir declarações de identidade, verificação, limites de uso gratuito e formas de envolver uma pessoa ou organização posteriormente.
• Após o cadastro, agentes podem continuar usando APIs e outros mecanismos existentes; auth.md se concentra na etapa de registro.
• A proposta é permitir que agentes comecem a usar serviços antes de exigir pagamento, de acordo com as regras de cada provedor.
• Grinich incentiva provedores e desenvolvedores a experimentar a especificação e construir para a chamada economia de agentes.

Capítulos

Início	Capítulo	Resumo
00:12	A evolução da engenharia com agentes	Grinich descreve a passagem da programação interativa para agentes que trabalham por longos períodos e em paralelo.
05:21	Agentes como novos consumidores	A palestra apresenta os serviços escolhidos por agentes e explica por que os produtos devem permitir que eles se cadastrem.
10:29	A proposta de auth.md	Grinich diferencia a conexão oferecida por MCP do cadastro e introduz auth.md como uma especificação aberta para essa etapa.
15:39	Demonstração e funcionamento do cadastro	A demonstração mostra um agente obtendo uma credencial, criando uma conta na Cloudflare e implantando um projeto.
19:18	Especificação aberta e a próxima plataforma	O palestrante destaca que auth.md pode ser implementado em diferentes plataformas e compara a ascensão dos agentes a uma nova onda de software.

Citações

Também precisamos pensar em criar algo que os agentes queiram. — 06:24

MCP não é suficiente. — 10:29

auth.md serve apenas para a etapa de cadastro. — 16:41

Acho que os agentes são a próxima grande onda. — 20:21

Conceitos e entidades

• auth.md (conceito): Especificação aberta apresentada para orientar agentes no cadastro em serviços online.
• agent harness (conceito): Ambiente que reúne componentes como o modelo, a memória e o contexto necessários para um agente executar tarefas.
• MCP (conceito): Padrão para conectar agentes a ferramentas, serviços e contexto, mas que, segundo a palestra, não resolve a etapa de cadastro.
• ID-JAG (conceito): Credencial assinada descrita na demonstração, usada para representar uma identidade durante o registro do agente.
• WorkOS (empresa): Empresa fundada por Michael Grinich, associada à proposta de auth.md.
• Cloudflare (empresa): Provedor usado na demonstração de cadastro e implantação realizada por um agente.
• Michael Grinich (pessoa): Fundador da WorkOS e palestrante que apresenta a proposta de auth.md.
• Salesforce (empresa): Empresa citada como exemplo de provedor que expõe seus produtos por interfaces voltadas a agentes, incluindo API, MCP e CLI.
• Y Combinator (empresa): Aceleradora mencionada como origem da frase sobre criar algo que as pessoas queiram.

Tradução completa (pt-BR)

00:12 Olá, pessoal. Bom dia. Meu nome é Michael Greenwich. Sou o fundador da work OS e estou aqui para conversar com vocês hoje sobre agents e, especificamente, sobre como podemos torná-los mais autônomos e permitir que acessem mais serviços na web. Então, vamos começar. Um salve também para quem está na primeira fila. Estou vendo vocês aqui. Há cerca de um ano, os engenheiros de software escreviam código assim. Usávamos IA, mas dávamos um prompt e depois escrevíamos um pouco de código

00:44 e então dávamos outro prompt, e ela escrevia mais um pouco de código. E continuávamos assim, com a engenharia de software interativa, com humanos no loop. Mais tarde naquele ano, surgiram coisas como os Ralph loops, caso alguém se lembre deles, com os quais automatizamos isso, de certa forma. Mais ou menos, era assim que trabalhávamos. Era uma alternância entre humano, agent, humano, agent. Mas, à medida que os modelos foram ficando cada vez melhores, eles conseguiram escrever cada vez mais código e funcionar por períodos mais longos. Então, hoje, boa parte da engenharia de software se parece com isto. Você escreve um único prompt e o agent consegue gerar um

01:14 monte de código. E, às vezes, ele consegue até criar um recurso inteiro, talvez até um produto inteiro, e talvez funcionar não por minutos, mas por horas e horas ou até dias e dias. Isso transformou de verdade a maneira como todos nós escrevemos código. Eu já não escrevo código à mão. Provavelmente você também não. E não se trata apenas de uma única thread. Na verdade, é possível paralelizar isso. Existem muitas ferramentas por aí, incluindo, sabe, os principais harnesses de codificação dos laboratórios, que permitem executar vários desses processos em paralelo. O fator limitante aqui, na verdade, o

01:45 gargalo é o seu cérebro. Quanto contexto você consegue manter na cabeça para dar conta de tudo isso ao mesmo tempo? Isso transformou a engenharia de software. As pessoas conseguem ser mais produtivas. Acho que todos nós já vimos no setor o quanto as coisas estão avançando mais rápido. Na raiz de tudo isso está a engenharia agentic: agents que passam de modelos de linguagem de previsão de tokens para raciocínio e, agora, para processos de longa duração que conseguem fazer coisas por nós de forma autônoma. E acho que o que vimos na engenharia de software com workflows agentic vai

02:15 chegar a muitas outras categorias. Não serão apenas os engenheiros que trabalharão dessa maneira. Serão pessoas de muitas áreas diferentes. Agents são a próxima grande novidade. Acho que uma boa referência para pensar nisso é o que vem acontecendo com os veículos. Sabe, este parece um carro bem moderno. Tem um painel digital. Provavelmente é o tipo de carro que você teria comprado nos últimos 5 a 10 anos. Mas, se você mora em San Francisco ou em uma das cidades com esses veículos autônomos, provavelmente já viu que estamos começando a eliminar a interface. Você já não

02:47 entra no carro e, sabe, pega o celular para abrir mapas, com você, como humano, no loop. Pode haver controle de cruzeiro, mas você ainda está no loop. Em vez disso, são sistemas autônomos. Você só diz para onde quer ir, entra no carro, nem precisa dizer nada, e ele simplesmente parte e leva você ao seu destino. Lembro da primeira vez que entrei em um Whimo: fiquei impressionado, completamente boquiaberto. E, depois de uns 3 segundos, peguei o celular e comecei a rolar o X. Virou algo comum. E acho que já vimos isso acontecer na engenharia. O poder dos agents

03:18 nos permite trabalhar e pensar em um nível mais alto, sabe, exercitar mais nossas funções executivas em vez de apenas planejar e executar. Há uma pergunta aqui: de que os agents precisam para ter sucesso? Na verdade, do que precisam para executar? Bem, primeiro, precisam de um ambiente de execução, um sandbox. Precisam de um lugar onde possam funcionar, que seja seguro, protegido e de alto desempenho. Também precisam de ferramentas. Precisam conseguir fazer coisas no mundo. Um agent não é muito útil se não consegue realizar ações. Então, precisa de ferramentas.

03:49 Terceiro, precisa de contexto. Sabe, esses novos modelos, com toda a inteligência que têm, são como pegar a pessoa mais inteligente que você conhece e colocá-la numa empresa, num projeto ou numa equipe onde ela não sabe nada; assim, não consegue realmente fazer nada. Ela precisa de contexto, de informações sobre o sistema e sobre os objetivos. Precisa de feedback. Ou seja, de uma maneira de executar e validar o trabalho, verificar se está correto e, se não estiver, continuar trabalhando. E, por último, mas não menos importante, é claro que ainda precisa de revisão humana. Isso pode ser uma revisão de código. Pode ser outras formas de

04:19 evals. Pode ser algum tipo de verificação do trabalho para garantir que esses agents estejam, de certa forma, alinhados aos seus objetivos. O LLM, o mecanismo de inteligência, essa nova tecnologia que criamos nos últimos anos, pode ser entendido como um motor. É como um motor de alto desempenho. Acho que este é um motor V8. Sabe, produz muita potência. Consegue converter combustível em, sabe, resultado. Mas um motor sozinho não é muito útil para um carro. É preciso colocá-lo no carro propriamente dito

04:50 É preciso ter o chassi, a transmissão, o sistema de tração e as rodas. E só com tudo isso o carro será eficaz para levar você a algum lugar. É a isso que muita gente se refere como harness. A engenharia de harness é essa nova área em que, se os modelos melhorarem, mas você não tiver um bom harness, sabe, o sistema não será muito eficaz. Então, à medida que os modelos melhoram, mudamos nossos harnesses e os adaptamos a eles. E aquelas coisas que mencionei antes são, de certa forma, componentes de um harness. Os agents executam dentro desses harnesses para realizar tarefas, e precisam de todos esses elementos para serem realmente eficazes.

05:21 E, quando dirigem, dirigem muito, muito rápido. Então, imagine que você tem um desses agents trabalhando. Você dá um prompt para ele construir alguma coisa para… Sabe, ele fica processando por um tempo e diz: “Certo, vou precisar deste recurso e deste outro, de um banco de dados e de, sabe, este sistema de edição para fazer o deploy. Também vou precisar, sabe, talvez desta ferramenta para redimensionar imagens, transcodificar vídeos, enviar e-mails ou qualquer outra coisa.” E o seu agent consegue fazer toda essa pesquisa e construir todos esses sistemas. E hoje o que está acontecendo com os agents é que eles estão escolhendo fornecedores.

05:53 Provavelmente você já viu o crescimento de alguns desses sistemas, sobre os quais os CEOs publicam no Twitter seus gráficos de crescimento, que disparam. E isso acontece porque os agents os escolhem. Escolhem seus sistemas para enviar e-mails ou fazer deploy de código. Seus sistemas para armazenar dados. Hoje, talvez seja mais importante criar para agents do que para pessoas. Agents são uma nova classe de consumidores. Vou falar disso daqui a pouco. Há uma frase bastante popular em San Francisco e no Vale do Silício: “Crie algo que as pessoas queiram”. Ela vem da Y Cominator, sabe, a fábrica de startups de Paul Graham. E acho que está na hora de talvez editar um pouco essa frase. Daqui para a frente, também precisamos pensar em criar algo que os agents queiram. No futuro, haverá mais agents do que pessoas, talvez até hoje. Será mais rápido colocá-los em funcionamento. Eles farão as coisas mais depressa. Tomarão decisões em nosso nome. Então, se você quer criar para a próxima era de consumidores, também deve criar para agents, além de para pessoas. Mas há um problema hoje. É possível acessar a web. É possível acessar o mobile.

06:24 Mas os próprios agents não conseguem realmente acessar os sistemas. Provavelmente, hoje a sua empresa não está aberta para agents. Mesmo havendo muitos deles por aí, e podendo ser criados muito rapidamente, a porta está fechada. E achamos que isso acontece porque falta um elemento fundamental: o cadastro agentic, o cadastro de agents. Há muitas soluções ótimas para conectar agents e levar contexto aos sistemas, além de diferentes frameworks open source, mas esse primeiro passo, de um agent realmente se cadastrar em um serviço, é

06:56 Mas os próprios agents não conseguem realmente acessar os sistemas. Provavelmente, hoje a sua empresa não está aberta para agents. Mesmo havendo muitos deles por aí, e podendo ser criados muito rapidamente, a porta está fechada. E achamos que isso acontece porque falta um elemento fundamental: o cadastro agentic, o cadastro de agents. Há muitas soluções ótimas para conectar agents e levar contexto aos sistemas, além de diferentes frameworks open source, mas esse primeiro passo, de um agent realmente se cadastrar em um serviço, é

07:26 está faltando. Isso ainda não foi resolvido e é um enorme obstáculo para a adoção. Nos últimos 20 anos, talvez 30, o tráfego automatizado na web tem sido ruim. Tentamos bloqueá-lo por completo. Por isso, criamos todos esses sistemas para detectar agentes automatizados e impedi-los de agir. Prevenção de ataques DoS, credential stuffing e outros ataques. A tela de login, por exemplo, hoje é muito protegida contra cadastros feitos por agents. Não

07:57 intencionalmente, mas simplesmente por causa dos sistemas legados que construímos. E é muito difícil distinguir um usuário automatizado legítimo de um mal-intencionado. Se algum de vocês já usou algum desses ambientes de execução de navegador na nuvem, um dos recursos que eles costumam destacar é quebrar CAPTCHAs, o que é bem surpreendente. Sabe, estamos tentando voltar no tempo. Mas o CAPTCHA de hoje ainda está meio morto. Há abusos generalizados. Há muita fraude com tokens. Então, precisamos encontrar uma maneira melhor de permitir a entrada dos

08:27 agents legítimos e bloquear os mal-intencionados, certo? Porque, como eu disse antes, se você não construir para a economia dos agents, seu produto talvez não vença. Talvez não tenha sucesso. Os fluxos de cadastro atuais pressupõem que uma pessoa consegue ler a página inicial, preencher um formulário — sabe, inserir o endereço de e-mail e a senha —, resolver um CAPTCHA e verificar o e-mail. Não basta inserir o endereço: é preciso clicar em algo em algum lugar. Lembre-se: um agent provavelmente não tem um endereço de e-mail. Se ele estiver se cadastrando em um serviço, precisa ter… sabe, uma pessoa pode

08:58 escolher um plano para pagar pelo serviço. Sabe, uma pessoa pode copiar a chave de API, colá-la em algum lugar e usá-la em outro; e até mesmo acessar um painel. Pense na experiência de um painel: ela não é realmente nativa para agents. Tudo isso foi feito para pessoas. É uma interface para humanos, não para agents. Agents precisam de outra coisa. Precisam de descoberta nativa. Eles podem se cadastrar em um sistema? As portas estão abertas para agents ou não? Declaração de capacidades: o que ele pode fazer? Intenção de cadastro: por que você está se cadastrando? O que está tentando fazer

09:28 aqui? Ou qual é a intenção ao simplesmente se cadastrar? Há muitas questões de risco envolvidas. Então, para um cadastro nativo para agents, talvez você não tenha certeza se o agent que está se cadastrando será legítimo ou mal-intencionado. Nesse caso, é preciso fazer uma avaliação de risco. Pode haver diferentes formas de verificar a identidade de um agent. Se algo como Claude estiver se cadastrando, talvez possa trazer consigo a identidade do usuário. Ou, se você tiver um OpenClaw, seu harness do Pi ou algo do tipo, talvez ele não traga a identidade do usuário e seja verificado por outro meio. Há também

09:59 toda a questão das organizações que fazem isso. Se estou criando algo dentro de uma empresa, como a identidade da minha empresa entra nisso? Sabe, minha organização, direitos de acesso, permissões, emissão de credenciais, capacidade de auditoria — a lista continua. Há muita coisa que precisa mudar. Na verdade, provavelmente a maior parte das coisas precisa mudar na transição do cadastro de humanos para o cadastro de agents e sistemas nativos para agents. Lamento dizer, mas MCP não é suficiente.

10:29 Provavelmente sou um dos maiores fãs de MCP. Fizemos vários eventos em San Francisco sobre MCP. Estou vendo alguém aqui usando uma das nossas camisetas Run MCP que fizemos. Adoro MCP. MCP é ótimo para conectar, fornecer ferramentas, skills e contexto, mas não resolve a etapa de cadastro. Hoje, a autenticação por meio de MCP ainda exige que um humano participe do processo. Você dá seu consentimento. Adiciona um servidor MCP — por exemplo, do PostHog — ao Claude e entra com suas credenciais do PostHog. O que estamos discutindo aqui, o cadastro nativo para agents, precisa acontecer sem o

11:00 envolvimento de um humano ou, pelo menos, sem envolvimento inicial. Então, estamos trabalhando nisso há algum tempo, e esta é a nossa proposta. É uma nova especificação que chamamos de auth.md, porque arquivos Markdown são o futuro, certo? Bem, como isso funciona na prática? O que é auth.md? A ideia é que auth.md diga aos agents como eles podem se tornar usuários legítimos. É um conjunto de instruções que diz a um agent que está se cadastrando em um serviço: é isto

11:31 que você precisa fazer para se cadastrar, ser considerado legítimo e receber acesso. O objetivo é oferecer aos provedores de serviços — sabe, às pessoas que estão criando serviços — uma experiência de cadastro nativa para agents, mas baseada em padrões existentes, em vez de inventar uma religião nova e maluca ou algo muito complicado. Com auth.md, não estamos resolvendo todo o problema da identidade dos agents, das permissões, da longa duração nem dos serviços conectados. Estamos tentando resolver apenas essa questão mais restrita

12:02 do cadastro, porque acho que é um enorme obstáculo. Vamos começar pequeno e crescer a partir daí. Isso é baseado em padrões abertos e em muito trabalho que já foi feito em todo o OAuth, adaptado especificamente para a etapa de cadastro. Ele pode responder a perguntas como: o que o serviço faz? Pode dizer aos agents como se cadastrar e quais provas de identidade são aceitas. Também pode dizer como um agent ou usuário comprova sua identidade, quais fluxos de autenticação são aceitos, se é possível se cadastrar com SSO, endereço de e-mail ou MFA, quais

12:35 escopos e direitos de acesso podem existir, quais capacidades estão disponíveis e quais são as restrições do plano gratuito. Talvez você tenha um sistema em que queira oferecer um pouco de capacidade gratuita a um agent, mas não demais até que ele verifique a identidade ou pague de alguma forma. Certo. E, claro, como o humano se envolve depois? Um humano ou uma organização pode reivindicar a conta posteriormente. Assim, um agent pode se cadastrar, mas você quer que o humano passe a ter controle depois. É isso que auth.md foi projetado para resolver. Essas são as principais questões relacionadas à etapa de cadastro.

13:05 Então, como isso funciona na prática? Vou mostrar uma pequena demonstração ilustrada. E tudo isso funciona, aliás; vocês podem experimentar depois. Digamos que eu esteja aqui em qualquer harness de programação ou sistema que eu esteja usando, Pi, Claude ou algo assim, e apareça: “Boas-vindas de volta, Michael, da WorkOS” — esse é mesmo meu e-mail, caso queiram me escrever. “Quer continuar trabalhando no seu app Spell?” “Sim, claro. Gostaria de compartilhá-lo com meus amigos, mas eles não conseguem acessá-lo.” E o agent responde: “Ah, é que o localhost só funciona na sua máquina, então seus amigos não vão conseguir acessá-lo.” É claro que, para compartilhá-lo, preciso fazer o deploy em algum lugar de verdade.

13:36 Alguns provedores permitem que eu cuide do cadastro. Assim, sabe, você não precisaria se cadastrar e fazer isso. “Quer que eu procure?” “Sim, por favor.” “Agent, procure serviços que anunciem por meio de auth.md.” O Vercel tem auth.md, então o agent pode dizer: “Ah, Cloudflare. É esse.” A Cloudflare é a escolhida, porque posso me cadastrar nela e acessar o

14:06 serviço. Posso realmente usá-lo e fazer tudo isso. “Quer seguir com essa opção?” “Sim, vamos lá.” Esta é a etapa de cadastro. É aqui que a mágica acontece. O que meu agent está fazendo é emitir uma declaração de identidade e entregá-la à Cloudflare. Então, a Cloudflare pode verificá-la ou não. A Cloudflare pode optar por verificar por outro meio. auth.md é muito flexível. Há diferentes maneiras de configurá-lo, dependendo do comportamento que você procura. Uma solução única não serve para todos.

14:37 Cada aplicativo é diferente. As restrições são totalmente diferentes. Se você estiver criando algo como um serviço de banco de dados, em que haverá pouca informação, talvez queira oferecer um pouco de tráfego grátis. Mas, se estiver criando algo como um serviço de e-mail — especialmente se houver acesso ao mundo físico —, talvez não queira oferecer nada de graça. Isso depende muito do aplicativo. Aqui, a Cloudflare diz: “Certo, estamos dispostos a deixar você fazer o deploy por, talvez, 72 horas ou algo assim. Obtenha a declaração de identidade. Pronto, pronto, pronto. Siga em frente.” O padrão se chama ID-JAG. E então ele retorna

15:08 e diz que você está com uma conta da Cloudflare configurada. Agora, nessa experiência, eu, como humano, não precisei clicar em nada. Não me cadastrei em lugar nenhum. Ele simplesmente conseguiu o token. Posso fazer alguns pequenos ajustes. Ele sabe usar o Wrangler. Quer que eu faça essas alterações? Pode fazer. Alguém dá prompts assim para os agentes? É só: “Sim, sim, faça, por favor.” Sem dizer muita coisa. Ele consegue escrever o código para o Wrangler, configurar tudo, passar por todo o processo de deploy e, então, pronto: está no ar. Na verdade, temos isso funcionando como uma demonstração ao vivo. Fizemos uma colaboração com

15:39 a Cloudflare nesse projeto também. É bem legal. E dá para perceber que os prompts que eu estava dando não eram exatamente ciência de foguetes. O agent conseguia simplesmente passar por todo o processo. Na verdade, não havia nada que eu estivesse fazendo por meio dos prompts além de aprovar, aprovar e aprovar. Ele deveria conseguir fazer isso de uma só vez. É assim que isso fica graficamente. Então, no cadastro de agents com auth.md, você tem, por exemplo, o Pi, seu agent harness. Dentro dele estão o LLM, talvez a memória e diferentes camadas de contexto. Ele se conecta ao serviço de identidade de apoio

16:10 Então, esse é o serviço de identidade do usuário. E, quando o agent se cadastra, ele envia a chamada de descoberta para a Cloudflare. Ele procura o serviço de autenticação ou qualquer que seja o serviço. Também temos isso funcionando com o Firecrawl. É bem legal. Ele envia o ID-JAG, o Identity JSON Access Grant. É essencialmente uma credencial assinada que representa o usuário e diz: “esta é uma identidade”. Em seguida, recebe de volta o token de acesso, o token de API de verdade, e pronto: acabou. Você pode fazer solicitações normais à API, pode chamar

16:41 MCP; todo o resto continua funcionando. Então, dá para ver que auth.md serve apenas para a etapa de cadastro. Sua API normal continua funcionando, o restante da documentação não precisa mudar; é só essa etapa de cadastro para agents. Mas essa simplicidade traz, na verdade, um enorme poder, porque, de repente, permite que agents façam coisas de ponta a ponta. Detesto a etapa de planejamento. Quando escrevo algo, só quero que o agent vá e faça. Em geral, ele meio que entende o que estou tentando fazer, e quero voltar e encontrar um protótipo funcionando, não

17:12 algo como: “Ei, aqui está meu longo plano. Aqui estão vários serviços nos quais você precisa se cadastrar.” Especialmente quando estou criando protótipos novos, prefiro que ele simplesmente faça o deploy em algum lugar de graça, para eu poder ver e explorar, sem me obrigar a passar pelo trabalho de me cadastrar em todos esses fornecedores diferentes. E é isso que auth.md permite. E, se você é um provedor de serviços, se está criando APIs ou serviços, isso permite que você se torne uma opção para os clientes desses sistemas. Você pode pensar nisso como uma expansão do seu funil de crescimento: começando talvez apenas com humanos e acrescentando todo o universo de agents. É muito bom.

17:43 Achamos que isso vai ser enorme. Sua porta ficará aberta para que agents se cadastrem, se registrem e usem seus serviços. Isso deve gerar um impulso imediato de crescimento para seus produtos. E não estou dizendo que tudo o que os agents criarem será útil. Talvez nem tudo o que criarem vá para produção ou dure tanto tempo, mas algumas coisas vão. Assim como aconteceu com PLG ou, antes disso, com o freemium, essa é uma forma de expandir seu negócio, conquistar mais clientes e, de fato, se tornar maior e mais bem-sucedido. E, onde há uso, acreditamos que também há intenção de pagar.

18:15 Há muito trabalho interessante sendo feito para que agents realmente paguem pelas coisas. Existem protocolos baseados em criptomoedas, como o X42. Há outras coisas que os provedores de pagamento estão desenvolvendo, mas achamos que isso deve vir depois. Não queremos que os pagamentos sejam exigidos logo de início. Não queremos obrigar seu agent a se cadastrar com cartão de crédito. Isso parece o contrário do que deveríamos fazer. No mundo do SaaS, já nos afastamos disso. Com auth.md, os agents podem se cadastrar, podem se registrar, podem começar a usar o serviço e, depois, optar por pagar nos seus termos, de acordo com seus preços e seu modelo. Se você não acredita em mim ou no tipo de produto sem interface, este é Marc Benioff. Ele é o CEO e fundador da Salesforce, a empresa daquele grande prédio aqui na cidade. Eles acreditam em agents mais do que em qualquer outra coisa. “Nossa API é a interface.” As plataformas Salesforce e Agentforce Slack agora estão disponíveis por meio de API, MCP e CLI. Isso sim é colocar agents em primeiro lugar. Uma empresa que muita gente considera uma espécie de fornecedora legada de SaaS, mas que, na verdade, inventou a categoria de software como serviço. Eles estão se livrando do painel e da interface. Quer dizer, não estão se livrando deles, mas acreditam que os agents são o futuro.

18:46 produtos do tipo sem interface, este é Mark Benioff. Ele é o CEO e fundador da Salesforce, o pessoal do prédio grande aqui na cidade. Eles acreditam em agents mais do que em qualquer outra coisa. Nossa API é a interface. As plataformas Salesforce, Agentforce e Slack agora estão totalmente disponíveis por API, MCP e CLI. Isso sim é priorizar agents. Uma empresa que muitas pessoas consideram uma espécie de fornecedora legada de SaaS realmente inventou a categoria de software como serviço. Eles estão se livrando do painel e da interface. Quer dizer, não estão se livrando deles, mas acreditam que os agents são o futuro.

19:18 Então, se você não está pensando nisso, recomendo muito que comece a criar alguns protótipos e conversar com usuários, porque não vai querer perder essa oportunidade. Se quiser usar isso, já está disponível. Temos uma especificação aberta. Há um repo no GitHub. Você pode até pedir para seu agent implementar isso. Sei que é meio metalinguístico. É uma especificação aberta. A WorkOS não controla isso. Temos uma versão hospedada por nós, mas você pode criar a sua. Pode executá-la nos seus sistemas atuais. Acho que isso é tão importante que nenhum fornecedor deveria ser dono dessa tecnologia. Com um clique, ela fica habilitada se você usa nossos produtos, mas você também pode criá-la em qualquer

19:49 plataforma que quiser. Para terminar, isso aconteceu há quase 20 anos, acho que aqui mesmo no Moscone, o que é bem legal. Em janeiro de 2007, acredito, Steve Jobs apresentou o iPhone. Eu estava na faculdade e me lembro — sim, no primeiro ano da faculdade — disso com muita clareza. Foi a próxima grande plataforma de software a ser criada. Muitas empresas surgiram porque podiam criar produtos para esses dispositivos. A revolução dos smartphones

20:21 e, desde então, não houve realmente um momento como esse, pelo menos para mim, na era da tecnologia. O que fizemos com SaaS B2B, a nuvem e tudo isso é ótimo, mas aquilo foi um paradigma totalmente novo, uma nova plataforma de software. E acho que os agents são isso; os agents são a próxima grande onda. Então, o que eu diria a todos vocês é: saiam e criem com auth.md. Esperamos que isso abra essa possibilidade para vocês, para seus negócios e para o crescimento de vocês. Mas queremos ouvir de vocês onde estão encontrando dificuldades. E acho que, juntos, podemos criar para esta próxima era empolgante do software e construir

20:53 para a revolução agentic. Muito obrigado.

Transcrição original

[00:12] Hello everyone. Good morning. My name is Michael Greenwich. I am the founder of work OS and I’m here to talk with you today about agents and specifically about how we can make agents more autonomous and allow them to access more services on the web. So let’s jump in and get started. Shout out to those of you in the front row also. I see you out here. So about a year ago, software engineers were writing code like this. We were using AI, but we would prompt it and then we would write a little bit of code

[00:44] and then prompt it again and it would write some more code. And you would continue to do this human in the loop interactive software engineering. Later in the year, we had things like Ralph loops, if any of you remember those, where we kind of automated this. More or less this is the way that we were working. It was this human agent human agent back and forth. However, as the models got better and better, they were able to write more and more code and run for longer periods of time. And so today, a lot of software engineering looks like this. You write a single prompt and then the agent can spit out a

[01:14] lot of code. And sometimes it can actually build a whole feature, maybe even a whole product and maybe run for not minutes but uh hours and hours or even days and days. This has really transformed the way that we all write code. I don’t write code by hand anymore. Probably you don’t as well. And it’s not just this one thread. You can actually parallelize this. So there’s many different tools out there including, you know, the major code coding harnesses from the labs that allow you to run many of these in parallel. The limiting factor here, really the

[01:45] bottleneck is your brain. How much context do you can keep in your mind to keep all of these going at once? And this has transformed software engineering. People can be more productive. I think we’ve all seen in the industry how much faster things are moving. At the root of all of this is actually agentic engineering agents going from these token prediction language models to reasoning and now longunning processes that can actually do things autonomously for us. And what I think we’ve seen in software engineering here around agentic workflows is going to

[02:15] come to a lot of different categories. It won’t just be engineers that have this way of working. It’ll be people in many different fields. Agents are the next big thing. I think a good reference for this, a way to think about it is actually what’s been happening with vehicles. So, you know, this looks like a pretty modern car. It has a, you know, digital display on it. This is probably what you would have bought in the last, you know, 5 to 10 years. But if you live in San Francisco or one of the cities with these autonomous vehicles, you’ve probably seen that we’re starting to delete the interface. No longer do you

[02:47] get inside of the car and actually, you know, pull up your phone and get maps where you as a human are in the loop. There might be cruise control, but you’re still in the loop. Instead, these are autonomous systems. You just say where you want to go, you get in the car, you don’t even say anything, and it just takes off and takes you to your destination. I remember the first time I got into a Whimo, I was blown away, mind totally blown. And then after about 3 seconds, I pulled out my phone and started scrolling X. It became common place. And I think we’ve seen this already happen with engineering. The power of agents

[03:18] allows us actually to work and think at a higher level for us to, you know, exercise more of our executive function versus just planning and execution. There’s a question here of what do agents need to be successful? Actually, when they execute, what do they need? Well, first they need a runtime, a sandbox. They need somewhere that they can run that needs to be safe, secure, performant. They also need tools. They have to be able to go do stuff in the world. An agent’s not very useful if it can’t take actions. So, it needs tools.

[03:49] Third, it needs context. You know, these new models with the power of the intelligence in them, it’s kind of like taking the smartest person you know and dropping them into a company or a project or a team where they don’t know anything, they can’t really get anything done. They need to have context, information about the system, information about the goals. They need feedback. So a way that they can actually run and validate that they can check that their work is correct and if it’s not correct keep going. And last but not least of course they still need human review. This might be code re review. This might be other forms of

[04:19] evals. This might be forms of checking their work to make sure that these agents are sort of aligned with your goals. The LLM the intelligence engine this new technology we’ve created in the last last few years you can think of as like an engine. It’s like a really high performance. You know, I think this is a a V8 engine. You know, puts out a lot of horsepower. It can convert fuel into, you know, output. But an engine by itself isn’t very useful for a car. You need to drop this into the actual car

[04:50] itself. You need the chassis, you need the transmission, you need the drivetrain, you need the wheels. And only with all of that is it going to be effective to take you places. And this is what a lot of people refer to as the harness. Harness engineering is this new domain where if the models get better but you don’t have a good harness you know it’s not going to be very effective so as the models improve we change our harnesses we adapt them to it and those things that I mentioned earlier are sort of a form of a harness so agents execute within these harnesses to get stuff done and they they need all those elements to actually be effective

[05:21] and when they drive they drive really really fast so say you have one of these agents that’s going off you prompt it to go build something for So, you know, it spins for a while. It says, “Okay, I’m going to need this feature and this feature and I’m going to need a database and I’m going to need, you know, this editing uh, you know, system to deploy and I’m going to need, you know, maybe this thing for image resizing or video transcoding or sending email or whatever.” And your agent can actually go do all this research and build all these systems. And today, what’s happening with agents is they’re actually selecting vendors.

[05:53] You’ve probably seen the rise of some of these systems where you know like the CEOs will tweet about their growth graph and it really takes off and it’s because agents are picking them. They’re picking their systems for sending email or deploying code. Their systems for storing data today actually it might be more important to build for agents than to build for people. Agents are kind of this new consumer class. I’ll talk about that in a bit. There’s this uh kind of popular thing that people say in San Francisco Silicon Valley. Make something people want. This comes from Y Cominator, you know, the

[06:24] startup factory from Paul Graham. And I think it’s time to maybe edit this a little bit. And going forward, we also need to think about making something that agents want. There will be more agents in the future than people, maybe even today. They’ll be faster to spin up. They’ll do things quicker. They’ll be making decisions on our behalfs. And so, if you want to build for the next era of consumers, you should be building for agents as well as people. But there’s a problem today. You can access the web. You can access mobile.

[06:56] But agents themselves can’t really access systems. Your business probably isn’t open for agents today. Even though there’s a lot of them out there, they can spawn very quickly. The door is not open. And we think this is because there’s a missing primitive. Agentic registration, agent registration. There’s a lot of great stuff around agents connecting and bringing context to systems and different open source frameworks, but that first step of an agent actually signing up for a service is actually

[07:26] missing. It hasn’t been solved and it’s a huge blocker to getting adoption. For the last like 20 years, maybe 30 years, automated traffic on the web has been bad. We’ve tried to block all of it. And so there’s all these systems that we’ve put in place to detect automated actors and stop them in their tracks. DOS prevention, credential stuffing, and attacks. The login box, for example, is very hardened against agentic registration today. Not

[07:57] intentionally, but just because of the legacy systems of what we built. And it’s very hard to distinguish between what’s a good automated user versus a bad automated user. If any of you have used any of these like cloud-based uh browser execution environments, one of the selling features they often have is to break captures, which is pretty wild. You know, we’re trying to go backwards. The capture today though is is still kind of dead. There’s rampant abuse. There’s lots of token fraud. And so, we need to find a better way to allow the

[08:27] good agents in and then block the bad agents, right? Because like I said earlier, if you don’t build for the agent economy, your product might not win. It might not be successful. Today’s signup flows assume that a human can read the landing page, that they can fill out a form, you know, put their email address, their password in it, that they can solve a capture, that they can verify their email, not just put it in, but go click something somewhere. Remember, an agent probably doesn’t have an email address. If it’s signing up for a service, it needs to have a, you know, a human can

[08:58] choose a plan to pay for it. You know, human can copy the API key out, paste it somewhere, use it somewhere else, and really even a dashboard. Think of a dashboard experience. It’s not really agent native. All this stuff is built for people. It’s kind of a human interface, not an agent interface. Agents need something else. They need native discoverability. Can they register for a system? Are the doors open for agents or not? Capability declaration. What can it do? Registration intent. Why are you registering? What are you trying to do

[09:28] within this? Or the intent to actually just sign up. There’s a lot of stuff around risk here. So for an agent native registration, maybe you want to you’re not sure if the agent signing up is going to be good or bad. So you need to actually do a risk assessment of that. There might be different forms of identity verification for an agent. If something like claude is going and signing up, maybe it can bring the user’s identity with it or if you have a you know open claw or like your pi harness or something else, maybe it doesn’t bring the user’s identity and gets verified out of band. There’s the

[09:59] whole thing around organizations doing this. So if I’m building something within a company, how does my company identity come in? You know, my organization, entitlements, permissions, credential issuance, auditability, the list goes on. There’s so many things that need to be changed. In fact, probably most things need to be changed going from, you know, human registration to agent registration, agent native systems. I’m sorry to say MCP is not enough.

[10:29] Probably more than anybody, I’m a big MCP fan. We’ve done a bunch of events in San Francisco around MCP. I see somebody wearing one of our run MCP shirts up here that we made. Love MCP. MCP is great for connecting, for providing tools, skills, context, but it doesn’t solve the registration step. Today, authentication through MCP requires your human to still be in the loop. You give consent. You add an MCP server, say for Post Hog to Claude, you sign in with your Post Hog credentials. What we’re talking about here for agent native registration needs to happen without the

[11:00] human involved or at least not involved initially. So we’ve been working on this for a while and our proposal. This is a new spec we have called o.md because markdown files are the future right? Well, how does this actually work? What is o.md? Well, the idea here is that OMD tells agents how they can become legitimate users. It’s a set of instructions that tells an agent registering for a service, this is what

[11:31] you need to do to sign up and be considered legit and for me to give you access. And the goal here is to give these service providers, you know, people that are building building services an agent native signup experience, but it’s built on existing standards instead of inventing a crazy new religion or something really complicated. With OMD, we’re not solving the whole problem around agent identity, you know, permissions, long duration, you know, connective services. We’re just trying to solve this narrow one

[12:02] around registration because I think it’s a huge blocker. Let’s start small and grow from there. This is built on open standards. It’s built on a bunch of work that’s already been done across the OS specifically tailored to that registration step. often do you can answer what does the service do tell agents how to register it can tell them what identity proofs are accepted how to how how an agent or user is proving their identity what offflows are supported can you sign up with SSO or email address or MFA what

[12:35] scopes and entitlements can exist kind of what capabilities are here what free tier constraints apply you might have a system where you want to give an agent a little bit of free capacity but not too much until they verify or pay in some Okay. And then of course, how does the human get involved later? A human or an organization claiming it afterwards. So an agent can sign up, but you want the human to have custody later on. This is what A&D is designed to solve. These are the main questions around the registration step.

[13:05] So how does this actually work? Well, here’s a little uh kind of cartoon demo that I’ll show you. And all this works, by the way, you can go try it after this. So say I’m here in u whatever coding harness or system I’m using pi or clot or something and it says welcome back Michael at work OS that’s actually my email if you want to email me do you want to keep working on your spelled app like yeah sure I’d like to share this with my friends but they can’t access it and the agent’s like oh well local host only works on your machine so your friends won’t be able to hit it of course to share it I need to deploy it

[13:36] somewhere real some providers actually let me handle the sign up so you know you wouldn’t have to sign up and do this you want me to look Yes, please agent look for services that advertise through author here does have an OMD and so the agent here can say ah Cloudflare that’s the one cloudflare is a winner because I can go sign up for it I can access the

[14:06] service I can actually use it so I can do the whole thing you want to go with it yeah Let’s do it. This is the registration step. This is kind of where the magic happens. What my agent is actually doing is minting an identity assertion and giving that to Cloudflare. And then Cloudflare is able to verify that or not. Cloudflare can choose actually to verify out of band. AMD is very flexible. There’s different ways you can dial it in depending on the behavior that you’re looking for. One size does not fit all.

[14:37] Every application is different. Constraints are totally different. If you’re building something that’s like a database service where there’s going to be very little amount of information, you might want to give away a little bit of traffic for free. But if you’re building something maybe like an email service or something certainly if you access the physical world, you you maybe don’t want to give anything away for free. It’s very application specific. So here Cloudflare says, “Okay, we’re willing to let you deploy maybe for 72 hours or something like that. Get the identity assertion. Boom, boom, boom. Go through. It’s called ID Jag is what the standard is.” And then it returns back

[15:08] and says you’re set up with a Cloudflare account. Now in this experience, my you know human I didn’t go click anywhere. I didn’t sign up anywhere. It just it just got the token. I can make a couple small tweaks. It knows how to use Wrangler. Want me to make those changes? Go ahead. Does anybody prompt their agents like this? It’s just like yes, yes, do it, please. Not really saying much. It’s able to write the Wrangler, get the thing set up, go through the full deployment process, and then boom, it’s live. We actually have this working as a live demo. We did some collaboration with

[15:39] Cloudflare on this too. It’s pretty cool. And you can tell the prompting that I was giving through this not exactly rocket science. The agent could just run through the whole thing. Actually, there’s nothing actually that I was doing through prompting it other than just approving, approving, approving. It should be able to do this one shot. This is what it looks like graphically. So agent registration with OMD, you have your agent harness pi for example. within that is your LLM, maybe your memory, different, you know, context layers. It connects to your backing

[16:10] identity service. So this is the user identity. And when that agent goes and registers, it sends the discovery call to Cloudflare. It looks for that aund or whatever service. We also have this working with fire call. It’s pretty cool. It sends that ID Jag, the identity JSON access grant. It’s essentially a signed credential that represents the user says this is an identity receives back the access token actual API token and then boom it’s it’s done you can make normal API requests you can call

[16:41] MCP everything else still works so you can see that OMD is just for the registration step your normal API keeps working the rest of your docs don’t have to change it’s just that registration step for agents but with the simplicity comes actually an enormous amount of power because suddenly it lets agents do things end to end. I hate the planning step. When I write something, I just want the agent to go do it. Usually it kind of knows what I’m trying to get at and I want to come back to actually a running prototype and not

[17:12] like, hey, here’s my long plan. Here’s a bunch of services to sign up for. If I’m building new prototypes, especially, I would prefer it just to get deployed on something for free so I can see it and click around and not put me through the burden of going sign up for all these different vendors. And that’s what OMD allows for. And if you’re a service provider, if you’re building APIs or services, this allows you to become a customer of those systems and you can think about it increasing your growth funnel starting from, you know, maybe just humans and adding the whole world of agents on top. Pretty great.

[17:43] We think this is going to be huge. Your door will be open for agents to actually sign up, register, use your services. This should be an immediate growth boom for your products. And I’m not saying everything that agents are going to build will be useful. Maybe not everything they build will go into production or last that long, but some things will. Just like with PLG or Premium before that, this is the way to grow your business and get more customers and actually become, you know, larger and more successful. And where there’s usage, we believe there’s also intent to pay.

[18:15] There’s a lot of interesting work being done for agents to actually pay for stuff. There’s crypto-based protocols like X42. There’s other things that the payment providers are building, but we think that should be downstream. We don’t want payments to be upfront. We don’t want to have to force your agent to sign up with a credit card. That seems backwards. We moved away from that in the world of SAS. With OMD, agents can sign up, they can register, they can start using it and then downstream choose to pay on your terms based on your own pricing, based on your own model. If you don’t believe me or on the

[18:46] headless type of products, this is Mark Beni off. He’s the CEO and founder of Salesforce, the guys at the big building here in town. They believe in agents more than anything. Our API is the UI. Entire Salesforce and agent force Slack platforms are now exposed as API, MCP, and CLI. Talk about going agent fork first. A company that many people consider to be sort of a legacy SAS vendor really invented the category of software as a service. They’re getting rid of their dashboard and UI. I mean, they’re not getting rid of it, but they believe that agents are the future.

[19:18] So, if you’re not thinking about this, I definitely encourage you to start building some prototypes, talking to users, because you don’t want to miss miss this. If you want to use this, this is available today. We have open spec for it. There’s a GitHub repo. You can actually have your agent go implement it. I know it’s kind of meta. It’s an open spec. Work OS doesn’t control it. We have a version of it that we host, but you can build it yourself. You can run it yourself in your existing systems. I think this is so important that no single vendor owns this. It’s one click enabled if you use our stuff, but you can build it on whatever

[19:49] platform you want instead. Last thing I’ll close with, this actually happened almost 20 years ago, I think actually here at Moscone, which is pretty awesome. in uh January of 20 uh 2007 I believe Steve Jobs introduces iPhone and I was in college and I remember or yeah like first year of college I remember this super super clearly. It was the next great software platform that got built. So many companies got started because they could build on top of these devices. smartphone revolution

[20:21] and there hasn’t really been a moment like this since I think in the the era of technology at least for me the stuff we did around B2B SAS and cloud and all that is great but this was a totally new paradigm a new software platform and I think agents are this agents are the next big wave and so what I would say to all of you is go out and build with AMD we’re hoping to unlock this for you unlock this for your business and for your growth but we want to hear from you here the places you get stuck and I think together we can build for this next exciting era of software and build

[20:53] for the agentic revolution. Thank you so much