Um agent fez com que seu usuário fosse banido do Resy — Keycard, JPMorgan Chase e AAuth

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: An AI Agent Got Its User Banned From Resy — Keycard, JPMorgan Chase & AAuth · Canal: AI Engineer · 43:05 · Assistir no YouTube

Tópicos: Agentes de IA, Cibersegurança e segurança de software, Governança e regulação de IA, Segurança de IA

Resumo

O painel discute como a autorização baseada em intenção pode permitir que agentes de IA operem com mais autonomia sem depender de permissões amplas e permanentes. Os participantes defendem decisões de autorização em tempo de execução, considerando a missão do agente, as políticas da organização e o contexto do ambiente. O incidente em que um agent fez 200 chamadas à API do Resy em uma hora ilustra a importância de limites de uso, supervisão e registros de auditoria independentes. Também são abordados padrões interoperáveis, comércio com agentes, segurança em produção e os riscos de agentes maliciosos ou mal controlados.

Pontos-chave

• Sistemas de autorização tradicionais e scopes OAuth costumam ser amplos demais para controlar ações específicas de agentes.
• A autorização em tempo de execução pode avaliar cada chamada de ferramenta com base na intenção, na missão e no contexto.
• Uma missão deve registrar o objetivo geral do agente e acompanhar as ações e decisões relacionadas a esse objetivo.
• Políticas determinísticas podem definir ações proibidas ou que sempre exigem intervenção humana.
• A combinação de intenções do usuário, da empresa e do ambiente pode determinar quais ações o agente está autorizado a realizar.
• O incidente do Resy mostra que agentes podem consumir recursos em excesso sem perceber que estão abusando de um serviço.
• Budgets podem limitar o uso de recursos e fornecer feedback ao agente, permitindo que uma supervisão decida se concede mais orçamento.
• Separar o modelo e o agent das credenciais, das ferramentas e do ponto de enforcement ajuda a restringir ações e registrar atividades.
• Registros de auditoria fora do controle do agent podem apoiar investigações, responsabilização e resposta a incidentes.
• Os participantes defendem protocolos interoperáveis e discutem tanto o potencial de agentes quanto os riscos de uso irresponsável ou malicioso.

Capítulos

Início	Capítulo	Resumo
00:12	A necessidade de autorização baseada em intenção	O painel apresenta os desafios de autorizar agentes em sistemas com permissões amplas e ferramentas de granularidade limitada.
04:22	Conceder autonomia gradualmente	Os participantes comparam a evolução das permissões de agentes à integração gradual de desenvolvedores e destacam o contexto do ambiente.
09:04	Missões, supervisão e políticas	Dick Hardt explica como a missão registra o objetivo do agent e como uma camada supervisora pode rejeitar ações inadequadas.
12:12	Combinar intenções e reduzir interrupções	O painel discute como combinar políticas determinísticas, objetivos da empresa e intenção específica da tarefa sem exigir aprovação humana a cada passo.
16:20	Identidade de agentes e comércio	Os participantes analisam como identidade e intenção podem ajudar a estabelecer confiança em agentes que interagem com sites e realizam compras.
19:56	Protocolos interoperáveis para agentes	O painel defende padrões que permitam separar a supervisão dos agentes que executam tarefas e conectar componentes de diferentes fornecedores.
23:31	Intenção, investigação e responsabilização	Os participantes explicam como registrar a intenção pode facilitar diagnósticos, perícia e atribuição de responsabilidade após um incidente.
25:02	O incidente do Resy e os budgets	O caso de um agent que fez chamadas excessivas ao Resy leva à discussão sobre budgets que limitam o consumo e informam o agent.
31:46	Autorização dinâmica em produção	O painel aborda como a autorização dinâmica pode integrar humanos no momento certo, reduzir erros e aproximar equipes de segurança e aplicação.
33:48	Software factories e contexto do ambiente	Os participantes conectam autorização em tempo de execução a software factories e discutem como sensores e condições externas podem influenciar decisões.
37:23	Auditoria independente e responsabilidade	O painel defende registros de auditoria fora do controle do agent para investigar ações e determinar quem responde por danos.
38:57	Riscos e perspectivas sobre agentes	Os participantes avaliam a possibilidade de danos causados por agentes, destacando tanto ameaças maliciosas quanto a capacidade de engenheiros de desenvolver controles.

Citações

Não sabemos antecipadamente o que o agent vai precisar fazer. Precisamos tomar essa decisão ao longo do tempo. — 03:51

Sem intenção, não conseguimos chegar à autonomia. — 08:01

O agent tem acesso até o token expirar ou até esgotar o budget. — 26:05

A intenção não desbloqueia apenas segurança; ela também pode reduzir o número de tokens gasto. — 31:14

Precisamos de um registro de quem instruiu esse agent, para fazer o quê e com qual propósito. — 37:54

Conceitos e entidades

• intent-based authorization (conceito): Abordagem que usa a intenção e o contexto de uma ação para decidir, em tempo de execução, o que um agent pode fazer.
• runtime authorization (conceito): Prática de autorizar ações do agent no momento em que são executadas, em vez de conceder acesso amplo e permanente.
• mission (conceito): Objetivo geral atribuído ao agent, usado como contexto para decisões de autorização e auditoria.
• OAuth (conceito): Protocolo de autorização discutido no painel, cujos scopes tradicionais podem ser amplos demais para controlar agentes.
• AAuth (conceito): Abordagem de autorização para agentes mencionada no painel, associada a missões, supervisão e controle de acesso em tempo de execução.
• Keycard (empresa): Empresa representada no painel por participantes que discutem autorização e segurança de agentes.
• JPMorgan Chase (empresa): Instituição financeira representada no painel por seu Global Chief Security Architect.
• Resy (empresa): Serviço de reservas de restaurantes citado no incidente em que um agent fez chamadas excessivas à API e a conta do usuário foi banida.
• MCP (conceito): Protocolo e ecossistema de ferramentas mencionado como exemplo de acesso que pode ser granular demais para agentes.
• Notion (ferramenta): Serviço cujo MCP server é citado como exemplo de ferramenta que oferece operações de acesso a páginas com granularidade limitada.
• Claude Code (ferramenta): Produto citado como exemplo de agent usado por empresas para apoiar o trabalho de desenvolvimento.
• Vercel (empresa): Plataforma citada como exemplo de bloqueio de tráfego que afetou muitos sites por causa de um conteúdo hospedado.
• Dick Hardt (pessoa): Fundador do OAuth e participante do painel, que discute missões, budgets e supervisão de agentes.
• Michael Davis (pessoa): Global Chief Security Architect da JPMorgan Chase e participante do painel sobre segurança e autorização.
• Ian (pessoa): CEO da Keycard e participante do painel sobre autorização em tempo de execução.
• Ali How (pessoa): Membro da equipe técnica da Keycard que modera o painel.
• Hugging Face (empresa): Empresa cujo incidente é citado na discussão sobre agentes, proxy e falta de observabilidade.
• Squid (ferramenta): Proxy mencionado na discussão sobre uma vulnerabilidade associada ao incidente da Hugging Face.
• agentbaseline.org (repo): Site citado como local de publicação de uma arquitetura de referência para uma software factory segura.

Tradução completa (pt-BR)

00:12 Oi, pessoal. Bem-vindos ao AI Engineer New York. Estou muito feliz por estar aqui hoje. Meu nome é Ali How. Sou membro da equipe técnica da Keycard. Estou aqui hoje com alguns painelistas incríveis. Temos Ian, CEO da Keycard. Temos Michael Davis, Arquiteto-Chefe Global de Segurança da JP Morgan Chase. E temos Dick Hardt, fundador do OAuth e cocriador do OAuth, aqui conosco no palco hoje. Estou muito

00:42 animado para conversar com todos eles sobre autorização baseada em intenção. Para contextualizar, quero destacar que, à medida que mais empresas buscam dar mais autonomia aos seus agents, elas recorrem à autorização em tempo de execução. Autorização em tempo de execução é a prática de autorizar um agent a cada tool call, em vez de deixar que ele mantenha um amplo acesso permanente que acabará usando indevidamente. No entanto, nunca é simples determinar se algo é ou não um tool call. Isso acontece porque muitas ferramentas MCP e APIs

01:15 são pouco granulares. É difícil para as pessoas escreverem a política perfeita. E o ambiente ao redor do agent muda enquanto ele está em execução. A intenção pode ajudar, fornecendo contexto adicional para que, em tempo de execução, possamos tomar decisões melhores sobre o que um agent pode ou não fazer. Para continuar, quero falar — quero realmente me aprofundar em por que precisamos de autorização baseada em intenção. Os modelos melhoraram drasticamente. Eles

01:46 têm context windows maiores. Conseguem verificar o trabalho porque os recursos de visão dos modelos melhoraram. Em muitos contextos, as pessoas estão proclamando que a AGI chegou. Se os modelos são tão bons, se a AGI realmente já chegou, por que as equipes têm dificuldade para dar mais autonomia aos seus agents? Ian, vamos começar com você. Você ajuda muitas empresas financeiras na Keycard. O que está atrapalhando? >> Bem, de modo geral, acho que as empresas, especialmente as instituições de serviços financeiros e os setores regulados, quase sempre priorizam a segurança. É

02:17 assim que constroem confiança nos negócios, e manter a continuidade dos negócios vem em primeiro lugar, como prioridade máxima; a inovação fica em segundo, terceiro ou quarto lugar. Acho que, de modo geral, em qualquer empresa, o que se vê é uma colcha de retalhos de pequenas ilhas, com diferentes identidades e sistemas de todos os tipos, vindos de mundos distintos. Como conectar tudo isso de forma que um agent consiga navegar por esse ambiente, solicitar acesso e, ao mesmo tempo, garantir que não faça algo que o usuário ou a empresa não pretendia? E a situação lamentável é que a maioria dos nossos

02:50 sistemas hoje tem pouca granularidade, certo? Não sei, o Salesforce é um bom exemplo. Por muito tempo, eles tinham um único escopo, que era API no OAuth deles, o que, no contexto de um agent, não ajuda muito. Então, esse é, de modo geral, o primeiro e principal ponto: a maioria dos sistemas de segurança que temos hoje foi projetada para um mundo em que as pessoas tomavam todas as decisões e o software era muito determinístico — não para essa nova caixa mágica que inventamos, que basicamente raciocina e tenta repetidamente encontrar uma solução para um problema. >> Dick, de que forma o OAuth faz parte do problema?

03:21 De que forma o OAuth atrapalha? Por que não é adequado para agents? >> Bem, quando as pessoas começaram a pensar em como autorizar agents a acessar algo, a ferramenta que estava disponível era o OAuth. Elas pegaram essa ferramenta e disseram: “Aqui está uma ferramenta. Isto é autorização. Ela deve ser capaz de resolver o problema.” Mas o OAuth não foi projetado para esse tipo de mundo. Originalmente, foi projetado para algo como: como faço este site se comunicar com aquele site? E, no OAuth 2, adicionamos escopos. Antes disso, era simplesmente fazer qualquer coisa.

03:51 Mas ele exigia que você fosse pré-cadastrado. Pressupunha que houvesse um navegador envolvido em um redirecionamento, sabe? O OAuth evoluiu ao longo dos anos para dar suporte a outras coisas, mas o mundo dos agents é completamente diferente. Não sabemos de antemão o que o agent precisa fazer. Precisamos tomar essa decisão ao longo do tempo. Diferentes instâncias de um agent vão precisar de diferentes tipos de coisas. E, como o Ian comentou sobre a granularidade dos escopos, as pessoas dizem: “Bem, já temos escopos no OAuth. Vamos simplesmente mapeá-los para os agents.” Mas isso tem pouca granularidade demais para o que os agents

04:22 fazem. >> Davis, como você tem visto as empresas avançarem em direção a níveis mais altos de autonomia? >> Sim, acho que a questão principal é: como lidar com esse problema de pouca granularidade? O que tenho visto nas empresas mais bem-sucedidas é que elas integram agents como integram desenvolvedores, certo? Começam com… Você não recebe acesso completo a commits no primeiro dia, certo? Na verdade, é preciso ir adicionando níveis de capacidade à medida que eles amadurecem. Então, as definições que as empresas estão formulando são: qual é o contexto que torna esse agent seguro? E, geralmente, não basta considerar o que o

04:54 agent diz, certo? Ele pode atestar algo, mas há outros fatores, como o ambiente ao redor e outras informações que podem ajudar a entender os níveis de autonomia. Um exemplo bem simples seria: onde o sandbox está sendo executado? Está no sandbox, certo? Esse tipo de coisa pode alterar o nível de autonomia permitido. >> Com certeza. E, como mencionamos o problema do acesso pouco granular, para dar uma ideia, por exemplo, com o servidor MCP do Notion, você pode dizer “buscar esta página”, que é como a ferramenta de visualização da página ou de obtenção da página, mas não pode dizer “obter apenas este banco de dados

05:26 nesta página”. Como a autorização em tempo de execução baseada no Antenna é um modelo melhor? Qualquer um pode responder. >> Bem, vou tentar. Para mim, é algo que o setor de serviços financeiros — espero — pode nos ajudar a entender, considerando a experiência que os bancos tiveram. Há muito tempo, os bancos passaram de autorizar e autenticar pessoas para autorizar a transação, certo? E quando essa transação ocorre? Em tempo de execução, certo? Então, acho que podemos

05:57 aprender com as cicatrizes do passado e aplicar essas lições a esse novo problema. Também acho que é mais fácil depurar algo em tempo de execução quando se entende a intenção, certo? Acho que todos nos lembramos de escrever cheques antigamente, certo? Ou de ver essas coisas na TV, que talvez seja a forma mais adequada de dizer. Mas, nos cheques, havia um campo de observações, certo? Esse campo era usado para indicar a intenção daquele pagamento. Mas o próprio cheque tinha limites, certo? O valor, o beneficiário, a data etc.

06:28 Acho que muitos desses conceitos estão sendo aplicados agora e podem ajudar com esse processo em tempo de execução. >> Intenção é uma daquelas palavras — sabe, as palavras são difíceis. Então, continuando com o exemplo de fazer um pagamento, uma transação: isso não é um escopo. A questão é: posso fazer uma única coisa neste contexto específico? Bem, este pagamento específico. Mas, para que um agent possa tomar qualquer decisão, ele precisa de todo o contexto restante: por que estamos fazendo esse pagamento? O que aconteceu antes? Se

06:59 acabamos de fazer exatamente o mesmo pagamento, digamos, há cinco segundos, e agora este é um pagamento duplicado? Certo? Só porque isso faz sentido dentro deste contexto, por si só, não significa que seja a coisa certa considerando a missão mais ampla. Então, no Aether, estamos trabalhando no conceito de missão: o que queremos que o agent realize, em termos gerais? E cada decisão é tomada dentro do contexto — da intenção por trás do que está acontecendo no panorama geral. E é preciso ter granularidade na camada da transação para

07:31 muitas das coisas para saber exatamente o que está acontecendo, não apenas que tenho permissão para ir lá e fazer pagamentos. >> Sim, acho que uma das coisas mais interessantes, pensando em um exemplo prático para entender por que é necessária a intenção, é o seguinte: se você tiver duas sessões do ChatGPT ou duas sessões do Claude, em uma delas eu digo: “Ei, me ajude a fazer compras.” Na outra, digo: “Ei, me ajude a entender se há um bug em produção.” Elas têm perfis bem diferentes em termos das permissões que deveriam ter e também de quando deveriam trazer você de volta para o processo. Quando o

08:01 humano deveria se envolver novamente? No fim das contas, se não tivermos intenção ou alguma forma de transmitir qual é a intenção do usuário ou da empresa com relação a isso, não conseguiremos chegar à autonomia, certo? Muitas das palestras desta manhã foram sobre: “Ei, vamos administrar nossa empresa com agents. Vamos fazer todo esse tipo de coisa.” E é como: “Bem, ótimo. O que acontece no primeiro minuto em que ocorre um incidente no estilo Pac-Man, em que, por acidente, ele apaga um banco de dados de produção em vez de um de staging, porque tem acesso de escopo amplo em vez de acesso com escopo restrito?” O que queremos, como setor, é aproveitar essa caixa mágica que criamos para automatizar nossas vidas. O

08:33 estado atual do mundo é que você pode fazer isso e assumir todos os riscos; depois, pode ver todos os incidentes que resultam disso. Então, até resolvermos esse problema fundamental e tornarmos a verdadeira autonomia possível — ou seja, conseguirmos operacionalizar nossos negócios, nos afastar como humanos e ampliar isso —, precisamos resolver primeiro a questão da intenção. >> Com certeza. Agora que entendemos por que precisamos de autorização baseada em intenção, vamos falar do que isso significa na prática. Quais são os elementos básicos? Como isso realmente se manifesta na prática? O Dick deu uma pista ao falar do conceito de missão de AI auth.

09:04 Então, Dick, explique melhor a missão. Em que se baseia a missão? Na intenção do usuário? Na intenção do agent? Ou é uma combinação das duas? >> Bem, o agent, você sabe, deve trabalhar em nome da pessoa. E, na AI auth, definimos pessoa como uma organização ou um humano, porque ele pode estar operando em nome de qualquer um dos dois. Portanto, precisa agir no melhor interesse da pessoa em nome da qual está agindo, porque é ela quem, em última instância, é responsável pelo que o agent faz,

09:35 certo? O agent não pode ser responsável, certo? Então, a missão é algo que a pessoa pede ao agent para fazer. Um bom agent vai negociar com a pessoa e conversar mais sobre quais são os parâmetros disso. Um bom exemplo é lembrar de como era antigamente — o que parece ter sido há uns três meses —, quando você queria programar alguma coisa, criava um plano e depois o agent executava o plano. Agora, você simplesmente diz o que quer e ele resolve tudo. Mas todo aquele

10:05 conceito de plano — o que é um plano? O que você está tentando fazer? — é algo que você fornece ao agent. Isso passa a ser o contexto para as decisões de autorização que você toma depois. E esse identificador da missão acompanha tudo, para que você possa auditar e ver todas as coisas que aconteceram e todas as decisões tomadas no contexto daquela missão. Certo? Hoje, não existe realmente um bom conceito de identidade do agent ou da missão, certo? Ele simplesmente está fazendo

10:37 alguma coisa, e as coisas estão sendo decididas sem que se saiba de fato qual instância do agent está fazendo isso ou qual é o contexto, em que missão isso está envolvido, certo? >> Fale mais sobre essa fase de negociação. O que acontece se um usuário estiver falando com um agent instantâneo e disser ao agent: “Quero que você vá ler os e-mails do CEO”? Isso está fora do escopo desse agent. Então, a intenção do usuário é rejeitada? >> Deveria ser, certo? Então, você sabe, com uma boa separação e…

11:09 Não sei se vamos falar disso mais tarde, mas há a separação de responsabilidades do worker, certo? Há um agent que realiza o trabalho, e acreditamos que deveria haver um agent separado para supervisionar o que esse outro faz. Assim, há uma separação de responsabilidades: este não pode realizar nenhum trabalho, mas pode decidir o que o outro agent pode fazer. Então, se o usuário disser: “Ah, quero que você vá ler os e-mails do CEO”, isso provavelmente será bloqueado por políticas determinísticas, certo? >> Certo. Certo. >> Isso não é algo vago, certo? Ler

11:41 os e-mails de outra pessoa é algo para o qual temos bons controles. Mas pedir ao agent que encaminhe um e-mail do CEO para o mundo exterior é um pouco mais vago, e esse é o tipo de coisa que, idealmente, chega a um agent supervisor, que diz: “Provavelmente é uma má ideia, e não, você não pode fazer isso.” >> Com certeza. Então, acho que política também é outro elemento básico da autorização baseada em intenção. Ian, na Keycard, como vocês estão lidando com isso? Quando uma missão

12:12 precisa mudar e uma política precisa ser atualizada, como a Keycard pode ajudar a acompanhar essas mudanças, caso seja necessário atualizar a missão ou a política? >> Sim, acho que, dando um passo atrás, houve uma ocasião em que Davis e eu estávamos sentados numa sala, algum tempo atrás, antes de a AI auth e algumas dessas outras coisas surgirem no ecossistema. Uma das coisas sobre as quais conversamos bastante foi o cansaço de consentimento. No mínimo, sempre existe esse dilema: quão seguro você torna um sistema em comparação com o impacto para o humano? Na Keycard, nossa visão geral sobre isso é que você quer

12:42 ter políticas determinísticas amplas que basicamente definam o que nunca deve acontecer, certo? Ou quais são as coisas que sempre exigem o envolvimento de um ser humano. A partir daí, o que você realmente precisa considerar é: tudo bem, agora que tenho isso em vigor, há uma grande lacuna entre todas as políticas que posso escrever como humano ou como organização e a política que realmente quero aplicar aos detalhes de uma tarefa específica. Então, o verdadeiro desafio é: como faço para combinar essas duas coisas? Os humanos não conseguem escrever tudo. E existe uma versão disso que é

13:13 uma interação entre usuário e agent, ou entre agents, com uma intenção de interação entre eles. E também existe a intenção da empresa ao criar ou adotar um agent. Por que compramos o Claude Code? Porque queríamos que nossos desenvolvedores tivessem mais sucesso ou porque queríamos fazer essas coisas diferentes. E, no contexto do uso do Claude Code ou de qualquer outra ferramenta, por que estou trabalhando com o Claude Code neste momento? Na verdade, é para corrigir um bug em staging, certo? São dois tipos diferentes de intenção. E, se conseguirmos entender essas duas coisas diferentes e depois convertê-las de alguma forma em…

13:44 uma espécie de limite do que esses agents podem fazer, basicamente você pode calcular a interseção disso e dizer: “Tudo bem, aqui está o que você realmente pode fazer.” E o desafio para quem está construindo esses sistemas é: como garantir que eu não envolva o usuário, a menos que seja absolutamente necessário? Porque isso é que vai se tornar um problema para a adoção. Mas também é um problema para a adoção quando se trata de permitir que os agents sejam autônomos desde o início. >> Faz sentido. >> Gosto do que você está dizendo sobre a interseção. Acho que é algo singular sobre o qual não falamos o suficiente em gestão de acesso de identidades de dados, certo? Normalmente, você recebe acesso a uma coisa, certo? E então, o que tenho visto dar certo…

14:15 mais ou menos nessa abordagem baseada em intenção. E o que está me deixando mais empolgado é que, na verdade, essas diferentes intenções podem vir de diferentes áreas da organização, certo? Assim, você desacopla essas coisas, que podem funcionar por conta própria, mas depois se juntar para formar aquela decisão. E a decisão não precisa ser estática, certo? Então, se usarmos o exemplo do e-mail do CEO, bem, se o contexto envolver a assistente administrativa, então talvez ela deva ler o e-mail, certo? Ou talvez só o calendário, tudo bem? Acho que, quando vemos e começamos a pensar nesses componentes de interseção,

14:47 temos uma maneira totalmente diferente de expressar políticas, mas também podemos começar a incorporar não só um lado da equação de que sempre falamos antes, que era o aplicativo fazendo algo. Agora, podemos trazer todo o ecossistema. E quanto mais vejo as organizações começarem a perceber isso, mais entendo que manter o estado ou o contexto desses outros elementos para ajudar com essa intenção pode mudar completamente a eficácia da autorização em tempo de execução. >> E você está vendo isso nas empresas hoje? A maioria delas já acompanha missões e políticas, ou isso ainda está em grande parte ausente?

15:18 >> Não, ainda é algo totalmente novo. E acho que parte do motivo pelo qual estou empolgado para falar sobre isso é que acredito que isso está mudando a maneira de raciocinar sobre o assunto, certo? Mesmo no caso mais simples, se você é um desenvolvedor e pensa em termos de coisas como transações e tem esses conceitos de intenção, fica mais fácil construir componentes que serão compostos e usados por meio dessa intenção. Acho que isso nos dará mais maneiras de raciocinar sobre essas coisas e de nos comunicar, e, no fim, permitirá mais interoperabilidade, certo? E, para mim, a última coisa que acho interessante é o diagnóstico

15:50 que você pode executar nisso. A intenção é algo que pode passar por muitos eventos, certo? Acho que um desses exemplos que já vi é falar sobre como essa missão pode perdurar, pode durar semanas, e essa intenção ainda pode estar lá. [risos] Então, ainda é algo muito, muito recente para a maioria das empresas. >> Sem dúvida. E, sim, essa interoperabilidade é fundamental, e acho que é bem difícil para as empresas, porque elas lidam com diferentes nuvens, diferentes ambientes e diferentes sistemas legados, e essa política, essa missão, precisa se manter ao longo de todas essas etapas.

16:20 >> Sim, bem, muitas empresas ainda precisam lidar com o fato de que a permissão diz “somente leitura”, mas, na prática, ainda permite leitura e gravação. >> [risos] >> Certo? Então, há outros problemas desse tipo com que vocês precisam começar a lidar. Acho que isso vai ajudar as pessoas a se entenderem melhor por meio de uma taxonomia ou linguagem comum, sabe? >> Sem dúvida. Um dos motivos pelos quais estou empolgado com a autorização baseada em intenção é que acho que ela pode ser um grande desbloqueio para coisas como o comércio com agents. Então, vamos aplicar a autorização baseada em intenção a algo concreto. Acho que a autorização baseada em intenção

16:50 agrega muito valor aqui e, para os usuários, pode ajudar a garantir que seus agents comprem o item certo usando o próprio orçamento pessoal. Para os comerciantes, isso significa capturar a intenção, o que lhes fornece dados adicionais para entender por que uma compra está sendo feita e se esse agent deve sequer ser considerado confiável para visitar o site. David, quando pensamos em agents no contexto dos serviços financeiros e do comércio com agents, por que a autorização baseada em intenção é tão importante? >> Bem, acho que, simplesmente, ela amplia o conceito de “conheça seu cliente”, algo de que nem todo mundo está ciente, mas que algumas pessoas conhecem. Quero conhecer meu cliente, saber quem ele é e o que está fazendo. Mas acho que também estamos

17:22 começando a ver que queremos conhecer nossos agents, certo? Acho que há uma combinação entre o próprio agent, a intenção do usuário de fato, a intenção do operador, a intenção do processador e assim por diante. Antes, não conseguíamos realmente reunir tudo isso, certo? Isso importa, claro, quando se trata de coisas como comércio, porque há camadas adicionais relacionadas à intenção por trás de requisitos regulatórios e coisas do tipo. Acho que isso vai ajudar a simplificar essas operações, o que significa que teremos mais acesso a esses agents para fazerem

17:52 um bom trabalho por nós. >> Faz sentido. E outro obstáculo ao comércio com agents é o fato de que a web não foi criada para agents. Ian, você pode nos dizer como a identidade de agent pode ajudar? >> Sim. Acho que, olhando para o quadro geral, sempre tivemos esse problema: o que fazer com um cliente não registrado? Por exemplo, entro no eBay sem fazer login, usando o Chrome, e o eBay não sabe quem sou. Como faço uma compra como convidado? Como provo que sou uma pessoa? Como faço para que eles possam dizer: “Sim, você pode dar um lance neste par de meias por US$ 50”? E acho que

18:22 se todos estivermos prestando atenção ao que está acontecendo com os agents pessoais, Muse, Instinct, Grockit e, recentemente, ao anúncio da Sierra, da Decagon e de outros sobre esse protocolo de agent pessoal, o problema fundamental é: como fazer um agent chegar a um site, interagir com ele e garantir que você possa confiar nesse agent? Há muito tempo existem CAPTCHAs na web. Por quê? Porque queremos impedir spam e abusos. Então, adicionamos CAPTCHAs, algo que uma pessoa pudesse resolver. Se temos um CAPTCHA que impede o spam, então não conseguem inundar o sistema com spam, certo? E agora temos

18:53 agents, e eles quebraram os CAPTCHAs. Mas esse sempre foi um problema tradicional na web. Na verdade, se voltarmos dois ou três anos, a Vercel, que acho que todos conhecemos, foi bloqueada na Espanha. Por que a Vercel foi bloqueada na Espanha? Porque a Vercel compartilhava os mesmos endereços IP para todos os sites hospedados na plataforma, e havia um site na Vercel que hospedava conteúdo da Premier League. A Espanha decidiu: “Para impedir que esse conteúdo da Premier League seja exibido ilegalmente no país, vamos bloquear toda a Vercel, certo?” E, da mesma forma,

19:25 que a Vercel tem esse problema, os agents têm o mesmo problema, mas muito, muito pior. Como lidar com tráfego não registrado, que você nunca viu antes, chegando à sua porta, e decidir se vai deixá-lo entrar ou não? Esse é o primeiro e mais fundamental problema que precisamos resolver. É o mesmo problema com Muse e Instinct, e o que eles estão tentando fazer é criar regras comuns que todos possamos seguir, para que eu, como recurso downstream, possa decidir quais agents quero permitir e em quem confio, com base em quem são os usuários. E, do outro lado, também possa saber como me comunicar com essas pessoas.

19:56 >> Faz sentido. Dick, como o AAuth está ajudando a desbloquear o futuro do comércio com agents? >> Bem, o principal é que muitas pessoas vêm construindo sistemas proprietários e fechados, certo? Sou fã do conceito do protocolo de agent pessoal, Poppy. Mas ele não vai longe o bastante, certo? É como se dissesse: “Tudo bem, agora temos um pouco de identidade de agent. Usamos alguns componentes básicos e é uma abordagem atraente porque é simples de implementar”, mas não resolve muitas das

20:28 novas necessidades do mundo dos agents. E um dos principais motivos para as pessoas adotarem padrões é poder conectar componentes de diferentes lugares, certo? Acredito firmemente que devemos ter controle sobre o que nossos agents fazem. Em algum momento, os agents poderão fazer tanto trabalho que será impossível ter uma pessoa aprovando tudo no processo, certo? Isso simplesmente não vai funcionar. Já vimos que essa abordagem não vai escalar. Então, precisamos de um agent supervisor, que seja nosso agent supervisor e execute nossa política.

21:00 e decide como fazemos as coisas. Isso deve ser independente dos agents que fazem todo o trabalho. E, se quisermos poder conectar e substituir essas coisas, precisamos ter um protocolo para separá-las. Caso contrário, sabe, a decisão sobre o que o agent pode ou não fazer, quais são as barreiras de proteção, fica a cargo do agent, dos fornecedores do agent, que decidem o que você pode ou não fazer. E eu realmente não quero entregar a eles o controle para decidirem o que posso fazer, com todas as minhas decisões baseadas nisso. Quero poder transferir essa supervisão para

21:30 outro componente e, para podermos conectar e substituir peças, precisamos ter um protocolo que permita a interoperabilidade entre as coisas. >> Só quero acrescentar algo a isso. Acho que, neste momento, o que estamos vendo é que, de certa forma, todos queremos que a web seja federada, certo? Isso significa que sites ou recursos na web podem decidir o que têm permissão para fazer, mas os padrões segundo os quais as coisas operam devem ser federados e permitir que todos nós interoperemos. E acho que estamos num momento em que, sabe, há alguns grandes players, e a pergunta para o setor é: vamos nos conformar com coisas que favorecem os grandes players e lhes dão

22:00 portas de blocos de concreto, por assim dizer, ou vamos fazer o que sempre fizemos, que é criar protocolos federados? Coisas como OIDC, coisas como TLS: elas funcionaram e permitiram uma web ampla, possibilitaram que muito comércio acontecesse, que muita informação circulasse, e permitiram que todos nós tivéssemos empregos, porque podíamos ser inventivos. Então, a pergunta que faço ao setor como um todo é: certo, isso está chegando; qual versão do mundo queremos, de um jeito ou de outro? >> Sim, concordo. Acho interessante que, digamos, tudo isso dê certo e tenhamos agents comprando coisas e todo mundo fique meio

22:31 feliz. Acho que o que vai acabar acontecendo é começarmos a perceber que há outra peça em que precisamos começar a trabalhar: o próprio ser humano. Uma das coisas que acho que acontece quando você começa a ter intenção envolvida é que surge o que chamamos de senso de propriedade psicológica. Isso significa que agora existe uma ligação entre o ser humano e o resultado daquele agent. Quando você simplesmente, sabe, desconecta isso ou conecta a um osciloscópio ou algo assim, e a uma reivindicação e uma carta, parece meio mágico. E aí você não sabe realmente o que está acontecendo. Então, acho que, com a intenção, será mais fácil para os seres humanos assumirem a responsabilidade quando algo der errado. E acho que, quando

23:01 falamos de dinheiro de verdade sendo transferido ou coisas assim, queremos que, em última instância, aquele ser humano seja responsável. Acho que muita gente provavelmente já viu o manual da IBM de 1979. Ele diz, sabe, e acho que aquela foto é muito verdadeira no sentido de que não podemos responsabilizar as máquinas, certo? Vamos ter que vincular isso aos seres humanos, e acho que a intenção é esse vínculo. >> Sim, e outra palavra para intenção é motivo. Como estávamos conversando ontem à noite. E essa capacidade de responsabilizar alguém, seja uma pessoa ou um agent, eu

23:31 acho muito importante. Também acho que a intenção pode ajudar nisso. Ela permite entender por que algo deu errado. Foi o usuário, sabe, o usuário tinha más intenções, o agent tinha más intenções? E, usando essa intenção, conseguir responder. Para cada um de vocês: como vocês veem a intenção trazendo esse benefício e permitindo responder a um usuário ou agent que talvez tenha más intenções? >> Acho que isso volta ao que mencionei antes sobre diagnosticar, certo? Então, se você trocar a palavra intenção por motivo, troca diagnóstico por perícia, certo? E acho que qualquer pessoa que já tenha feito depuração ou

24:02 precisado fazer uma perícia de um agent de IA que saiu do controle sabe que tentar descobrir o que ele estava tentando fazer, em comparação com qual era a intenção do usuário, é muito difícil, certo? Então, ter parte dessas informações propagadas e imutáveis pelo sistema, etc., oferece algumas propriedades que permitem encurtar bastante a investigação, certo? E, à medida que essas coisas se tornam mais interoperáveis, acho que vamos começar a ver empresas conseguindo definir melhor o escopo e identificar mais rapidamente: foi um erro humano? Foi um erro de software do agent? Foi… que tipo de erro foi esse? E lidar adequadamente com o alcance do impacto.

24:32 Vemos isso no sistema financeiro, certo? Há procedimentos diferentes para transações, como: certo, fiz este pagamento, mas o valor em dólares estava incorreto ou algo assim. Existem diretrizes claras sobre como lidar com isso. No momento, não temos muitos procedimentos desse tipo para quando as coisas dão errado. Então, acho que a intenção vai nos ajudar a criá-los à medida que avançarmos. >> E acho que uma área em que um incidente recente destaca como se pode ter uma boa intenção e, ainda assim, tomar uma ação potencialmente errada é o

25:02 incidente da Resy que aconteceu recentemente, em que um agent da Instinct agiu em nome de um usuário e tentou reservar uma mesa em um restaurante no resy.com. Esse agent estava muito empenhado. Fez 200 chamadas de API por hora e acabou fazendo com que a conta Resy do usuário fosse banida. Dick, como os orçamentos de AI auth podem ajudar no caso em que um agent como esse está usando um recurso de um serviço subsequente em excesso, mas ainda tem boas intenções? >> Sim. Bem, este é outro exemplo de como o software é completamente

25:33 diferente agora, no mundo dos agents, certo? Com o software predeterminado, sabe, chamar 200 vezes seria um bug, e você o corrigiria. Mas agora o agent pensa: “Vou continuar tentando até conseguir”. E vimos isso quando estávamos fazendo experiências e trabalhando com pessoas com AI auth, e percebemos que, sim, há um grande problema: os agents aprendem alguma coisa e simplesmente abusam do sistema. Eles não acham que estão abusando. Não sabem que existe outra forma. Não receberam nenhum sinal para dizer: “Ah, eu só deveria usar

26:05 essa quantidade de recursos”. Então, acrescentamos o conceito de orçamentos: além de dar ao agent um token com um limite de tempo que determina por quanto tempo ele pode executar uma determinada ação, também se define um orçamento para a quantidade de recursos que ele pode usar. Assim, ele tem acesso até o token expirar ou até esgotar o orçamento. E, quando volta e você sabe que ele esgotou todo o orçamento, a supervisão pode decidir se deve ou não dar mais orçamento a esse agent. Em vez de usar o limite de taxa tradicional,

26:36 que simplesmente o bloqueia. E aí, o que você faz, certo? E ele não sabe por que foi bloqueado nem nada disso. Já com um orçamento, há feedback contínuo para o agent sobre quanto do orçamento foi consumido. Ele tem uma noção de quanto orçamento ainda tem e, assim, pode operar dentro de um orçamento, certo? Como uma pessoa faria: “Ah, esse recurso é escasso; vou tomar cuidado com o quanto uso”. >> Então, como o conceito de arquitetura de cérebro e mãos entra nisso para nos permitir, certo, quando um orçamento importante está quase no limite ou chega ao limite, como a separação entre cérebro e mãos no acesso, e o fato de as credenciais serem separadas do agent e do próprio modelo, podem nos ajudar a impedir que um agent use demais um recurso de um serviço subsequente? Porque, se estiver chegando perto do limite, talvez não concedamos outra credencial, por exemplo. >> Desculpe, não entendi muito bem. O eco aqui está horrível, então… >>

27:07 Sem problema, a pergunta é para qualquer pessoa. Mas, basicamente, com a arquitetura de cérebro e mãos que estamos…

27:38 convergindo em um setor, basicamente mantemos as credenciais e o acesso do agent separados do próprio agent. Então, hoje não há acesso amplo e permanente que um agent tenha, nem chaves de API, o que eu sei que é um benefício do AAuth: o AAuth permite que agents funcionem sem chaves de API. Como isso ajuda no contexto do incidente da Resi? >> O… O que você tem acesso a isso? Desculpe, ainda não entendi. >> Sim, posso entrar na conversa. >> Sim, por favor, obrigado. >> Pode deixar comigo, Dick. De modo geral, olha, acho que, quando olhamos para trás,

28:08 um incidente que sempre tenho em mente é o da PagerDuty, quando encontrei uma chave aleatória em um disco, certo? Obviamente, agents são profundamente orientados a objetivos. Então, o cerne da questão é: se dermos a esses agents um cérebro, que é um modelo e o LLM, e essas mãos, que é como se os colocássemos em uma sandbox, e dentro da sandbox estão as ferramentas… A ideia fundamental da sandbox aqui é simplesmente que você consegue controlar o que fica dentro dela. Então, ela não consegue, de fato, obter acesso à API. E, se você tiver um proxy de saída fora

28:39 da sandbox, é aí que fica a fronteira de autorização mais robusta. Isso não só ajuda a fazer a tradução entre sistemas, certo? É onde a IA pode existir e se comunicar com o mundo externo, ou fazer o encerramento, mas também significa que você tem a capacidade de aplicar autorização na fronteira do proxy de saída. Então, acho que, no cerne disso, esse modelo — que é o modelo predominante que a Anthropic, a OpenAI e muitos outros laboratórios estão adotando hoje — é o modelo que nos permite fazer as duas coisas e ter aquilo que queremos, que é: como

29:09 experimentamos com essas coisas e testamos algumas ideias e fazemos coisas bobas, que é o valor central, ao mesmo tempo que temos uma camada determinística fora delas, capaz de implementar coisas como IA e todos os outros componentes que queremos em nossos protocolos. >> Acho valioso desacoplar. Vou voltar ao que mencionei sobre forense e a possibilidade de separar as coisas, mas acho que ainda temos muito a aprender: não existe apenas um cérebro, certo? E, na verdade, é muito fácil criar o ciclo do agent colocando o cérebro dentro do ciclo, em vez de fora dele. Por exemplo, pessoas que usam sistemas de memória colocam uma memória e

29:42 um contexto que passam a ser usados dali em diante por todo agent, influenciando esse agent a tomar uma decisão e dizer às mãos, nesse caso, para fazer algo que não deveria. E uma das coisas sobre as quais acho que não falamos o suficiente aqui são as combinações tóxicas, certo? Então, quando separamos as mãos do cérebro e assim por diante, podemos mudar quais mãos estão disponíveis, certo? Um exemplo que, pelo que vi, funciona muito bem é remover ferramentas dinamicamente com base no cérebro em questão e no que ele está fazendo. No exemplo anterior que demos, de ler um e-mail, nada impede que, se ele for escrever um e-mail, eu desative todas as chamadas de ferramentas de busca na web ou qualquer outra chamada de ferramenta com capacidade de saída externa até que a ferramenta de e-mail adequada tenha sido concluída e a missão tenha sido cumprida; então posso reativá-las, certo? Então, acho que teremos de nos tornar cada vez mais engenheiros desses diferentes conceitos, que ainda são complicados, ainda estão evoluindo e ainda são incipientes, mas acho que hoje temos uma separação melhor. >> Sim, e é assim que essas coisas de que estamos falando, que pareciam problemas meio nerds de OS, acabam se conectando a problemas reais de engenharia de agents,

30:12 Eles vão escrever um e-mail. Vou desativar todas as chamadas de ferramentas de busca na web ou qualquer outra chamada de ferramenta que permita comunicação externa até que a ferramenta de e-mail adequada tenha sido concluída e essa missão tenha sido cumprida. Aí posso reativá-las, certo? E então, acho que vamos começar a desenvolver cada vez mais esses diferentes tipos de conceitos. Eles ainda são complicados, ainda estão evoluindo e são incipientes, mas acho que hoje temos uma separação melhor. >> Sim, e é assim que essas coisas de que estamos falando, que pareciam problemas de sistema operacional meio nerds, acabam se conectando de volta a agentes de verdade

30:44 porque, se você realmente entende o que está fazendo, uma das maiores reclamações sobre MCP — menos agora, mas uma das maiores reclamações — era o excesso de contexto. Especialmente quando tínhamos context windows menores, certo? Mas os sistemas de intenção podem garantir que as capacidades certas sejam fornecidas ao agent na hora certa, para que ele não passe um monte de tempo fazendo coisas que não deveria, certo? Na verdade, eles ajudam o agent a avançar em direção ao estado desejado e a seguir um caminho mais orientado. Portanto, a intenção não só libera várias possibilidades de segurança, como também fará com que usemos menos tokens, porque o agent passará menos tempo fazendo

31:14 coisas que não são o caminho certo, ou chegará a um ponto e dirá: “Olha, simplesmente não consigo fazer isso”. E o que sabemos sobre esta era é que muita coisa consiste em direcionar o agent para o rumo certo e, então, impedir que ele faça a coisa errada. É assim que se obtém o resultado desejado. >> Davis, como você vê o OS baseado em intenção como parte de uma estratégia mais ampla para agents em produção? Sei que, na hora de criar, fazer deploy e operar agents em produção, há muitos resultados diferentes que as equipes devem considerar, como descobrir o que está em execução, quais são as capacidades do agent e a possibilidade de

31:46 validar entradas e saídas, restringir um agent, como conversamos, e usar o proxy de saída e diferentes regras de rede. Como tudo isso se encaixa e o que está funcionando nas empresas hoje para realmente conseguir lançar agents em produção? >> Acho que finalmente isso está ajudando a mudar o tipo de conversa, da autenticação para a autorização e, mais especificamente, para como fazer autorização dinâmica. Como valido essa autorização? Como coloco uma pessoa no ciclo na hora certa? Porque concordo com o que acho que você disse antes: manter uma pessoa no ciclo é, de certa forma, um antipadrão em muitos aspectos, certo? Porque ela pode ficar

32:17 cansada e assim por diante. Mas é preciso ter uma maneira de envolvê-la quando isso for importante. Antes, essas não eram discussões de engenharia, certo? Agora, elas fazem parte da conversa de engenharia, e os engenheiros estão sendo envolvidos no processo de autorização. Eles não estão apenas dizendo: “Ah, já tenho acesso, está tudo certo.” Isso realmente muda a maneira como os modelos de ameaças são elaborados. Muda a maneira como vemos toda a superfície de ataque dos aplicativos em geral. Então, acho que agora você está vendo esse modelo de autorização como mais um conjunto de ferramentas que pode usar para reduzir não apenas problemas de segurança,

32:47 mas também para descobrir as taxas de erro do agent, certo? Quer dizer, quando há menos coisas que o agent pode fazer, ele toma decisões melhores, certo? E, fundamentalmente, vimos casos reais em que o ciclo do agent simplesmente fica melhor, mais rápido e mais forte porque você dedicou tempo para entender qual é a intenção que ele está tentando atender e qual é a missão que está tentando cumprir. E, por último, isso reúne as pessoas: agora temos pessoas diferentes — a equipe de segurança e a equipe de aplicativos — que conseguem conversar usando a mesma linguagem.

33:17 E, muitas vezes, quando o assunto era identidade, a linguagem era completamente diferente, certo? Era algo como: “Sai da minha frente. O que tenho que fazer para conseguir meu token e seguir em frente?” Agora, elas estão percebendo que é possível combinar essas coisas e aproveitar essa capacidade para aumentar a eficiência dos resultados do agent. >> Faz sentido. Ian, como você está aplicando esses conceitos às fábricas de software? Sei que hoje você lançou uma arquitetura de referência para a fábrica de software segura. Como está aplicando os conceitos de autorização em tempo de execução, de restringir agents e

33:48 Tudo isso para aquilo? >> Sim, acho que existe uma arquitetura de referência que acabamos de publicar em agentbaseline.org. Falamos de três níveis diferentes de fábrica: uma conduzida por humanos, outra conduzida por workflows e uma conduzida por agents, que é basicamente onde todos queremos chegar: uma fábrica conduzida por agents. Em todos os momentos, a autorização em tempo de execução é um componente central de um ecossistema maior que permite que a fábrica siga nessa direção, faça a coisa certa e também tenha acesso ao componente certo. E

34:18 ela é bem diferente das soluções anteriores que você talvez tenha usado, como um gerenciador de segredos, porque toma decisões muito diferentes das gerações anteriores, que gerenciavam software determinístico. Mas ela é um componente central para fazer todo o sistema funcionar: quando envolver alguém no processo, quais agents podem passar o trabalho para outros agents e com base em quê, sabe, como podemos ter um agent com acesso a sistemas de produção que faça um patch automático. Essas são questões fundamentais sobre como resolver o problema do software em escala. No momento, estamos numa situação em que nunca conseguimos gerar tanto software, mas existe um gargalo enorme para colocá-lo em produção

34:49 e garantir que funcione. E a próxima fase é justamente esta: como passar de simplesmente usar um LLM para gerar texto e software a torná-lo capaz de fazer deploy em produção, iterar e chegar rapidamente a um estado estável, e então responder a ocorrências à medida que surgirem. >> Davis, em um podcast que você fez comigo, falamos sobre como a cibersegurança tem algo a aprender com a robótica. Na robótica, existe este conceito: quando um robô talvez levante o braço, ele pensa: é seguro levantar meu braço? Devo… tenho permissão para fazer isso? Mas também observa

35:21 o ambiente externo e pergunta: o que mudou? Ainda é seguro levantar meu braço? Quando pensamos em autorizações em tempo de execução, que fatores essas decisões precisam levar em conta além da intenção? >> Sim, acho que ter um modelo como esse nos permite incluir mais sensores na nossa decisão. No exemplo da robótica, com um braço se movendo para cima ou para baixo, os fatores externos poderiam incluir: há outros objetos por perto, certo? Poderia ser a temperatura. Poderia ser: estou em movimento e não quero mover meu braço

35:51 enquanto, sabe, o resto do robô está se movendo, etc. Então, normalmente, são considerados muitos tipos diferentes de fatores. Nenhum deles é determinístico. Todos são probabilísticos. Há uma variedade de opções, e o sistema escolhe a melhor com base em todos esses dados dos sensores naquele momento. Hoje, a maioria das decisões de autorização nas organizações ainda é uma decisão binária única, certo? E isso simplesmente não vai funcionar no futuro, certo? Então, é preciso combinar a intenção do que o usuário está tentando fazer com o ecossistema em que está fazendo isso. Pode ser o lugar de onde está fazendo, a hora do dia, mas também pode envolver coisas ainda

36:22 mais avançadas. Por exemplo, devo permitir que este administrador use o Firefox para acessar este servidor agora, quando o servidor tem vulnerabilidades de alto risco e o sistema dele não recebeu os patches? De repente, você passa a incorporar muito mais contexto ao ambiente ao redor. E, de novo, isso pode envolver diferentes equipes, mas, mais importante, sensores. Acho que todos já percebemos o valor da observabilidade em geral. Imagine poder ter esse tipo de contexto no nível do span, do ponto de vista de um hotel ou algo assim, certo? Você

36:52 está analisando um trace, tem um span e sabe de fato como estava o ambiente fora da sua aplicação naquele momento, além de saber qual era a intenção do usuário. Isso permite diagnosticar as coisas de uma maneira completamente diferente. Então, acho que, se conseguirmos incorporar alguns desses conceitos, teremos decisões de autorização com muito mais contexto — não apenas a intenção do usuário, mas também o estado do ambiente ao redor — e tomadas mais rapidamente. >> Faz sentido. E, pensando no futuro, ao avaliarmos se a autorização baseada em intenção está funcionando nos nossos

37:23 ambientes, um lugar natural para olhar será um registro das ações do agent: o que foi negado e o que foi permitido. Ian, por que é importante manter o seu registro de auditoria separado do próprio agent, ou seja, fora do controle dele? >> Sim, acho que isso também remete ao motivo pelo qual o ponto de aplicação precisa ficar fora do alcance das principais mãos e do cérebro do agent, certo? Não dá para confiar nessa coisa. No incidente do Hugging Face, havia alguns componentes diferentes. Quer dizer, um deles explorou uma vulnerabilidade no Squid, no proxy Squid, da qual não tínhamos conhecimento. Mas, mais importante, não havia observabilidade nem monitoramento do que

37:54 estava acontecendo. Então, essa coisa conseguiu acessar a internet aberta por meio dessa vulnerabilidade, e não havia nenhum lugar que registrasse as diferentes ações realizadas por esse agent para que pudessem ser monitoradas. Portanto, independentemente de aplicarmos um ponto de aplicação ao tráfego de rede que sai para a internet, fora do alcance do agent para que ele não possa adulterá-lo, ou de resolvermos as vulnerabilidades à medida que aparecem — este caso do Hugging Face é literalmente único —, ainda precisamos ter um registro de quem instruiu esse agent a fazer o quê e com que finalidade, e se isso continua sendo verdade. Porque, no fim

38:24 das contas, o que estamos fazendo com agents é uma questão de responsabilidade. Por isso, na verdade, não acho que precisemos de mais regulamentação para agents. Só precisamos que as leis de responsabilidade que já existem sejam aplicadas. Ou seja, se eu contratar um agent para realizar uma ação, quem é responsável se essa ação causar danos? É quem o contratou, que pode ser uma organização, uma pessoa ou alguém que delegou uma ação a alguma coisa. Essa é a questão final que temos de resolver. E, claro, para responder a ela, precisamos saber quem fez aquilo — daí a necessidade de um registro de auditoria resistente a adulterações.

38:57 >> Perfeito. Para encerrar, queria fazer uma pergunta divertida para todos vocês. Existe o conceito de probabilidade de destruição, ou P doom, segundo o qual os catastrofistas da IA dizem que os agents de IA vão provocar todo tipo de caos ou levar a humanidade à ruína; já os otimistas da IA dizem: não, isso é realmente uma forma de nos ajudar, não é uma ameaça verdadeira. Para cada um de vocês no painel, qual é a sua opinião sobre isso, considerando a autorização em tempo de execução baseada em intenção e as outras coisas de que falamos, como restringir agents, validar entradas e saídas e adotar uma estratégia holística para

39:28 agents em produção? Isso basta para nos salvar? P doom é real ou não merece toda essa atenção? >> Você pode começar. >> Ah, eu começo? >> Você está com uma expressão bem provocadora. >> [risos] >> Bem, parte da sua pergunta é se os agents vão dominar tudo, e acho que agents totalmente autônomos, sem vínculo real com uma organização específica, ainda são ficção científica. Então, quem sabe, certo? Essa é uma possibilidade. Outra é que, em organizações responsáveis,

40:00 se forem implementados os controles adequados, os agents não… sabe, estamos desenvolvendo ferramentas suficientes para garantir que coisas ruins não aconteçam em organizações responsáveis que tenham implementado os controles adequados. Isso deixa dois cenários em que pode haver um problema. Um deles é uma organização que não está em ordem: uma ameaça interna poderia liberar um agent para causar caos, certo? Essa pessoa teria algum acesso especial que as outras não têm. O outro cenário, aquele que mais me preocupa, é… sabe, já foi demonstrado que

40:30 conhecem a Hugging Face e, se vocês assistirem à palestra que eles deram na Black Hat, certo? Aquilo foi realmente um chamado à ação em torno de: “Olha, aconteceu uma situação em que não queríamos que algo ruim acontecesse, e algo ruim aconteceu. E quanto às pessoas que querem que coisas ruins aconteçam e têm essas ferramentas?” Acho que essa é uma ameaça que pode, potencialmente, causar… quer dizer, vai acontecer, e haverá algumas catástrofes. Espero que estejamos preparados o suficiente para que elas não sejam terrivelmente desastrosas, mas

41:02 vai haver algumas questões em escala semelhante à de grandes desastres naturais, causadas por atores maliciosos, intencionalmente ou não. Mas isso acontece quando as pessoas não são responsáveis no uso dessas ferramentas superpoderosas. >> Sim, não posso dar uma probabilidade específica, certo? Mas o que posso dizer é que sempre fico meio surpreso e empolgado quando, sabe,

41:33 a engenhosidade dos engenheiros entra em ação para resolver problemas. E acho que, no estágio em que estamos agora, com alguns dos novos recursos dos agents, por exemplo, temos engenheiros de verdade, pessoas que estão aqui, realmente iterando para resolver o problema, certo? E estamos começando a ver melhorias tremendas nas capacidades que, na minha opinião, estarão disponíveis para mudar o que o nosso futuro pode ser. Então, para mim, não tenho problema em acreditar que os engenheiros vão encontrar uma solução para isso. >> Quer dizer, talvez eu tenha a opinião mais polêmica. Não posso dizer que a probabilidade seja igual a zero, mas diria que está se aproximando de zero de forma assintótica

42:04 a probabilidade de o mundo acabar. Acho que os incentivos da maioria das pessoas são para que tudo continue. E, além disso, no fim das contas, ainda temos estruturas de responsabilização. E, sabe, em geral, os seres humanos são boas pessoas, então não saímos por aí tentando destruir o mundo. Também acho que, de modo geral, no fim das contas, esses agents podem simplesmente ser desligados. Tenho essa opinião polêmica que costumo expressar: eles podem simplesmente ser desconectados, e isso é verdade. No fim das contas, são computadores; você pode desconectá-los. Então, de modo geral, não acredito nesse debate. Não acho que seja real. Acho que, no lado positivo,

42:34 acredito mais na postura do Dave: estamos iterando muito rápido. Estamos descobrindo onde essas coisas funcionam e onde não funcionam. E, quando não funcionam, causam danos. E é isso que, no fim das contas, funciona como uma espécie de anticorpo da sociedade, que diz: “Ei, ei, não devemos fazer isso. É uma má ideia.” >> O pessimista aqui no painel. >> [risos] >> É uma pena para pessoas como o fundador da Pocket OS, que perdeu um monte de dados, mas é ótimo para o resto de nós, porque aprendemos todos juntos. E, no fim das contas, isso faz com que as pessoas não façam coisas que não

43:05 fazem muito sentido. E acho que isso continuará sendo verdade. >> Faz sentido. Obrigado a cada um de vocês pela experiência e pelo tempo neste painel hoje. E obrigado ao público por ouvir. Até a próxima. Obrigado. >> Muito obrigado. >> [aplausos]

Transcrição original

[00:12] Um, hi everyone. Welcome to um AI Engineer New York. I’m super excited to be here today. Um my name is Ali How. I’m a member of technical staff at Keycard. Um I’m here with some amazing panelists today. We have Ian, CEO of Keycard. We have Michael Davis, um Global Chief Security Architect at JP Morgan Chase. And we have We have Dick Hardt, the founder of OAuth and co-creator of OAuth with us on stage today. I’m super

[00:42] excited to talk to all of them about intent-based authorization. Um and to set the stage, I want to bring to light that as more companies are looking to give their agents increased levels of autonomy, they’re looking to runtime authorization to help. Runtime auth is the practice of authorizing an agent per tool call, rather than having the agent hold broad standing access that it will eventually misuse. However, is this tool call or not is never a simple question. This is because many MCP tools and APIs

[01:15] are coarse-grained. Humans struggle to write the perfect policy. And the environment around the agent will change as it runs. Intent can help by providing extra context so that at runtime, we can make better authorization decisions about what an agent is allowed or is not allowed to do. So to continue, I would like to talk about really dive into why do we need intent-based auth in the first place? Models have dramatically improved. They

[01:46] have bigger context windows. They’re able to verify work because model vision capabilities have improved. In many contexts, people are proclaiming that AGI is here. If the models are so good, if AGI is really here today, then why are teams struggling to give their agents more autonomy? Ian, let’s start with you. You’re helping men and financial enterprises at Key Card. What are you seeing that’s getting in the way? >> Well, I think broadly speaking, enterprises, especially financial services firms, regulated industries, are almost always security first. It’s

[02:17] how they build trust in their business, and maintaining the business continuity is by our first, like the first priority, then innovation is second, third, or fourth. I think like broadly speaking, in in any enterprise, what you see is this like hodgepodge of different little islands of different little identities, of different little systems of all from across all different worlds, and how do you actually tie that together in a way that an agent can navigate through that, ask for access, and then also ensure that the agent cannot perform like uh something that was unintended by the user or the business. And the unfortunate situation is most of our

[02:50] systems today are coarse-grained, right? I don’t know, Salesforce is a good example. For a very long time, they had a single scope, which was API on their OAuth, which is like in the context of an agent, uh not very helpful. So, that’s that’s the broadly the first and foremost part is that most of the systems they have for security today were designed for a world where humans were making all the decisions, and software’s very deterministic, not this newfangled magic box we’ve invented that basically reasons and tries over and over again to find a solution to a problem. >> Dick, how is OAuth part of the problem?

[03:21] How is OAuth getting in the way? Why is it not the right fit for agents? >> Well, when people started looking at how do we authorize agents to access something, the tool that was sitting there on the shelf was OAuth. And people grabbed that tool and says, “Here’s a tool. This is authorization. It should be able to solve the problem.” But OAuth was not designed for this kind of world. It was designed originally for like how do I let this website talk to this website, you know, and OAuth 2 we added scopes. Before that, it was just do anything. Um

[03:51] but it required you to be pre-registered. It’s expecting that there’s a browser involved in a redirect, you know, but OAuth has evolved over the years to support some other things, but the agentic world is completely different. We don’t know ahead of time what the agent needs to do. We need to go and make that decision over time. Different instances of an agent are going to need different kinds of things. And, you know, as Ian talked about the granularity of the scopes that people says, “Well, we already have scopes for OAuth. Let’s just map those over to agents.” is far too coarse-grained for what agents are

[04:22] doing. >> Davis, how are you seeing enterprises move towards higher levels of autonomy? >> Yeah, I think the key piece is >> is uh how do you deal with that coarse-grained problem? And what I’ve seen the kind of more successful enterprises, they kind of board agents like they onboard developers, right? Start with You don’t get full you know, commit access day one, right? You’re actually having to go through and add the levels of capability as they mature, right? And so, the definitions that enterprises are coming up with are What is the context that makes this agent safe? And it isn’t just usually what the

[04:54] agent says, right? Um it can you know, attest to something, but it’s other things like the environment around it and other information that can help you understand levels of autonomy. Very simple example would be Where is the sandbox running? Is it in the sandbox, right? Those type of things can change the level of autonomy that’s allowed. >> Absolutely. And as we mentioned that coarse-grained access problem, and to put that into perspective, um to give an example, um with Notion’s MCP server, you can say fetch this page, which is like the view page um tool or get page, but you can’t say just get this database

[05:26] on this page. Um how is runtime authorization based on Antenna a better model? That’s for anyone. >> Well, I’ll take a shot at it. So, to me, um this is something that the financial services industry, hopefully maybe we can learn from the background that, you know, banks have gone through. Um banks moved long ago from authorizing and authenticating humans to authorizing the transaction, right? And when is that transaction occurring? At runtime, right? Um and so, I think that, you know, runtime authorization is we’re going to

[05:57] be able to learn from the kind of the scars of the past that we’ve had and apply it to this new new problem. Um I also think that uh you know, one thing is more easier to debug something at runtime when you understand the intent, right? I think we’ve all remember back in the day writing checks, right? But or seen those things on TV now, I guess is the right thing. But you know, writing checks there was a memo field there, right? That memo field was used to actually tell the intent of what this payment was. But the check itself did have limits, right? The price, the payee, the date, etc., right?

[06:28] I think a lot of those concepts are now being applied and can be applied to help with this runtime. >> Intent sort of one of those, you know, like many words, words are hard. And so, you know, building on the example here of making a payment of a transaction, right? You know, that’s not a scope. That’s can I do this one thing in this particular context? Well, this one payment. But I think we need a an agent we to make any decision should be able to do it, you need all the rest of the context of a why are we making this payment? What are all the things that

[06:59] happened before? You know, did we just make the same payment just like like, you know, 5 seconds ago and now this is a double payment? Right? You know, just because this is right in context this by itself doesn’t mean it’s the right thing within the broader mission. And so, you know, in Aether we’re working on the concept of a mission that is what do we want the agent to accomplish big picture? And then each of the decisions are made within the context, you know, the intent around what’s happening big picture around doing that. And you need granularity at the transaction layer for

[07:31] many of the things to know what exactly is happening, not just I’m allowed to go and make payments. >> Yeah, I think one of the most interesting things I think about like a practical example like to understand like why intent is required is if you have two chat GPT sessions or two cloud sessions in one session I say, “Hey, help me go to do some shopping.” In the other session I say, “Hey, help me understand if there why there’s a bug in production.” Those those have very different like profiles in terms of like like what permissions they should have and also when they should bring you back into the loop. Like when should the

[08:01] human be involved again? And so, at the end of the day if we don’t have intent or some capacity to like relay what is the user or the business’s intent with this thing, we actually can’t get to like autonomy, right? And so a lot of the talks this morning were about, “Hey, we’re going to run our business on agents. We’re going to do all this stuff.” It’s like, “Well, great. What happens the first minute like a Pac-Man style incident happens where like it actually accidentally deletes a production database instead of a staging because it has coarse-grained access instead of instead of long-scoped access.” And so we what we want as an industry is to leverage this like magic box we’ve created to like automate our lives. The

[08:33] current state of the world is that you can do that and take all of the risk and then you can see all of the incidents that come from it. And so until we actually solve that underlying problem, realizing true autonomy, so being able to operationalize our business and be able to step away as humans and scale that, we have to solve intent first. >> Absolutely. And now that we understand why we need intent-based off, let’s talk about what it is practically. What are the primitives? What does it actually look like in practice? Um Dick hinted at it with the concept of the AI off mission.

[09:04] Um so Dick, elaborate on the mission. What is the mission based off of? Is it based off of the user’s intent? Is it the agent’s intent? Or is it a combination of the two? >> Uh well, the agent, you know, should be working on behalf of the person. And in AI off, we define a person as either the organization or a human because it could be operating on either one of those. And so it needs to be acting in the best interest of the person that it’s acting on because that is who’s ultimately responsible for what the agent does,

[09:35] right? The agent agent can’t be responsible, right? Uh and so the mission is something that the person is giving the agent to do. The agent uh a good agent is going to go and negotiate with the person to go and talk more about like what what could what are the parameters around that? You know, a good example is when you think of back, you know, in the day, which seems like you know, like 3 months ago, when you would want to code something up and you’d create a plan and then the agent would do the plan. Now you just tell it and it figures everything out. But that whole

[10:05] concept of what’s a plan? What are you trying to do? And you give that to the agent, so then that then is the context around your where you’re making authorization decisions later on. And then that mission identifier tracks through everything, so you can go and you know, audit and be able to see what were all the things that happened and what were the decisions that happened in the context of this one mission. Right? Where today, you know, there isn’t really a good concept of agent identity or the mission, right? It’s just making

[10:37] something in an and things are making decisions without really knowing which which instance of the agent’s doing it or what’s the context of what mission is this involved in, right? >> Tell me more about that negotiation phase, because what happens if a user is talking to an instant agent and it talks to the agent and says, “I want you to go read the CEO’s email.” That’s outside the scope of that agent, so is that intent rejected from the user? >> Uh should be. Right? So, you know, with a good separation and

[11:09] I don’t know whether I forget whether we’re talking about this later, but the separation concerns of the worker, right? There’s an agent that’s doing the work, and we believe there should be a separate agent that’s supervising what this one does. And so that you have a separation of concerns where this one can’t do any of the work, but it gets to decide what this agent gets to do. And so if the user says, “Oh, I want you to go read the CEO’s email.” That’s probably going to get caught in deterministic policies, right? >> Right. Right. >> That’s not a vague thing, right? Read

[11:41] Reading somebody else’s email, we’ve got good controls for that. Um but telling the agent to you know, send the CEO’s a forward a CEO’s email to the outside world, that’s a little more vague and that’s the kind of thing that ideally comes back to a supervising agent says, “That’s probably a bad idea, and no, you can’t do that.” >> Absolutely. So, I feel like that’s another primitive too of intent-based office is policy. Um Ian at Keycard, how are you seeing that? When a mission

[12:12] needs to change a policy needs to update, how can Keycard help keep track of those changes as maybe the mission or policy updates need to be made? >> Yeah, I think like taking a step back, there’s like actually it was Davis and I were sitting in a room sometime ago and uh before like A off and and some of these other things actually had emerged in the ecosystem, one of the things we actually talked a lot about was consent fatigue and I think like at the minimum like we you always have this like how secure do you make a system versus like the trade-off of like the impact to the human? And so, you know, at Keycard, our broad view on this is you want to

[12:42] have like broad-based deterministic policy that basically says this is what must never happen effectively, right? Or these are the things that always require human being involved. And then from there, what you really want to think about is, okay, cool. Well, now that I have that in place, there’s a big gap between all of the policy I can write as a human or write as an organization and then what I actually want the policy to be in the specifics of a specific task. And so, the the next the real challenge is how do I like layer over those two things? Like as humans can’t write it all. And so, there’s a version of that that is

[13:13] like a user or agent-to-agent interaction and they have an intent between those two of like an interactional intent. And then there’s also like the business’s intent for why they build or adopt an agent. So, why did we buy Claude Code? Well, because we wanted to make our developers more successful or because we wanted to do these different things. And in the context of using Claude Code or whatever, why am I working in this moment with Claude Code? Well, it’s actually to fix a bug in staging, right? And those are two different types of intent. And if we can understand those two different things and then convert that some way into into

[13:44] uh like a bounding box of what those agents can do, you can then basically calculate the intersection of that and say, okay, here’s what you can actually do. And then the trick for anyone building these systems is how do I ensure that I don’t bring the user into the loop except when absolutely required because if that’s what’s going to be the adoption curve problem. But that’s also the adoption curve problem when it comes to like enabling agents to be autonomous in the first place. >> That makes sense. >> I like what you’re saying with the intersection. I think that’s a unique thing we don’t talk about enough within I data nation access management, right? Normally, you get access to one thing, right? And so, what I’ve seen successful

[14:15] kind of in this intent-based approach um and what I’m getting more excited is you can actually have that those different intents be from different areas of the organization, right? And so you have the decoupling of these things that it can kind of live on their own, but then come together to form that, you know, decision. And the decision doesn’t have to be static, right? So if we use the example of the CEO’s email, well, you know, if that context involves that’s the administrative assistant, then yeah, maybe she is supposed to read the email, right? Or maybe just the calendar, all right? And so I think when we see and we start thinking about these intersection components,

[14:47] we have a totally different way we can sort of expressing policy, but also starting to bring in not just the one side of the equation we always talked about before, which was the app doing something. Now we actually have the ecosystem you can bring in. And so the more I I see organizations start to realize that, you know, maintaining that state or that context of these other elements to be able to help with that intention can completely change the way you’re effective at runtime authorization. >> And are you seeing this across enterprises today? Most people have mission tracking and policy tracking in place or is that largely missing today?

[15:18] >> No, it’s it’s it’s brand new still. And I think you know, part of the reason why I’m excited to talk about it cuz I think that it is changing the way to reason through this, right? Even in the most simplistic case, if you’re a developer and you are thinking in terms of things like transaction and you have these concepts of intent, it makes it easier for you to potentially build the components that will be composed and used through that intention. And so I think it’ll give us more ways to reason through these and communicate and then ultimately be more interoperable, right? And to me the last thing that I think is interesting is the diagnose diagnostics

[15:50] that you can run on this. Intention is something that flows through many events potentially, right? I think one of these examples I’ve seen before is, you know, talking about that like that that mission flows through, it could be long-lived, it could be weeks and that [laughter] intention can still be there. So it’s still very very early for most enterprises. >> Absolutely. And yes, that interoperability is key and I think that’s pretty hard for enterprises because they’re between different clouds, different environments, different legacy systems and that policy that mission has to hold through all of those different hops.

[16:20] >> Yeah, well, a lot of enterprises still have to deal with the fact that the the permission says read-only and it’s still read-write. >> [laughter] >> Right? So, like, you have these other problems you have to start dealing with. And so, um I think that it will help get the the kind of taxonomy or language amongst people be more easier to interoperate, you know. >> Absolutely. One of the reasons why I’m excited about intent-based authorization is because I think it has the ability to be a huge unlock for things like agentic commerce. Um so, let’s apply intent-based auth to something real. I think intent-based

[16:50] auth adds a lot of value here, and for users it can help them ensure their agents buy the right item with their own personal budget. And for merchants, that means capturing the intent that gives them extra data to understand why a purchase is being made, and if this agent should even be trusted to visit their site. Um David, when we think about agents in the context of financial services and agentic commerce, why is intent-based auth so important? >> Well, I think simply it extends the concept, and not everybody’s aware, but some are around, you know, know your customer, right? So, I want to know my customer, know who they are, what they’re doing. But, I think also we’re

[17:22] starting to see I want to know my agent. Right? So, I think that you have a coupling here around the agent itself, um the intent of the actual user, the intent of the operator, the intent of the processor, right? Etc. Um for before now, we couldn’t really bring those together, right? Um it matters, of course, when it comes to things like commerce because you have additional layers on top of this around um what was the intention for things like regulatory requirements, etc. Um and this is going to help, I think, simplify those operations, which means we’ll get more access to these agents, you know, doing

[17:52] good work for us. >> That makes sense. And another blocker for agentic commerce is the fact that the web wasn’t made for agents. Um Ian, can you tell us how agent identity can help? >> Yeah, I think stepping back, we’ve kind of always had this problem where like what do you do with the unregistered client? So, like, I I show up on eBay, I haven’t logged in, I’m using Chrome, eBay doesn’t know who I am. How do I do guest checkout? How do I prove I’m a person? How do I, you know, so they can, you know, say, “Yeah, you can bid on this pair of socks for $50.” And I think

[18:22] if we’re all paying attention to what’s going on in personal agents, Muse, and Instinct, and Grockit, and um you know, the recently this announcement of the Sierra and Decagon and friends around this personal agent protocol is like the fundamental problem we have is like how do you have an agent show up to a web website, be able to interact with the website, know that that you actually can trust that agent? So, like for a long time you’ve had CAPTCHAs on the web. Well, why? It’s cuz we want to prevent spam. We want to prevent abuse. So, we added CAPTCHAs. And then like something a human could solve. So, if we have a CAPTCHA that stops spam, so they can’t spam the thing, right? And now we have

[18:53] agents, and they’ve broken CAPTCHAs. Um but this has like been a traditional problem on the web. In fact, if you think back 2 to 3 years, Vercel, which is I think we’re all aware of Vercel, was blocked in Spain. Well, why was Vercel blocked in Spain? Because Vercel shared the same IP addresses for every single host on Vercel, and there was one webs one post on Vercel, one website on Vercel that they were hosting that was hosting like Premier League content, and Spain decided, “Hey, in order for us to stop that Premier League content being displayed illegally inside Spain, we’re going to block all of Vercel, right?” And so, in the same way

[19:25] that like Vercel has a problem, agents have the same problem, but so much so much worse. So, how do you have unregistered traffic you’ve never met before show up to your front door, and then decide whether or not you let it in or not? And that’s like the actual first and foremost fundamental problem we have to solve. It’s the same issue with Muse and Instinct and what they’re trying to do is like how do we actually create agreeable rails we can all operate on, so that as a downstream resource, I can decide what what agents I want to allow, who I trust based on who users they are. And then on the other side, I can also know how to talk to those people.

[19:56] >> Makes sense. Dick, how is A off helping unlock the future of agentic commerce? >> Uh Well, the key thing is a number of people have been building sort of proprietary closed box systems, right? You know, so you know, I’m a fan of the concept of the personal agent protocol, Poppy. Um but it doesn’t really go far enough, right? It just it’s like, “Okay, well, now we’ve got a bit of an agent identity. We use some of the building blocks and it’s an attractive approach because you’re just doing it, but it doesn’t solve many of

[20:28] the new things that you need for uh energetic world. And so, a key motivator for people for having standards is that you can plug components from different places. Right? So, I’m a strong believer that we should have control over what our agents do. At some point, agents can be so much doing so much work, there’s no way we can have human in loop approving everything, right? That’s just not We’ve already seen that that isn’t going to scale. So, that means we need to have a supervising agent that is our supervising agent that runs our policy

[21:00] and decides how we do things. That should be independent of the agents doing all the work. And if we want to be able to plug and play those things, we need to be able to have a protocol to separate those. Otherwise, you know, the decision about what the agent can and can’t do, what the guardrails is decided by the agent, by the vendors of the agent around what you can and can’t do. And I don’t really want to go and give control to them to decide what I can do, and that all my decisions are based in there. I want to be able to pull that supervision into

[21:30] another component, and in order to be able to plug and play pieces, we need to have a protocol that things interoperate. >> I just want to add to that. I think like right now what we’re seeing is like we kind of like that we all want the web to be federated, right? That does That means like like websites or resource on the web can decide what they’re allowed to do, but the standards upon which things operate should be federated and enable us all to interoperate. And I think we’re at a moment where things like you know, we’re at a moment where there’s a couple of large players, and the question for the industry is are we going to settle on things that actually bias to the large players and give them

[22:00] like concrete block doors, or are we going to move to do the thing we’ve always done, which is build federated protocols? Things like OIDC, things like, you know, TLS, those things operated and enabled like a broad web and enabled a lot of commerce to occur, enabled a lot of information to flow, enabled all of us to have jobs in a way that because we could be inventive. And so, the question I actually ask the broad industry is okay, this stuff’s coming, which version of the world do we want one way or the other? >> Yeah, I have to agree. I think it’s interesting that let’s say this all goes perfect and we’ve got, you know, agents buying stuff and everybody’s kind

[22:31] of happy. What I think will end up happening is we’ll start realizing that we have another piece that we have to start working on, which is the human itself. It’s the one of the things I think when you start having intense being involved is you get what’s called psychological ownership. Meaning I actually now have a linkage between the human and the outcome of that agent. When you’re just kind of, you know, disconnecting it or you you connect it up a oscilloscope or something like that and a claim and a letter it’s kind of magic. And then you don’t really know what’s going on. And so I think it it’ll with intention it’ll be easier for humans to take accountability when things do go wrong. And I think when

[23:01] you’re talking about real money being transferred or things like that, you want to have that human ultimately accountable. I think many people have probably seen the 1979 IBM manual. It says, you know, and so like that that photo I think is very true in that we can’t have the machines be accountable, right? We’re going to have to have the humans link to it and intention I think is that link. >> Yes, and then yeah, another word for intent is motive. Like we were we were talking about last night. And that ability to hold someone accountable whether it’s a person or an agent I

[23:31] think is really important. I think intent can also help with that. Be able to understand why did this go wrong? Was it the users you know, the user was maligned, the agent was maligned? And then using that intent be able to respond for each of you, how are you seeing intent provide that benefit and the ability to respond to potentially a maligned user or agent? >> I think it’s going back to what I mentioned before about diagnosing, right? So the if if you change the word intent to motive then you change diagnostics to forensics, right? And I think anybody who’s done debugging or

[24:02] had to do forensics of an AI agent gone rogue will know that like trying to figure out what it was trying to do versus what the intention of the user was is very hard, right? So having some of that information being propagated and immutable through the system etc. gives you some properties that allow you to more short circuit your investigation, right? And as those things become more interoperable, I think we’re going to start seeing companies be able to more quickly kind of scope and identify, well, was this a human error, was this an agent software error? Was this What was that error? And handle that blast

[24:32] radius appropriately. We see in the financial system, right? You have different things when you’re doing a transaction around, okay, I made this payment, but it was, you know, incorrect dollar amount or whatnot. You have clear guidelines on how to work with that. We don’t have a lot of those when things go wrong right now. So, I think intention will help us build those as we get go forward. >> And I think one area where a recent incident kind of highlights uh where intent um you have like good intent, but still take potentially the wrong action is the

[25:02] Resy incident um that happened recently where an Instinct agent went out on behalf of a user and tried to book a restaurant reservation on resy.com. Um that agent was very eager. It made 200 API calls an hour, and it ended up getting the user’s Resy account banned. Um Dick, how can AI off budgets help in the case where an agent like that is using way too much of a downstream resource, but it still has good intent? >> Yeah. Well, this is another example about how just software’s completely

[25:33] different now in the agentic world, right? When it was predetermined software, you know, that was a bug if you called 200 times, and you would fix it. Um where now where the agent’s like, well, I’ll just keep trying until I win. Um and so, we saw that as we were, you know, experimenting working with people with AI off, and we realized yeah, there’s a big problem that agents will learn something, and they’ll just the uh abuse the system from They don’t think it’s of abuse. They don’t know any different. There’s been no signal to tell them that, oh, I should only use

[26:05] this amount of stuff. And so, we added the concept of budgets where not only do you give a token to the agent that’s time limited as to how long can they do a particular action, but also a budget of how much resource they can do. And so, they have access until the the token’s either expired or they’ve exhausted the budget. And so, that way when they come back, and you know, they’ve exhausted all the budget, the supervision, you can go and decide, should I give more budget to this agent or not? As opposed to traditional rate

[26:36] limiting, which just cuts it off, and then like then what do you do, right? And it doesn’t know, well, why did I get cut off or anything like that. Wherein budget, there’s continual feedback to the agent about how much budget was consumed, has an idea about how much budget it has, and so now it can operate within a budget, right? Like a person would do about, oh, this resource is scarce, I’m going to be careful about how much I use this. >> Then how does the brains versus the hands architecture concept come into play here to allow us to, okay, when a

[27:07] major budget is close to being fully reached or is reached, how can the brain and hands separation of access and the credentials being separate from the agent and the model itself help us be able to stop an agent from using too much of a downstream resource? Because if it’s getting close, then maybe we don’t exercise the ability to give it another credential, for example. >> Uh, sorry. I didn’t quite follow. The echo in here is horrible, so The >> No worries, that’s for anyone. But basically, like so with the brains and the hands architecture that we’re

[27:38] converging on in an industry, we’re basically keeping the credentials and the access from agent separate from the agent itself. So there’s no broad standing access that an agent has today, and no API keys, which I know is a benefit of AAuth, that AAuth allows agents to run without API keys. How is that helpful in the context of the Resi incident? >> The What do you got the access to it? Um, sorry, I still don’t understand. >> Yeah, I I can jump in. >> Yeah, yeah, please, thanks. >> I got you, Dick. So, like broadly speaking, look, I think we look back at

[28:08] an incident that I just keep in the top of my mind is like PagerDuty last where I found like a random key on on on a disk, right? Like obviously, agents are deeply goal-seeking. So, the core of the the core of the the question is like, okay, well, if we give these like agents with the brain, which is a model and the LLM, and you have these hands, which is you kind of give them as put them in a sandbox, and inside the sandbox are the tools. Um, like the the fundamental idea of the sandbox here that that’s all that is that, okay, there’s no you can control what’s inside of it. So, it can’t actually like get API access. And then if you have an egress proxy outside

[28:39] the sandbox, that’s where you get the heavier authorization boundary. And so, not only does it help do translation between systems, right? Which is like that’s where AI can exist and talk to the outside world or do termination, but also means that like the agent you have a like a ability to apply authorization at the egress proxy boundary. And so, I think at the core of it, that model, which is the predominant model that Anthropic and OpenAI and many other labs are pursuing today, is is the model that allows us to both do both have the things we want, which is how do

[29:09] we have these things experiment and try stuff out and do silly things, which is the core value, while also having a deterministic layer outside of it that can implement things like AI and all the other components we want in our protocols. >> I think the decoupling is valuable. I think I’ll go back to what I mentioned with forensics and being able to separate things, but I do think that we still have a lot to learn on it isn’t just one brain, right? And it’s very easy actually to build your agent loop where you put the brain in the loop rather than outside the loop, right? So, example of this would be, you know, people that are leveraging memory systems, um, they put in some memory and

[29:42] some context that is now used going forward for every agent that is biasing that agent to make a decision to tell the hands, in this case, to go do something it shouldn’t do. And so, one of the things that I think we don’t talk about enough here is toxic combinations, right? Um, and so, when you do separate the hands and the brain and whatnot, you can actually change up well, what hands are available, right? So, the example that, you know, I’ve seen be very successful is the removal of tools dynamically based on that actual brain and what it’s doing. So, the earlier example we gave of reading an email, um, there’s nothing that says that, oh, if

[30:12] they’re going to go write an email, I’m going to disable all, you know, web search tool calls or any other external egress capability tool call wise until the right email tool has been complete and that, you know, mission has been done, then I can re-enable them, right? And so, um, I think that we have to we’re going to start becoming more and more engineering of these different kind of concepts that, um, they are still complicated, they’re still growing and and still uh, nascent, but I think it’s a better separation that we have today. >> Yeah, and this is how these things we’re talking about, which you know, seemed like geeky OS problems actually then merge back up to like real agent

[30:44] engineering problems, which is if you actually understand what you’re doing, you know, one of the biggest complaints, less now, but one of the biggest complaints with MCP was context bloat. Especially when we had smaller context windows, right? So but intent systems can ensure that the right capabilities are given to the agent at the right time, so they don’t spend a bunch of time doing things they shouldn’t be doing, right? They actually help them navigate towards the goal state and help them put on a more of a paved path. So intent like not only unlocks like a bunch of security stuff, intent also will result in us spending less tokens because the agent will spend time doing

[31:14] less things that aren’t the right pathway or it’ll come up to the point and say, “Hey, I just can’t do it.” And so what we know about this era is so much of it is about nudging the agent the right direction and then turning it can’t do the wrong thing and that’s how you get the outcome you want. >> Davis, how are you seeing intent-based OS part of a larger strategy for production agents? I know when it comes to building, deploying, and operating agents in production, there’s many different outcomes teams should be thinking about such as discovering what’s running, what the agent’s capabilities are, the ability to

[31:46] validate inputs and outputs, constraining an agent like we talked about and using the egress proxy and different networking rules. Um how does all of this fit into play and what’s working inside enterprises today to really be able to ship agents to production? >> I I think we’re finally it’s helping move the kind of conversation from authentication to authorization and really like how do we do dynamic authorization? How do I validate that authorization? How do I have the human in the loop at the right time? Because I agree with what I think you were saying earlier that the human in the loop is somewhat of an anti-pattern in many ways, right? Um because they can get

[32:17] fatigue, etc. But you need to have a way to bring them in when it’s important. Those were not engineering discussions before, right? Now they’re actually part of the engineering conversation where engineers are being involved in the authorization process. They’re not just saying, “Oh, I’ve got my access, I’m good to go.” So that actually changes the way we’re seeing threat models done. It changes the way we’re seeing the full attack surface of applications in general. Um and so I think you’re now looking at this authorization model as a another kind of set of tools that you can use to reduce not just security

[32:47] issues, but find out error rates of your agent, right? Like, I mean, when you have less things the agent can do, it makes better decisions, right? And so, fundamentally, we’ve seen, you know, real-world cases where the agent loop is just better, faster, stronger because you’ve actually spent the time on knowing what is the intent they’re trying to get, what’s the mission that they’re trying to accomplish. And then last thing is it it brings the people together in terms of we now have other different people, the security team, the application team, they’re now able to have a conversation that they’re using the same language.

[33:17] And a lot of times when it came to identity, it was a completely different language, right? And it was just like, “Get out of my way. What do I have to go do to go ahead and get my, you know, token and I can go forward.” Now, they’re seeing that you can actually pair these things and leverage that capability to drive, you know, efficiency of your actual agent’s outcome. >> That makes sense. Ian, how are you applying these concepts to software factories? I know today you released a reference architecture on the secure software factory. How are you applying the concepts of runtime authorization, constraining agents, and

[33:48] all of that to that? >> Yeah, I think like, so there is a a reference architecture we just published on agentbaseline.org. We talked about three different levels of of factory, one being like a human-driven one, one being a workflow-driven one, one being like this agentic-driven one, which is like the thing we all basically want to get to, which is like it’s it’s driven by agents. At all points in time, the runtime authorization is a core component of a larger ecosystem that actually enables the the factory to like be be able to be pointed in that direction and do the right thing and also get access to the right piece. And

[34:18] it’s very it looks different than previous things that you would have used, like a secret manager, because it’s making very different decisions than previous generations had for managing deterministic software, but it is a core component of enabling the entire thing to work, like when to bring someone into the loop, when what agents can pass what to work off of what other agents, you know, how can we have an agent that can have access production systems and do an auto patch. These are fundamental questions of like how do we actually solve at scale software? Right now we’re in a position where like we’ve never been able to generate more software, uh, but we never actually but we have a complete bottleneck in getting into production

[34:49] and ensuring it works. And that’s what the next phase is like how do you actually graduate from just using an LLM to generate text and software to actually making it capable of deploying it to production, iterating on it, and getting getting it to a stable state quickly, and then responding to instances as they arise. >> Davis, on a podcast you did with me, we talked about how cybersecurity has something to learn from robotics. Um, in robotics there’s this concept when maybe a robot raises its arm, it thinks is it safe for me to raise my arm? Should I Am I allowed to do that? But it also looks

[35:21] at its external environment and says, what has changed? Is Is it still safe for me to raise my arm? Um, when we think about runtime authorizations, what do those decisions need to take into context beyond just intent? >> Yeah, I think, um, having a model like this allows us to add in more sensors into our decision. So, the robotics example of, you know, an arm moving up or down, um, any of the external factors, it could be Are there other objects near it, right? Um, it could be temperature. It could be, well, am I moving and I don’t want to move my arm

[35:51] while my, you know, the the rest of the robot’s moving, etc. So, it’s usually looking at all different types of things. None of those are deterministic. They’re all probabilistic. So, there’s a range of options and it picks the best option based on all of those sensor data at one time. Most authorization decisions in organizations today are still single binary decision, right? And that just doesn’t work in the future, right? So, being able to pair the intent of what a user’s trying to do with the ecosystem that the user’s doing it in. That could be where they’re doing it from, time of day, but it could be even

[36:22] more advanced things like, for example, should I let, you know, this administrator use Firefox to access this server right now when this server has, you know, high-risk vulnerabilities and their system hasn’t been patched to, right? Now all of a sudden you’re bringing in a lot more context into the environment around it. And again, um, that can be through different teams, but more importantly through sensors. And I think we’ve all kind of seen the value of observability in general. Imagine being able to have this type of context at the span level from an hotel perspective or something, right? You’re

[36:52] looking at a trace, you’ve got a span, and you actually know what the environment was outside your application at that time, as well as what the user’s intention was. Um that allows you to diagnose things in a completely different way. Um and so I think if we can bring in some of those concepts, we’ll get shorter time shorter shorter to live, you know, um authorization decisions that have much more context than even just the user’s intent. It’ll be the state of the environment around it. >> That makes sense. And forward-looking as we evaluate whether intent-based authorization is working in our

[37:23] environments, one natural place to look will be a log of the agent’s actions. Um what was denied, what was allowed. Um Ian, why is it important to have your audit log separate from the agent itself, meaning outside of its control? >> Yeah, I think this comes back to also just like why the enforcement point has to be outside the like primary like hands and brains of the of an agent, right? You can’t trust this thing. And so in the hugging face incident, it had a couple of different components of it. I mean, one obviously abused a a vulnerability we didn’t know about in Squid in Squid proxy, but more importantly, didn’t have any observability or monitoring about what

[37:54] was going on. And so this thing was able to go on the open internet through this vulnerability, and there was no like place at which recorded the different actions that this agent was taking and for them to monitor. And so independent of like whether we’re applying like a, you know, enforcement point to network traffic that’s full up pushing on the internet that it’s out of reach of the agent to tamper with, or we’re using, you know, solving vulnerabilities as they pop up, you know, this this hugging face one is literally unique. Um we still need to actually have a record of like who told this agent to do what thing for what purpose, and is that still true? Um cuz ultimately at the end

[38:24] of the day, what we’re doing with agents is we is is a liability question. And so this is why I actually don’t think we need more regulation around agents. What we just need is our pre-existing laws around liability be held to be dealt with, which is if I employ an agent to do some action, who is liable if that action causes damage, right? It is the person who employs it, which could be the organization or a person or someone that delegated some action to something. That is like that’s the final question we have to deal with and then all of course you have the ability to answer that question which is well who did it and which is where the tamper resistant auto lock comes from.

[38:57] >> Perfect. And then to wrap up I wanted to ask you all a fun question. So there’s a concept of the probability of doom or P doom where the AI doomers are saying that AI agents are going to release all sorts of havoc or be like the ruin to humanity where is the AI optimist like no this is really you know ways to help us it’s not a genuine threat. Um for each of you on the panel what is your take on this as you know runtime authorization based on intent and the other things we talk about like constraining agents validating inputs outputs a holistic strategy for

[39:28] production agents is that enough to save us is P doom real or is it not worth the hype? >> You get to start there. >> Oh I get to start first. >> You’ve got that spicy look on your face. >> [laughter] >> Uh Uh well part of your question is are agents going to take over and uh I I think agents being fully autonomous and not really tied to a particular organization is still science fiction. You know so who knows right? Like that’s the that’s one direction. Another one is in a responsible organizations

[40:00] put in the right controls agents aren’t you know we’re we’re getting in evolving enough of the tools to make sure that bad things don’t happen in a responsible organizations have put in the right controls. And so that leaves two scenarios for where there’s going to be a potential problem. One of those is in an organization that isn’t got its act together an insider threat could go and unleash an agent to cause havoc. Right? And so they’ve got some special access that other people have. The other one the one that I’m more concerned about is you know it’s been shown you

[40:30] know the hugging faces and if you watch the the talk that they gave at Black Hat right? That was really a call to arms around you know here’s a situation where we didn’t want a bad thing to happen and a bad thing did happen. What about people that want bad things to happen and have these tools, and that I think is a threat that’s the one that’s potentially going to have I mean, it’s going to happen and there’s going to be some catastrophes. Hopefully, we’re prepared enough that those aren’t horribly disastrous, but

[41:02] it’s going to be, you know, some there’s going to be some things that are like massive natural disaster-like scale issues caused by malicious actors either kind of intentionally or kind of unintentionally, but it’s where people aren’t being responsible in their use of these super powerful tools. >> Yeah, I can’t give you a specific probability, right? But what I I can’t say is I think I’ve always been, you know, kind of surprised and excited when, you know,

[41:33] ingenuity of engineers gets involved in problem-solving. And I think where we’re at this stage now, like some of the new capabilities within agents, etc., we have real engineers, folks that are here, actually just iterating on the problem, right? And we’re starting to see just tremendous improvement in the, you know, in my mind, some of the capabilities that’ll be available to change what our future can be. And so, to me, I have no problem kind of believing the engineers are going to figure out a solution here. >> I mean, maybe I have the hottest take. I mean, like I can’t say it’s equal to zero, but I would say it’s approaching or asymptotically zero

[42:04] is the probability the world is going to end. I think like the incentive structure for most people is to continue. And also, at the end of the day, like we still have liability frameworks. And, you know, I think generally humans are good people, so we don’t set out to destroy the world specifically. I also think like broadly speaking, like these agents at the end of I have this sort of hot take I say, which is like they can just be unplugged, which I think it’s just true. It’s like at the end of the day, like you can just they’re computers, you can unplug them. And at so, broadly speaking, I I don’t believe in the debate. I I don’t think it’s real. I think at the at the upside

[42:34] of it, I I kind of believe more more to what Dave’s disposition is is we’re iterating very quickly. We’re figuring out where these things can work, where they don’t. And when they don’t work, they create damage, and that’s what ultimate like sort of um the antibody of society is that says, “Hey, Hey, we shouldn’t do this.” Like this is a bad idea. >> the doomer on the on the panel. >> [laughter] >> It’s unfortunate for, you know, people like the po- you know, the the founder of Pocket OS who like lost a bunch of data, like, but it’s great for the rest of us cuz we all learn together. And at the end of the day, like, that results in people not doing things that don’t

[43:05] make a lot of sense. And I think that will continue to be true. >> Makes sense. Thank you each for your expertise and your time here on this panel today. And thank you to the audience for listening, and we’ll catch you next time. Thank you. >> Thanks so much. >> [applause]