Quantas credenciais seu agente de IA deve ter? Zero. — Jim Clark, Docker

Autoria: AI Engineer · Assistir no YouTube

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

Idioma original: inglês

Vídeo original: How Many Credentials Should Your AI Agent Have? Zero. — Jim Clark, Docker · Canal: AI Engineer · 17:44 · Assistir no YouTube

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

Resumo

Jim Clark explica como melhorar a segurança de agentes de IA combinando agent harnesses, sandboxes e MCP gateways. A proposta é limitar cada sandbox às ferramentas, aos recursos e ao acesso de rede necessários para a tarefa, reduzindo o raio de impacto de possíveis erros. Ele defende que credenciais não devem ficar dentro do sandbox e apresenta o gateway como ponto central para gerenciar capacidades e acesso. A palestra também aborda o XAA e o uso de identidade corporativa existente para autorizar agentes.

Pontos-chave

Agentes que executam tarefas longas precisam de menos supervisão, mas isso aumenta a importância de limitar o que podem acessar.
O agent harness recebe contexto e aciona ferramentas, mas a segurança depende também dos recursos e das capacidades que chegam até ele.
Sandboxes devem ser moldados conforme a intenção da tarefa, com apenas as ferramentas, os dados e o acesso de rede necessários.
Separar funções em sandboxes — como pesquisa, checagem de fatos e publicação — evita combinar contexto não filtrado com ferramentas de escrita.
Um MCP gateway centraliza o controle de ferramentas, recursos e prompts disponibilizados a cada sandbox.
Os harnesses podem se tornar agnósticos a MCP quando as integrações são gerenciadas pelo gateway.
A recomendação de Clark é manter zero credenciais dentro do sandbox e gerenciar o acesso por meio do gateway.
A divulgação progressiva de capacidades ajuda a limitar o contexto e os recursos disponíveis em cada etapa do workflow.

Capítulos

Início	Capítulo	Resumo
00:01	Agentes, supervisão e segurança	Clark apresenta o tema e explica por que agentes que executam tarefas mais longas exigem atenção à segurança.
02:07	Harnesses, MCP e sandboxes	Ele descreve a função dos harnesses, o papel do MCP e a necessidade de limitar os recursos disponíveis aos agentes.
05:47	Separar tarefas em sandboxes	Com exemplos de uma redação e de um agente de programação, Clark mostra como separar funções e conceder acesso conforme a intenção.
10:25	MCP gateway e gestão de credenciais	A palestra apresenta o gateway como ponto de controle para capacidades, integrações MCP e acesso sem credenciais dentro do sandbox.
14:04	Divulgação progressiva e conclusão	Clark relaciona a divulgação progressiva de capacidades à redução de contexto e ao uso de sandboxes mais seguros, e encerra com uma demonstração do sbx.

Citações

Quantas credenciais devem estar em um sandbox? A resposta certa é sempre zero. — 12:01

Se não vou fazer um commit, não quero minhas chaves de assinatura de commit dentro daquele sandbox. — 09:24

Deixe os agentes resolverem problemas, mas faça cada sandbox representar a intenção da tarefa. — 14:35

A segurança vem de conceder menos acesso a cada ciclo do que o workflow inteiro teria. — 16:08

Conceitos e entidades

Jim Clark (pessoa): Engenheiro da Docker que apresenta a palestra sobre segurança de agentes de IA.
Docker (empresa): Empresa onde Jim Clark trabalha e cujo produto de sandbox é mencionado na palestra.
agent harness (conceito): Camada que recebe contexto e solicita ações por meio de ferramentas.
sandbox (conceito): Ambiente isolado cujas capacidades devem ser limitadas ao necessário para uma tarefa.
MCP gateway (ferramenta): Ponto central que encaminha o tráfego MCP e controla ferramentas, recursos e prompts disponíveis aos sandboxes.
MCP (conceito): Protocolo mencionado como meio de fornecer ferramentas e contexto aos agentes.
XAA (conceito): Abordagem descrita na palestra para conectar agentes a recursos corporativos usando identidade e autorização existentes.
Claude Code (ferramenta): Ferramenta que Clark diz ter usado para preparar a apresentação.
Codex (modelo): Modelo que Clark afirma ter usado na preparação da apresentação.

Tradução completa (pt-BR)

00:01 [música] >> Acho que estou pronto para começar. Todo mundo consegue… Eu consigo me ouvir. É, então vocês conseguem me ouvir. Meu nome é Jim. Sou engenheiro na Docker. Normalmente, quando me apresento nos slides hoje em dia, ou pelo menos quando costumava fazer isso, eu dizia:

00:31 Eu dizia: “Oi, sou Jim. Gosto de espaços, não de tabulações. Uso Neovim, não Emacs.” Mas isso tudo é irrelevante agora. Então, vou dizer que fiz este slide com… fiz esta apresentação com Claude Code. Usei o modelo Codex. Os MCPs que me ajudaram a escrever estes slides foram Marp e Mermaid. E vou falar com vocês sobre gateways de MCP. Mas, na verdade, vou falar sobre

01:01 segurança de IA. Então, vou passar por caixas de areia, gateways, harnesses e explicar por que estamos falando de segurança de IA na Docker agora. Os últimos seis meses provavelmente foram parecidos para todos vocês, assim como foram para mim. Os agents estão fazendo muito mais do que eu achava que faziam, muito mais do que eu achava que fariam. E não vou mais ficar sentado na frente do meu laptop dizendo: “Sim. Sim. Sim. Sim.”

01:35 Eles estão fazendo coisas que levam mais tempo, e eu gosto disso. E, à medida que me acostumo cada vez mais a deixá-los fazer coisas que levam mais tempo, acabo decidindo que meu critério para saber se projetei um problema no qual um agent pode se aprofundar é não precisar supervisioná-lo muito. Mas, se não vou supervisioná-lo, talvez também fique um pouco preocupado com o que ele vai aprontar. Então, só para contextualizar, isto é

02:07 o que acho que é o formato do problema neste momento. Precisamos falar sobre agent harnesses, sobre o que os agent harnesses fazem por nós. Precisamos falar sobre caixas de areia. Quando um agent harness entrega trabalho, em que ele o entrega? E, claro, temos os MCPs, que todo mundo conhece, e vamos falar um pouco mais sobre o que estamos fazendo nessa área. Mas vamos começar pelo agent harness. Então,

02:38 quero dizer, seria uma simplificação dizer que um agent harness é algo que recebe contexto e emite chamadas de ferramentas. Mas há um pouco de verdade nisso também. Essa não é a parte mais complexa. É um loop que recebe algum contexto que você fornece e pede para fazer algo em seu nome. Mas, por trás dessa simplicidade, vemos que todos estamos usando vários harnesses diferentes. E a capacidade de… por que será que

03:10 estamos sempre adotando harnesses diferentes? Gostamos das novas possibilidades interativas que eles nos oferecem. Então, vamos admitir desde o começo: vamos usar muitos harnesses. Eles vão evoluir bem rápido. Vamos substituir uns harnesses por outros. Mas um harness, sozinho, fica meio que numa sala vazia. Tipo: “Alô, alguém me dê algum contexto. Alguém me dê algo para fazer.” É aí, claro, que entram os MCPs.

03:42 Os MCPs nos permitem fazer coisas novas. Eles nos permitem sair do nosso próprio espaço, trazer contexto novo, trazer ferramentas novas e realizar trabalho de verdade. Então, quando se está pensando em segurança, não acho que seja uma simplificação dizer que uma das coisas que precisamos fazer é descobrir quais recursos são necessários para realizar o trabalho. Como sempre, até para nós, uma das primeiras coisas que analisaríamos ao querer

04:13 realizar uma tarefa nova é: do que preciso para concluí-la? De quais informações preciso? De quais ferramentas preciso para realmente concluí-la? E, se você soubesse que a caixa de areia que criou tinha os recursos certos, as ferramentas certas e somente esses recursos e ferramentas, isso faria você se sentir mais seguro. Você sentiria que limitou o raio de impacto caso algo desse errado enquanto aquele agent estivesse trabalhando. É aí que entram as caixas de areia. Uma caixa de areia é um lugar para um agent trabalhar, para

04:45 trabalhar. Hoje, a maioria de nós está acostumada com as caixas de areia de código. Damos a ele… damos um monte de código. Damos a ele todas as ferramentas do nosso laptop. Talvez, quando você começou a usar alguns desses agents, a caixa de areia fosse o seu laptop inteiro. Com o tempo, estamos começando a aprender a reduzi-la um pouco. Estamos tentando deixar os limites da caixa de areia pequenos o bastante

05:15 para que eles possam fazer apenas a tarefa que queremos que executem. Isso nos ajuda a nos sentir mais seguros para deixar o agent rodar por períodos mais longos, se a caixa de areia for um pouco menor. E, sabe, não estamos tentando colocar o próprio harness numa caixa de areia. O harness já está meio que isolado. É algo bem simples. Estamos tentando controlar as ferramentas e o contexto que entram nesse harness.

05:47 Então, para ilustrar alguns desses conceitos, criei duas histórias pelas quais vou guiar vocês. A primeira é uma analogia com uma redação. Um repórter de jornal sai pelo mundo, encontra histórias interessantes, encontra informações interessantes e as traz de volta. Talvez alguém dentro da agência faça uma checagem dos fatos, garanta que as informações estejam corretas e, então, você escreva uma matéria. É totalmente natural que essas funções

06:20 sejam completamente separadas. O repórter propriamente dito não vai ter permissão para publicar no site nem para escrever a matéria em si. Separamos essas funções. É assim que já construímos sistemas complexos. Dividimos tudo em partes pequenas. Então, neste slide, o que vocês veem é que dividi três caixas de areia, destacadas em azul. Temos um pesquisador, um verificador de fatos e um repórter. Essa caixa de areia do pesquisador, acho que eu…

06:50 penso nela como a do repórter. Ao definirmos essa caixa de areia, permitimos que acesse a web. Permitimos que acesse o máximo possível da internet, porque não vamos dar a ele MCPs que permitam escrever no nosso site corporativo. Ele não pode publicar nada. Vamos apenas deixá-lo… vamos deixá-lo sair, fazer o que quiser e pesquisar. Então, nossa caixa de areia é tipo: “É, poucas ferramentas. Não vou dar muito acesso de escrita, mas pode fazer bastante pesquisa. É só escrever sua pesquisa num… não sei, num diretório temporário, em algum lugar privado e local a este agent.”

07:22 Um verificador de fatos vai precisar de alguns MCPs, mas não vai precisar de acesso à rede. Então, vamos iniciar o verificador de fatos. Vamos colocá-lo numa caixa de areia diferente. Sem acesso à rede. É, e você pode ler a pesquisa que foi feita para você e verificar os fatos. E pode acessar nosso banco de dados de fatos. Sabe, filtre isso. E, por fim, chegamos à pequena coisa azul à direita.

07:53 E isso certamente não precisa de acesso à rede. Na verdade, não deveria ter nenhum, mas queremos dar a ele nosso MCP do Notion ou nosso MCP de publicação, porque ele só está vendo a pesquisa filtrada. Então, olhem para o slide inteiro e desenhem um retângulo em volta dele. Esse agent efetivo tem vários MCPs. Talvez tenha um MCP para publicação, tenha um MCP para checagem de fatos. Em determinado momento, ele tem acesso à internet inteira.

08:23 Mas dividimos tudo em caixas de areia lógicas, para que, em cada ponto específico, não tenhamos uma combinação perigosa: poder ler contexto maluco e não filtrado e fazer coisas com nossas ferramentas. Então, vamos ver o exemplo número dois. E vou falar sobre… na verdade, é assim que eu construo meu agent de programação atualmente. Costumo enviar

08:54 deixar o agente de programação executar tarefas bastante longas. Digamos que elas durem cerca de uma hora. Mas, enquanto o trabalho está acontecendo, também gosto que ele faça commits ao longo do caminho. Só que a parcela do tempo em que meu agente está de fato fazendo commits é quase nenhuma. Em uma hora, talvez ele precise das minhas chaves de assinatura do Git por, digamos, dois minutos.

09:24 E, quando estou fazendo um commit, preciso ver a árvore de commits do Git. Preciso fazer esse commit. Preciso de algumas chaves de assinatura, mas não preciso de mais nada. Então, gostaria que o sandbox em que um agent executa uma tarefa fosse modelado de acordo com a intenção do que estou fazendo. Se não vou fazer um commit, não quero minhas assinaturas de commit nem minhas chaves de assinatura de commit dentro desse sandbox. E acho que dá para aplicar isso a

09:55 muitas tarefas diferentes. Se você sabe — se seus agents sabem — qual é a intenção do que você está tentando fazer, use essa intenção para modelar as capacidades que você concede a eles. Isso está orientando o desenvolvimento do nosso produto de sandbox da Docker; está definindo boa parte da nossa maneira de pensar sobre como expor coisas como um gateway MCP. Então, quando você cria um sandbox, é claro que precisa colocar um harness nele para fazer coisas por você. E aí nós simplesmente

10:25 colocamos nele um pequeno endpoint de gateway. Esse endpoint de gateway direciona todo o tráfego MCP. Imagine algo como um URL interno do MCP, mcp.gateway.docker.internal, ou algo assim, que todo agent harness tenha. Todo o tráfego, todos os recursos que você precisa buscar e todas as chamadas de ferramentas passam por esse único gateway.

10:57 Então, o que isso nos proporciona? Bem, acabamos com um ponto de controle. O gateway gerencia quais ferramentas, recursos e prompts são fornecidos a cada sandbox. Assim, começam a surgir as possibilidades de você dizer: “Certo, estou fornecendo um harness. Estou fornecendo este endpoint de gateway. O gateway — a configuração do sandbox — controla o que você pode fazer dentro desse sandbox com coisas como MCP.” Outra vantagem é que, de repente, todos os seus harnesses são agnósticos em relação ao MCP.

11:29 Então, você não precisa ir ao Codex e configurar seus MCPs de um jeito e ir ao Claude Code e configurar seus MCPs de outro. Você só tem um — é quase como tornar o harness um parâmetro do sandbox. Coloque um harness, coloque os MCPs de que precisa, defina algumas regras de rede e pronto. Então, parece que o MCP é um bom lugar para gerenciar coisas como credenciais. Na verdade, eu diria que uma máxima que você pode aplicar aqui é: quantas

12:01 credenciais devem estar em um sandbox? Bem, quero dizer, a resposta certa é sempre zero. Elas simplesmente nunca deveriam estar lá. E o raio de impacto de um agent que faz algo errado — que vai lá e faz algo incorreto — é reduzido se não houver absolutamente nenhuma credencial lá dentro. Então, uma das coisas em que Docker, Entropic e Octo estão trabalhando juntos é uma novidade chamada XAA, aplicação entre apps.

12:32 E acho que isso ilustra muito bem por que os sandboxes e o gerenciamento de credenciais dessa maneira são importantes. Hoje, nas empresas em que vocês trabalham, vocês têm algum tipo de gerenciamento de identidade, têm SSO configurado e têm todos esses servidores de recursos que gerenciam os serviços que vocês usam com OAuth. Pode ser Notion, Atlassian, GitHub ou Slack.

13:03 Vocês já configuraram o SSO para esses serviços. Mas ele ainda não está acessível ao seu agent. Então, em um cenário de aplicação entre apps, seu harness, seu sandbox e seu gateway podem definir coisas como a identidade do agent, ou seja, em nome de quem esse agent está agindo. E, ao estender isso e trocar declarações de identidade com seu provedor de identidade,

13:33 que já existe, vocês podem receber algo novo: uma nova parte dessa especificação que agora verão na versão mais recente do MCP, chamada ID grant, uma concessão de autorização. Com essa concessão de autorização, estamos concedendo acesso a esse ator, a esse agent, aos mesmos servidores de autorização que vocês já vêm usando. Não há nada de novo aqui. Estamos aproveitando todo esse investimento existente que as redes corporativas já têm, mas, de repente, sem aquelas telas malucas de consentimento, sim, dá para fazer isso.

14:04 Sim, dá para fazer isso. Sim, dá para fazer isso. Podemos centralizar a administração do que um agent passa a fazer com todos esses servidores de recursos existentes. É ótimo. É uma simplificação enorme. Gosto de pensar que os gateways MCP estão começando a usar a divulgação progressiva, um termo que aprendemos com skills. Gosto de pensar que agora estamos começando a usar isso: podemos divulgar progressivamente

14:35 ferramentas, recursos e MCPs nesses sandboxes, usando princípios muito parecidos. E, claro, isso é incrível porque mantemos o tamanho do contexto baixo. Só porque talvez você use 50 MCPs diferentes em algum momento de um workflow não significa que cada sandbox precise ter todos esses 50 MCPs. Dê aos seus agents espaço para resolver problemas, mas faça com que cada sandbox represente a intenção da tarefa. Faça com que ele represente o que você está realmente tentando

15:05 fazer nessa tarefa. Gosto desta imagem porque, de repente, começamos a pensar que uma das funções dos orquestradores é perguntar: “Bem, o que estou fazendo? Qual é a minha tarefa? E preciso colocar uma tarefa em um sandbox. Então, em qual sandbox devo colocá-la? De quais capacidades ela precisa? E, claro, precisa de um harness. O que você coloca nele? OpenCode? Claude? Gemini? Codex? Vai precisar de alguns MCPs. Dê uma

15:36 olhada na tarefa e decida quais MCPs podem ser usados nela. Que regras de rede você deve aplicar? Ela precisa acessar api.github.com? Precisa navegar pela web de maneiras aleatórias? Ou não precisa de nada? De quais recursos? Quais árvores de trabalho? Estamos nos acostumando a pensar em como modelar capacidades, criar o sandbox certo para a tarefa e colocar a tarefa nele. E agora começamos a ver que esse loop individual é mais seguro porque tem

16:08 menos acesso do que o workflow inteiro, na prática. Então, isso é sobre containers. É sobre colocar agents em containers, e acho que é por isso que estamos aqui — que eu estou na Docker. Mas isso se conecta como uma espécie de separação de funções. Quais são as funções que seus agents desempenham? Como mapeá-las, colocá-las em containers e garantir que você esteja fornecendo sandboxes que expressem essa intenção? Nunca tenha credenciais em nenhum lugar, em nenhum

16:40 harness. Divulgue capacidades progressivamente aos agents, conforme eles precisarem delas. Os sandboxes são o que de fato representa a intenção. E, se permitirmos que algumas dessas coisas sejam executadas por mais tempo, mas com mais isolamento, ficamos um pouco mais tranquilos. É daí que vem a segurança. Então, temos uma demonstração. Nosso vice-presidente executivo de engenharia, Tushar Jain, vai falar lá em cima hoje. Acho que é às

17:11 16h, e ele está pegando muitas dessas ideias e fazendo demonstrações, demonstrações, demonstrações. Como mover sandboxes para a nuvem? Como criar orquestradores? Ele vai mostrar muitas dessas coisas ao vivo. Também temos um estande aqui. É uma ótima oportunidade para passar lá se você tiver interesse em qualquer uma dessas coisas. Podemos mostrar a CLI disponível hoje. Qualquer pessoa pode instalar com brew install sbx. Tudo de que falei hoje está nesta ferramenta, sbx. É assim que criamos containers. Então, por favor,

17:44 por favor, venham conversar conosco no estande. Adoraríamos saber o que vocês estão fazendo com segurança de IA e como poderíamos ajudar. Muito obrigado. >> [aplausos] [música]

Transcrição original

[00:01] [music] >> I guess I’m ready to start. Uh can everyone can I I actually I can hear myself. Yeah, so you guys can hear me. Uh my name’s Jim. Uh I’m a engineer at Docker. Normally when I introduce myself in the slides these days, or at least what I used to do, was

[00:31] I would say, “Hey, I’m Jim. I uh like spaces, not tabs. I use Neovim, not Emacs.” But, that’s uh all irrelevant now. So, uh I will say that I made this slide with uh I made this presentation with Claude Code. I used the Codex model. The MCPs that I that helped me write these slides were Marp and uh Mermaid. And I’m going to talk to you about MCP Gateways. But, I’m really going to be

[01:01] talking to you about AI safety. So, I’m going to kind of go through sandboxes, gateways, harnesses, and sort of motivate why we’re talking about AI safety at Docker right now. So, like probably the last 6 months has been similar for all of you as it’s been for me. Agents are doing way more than I thought they were doing uh than I thought they were going to do. And I’m no longer going to sit in front of my laptop and say, “Yes. Yes. Yes. Yes.”

[01:35] They’re doing longer running things, and I like that. And as I get more and more accustomed to them doing longer running things, I sort of decide that my metric for me having designed a problem that an agent can sink its teeth into is that I don’t really need to give it a lot of supervision. But if I’m not going to supervise it, maybe I’m also a little bit worried about what it’s going to get up to. So I think just to set context, this is

[02:07] what I think is so the sort of shape of the problem right now. We need to talk about agent harnesses, what the what the agent harnesses do for us. We need to talk about sandboxes. Like when a agent harness delivers work, what is the what is the thing it delivers work into? And then of course we’ve got MCPs, which which everybody knows, and we’ll talk a little bit more about what we’re doing there. But let’s start with the agent harness. So

[02:38] I I mean it’s it would be an oversimplification to say that an agent harness is something which just takes in context and emits tool calls. But there’s also a little bit of truth to that. It’s not the most complex part of it. It’s a loop that takes in some context that you give it and asks you to do something on its behalf. But belaying that simplicity, we get we’re all using a lot of different harnesses. And the inter the ability to why why do

[03:10] we pick up different harnesses all the time? Like we love the new sort of interactive interactive possibilities that they bring us. So let’s just admit right from the beginning, we’re going to be using a lot of harnesses. They’re going to evolve pretty quickly. We’re going to be swapping in different harnesses for one another. But a harness by itself is just kind of in a little bit of a dead room. Like uh hello, someone give me some context. Some somebody give me something to do. This is where this is of course where MCPs come in.

[03:42] MCPs allow us to do new things. They allow us to go outside of ourselves, pull in new context, pull in new tools, and and get actual work done. So, I think it’s when you’re trying to think about safety, I don’t think it’s an oversimplification to say that one of the things that you need to do is figure out what are the resources that you need to do your job. Like anytime, even for us, one of the first things you’d analyze when you want

[04:13] to do a new task is what do I need to get this tasks done? What information do I need? What tools do I need to actually get this done? And if you knew that the sandbox that you built had the right resources, had the right tools, and only the right those resources and tools, it would make you feel safer. It would make you feel like you limited the blast radius for what could go wrong when that agent is working. So, this is kind of where sandboxes come in. Sandbox is a place for an agent to do to

[04:45] do work. So, our typical sandboxes today, you’re most of us are accustomed to the Yeah, we have code sandboxes. We give it We give it a bunch of code. We give it all the tools on our laptop. Maybe like when you first started using some of these agents, the sandbox was your entire laptop. As over time, we’re starting to learn how to get that a bit smaller. We’re trying to make the sandbox boundaries small enough

[05:15] that they can actually just do the task that we want to do want them to execute. That helps us feel safer about letting the agent run for longer periods of time if this if the sandboxes is a little is is is smaller. And you know, it’s not that we’re trying to sandbox the harness itself. The harness is kind of already sandboxed. Like it’s a it’s a pretty simple thing. We’re trying to harness the tools and the context that are flowing into this harness.

[05:47] So, in order to kind of illustrate some of these concepts, I came up with two stories that I’m I’m just going to walk you through. The first one is um a newsroom analogy. So, if you’ve got a newspaper reporter, they go out in the world, they find cool stories, find cool information, they bring it back. Maybe someone inside of that agent agency uh look it does some fact-checking on that, make sure the information is right, and then you write a story. It’s totally natural that those roles

[06:20] are completely separate. The actual reporter is not going to be allowed to like publish to the website or or or write write the actual article. We we break those up. That’s actually how we already build complicated systems. We split them up into little pieces. So, on this slide, what you see is I’ve broken down three sandboxes in blue here. So, we’ve got a researcher, we’ve got a fact-checker, and we’ve got a reporter. So, that researcher sandbox, I think I

[06:50] think about that as the reporter. Now, when we define that sandbox, let it access the web. Let it access as much of the as much of the internet as we want because we’re not going to give it the MCPs that it can like write to our our corporate site. It can’t publish anything. We’re just going to let it do we’re just going to let it go out, go crazy, do research. So, our sandbox is like, “Yeah, not too many tools. I’m not going to give you too much write access, but definitely do lots of research. Just write your

[07:22] research out to a I don’t know, to some temp directory, some private thing that is local to this agent.” A fact-checker is going to need some MCPs, but it’s not going to need any network. So, then let’s start the fact-checker up. Let’s put that in a different sandbox. Let’s say no network. Yeah, and you can read the research that’s been done for you, and you can fact-check it. And you can have access to our our fact database. You know, filter that out. And then finally, we get to the little blue thing on the right.

[07:53] And this certainly doesn’t need any any access to networks. In fact, it shouldn’t have any, but we do want to give it our notion MCP or our publisher MCP because it’s just looking at filtered research. So, you know, look at this whole slide, draw a box around this entire slide, and that effective agent has a bunch of MCPs. Maybe it has an MCP for publishing, it has an MCP for fact-checking. At one point in time, it has access to the entire internet.

[08:23] But we break it up into logical sandboxes, so at each individual point, we have a don’t have a dangerous concept a dangerous combination of both being able to read in crazy unfiltered context and do things with our tools. So, let’s look at example number two. And I’m just going to talk about uh building a Actually, this is how I I build my coding agent right now. I tend to send

[08:54] the the coding agent off to do pretty long-running tasks. And let’s just say that they work for about an hour. But as the as the work is happening, I also like it if it just does commits along the way. But the ratio of the amount of time that it’s my agent is actually committing is almost nothing. In an In an hour, it might be it might need, say, my my my Git signing keys for like 2 minutes of that time.

[09:24] And when I’m committing, I need to see my my Git commit tree. I need to make that commit. I need some signing keys, but I don’t need anything else. So, I would like it if the actual sandbox that an agent is running a task in is modeled after the intent of what I’m doing. So, if I’m not going to make a commit, I don’t want my commit signatures, my commit signing keys inside that sandbox. And I think this this you can map across

[09:55] a lot of different tasks. If you know the if your agents know the intent of what you’re trying to do, then use that intent to model the capabilities that you give to that. So, this is driving in in our our Docker sandbox product, this is defining a lot of how we’re thinking about exposing things like an MCP gateway. So, when you build a sandbox, of course you have to put a harness in in that to do things for you. And then we’re just

[10:25] putting a little gateway endpoint into that. And that gateway endpoint funnels all MCP traffic. So, imagine it’s something like MCP an internal an an internal URL mcp.gateway.docker.internal or something like this that every single agent harness has and all traffic, all resources that you need to pull in, all tool calls move through this one this one single gateway.

[10:57] So, what does this buy us? Well, we end up with a control point. So, the gateway manages which tools, resources, and prompts are given to each sandbox. So, you’re starting to see the beginnings of your ability to say, “Okay, I’m giving you a harness. I’m giving you this gateway endpoint. The gateway this the configuration of the sandbox controls what you can do inside of that sandbox with things like MCP.” Another nice thing is suddenly all your harnesses are MCP agnostic.

[11:29] So, you don’t have to go to codex and configure your MCPs one way and go to uh cloud code and configure your MCPs one way. You just have one you almost make the harness a parameter of the sandbox. Stick a harness in, stick the MCPs you need in, give it some network rules, Bob’s your uncle. So it’s it feels the MCP MCP is is a good place to manage things like credentials. In fact, I would say that a maxim that you can use here is how many

[12:01] credentials should be in uh a sandbox. Well, I mean the the the right answer is always zero. It just they should just never be in there. And the blast radius of an agent going doing something going going uh doing something incorrect, if there are absolutely no no credentials in there, is is reduced. So one of the things that um Docker, Entropic, Octo are all partnering on is a is a new thing called XAA, cross app

[12:32] application. And I think this is a really great illustration of why sandboxes and um and managing credentials in this way is important. So today in your well you’re you’re working at at at your companies, you have some sort of identity management, you have SSO set up, and you’ve got all these resource servers that that manage that that that you work with for OAuth. It could be Notion or it could be Atlassian or GitHub or Slack.

[13:03] They’re you’ve already configured SSO for those. But it’s not yet accessible to your agent. So with a cross app application scenario, your harness, your your your sandbox, and your gateway can define things like agent identity or who are you that this agent is behaving on behalf of? And by extension by exchanging identity claims with your identity provider,

[13:33] which is already there, you can get back a new thing, which is a new part of this spec that you you’ll now see in the latest version of MCP, called an ID jag, an authorization grant. And with that authorization grant, we’re granting access to this act to the to this actor to this agent to the same authorization servers that you’ve been using. There’s nothing new here. We’re not We’re leveraging all this existing investment that these corporate internet corporate networks

[14:04] already have, but suddenly, without any crazy consent screens, yeah, you can do that. Yeah, you do that. Yeah, you can do that. We can centralize the administration of what an agent now does with all these existing resource servers. It’s a great It’s a huge simplification. So, the MCP gateways, I like to think are we’re starting to talk about progressive disclosure, which is a term we learned from from skills. I like to think we’re starting to use this now we’re able to progressively disclose

[14:35] tools and resources and MCPs into these sandboxes using very, very similar principles. And of course, it’s amazing because we keep contact size down. Just because you might at some point in a workflow use 50 different MCPs, doesn’t mean that each sandbox has to have all 50 of those MCPs. Give your agents room to solve problems, but let individual sandboxes represent the intent of the task. Let them represent what you’re actually trying to

[15:05] do in this task. So, I like this picture because suddenly we start to think about orchestrators as one of their jobs is to go, “Well, what am I doing? What’s my task? And I need to put a task into a sandbox. So, what sandbox do I put it in? What capabilities does this need? And of course, it needs a harness. Like, what do you put in? Open code? Put in Claude? Put in Gemini? Put in Codex? It’s going to need some MCPs. Take a

[15:36] look at the task, decide what MCPs are allowed to be used in this. Um what networking rules should you apply? Does this need access to api.github.com? Does it need access to surf the web in in in random ways? Or does it just need nothing? What resources? What work trees? We get used to thinking about modeling capabilities, building the right sandbox for the task, putting the task in, and now we’re starting to see that this individual loop is safer because it has

[16:08] less access than the entire workflow effectively has. So, this is um this is about containers. This is about containerizing agents, which is why uh I guess this is why we’re at I’m I’m at Docker. But this ties together as a kind of like role separation. What are the roles that you that your agents have? How do you map them and containerize them and and make sure that you’re giving them sandboxes that express that intent. Never have any any creds anywhere in any

[16:40] in any harnesses. Disclose capabilities progressively into agents as they need them. The sandboxes for you are are are what actually represent intent. And if we allow some of these things to run longer, but they’re more sandboxed, we feel a little bit safer about that. That’s this is where safety comes from. So, we have a demo. Our our EVP of of engineering, Tushar Jain, is I got to talk upstairs today. I think it’s at

[17:11] 4:00, and he’s taking a lot of these ideas and just demo demo demo. How do you make move sandboxes to the cloud? How do you build orchestrators? He’ll be really showing a lot of these things live. We also have a booth over here. Um it’s a great opportunity to come over if you’re interested in any of this stuff. We can show you the command line that’s available today. Anyone uh just brew install sbx. That Everything I’ve been talking about today is this tool sbx. This is This is how we build we build containers. Um so yeah, please

[17:44] please uh please come over and talk to us at the booth. We’d uh we’d love to hear what you’re uh what you’re doing with AI safety and how we might be able to help. But uh thank you very much. >> [applause] [music]