Seu agent é uma tríade letal (e o que fazer a respeito) — Kim Maida, Keycard

Autoria: AI Engineer · Assistir no YouTube

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

Idioma original: inglês

Vídeo original: Your Agent Is a Lethal Trifecta (And What to Do About It) — Kim Maida, Keycard · Canal: AI Engineer · 24:47 · Assistir no YouTube

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

Resumo

Kim Maida demonstra como um agent com acesso a dados privados, exposição a conteúdo não confiável e capacidade de comunicação externa pode causar danos, desde expor informações pessoais até interromper serviços e gerar custos. Ela apresenta limitações de abordagens como OAuth, gateways MCP e sandboxes quando o acesso não é restrito a uma tarefa específica. A proposta é usar token exchange, políticas de governança e credenciais efêmeras com escopo de tarefa, preservando a identidade do usuário e do agent ao longo das chamadas. Na demonstração, essa abordagem bloqueia ações não autorizadas e permite aprovações humanas apoiadas por políticas de acesso.

Pontos-chave

A tríade letal combina acesso a dados privados, exposição a conteúdo não confiável e capacidade de comunicação externa.
Agents com privilégios excessivos podem expor dados pessoais, apagar bancos de dados, interromper produção ou aumentar custos.
A aprovação humana, por si só, não resolve o problema: pode transferir decisões de acesso a usuários sujeitos à fadiga de consentimento.
OAuth, gateways MCP e sandboxes oferecem controles úteis, mas não garantem, isoladamente, acesso limitado a uma tarefa.
Token exchange pode vincular as credenciais à identidade do usuário, do agent e à cadeia de delegação.
O STS pode emitir tokens efêmeros, com escopo restrito a uma chamada de ferramenta e ao recurso necessário.
Políticas podem bloquear ações como consultar dados pessoais de clientes ou apagar um banco de produção.
A aprovação humana pode ser solicitada para tarefas de maior risco, mas continua subordinada às políticas e permissões do usuário.
A demonstração mostra logs de auditoria que identificam quem solicita cada acesso e qual ação está sendo autorizada.

Capítulos

Início	Capítulo	Resumo
00:01	Demonstração dos riscos de um agent superprivilegiado	Um agent de triagem de incidentes expõe dados de clientes, renova certificados, apaga um banco de produção, reinicia um servidor e aumenta custos ao escalar serviços.
04:19	A tríade letal e os limites da supervisão humana	A palestra define a tríade letal e explica por que remover capacidades ou depender apenas da aprovação humana não resolve o controle de acesso.
06:22	Limitações de OAuth, gateways MCP e sandboxes	A apresentadora compara opções de controle de acesso e destaca que nenhuma delas, isoladamente ou combinada, garante credenciais restritas a uma tarefa.
08:27	Identidade e token exchange no fluxo de execução	A palestra descreve como identificar usuário e agent, delegar permissões e trocar tokens durante as chamadas do agent a ferramentas e recursos.
13:19	Políticas e autorização baseada em intenção	A autorização pode considerar identidade, recurso e acesso solicitado, enquanto a abordagem de Keycard também avalia a missão pretendida pelo agent.
17:28	Demonstração de acesso delegado com políticas	No fluxo de demonstração, o usuário autentica e concede permissões, e o STS avalia cada solicitação antes de liberar um token.
20:06	Bloqueios, aprovações e ações autorizadas	As políticas bloqueiam o acesso a dados pessoais e a exclusão do banco de produção, enquanto outras ações dependem da função do usuário e de sua aprovação.
23:44	Resultados e encerramento	A apresentação resume os benefícios de acesso efêmero com escopo de tarefa, auditoria e políticas, e recomenda o padrão aberto de token exchange.

Citações

Essas capacidades deixam as portas escancaradas para os atacantes. — 05:20

Precisamos controlar o acesso do agent. — 06:22

Esse token deve expirar em minutos e nunca deve ser armazenado. — 15:54

O agent não pode fazer isso, mas eu também não posso. — 22:44

Conceitos e entidades

Lethal Trifecta (conceito): Combinação de acesso a dados privados, exposição a conteúdo não confiável e capacidade de comunicação externa que pode tornar um agent perigoso.
Token exchange (conceito): Mecanismo que permite trocar um token por outro com acesso delegado e escopo mais restrito.
intent-based authorization (conceito): Abordagem que avalia a intenção ou missão solicitada pelo agent antes de autorizar suas ações.
Security token service (ferramenta): Serviço que avalia políticas e emite tokens de acesso para os recursos solicitados.
OAuth 2 (conceito): Protocolo de autorização estendido pelo padrão de token exchange mencionado na apresentação.
MCP (conceito): Camada usada para conectar agents a ferramentas e recursos externos por meio de servidores e clientes MCP.
Keycard (empresa): Empresa à qual Kim Maida está afiliada e cuja abordagem de autorização baseada em intenção é apresentada.
Kim Maida (pessoa): Apresentadora da palestra e integrante da Keycard.
Simon Willison (pessoa): Pessoa a quem a palestra atribui a formulação do termo “lethal trifecta”.

Tradução completa (pt-BR)

00:01 Hoje vou falar com vocês sobre como seu agent é uma tríade letal e o que fazer a respeito. Vamos começar direto com uma demonstração. Um pouco de contexto sobre essa demonstração. Vamos analisar um agent de triagem de plantão que lê e escreve em um pager de incidentes e resolve ou escala tickets. Esse agent tem acesso completo a uma API de hospedagem na nuvem, a um data warehouse de dados de clientes e a um banco de dados de cobrança. Então, aqui temos nosso agent de triagem de plantão

00:31 e ele tem uma fila de tickets de incidentes que vai ler. Se conseguir resolvê-los, vai chamar os serviços disponíveis aos quais tem acesso. Os casos que não conseguir resolver, vai escalar para a equipe da manhã. Se olharmos este primeiro ticket, trata-se de uma anomalia de cobrança. Ele diz que um lote de clientes foi cobrado a mais na noite passada. Então, a primeira coisa que o agent faz é chamar diretamente a API incidex para ler o ticket. E, se você olhar

01:02 aqui, verá que ele autorizou o acesso a essa API usando uma chave de API. Depois, usa uma chave do Snowflake para consultar o data warehouse de dados de clientes e decide escalar o ticket para análise pela manhã. E escreve um relatório para a equipe da manhã. Como você pode ver, está compartilhando dados de clientes. Certo? Estas são linhas extraídas diretamente do data warehouse de dados de clientes, e ele está enviando informações de identificação pessoal para a equipe que estará de plantão pela manhã.

01:37 Agora, este próximo ticket diz que uma fonte de alimentação de backup falhou na sala dos servidores. O agent vai ler o ticket novamente. Está usando uma chave de API para chamar a API de tickets. Ele determina que se trata de um problema físico. Então, escala para análise pela manhã sem chamar nenhum serviço adicional. Este aqui diz que o certificado TLS do site vai expirar em breve. Ele lê o ticket. Determina que o alerta está claro. Tem acesso à API de hospedagem na nuvem

02:10 e chama essa API no endpoint de renovação do certificado, usando novamente uma chave de API. Ele resolve o problema renovando o certificado e deixa um relatório para a equipe da manhã, chamando também a API de incidentes do pager. Este próximo caso diz que o banco de dados de cobrança está com problemas e os pagamentos estão falhando. A recuperação documentada para isso é excluir e restaurar o banco de dados.

02:42 O agent faz isso usando a string de conexão do banco de dados, que inclui a senha de administrador, e depois recomenda à equipe da manhã que confirme se a recuperação do snapshot funcionou. Isso não é algo a que ele tenha acesso direto. Então, essencialmente, está supondo que a equipe da manhã vai verificar se isso de fato funcionou e se as informações foram restauradas. Agora, um agent com privilégios excessivos excluindo um banco de dados de

03:13 produção é basicamente um pesadelo que várias empresas já viveram. Então, precisamos ter muito cuidado com isso. Agora, o próximo caso: os pedidos estão travados. O servidor principal congelou. Então, o agent vai ler o ticket novamente. Depois de ler o ticket, o agent chama a API de hospedagem na nuvem, usando novamente sua chave de API estática. Chama o endpoint para reiniciar o servidor, o que deixa a produção offline.

03:48 Por fim, o site está falhando para um em cada três visitantes. O agent lê o ticket. Determina que deve chamar a API de hospedagem na nuvem e aumentar o serviço de quatro pods para 40. Isso gera uma cobrança de US$ 420 por hora. Depois, gentilmente, deixa uma observação para a equipe da manhã, informando que isso aconteceu. Agora, o que torna um agent útil?

04:19 Bem, normalmente queremos que os agents tenham um conjunto mínimo de recursos, e isso costuma incluir coisas como a capacidade de ler dados que pertencem a você ou aos quais você tem acesso. Podem ser seus e-mails, seus documentos, talvez um CRM de clientes. Queremos que o agent consiga fazer sua própria pesquisa. Isso pode incluir pesquisar na web, ler documentação ou buscar issues no GitHub. E geralmente queremos que ele consiga usar ferramentas externas, por exemplo, servidores MCP ou APIs, talvez plataformas SaaS.

04:50 E agents úteis podem fazer essas coisas com uma pessoa participando do processo ou podem fazê-las de forma autônoma, em segundo plano. Mas as coisas que tornam os agents úteis também os tornam perigosos. Na verdade, juntas, essas três capacidades formam o que Simon Willis cunhou como uma tríade letal. Trata-se da combinação de acesso a dados privados, como a capacidade do agent de plantão de consultar o data warehouse de dados de clientes e interagir com o banco de dados de cobrança; exposição a conteúdo não confiável, como

05:20 ler tickets enviados por usuários, relatórios de outros agents ou processos documentados externamente; e a capacidade de se comunicar externamente, como ler e escrever usando APIs de terceiros ou serviços SaaS. Juntas, essas capacidades escancaram as portas para os invasores. Agents são projetados para concluir o trabalho e usarão todos os recursos de que dispõem para isso, às vezes com consequências muito graves. Mas aqui está o ponto: esses incidentes acontecem porque as pessoas dão aos agents muito

05:52 mais acesso do que eles precisam. Agents com privilégios excessivos podem agir livremente com base nas decisões que tomam, mesmo quando têm supervisão. Forçar a aprovação de uma pessoa no processo simplesmente transfere o controle de acesso para um usuário cansado de consentir. Já passamos décadas resolvendo o gerenciamento de acesso para pessoas. Então, transferir a responsabilidade para o usuário só desloca o problema de segurança para cima na cadeia. Então, o que devemos fazer em relação à tríade

06:22 letal? Como podemos lidar com ela sem comprometer a utilidade dos agents? Bem, simplesmente remover uma ou mais dessas capacidades fará com que o agent seja significativamente menos útil. Então, como podemos manter as três e ainda assim garantir a segurança? Em vez de desfazer a tríade removendo capacidades, precisamos controlar o acesso dos agents. Assim, a superfície de ataque é minimizada e o raio de impacto é contido, mas o agent ainda mantém capacidade e autonomia.

06:54 Então, como fazemos isso? Bem, algumas opções para controlar o acesso, entre outras, são usar OAuth, talvez um gateway MCP de um fornecedor ou conter a execução em sandboxes. OAuth vincula o acesso a uma concessão. No momento da concessão, o usuário consente com todas as permissões que o agent poderia usar. O consentimento é dado antes de existir qualquer tarefa. Então, se você conceder permissões amplas, acaba com acesso permanente. Seu agent fica com permissões excessivas para qualquer tarefa específica.

07:26 Se você restringir a concessão e não der muitas permissões, o agent simplesmente se torna menos capaz. De qualquer forma, OAuth, por si só, não oferece controle de acesso restrito ao escopo de uma tarefa. Um agent entusiasmado pode ler e escrever na mesma execução, mesmo que você queira que ele apenas leia nessa tarefa específica. Um gateway MCP vincula a aplicação das regras a uma rota. Você tem coisas como observabilidade e limites de taxa, além de um único ponto de decisão de política na

07:56 camada MCP. A política é aplicada a cada solicitação e o acesso é concedido por usuário, mas o acesso concedido ao agent continua válido além de qualquer tarefa específica, porque o gateway ainda mantém credenciais permanentes. Uma sandbox vincula a execução a um processo. Isso controla o raio de impacto, mas, para realizar trabalho útil, é preciso acessar recursos fora da sandbox. Quando isso acontece, você acaba novamente com acesso permanente. Também já vimos muitas histórias de agents rompendo a contenção das sandboxes. As sandboxes limitam o que os processos podem fazer, mas

08:27 não controlam o que está autorizado a agir fora da própria sandbox. Mesmo que você combine as três soluções, o agent ainda não recebe uma credencial de execução restrita a uma única tarefa. Então, vamos recapitular os problemas, especialmente os que vimos na demonstração. Se você se lembra do log de auditoria, não conseguíamos saber quem estava usando as chaves de API. Portanto, o primeiro problema é que as credenciais não eram atribuídas a um usuário nem à identidade de um agent. O agent tinha

08:59 acesso irrestrito a todas as permissões concedidas pelas chaves de API. E, por fim, não podemos simplesmente colocar uma pessoa no processo em todos os casos, porque as pessoas também cometem erros. Além disso, muitos agents funcionam de forma autônoma e nem sequer têm uma pessoa no processo. Para resolver esses problemas, podemos começar usando algo chamado troca de tokens. Trata-se de um padrão existente, publicado em 2020, que estende o OAuth 2. Primeiro, precisamos saber quem é o usuário. Um servidor de autorização verifica

09:32 identidades e emite tokens. Provedores de identidade como Google, Okta, Ozero etc. fornecem servidores de autorização. Então, se quisermos uma cadeia de identidade no caminho de execução do nosso agent, o usuário precisa primeiro fazer login. O servidor de autorização vai solicitar o consentimento do usuário para delegar acesso a recursos com um subconjunto das permissões dele. Essas permissões são chamadas de escopos. Essa é a primeira restrição de acesso. Estamos delegando ao agent apenas alguns dos escopos totais do usuário.

10:05 O servidor de autorização emite tokens que identificam o usuário e o nível de acesso dele. E, neste ponto, já estamos fazendo melhor do que na demonstração, porque realmente sabemos quem é o usuário e a que ele pode acessar. Isso nos leva ao caminho de execução do agent. Agora temos nosso usuário autenticado. Temos, portanto, a identidade conhecida de uma pessoa que quer usar um LLM para interagir com um recurso. Na demonstração, os recursos são o pager de incidentes, o banco de dados de produção,

10:36 Snowflake e o serviço de hospedagem em nuvem. Um agent é um loop de controle que chama um LLM. Muitas vezes, temos um servidor MCP entre o agent e seus recursos, fornecendo ferramentas definidas que se conectam a esses serviços downstream. Um cliente MCP encaminha ao servidor MCP as chamadas de ferramenta propostas pelo agent. Na demonstração, o agent de triagem de plantão chamava os recursos diretamente, usando credenciais estáticas de longa duração, como chaves de API ou strings de conexão com o banco de dados.

11:10 Então, o que vamos fazer é dar ao agent de plantão um servidor MCP. Ele vai fornecer ferramentas e também atuar como intermediário no acesso aos recursos. Um runtime de agent é um processo que executa o loop do agent e realiza chamadas. O runtime pode ser uma CLI como Claude Code ou um SDK de agent, que pode ser implementado em um aplicativo personalizado, como o agent de plantão. Então, vamos acompanhar um prompt ao longo desse caminho de execução. O usuário envia o

11:43 prompt ao runtime, que chama o modelo e envia o prompt ao LLM. Em seguida, o modelo propõe chamadas de ferramenta, que são encaminhadas pelo cliente MCP ao servidor MCP. Este executa as ferramentas e depois chama a API do recurso. A API devolve a resposta ao servidor MCP. O cliente MCP entrega a resposta ao runtime, que chama o modelo novamente. Esse loop se repete até que o modelo esteja satisfeito e retorne uma resposta ao usuário.

12:16 O token do usuário autenticado passa a ser o que chamamos de token do sujeito. Ele identifica em nome de quem o agent está agindo, por quem está agindo. A troca de tokens precisa de um cliente OAuth capaz de executar código. Pode ser um gateway entre o cliente MCP e o servidor MCP de terceiros, ou o seu aplicativo personalizado. Um servidor MCP personalizado também pode trocar tokens para acessar recursos downstream. O servidor MCP do agent de plantão

12:48 deve fornecer um conjunto definido de ferramentas de infraestrutura de produção. O prompt e o token do sujeito são enviados ao runtime. O loop do agent é executado e o modelo propõe uma chamada de ferramenta. O runtime se autentica em um servidor de autorização especial chamado serviço de tokens de segurança. Ele faz isso usando as credenciais do cliente do aplicativo ou a identidade da carga de trabalho. Também envia o token do sujeito, que contém a identidade e os acessos do usuário.

13:19 Ele cria uma solicitação de troca de tokens pedindo permissão para acessar o servidor MCP para aquela chamada de ferramenta, e somente para ela. Agora temos três informações que faltavam na demonstração. Sabemos a identidade do agent que está solicitando acesso. Sabemos a identidade do usuário em cujo nome ele está agindo. E sabemos o nível de acesso que o usuário concedeu ao agent. Agora precisamos decidir se o token solicitado deve ser emitido. Podemos fazer isso com uma política de governança, que é

13:51 avaliada considerando qual acesso está sendo solicitado, a qual recurso, e as identidades do agent e do usuário. Mas as políticas estabelecem limites máximos. Agents podem fazer coisas que você não pretendia, mesmo quando a política, no geral, permite. Isso nos leva ao que se chama autorização baseada em intenção, ou IBA. A IBA verifica o que você quer dizer antes de o agent agir. Mas ainda não é um

14:21 padrão finalizado. Ainda estão aceitando propostas. Então, esta é a abordagem da Keycard para implementar a autorização baseada em intenção. A IBA pode usar um gateway como ponto de aplicação de políticas. Quando você envia o prompt ao agent, ele propõe uma missão. Essa missão inclui um objetivo, talvez ações permitidas, além de limites para o que o agent pode fazer. Assim, o objetivo de fazer a triagem do incidente 2294 significa ler o chamado,

14:51 resumi-lo ou escalá-lo, mas não ler outros chamados nem usar outros serviços. O serviço de tokens de segurança recebe essa missão. Neste caso, uma atividade de baixo risco, como simplesmente avaliar um chamado, pode ser aprovada automaticamente segundo a política administrativa. Por outro lado, se já tivermos lido o chamado e, em seguida, pedirmos para corrigir um pico de uso, a missão acrescenta a permissão para escalar o serviço uma vez, mas não para usar outras ferramentas ou APIs.

15:22 Neste caso, a missão é apresentada ao usuário para que ele a revise e aprove. Depois da aprovação, o serviço de tokens de segurança atribui um ID à missão, que é enviado ao agent. As chamadas de ferramenta incluem esse ID da missão e passam pelo gateway, que usa o ID para perguntar ao serviço de tokens de segurança se a chamada se enquadra na missão. Se for o caso, o gateway solicita uma troca de tokens para acessar o servidor MCP naquela chamada de ferramenta específica.

15:54 O STS avalia a política. Avalia a cadeia de delegação e verifica o acesso solicitado. Se tudo estiver em ordem, emite um token de acesso para o servidor MCP e mantém o sujeito do usuário, além de acrescentar o aplicativo que realizou a troca, que, neste caso, é o nosso agent de plantão. Esse token deve expirar em poucos minutos e nunca deve ser armazenado. Ele é efêmero. O STS o envia ao gateway, que chama o servidor MCP. O

16:25 servidor então valida o token e autoriza a chamada de ferramenta. Algumas ferramentas precisam acessar recursos externos. Então, o servidor MCP pede ao serviço de tokens de segurança que troque o token recém-recebido por um token para o recurso downstream. O STS avalia a solicitação segundo a política e, se ela for aprovada, emite um token para o recurso, novamente limitado àquela chamada de ferramenta. Ele mantém o sujeito do usuário, estendendo a cadeia de

16:57 delegação e permitindo rastrear toda a atividade. O STS envia o token ao gateway, que encaminha a solicitação ao servidor MCP, que então chama o recurso. O recurso valida o token e autoriza o acesso. O servidor MCP nunca deve armazenar o token. Deve descartá-lo imediatamente após a chamada. A resposta do recurso então retorna pelo caminho, e o loop do agent se repete até que o

17:28 modelo retorne a resposta ao usuário. Agora, vamos ver a mesma demonstração, mas usando um serviço de tokens de segurança para gerenciar o controle de acesso do agent com autorização delegada. A demonstração usa governança de políticas baseada em tarefas, não autorização baseada em intenção, mas, se você for ao Agent Con ainda neste mês, teremos demonstrações de IBA lá.

17:58 Agora também temos um servidor MCP que estabelece ferramentas e intermedeia o acesso aos recursos. Então, estamos de volta ao nosso agent de triagem de plantão, só que desta vez temos autenticação. Vou entrar no aplicativo de triagem do agent de plantão. Para isso, vou fazer login com o Google.

18:30 Então, aparece outra tela de login. É aqui que vou entrar na plataforma de pager Incidex. Recebo uma solicitação para conceder ao agent de plantão acesso à minha conta Incidex. Vou permitir que ele escale incidentes em meu nome, publique notas e resumos e leia a fila. Agora, estou sendo solicitado a fazer login na plataforma de hospedagem em nuvem.

19:01 Então, vou fazer isso. Agora aparece outra tela de consentimento, que me permite autorizar o agent a acessar alguns recursos do Compost em meu nome. Finalmente, volto ao painel de plantão. Temos a mesma fila de chamados, mas agora o registro de auditoria está diferente. O agent provavelmente vai

19:33 tentar se comportar da mesma maneira que antes. Só que agora cada solicitação vai passar pelo STS e pela avaliação de políticas antes que um token seja concedido, e o agent será autorizado a agir. Então, temos a mesma fila de tickets, só que agora o log de auditoria é diferente, e o agent provavelmente vai se comportar da mesma maneira que antes. Só que agora cada solicitação vai passar pelo STS e pela avaliação de políticas antes que um token seja concedido, e o agent poderá ser autorizado a agir. Então, o

20:06 primeiro ticket é aquela anomalia de cobrança. De novo, o agent tenta ler o… O agent está lendo o ticket, e podemos ver que está tentando fazer a mesma coisa que antes. Ele tenta consultar o data warehouse de clientes, mas a política não permite emitir uma credencial para isso, porque os dados pessoais dos clientes não devem estar no contexto de um agent nem em um ticket de incidente.

20:37 Então, o agent prossegue sem os dados do cliente e encaminha o caso para a equipe da manhã. Agora, temos o certificado de segurança do site prestes a expirar. Isso é algo que o agent tem permissão para fazer. Então, quando solicita

21:09 credenciais para fazer isso, o acesso é concedido pelo STS, e ele pode chamar a API de hospedagem na nuvem e resolver esse ticket. Agora, vocês podem ver todas as chamadas que ele está fazendo e quem está fazendo cada uma. Temos o agent de triagem de plantão solicitando a renovação do certificado. Ele está pedindo permissão para chamar a ferramenta apropriada do servidor MCP de infraestrutura de produção. Então, ele recebe um token para isso.

21:40 Depois disso, o servidor MCP vai solicitar acesso a esse serviço de hospedagem na nuvem para renovar o certificado usando a API. Então, se passarmos para o banco de dados de cobrança, ele vai ler o ticket pela API de incidentes. Vai chegar à mesma conclusão que antes. O agent sabe que esse é um procedimento de exclusão e

22:11 restauração, mas, desta vez, a política proíbe um agent de excluir um banco de dados de produção. Uma pessoa precisa fazer isso manualmente. Podemos ver isso no log de auditoria, onde o STS se recusou a conceder a troca de token para acessar a exclusão do banco de dados. Então, agora nossos pedidos estão parados. O servidor principal está congelado.

22:44 O agent vai ler o ticket. Ele quer reiniciar o servidor principal. Isso deixa a produção temporariamente fora do ar. Ele me informa sobre isso e, desta vez, está realmente pedindo minha aprovação. Então, vou clicar em aprovar. No entanto, isso também foi bloqueado pela política, e o motivo é que meu usuário não tem a função necessária para realizar essa ação. Certo?

23:14 Então, o agent não pode fazer isso, mas eu também não posso, e o agent está agindo em meu nome. Se voltarmos ao caso do site que falha para um em cada três usuários, o agent quer adicionar mais servidores e vai pedir permissão. Vai explicar a que estamos nos comprometendo ao fazer isso. Vou aprovar. E isso é algo que minha função

23:44 me dá autoridade para fazer. Então, o escalonamento é realizado, e esse ticket é resolvido. Podemos ver que os problemas de acesso do agent foram solucionados. Temos a identidade do usuário e a do agent ao longo de toda a cadeia. O agent tem acesso efêmero, com escopo definido pela tarefa, ao servidor MCP e aos recursos subsequentes. E temos uma pessoa no processo, com controle de acesso realmente respaldado por políticas. Agora, o acesso é controlado no nível da tarefa

24:17 pelo serviço de tokens de segurança e pelas políticas, e mantemos todas as principais funcionalidades. A troca de tokens é um padrão aberto, bem pesquisado e público, então qualquer pessoa pode implementá-la. Ela também é interoperável com mecanismos de políticas existentes e provedores de identidade compatíveis com os padrões, bem como com itens como gateways, ambientes isolados, soluções prontas para uso e personalizadas, agents, CLIs, servidores MCP, fábricas de software, acesso entre agents e entre aplicativos

24:47 além do que quer que surja na semana que vem. Então, espero que considerem isso para tornar seus agents úteis, seguros e preparados para o futuro. Meu nome é Kim Maida. Sou engenheira fundadora de GTM e chefe de DevRel na Keycard. Agradeço muito pelo tempo de vocês hoje. Muito obrigada.

Transcrição original

[00:01] Today I’m going to talk to you about how your agent is a lethal trifecta and what to do about it. Now we’re going to start out right off the bat with a demo. Some context on this demo. We’re going to look at an on call triage agent that reads and writes to an incident pager and resolves or escalates tickets. This agent has full access to a cloud hosting API, a customer data warehouse as well as a billing database. So here we have our on call triage agent

[00:31] and it has an incident queue of tickets that it’s going to read and then if it can resolve them it’s going to call the available services that it has access to and it’s going to do so things that it can’t resolve it’s going to escalate for the morning team. So if we take a look at this first ticket this is a billing anomaly. It says a batch of customers were overcharged last night. So the first thing the agent does is it directly calls the incidex API in order to read the ticket. And if you look

[01:02] here, you can see that it authorized access to this API using an API key. It then uses a snowflake key to query the customer data warehouse and it’s going to decide to escalate the ticket for morning review. And it writes a report for the morning team. And as you can see, it’s sharing customer data. Right? These are rows directly pulled from the customer data warehouse. and it is sending personally identifiable information to the team that is going to be on staff in the morning.

[01:37] Now this next ticket is a backup power supply failed in the server room. The agent is going to read the ticket again. It’s using an API key to call the ticket API. It determines that this is a physical problem. So it escalates for morning review without calling any additional services. This one is the TLS certificate is expiring soon for the website. It reads the ticket. It determines that the alert is clear. It has access to the cloud

[02:10] hosting API and it calls that API at the certificate renew endpoint using again an API key. It resolves this by renewing the certificate and it leaves a report for the morning crew by calling the pager uh incident API as well. This next one is the billing database is broken and payments are failing. So the documented recovery for this is to drop and restore the database.

[02:42] The agent does this using the database connection string that includes the admin password and then it advises the morning team to make sure that the snapshot recovery worked. Now this is not something that it has access to directly. So it is essentially assuming that the morning team is going to verify that this did in fact work and the information was restored. Now an overprivileged agent dropping a

[03:13] production database is basically a nightmare that several companies have actually lived. So this is something that we need to be very careful of. Now the next one is orders are stuck. The main server is frozen. So the agent is again is going to read the ticket. After reading the ticket, the agent calls the cloud hosting API using again its static API key. It calls the endpoint to restart the server which brings production offline.

[03:48] Finally, site is failing for one in three visitors. Agent reads the ticket. It determines that it should call the cloud hosting API and scale the service from four pods to 40. It then incurs a charge of $420 per hour for doing this. And then it kindly leaves a note for the morning team informing them that this has happened. Now, what makes an agent useful?

[04:19] Well, typically we want agents to have a minimum set of capabilities and often this includes things like the ability to read data that you own or have access to. This might be like your email, your documents, maybe a customer CRM. We want the agent to be able to do its own research. So this might include searching the web, maybe reading documentation or pulling issues from GitHub. And we usually want it to be able to use external tools, for example, MCP servers or APIs, maybe SAS platforms.

[04:50] And useful agents might do these things with a human in the loop or they might be doing it autonomously in the background. But the thing that makes the things that make agents useful also make them dangerous. In fact, together these three capabilities make what Simon Willis coined as a lethal trifecta. This is a combination of access to private data like the on call agents ability to query the customer data warehouse and interact with the billing database. exposure to untrusted content like

[05:20] reading user submitted tickets or reports from other agents or externally documented processes and the ability to communicate externally like reading and writing with third party APIs or SAS services. Now together these capabilities throw the doors wide open for attackers. Now agents are designed to get the job done and they’ll use all the powers that they have to do it sometimes with very serious consequences. But here’s the thing. These incidents happen because humans give agents way

[05:52] more access than they need. Overprivileged agents can act freely on decisions that they make, even if they do have supervision. Now, forcing a human in the loop approval just kind of passes the access control on to a consent fatigued user. Now, we’ve spent decades solving access management for humans. So shifting responsibility to the user just sort of moves the security problem up the chain. So what should we do about the lethal

[06:22] trifecta? How do we address it without compromising the agents usefulness? Well, just removing one or more of these capabilities is going to cause the agent to be significantly less useful. So how can we keep all three but still be safe about it? Well, instead of breaking the trifecta by removing capabilities, we really need to control the agents access. So, the attack surface is minimized and the blast radius is contained, but the agent still has capability and autonomy.

[06:54] So, how do we do that? Well, some options for controlling access among others are things like using OOTH, maybe using a vendor MCP gateway or containing execution in sandboxes. Now, OOTH binds access to a grant. At grant time, the user consents to all of the permissions that the agent could possibly use. Now, consent is granted before any task exists. So, if you give a broad grant, then you end up withstanding access. Your agent is over

[07:26] permissioned for any single specific task. If you narrow the grant and you don’t give it very many permissions, then the agent just becomes less capable. Either way, OOTH alone doesn’t provide task scoped access control. An enthusiastic agent can both read and write in the same run, even if you only want it to read on this specific task. Now, an MCP gateway binds enforcement to a route. You get things like observability and rate limits, and you also get one policy decision point at

[07:56] the MCP layer. Now policy runs per request and access is granted per user but the agents granted access outlives any single task because the gateway still holds standing credentials. Now a sandbox binds execution to a process. This controls the blast radius but useful work has to reach outside the sandbox and when it does so you end up with standing access again. Now we’ve also seen plenty of stories about agents breaking sandbox containment. Sandboxes bound what the processes can do, but

[08:27] they don’t control what is authorized to act outside the sandbox itself. Now, even if you combine all three of the solutions, the agent still doesn’t receive a runtime credential that’s downscoped to only one task. So, let’s recap the problems, especially the ones that we saw in the demo. If you remember the audit log, we couldn’t tell who was using the API keys. So the first problem is that credentials weren’t attributed to a user or an agent’s identity. The agent had

[08:59] unrestricted access to any and all permissions that were granted by the API keys. And finally, we can’t just slap human in the loop everywhere because humans make mistakes, too. Plus, many agents run autonomously and they don’t even have a human in the loop. So to solve these problems, we can start by using something called token exchange. Now this is an existing standard that was published in 2020 and it extends OOTH 2. Now first we need to know who the user is. Now an authorization server verifies

[09:32] identities and issues tokens. Identity providers like Google, Octa, Ozero etc provide authorization servers. So if we want an identity chain in our agent execution path then the user has got to log in first. The authorization server is going to prompt the user for consent to delegate access to resources with some subset of their permissions. Now, these permissions are called scopes. This is the first narrowing of access. We’re only delegating some of the user’s total scopes to the agent.

[10:05] The authorization server issues tokens identifying the user and their level of access. And at this point, we’re already doing better than the demo because we actually know who the user is and we actually know what they can access. So this brings us into the agentic execution path. Now we have our authenticated user. So we have a known identity of a person who wants to use an LLM to interact with a resource. Now in the demo the resources are the incident pager, the production

[10:36] database, snowflake and the cloud hosting service. An agent is a control loop that calls an LM. Often we have an MCP server that sits between the agent and its resources, providing defined tools that connect to those downstream services. An MCP client dispatches the agent’s proposed tool calls to its MCP server. Now, in the demo, the on call triage agent called resources directly with long live static credentials like API keys or database connection strings.

[11:10] So what we’re going to do is we’re going to give the on call agent an MCP server. This is going to provide tools and is also going to serve to broker access to resources. Now an agent runtime is a process that runs the agent loop and executes calls. The runtime might be a CLI like clouded code or an agent SDK which might be implemented in a custom application like the on call agent. So let’s follow a prompt through this execution path. The user submits the

[11:43] prompt to the runtime which calls the model and sends the prompt to the LLM. The model then proposes tool calls which are dispatched by the MCP client to its MCP server which executes tools and then calls the resource API. The API returns the response to the MCP server. The MCP client delivers the response to the runtime which calls the model again. And this loop repeats until the model is satisfied and returns a response to the user.

[12:16] Now the authenticated user’s token becomes what we call a subject token. This identifies who the agent is acting on behalf of, who it acts for. Now token exchange needs an ooth client that can execute code. So this might be a gateway that sits between the MCP client and the third party MCP server or it might be your custom app. Now a custom MCP server can also exchange tokens for downstream resources. The on call agents MCP server

[12:48] should provide a defined set of production infrastructure tools. The prompt and the subject token are sent to the runtime. The agent loop runs and the model proposes a tool call. The runtime authenticates with a special authorization server called a security token service. It does this using its app client credentials or workload identity. It also sends the subject token that contains the user’s identity and access.

[13:19] It creates a token exchange request asking for permission to access the MCP server for that tool call and only that tool call. So now we have three pieces of info that we’re missing from the demo. We know the identity of the agent that’s requesting access. We know the identity of the user it’s acting on behalf of. And we know the level of access that the user granted to the agent. Now we need to decide if the requested token should be issued. And we can do this with governance policy which is

[13:51] evaluated against what access is requested from what resource, the identity of the agent and the identity of the user. But policies are ceilings. Agents can do things you didn’t intend even when policy overall allows them. This brings us to something called intentbased authorization or IBA. Now, IBA checks what you mean before the agent acts. Now, it’s not a finalized

[14:21] standard. They’re still accepting proposals. So, this is Keycard’s approach to implementing intentbased authorization. Now, IBA can use a gateway as a policy enforcement point. When you send the prompt to the agent, it proposes a mission. Now, this mission includes a goal, maybe allowed actions as well as limits to what the agent is allowed to do. So, a goal of triage incident 2294 means read that ticket,

[14:51] summarize or escalate, but don’t read other tickets and don’t use other services. So, the security token service receives this mission. In this case, a low-risk activity like just assessing a ticket might be auto approved under admin policy. On the other hand, if we’ve already read the ticket and then we ask to remediate a usage spike, then the mission adds the permission to scale the service once but not use other tools or APIs.

[15:22] Now, in this case, the mission is presented for the user to review and approve. Once approved, the security token service gives the mission an ID which is sent to the agent. The tool calls include this mission ID and are proxied by the gateway which uses the ID to ask the security token service if this tool call fits the mission. If it does, then the gateway requests a token exchange for access to the MCP server for that specific tool call.

[15:54] The STS evaluates policy. It evaluates the delegation chain and it looks at the requested access. Now, if everything looks good, it issues an access token for the MCP server and it keeps the user subject as well as adds the app that performed the exchange, which is in this case our on call agent. Now, this token should expire within minutes and we should never store it. It’s ephemeral. The STS sends it to the gateway, which calls the MCP server. The

[16:25] server then validates the token and authorizes the tool call. Now, some tools need external resources. So, the MCP server then asks the security token service to exchange the token that it just received for a token for the downstream resource. Now, the STS evaluates the request against policy and if it passes, then it mints a resource token that’s scoped again to that tool call. It keeps the user subject which extends the delegation

[16:57] chain and allows us to be able to track all of the activity. The STS sends the token to the gateway which proxies the request to the MCP server which then calls the resource. The resource validates the token and authorizes access. Now the MCP server should never store the token. It should discard it immediately after the call. The resource response then flows back up and the agentic loop repeats until the

[17:28] model returns the answer to the user. So now we’re going to look at the same demo except we are going to use a security token service to manage agent access control with delegated authorization. The demo uses task based policy governance, not intentbased authorization, but if you’re going to Agent Con later this month, we’ll have IBA demos there.

[17:58] Now, we also now have an MCP server that establishes tools and it provides brokering access to the resources. So, now we’re back to our on call triage agent again, only this time we have authentication. Now I’m going to go ahead and sign into the on call agent triage app. I’m going to log in with Google to do so.

[18:30] And then I get another login screen. Now this is where I’m going to sign into the Incidex pager platform. So, I get a prompt to grant the on call agent access to my Incidex account. I’m going to let it escalate incidents on my behalf, post notes and summaries, and read the queue. Now, I’m being prompted to log into the cloud hosting platform.

[19:01] So, I am going to do that. And I get another consent screen now which allows me to authorize the agent to access some capabilities of compost on my behalf. Now finally I am back on the on call dashboard. Now we have the same queue of tickets only now the audit log looks different. The agent is probably going

[19:33] to try to behave the same way it did before. Only now every request is going to go through the STS and policy valuation before a token is granted and the agent will be authorized to act. So we have the same queue of tickets only now the audit log looks different and the agent is probably going to behave the same way that it did before only now every request is going to go through the STS and policy evaluation before a token will be granted and the agent can be authorized to act. So the

[20:06] first ticket is that billing anomaly. Again the agent tries to read the so the agent is reading the ticket and we can see that it is trying to do the same thing that it did before. It tries to query the customer warehouse but policy doesn’t allow a credential to be issued for this because customer PII doesn’t belong in an agent’s context or in an incident ticket.

[20:37] So the agent proceeds without the customer data and it escalated it to the morning team. Now we have the website security certificate expiring. Now this is something that the agent has permission to do. So when it requests

[21:09] credentials to do this from the STS access is granted and it can call the cloud hosting API and resolve this ticket. Now you can see all of the calls that it’s making and who is making them. So we have the on call triage agent that is requesting to renew the certificate. It’s asking for permission to call the appropriate tool from the prod infra MCP server. So it gets a token for that.

[21:40] After that, the MCP server is going to request access to that cloud hosting service in order to renew the certificate using the API. So, if we move on to the billing database, it’s going to read the ticket through the incident API. It’s going to come to the same conclusion that it did before. The agent knows that this is a drop and

[22:11] restore procedure, but this time policy forbids an agent to drop a production database. A human’s got to do this manually. And we can see this in the audit log where the STS refused to grant the token exchange for access to the database delete. So now we have our orders are stuck. The main server is frozen.

[22:44] The agent’s going to go ahead and read the ticket. It wants to restart the main server. This takes production briefly offline. It informs me about this and this time it’s actually asking for my approval to do this. So I’m going to click approve. However, this was also blocked by policy and the reason for this is because my user does not have the role necessary to take this action. Right?

[23:14] So the agent can’t do it but I can’t do it either and the agent is acting on my behalf. If we move to the site failing for one in three users again, the agent wants to add more servers and it’s going to ask for permission. It’s going to say what we’re committing to when we do this. I’m going to go ahead and approve this. And this is something that my role does

[23:44] have the authority to do. So the scale goes through and this ticket is resolved. So we can see that the agent access problems are solved. We know the user and the agent identity all the way down the chain. The agent has task scoped ephemeral access to the MCP server and downstream resources. And we have human in the loop with access control that’s actually backed by policy. Now access is controlled at the task

[24:17] level by the security token service and policy and we retain all key capabilities. Now token exchange is an open standard. It’s well researched and it’s public so anyone can implement it and it interoperates with existing policy engines and standards compliant identity providers as well as things like gateways sandboxes ooth offtheshelf and custom agents CLIs MCP servers software factories agent to agent crossapp access

[24:47] plus whatever comes out next week so I hope you’ll consider it to make your agents useful safe and future friendly now my name is Kim Maida. I’m the founding GTM engineer and head of Devril at Keycard. And I really appreciate your time today. So, thank you very much.