Jim Clark, principal software engineer at Docker, discusses AI agent safety through sandboxing. As agents run longer and unsupervised, he argues safety comes from controlling what context and tools flow into agent harnesses, not from the harness loop itself. Through two examples — a newsroom workflow split into researcher, fact-checker, and publisher sandboxes, and a coding agent that only receives signing keys when committing — he shows how to model each sandbox on the task's intent. He explains why the right number of credentials in a sandbox is zero, how a single MCP gateway endpoint per sandbox provides a control point and makes harnesses interchangeable, and how Cross App Access (XAA) with Okta lets agents use existing SSO. Recorded at the AI Engineer World's Fair 2026 in San Francisco. # Channel Presentation Observations ## Source Scope - **Evidence base:** One video, its title, and its transcript. No curated metadata was supplied. - **Format:** A recorded conference talk, with audience-facing address and applause at the end. - **Limit:** These observations describe this video only and do not support channel-wide conclusions. ## Explicit Self-Description These are statements the speaker makes about himself or his work. - **Identity and role:** > "Uh my name's Jim. Uh I'm a engineer at Docker." - **Tooling disclosure:** The speaker states how the slides were produced: > "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." - **Self-introduction joke:** He describes a former introduction style and calls it outdated: > "I like spaces, not tabs. I use Neovim, not Emacs." … "But, that's uh all irrelevant now." - **Personal workflow claim:** He describes how he works with agents: > "I'm no longer going to sit in front of my laptop and say, 'Yes. Yes. Yes. Yes.'" ## Claimed Scope - **Stated topic versus actual focus:** > "I'm going to talk to you about MCP Gateways. But, I'm really going to be talking to you about AI safety." - **Announced outline:** Harnesses, sandboxes, and gateways, framed as the "shape of the problem right now." - **Organizing thesis (stated as his view):** > "The sandboxes for you are are are what actually represent intent. … That's this is where safety comes from." ## Intended Audience (as Addressed) - **Practitioners who use AI agents:** > "probably the last 6 months has been similar for all of you as it's been for me." - **Conference attendees:** Opening address to "everyone," followed by an invitation to visit the booth and a referenced session "upstairs" at 4:00. - **Assumed familiarity:** Terms such as "harness," "MCP," "OAuth," "SSO," and "progressive disclosure" are used without definition, which suggests an existing technical audience. ## Demonstrated Presentation Patterns These patterns are observable in the transcript itself. - **Analogy-driven explanation:** A newsroom model (researcher, fact-checker, publisher) maps sandboxes to roles. - **Worked example:** A long-running coding agent that needs commit-signing keys for only "about 2 minutes" of an hour-long task. - **Repeated maxim:** > "how many credentials should be in uh a sandbox. Well, I mean the the right answer is always zero." - **Hedged, conversational delivery:** Frequent use of "I think," "I like," and "maybe," with personal anecdotes. - **Product linkage:** - Docker's sandbox product is presented as the basis for the ideas discussed: "Everything I've been talking about today is this tool sbx." - The viewer is given an install command: "brew install sbx." - The booth and a demo by an EVP are promoted. - **Partner references:** Docker, "Entropic," and "Octo" are named as partners on a cross-app access initiative. These names appear as transcribed and may be speech-recognition errors. ## Creator Claims Versus Material Shown | Category | Observation | |---|---| | **Stated as claim** | Smaller sandboxes "reduced" blast radius and "make you feel safer." | | **Stated as claim** | Agents are "doing way more than I thought they were doing." | | **Demonstrated in transcript** | The newsroom and commit-key examples are verbal illustrations. No code, configuration, or live output appears in the transcript. | | **Promotional context** | The talk closes by directing viewers to a product and booth, which the speaker presents as an invitation to discuss "how we might be able to help." | ## Limitations - The transcript contains apparent speech-recognition artifacts (for example, "Entropic," "Octo," and repeated words), so proper nouns and some phrasing should be treated as provisional. - All observations are limited to this single talk and do not establish a pattern across any broader channel or speaker history. # Delivery Observation — Jim Clark, Docker ## Overall Communication Style The delivery is **conversational and self-narrating**, marked by frequent mid-sentence self-corrections and verbal hedging. It reads like an engineer thinking aloud on stage rather than a polished keynote. > "Uh my name's Jim. Uh I'm a engineer at Docker." > "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." ## Recurring Linguistic Patterns - **Repeated framing question**: "How many credentials should be in uh a sandbox. Well, I mean the the the right answer is always zero." (echoes the talk title; also "Never have any any creds anywhere") - **Self-deprecating simplification device** — used at least twice, nearly symmetrically: > "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." > "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..." - **Emphatic repetitions for emphasis**, often spoken as stutter-repetition: > "Let it go out, go crazy, do research." > "yes, you can do that. Yeah, you do that. Yeah, you can do that." > "demo demo demo" - **Casual idioms as connectors**: > "Stick a harness in, stick the MCPs you need in, give it some network rules, Bob's your uncle." ## Teaching Habits - **Concrete analogy-first instruction.** The core concept is explained through a **newsroom analogy** (researcher → fact-checker → reporter) before any product content appears: > "The actual reporter is not going to be allowed to like publish to the website... We we break those up. That's actually how we already build complicated systems." - **Personified systems.** The harness is given a voice: *"a harness by itself is just kind of in a little bit of a dead room. Like uh hello, someone give me some context."* - **Question-driven scaffolding.** Many slides are introduced as questions: *"what sandbox do I put it in? What capabilities does this need?... Does it need access to api.github.com?"* - **Repetitive recapping.** The same thesis — model the sandbox on task intent — restated multiple times: *"the actual sandbox... is modeled after the intent of what I'm doing"* and later *"let individual sandboxes represent the intent of the task."* - **Direct personal experience as evidence**: "this is how I I build my coding agent right now," including a specific numeric breakdown (Git signing keys needed for "like 2 minutes" of an hour-long task). ## Vocabulary and Register - Consistent jargon set: **sandbox, harness, gateway, blast radius, MCP, progressive disclosure, intent, capabilities** — "blast radius" recurs: *"you limited the blast radius for what could go wrong."* - Informal, first-person register throughout: "I like that," "I would like it if," "I guess I'm ready to start." - Company-adjacent framing kept light: *"which is why uh I guess this is why we're at I'm I'm at Docker."* ## Structure of the Talk 1. Self-intro with a joke about outdated identity markers ("I like spaces, not tabs... that's uh all irrelevant now"), followed by AI-tool disclosure (Claude Code, Codex, Marp, Mermaid MCPs). 2. Problem framing → two worked examples → product tie-in (MCP gateway, `sbx`) → XAA spec → demo/booth call to action: *"just brew install sbx."* ## Uncertainty Notes - The transcript shows frequent stutters and restarts ("the what the", "we give it We give it"); this appears habitual across the whole talk, but it may partly reflect transcript artifacts rather than spoken delivery — treat as low-confidence. - Audience interaction is minimal in the transcript (mostly rhetorical questions), so conclusions about live audience engagement cannot be drawn. - Whether the credential "always zero" maxim is a documented Docker position or this speaker's personal formulation is not determinable from the transcript alone. # Position Record: "How Many Credentials Should Your AI Agent Have? Zero." (Jim Clark, Docker) **Source:** Video transcript, titled as above **Speaker:** Jim Clark, identified in the transcript as an engineer at Docker **Record type:** Expressed positions, reasoning, and qualifications. No claims about private beliefs. **Transcript note:** The transcript is auto-generated and contains errors. Two partner names appear as "Entropic" and "Octo," and "XAA" is glossed as "cross app application." These readings are preserved as transcribed. --- ## 1. Core Thesis - **Central claim:** AI safety for agents depends on limiting what each agent can reach. The speaker frames this as limiting the **blast radius** of what an agent can do. - **Stated maxim:** > "How many credentials should be in a sandbox. Well, I mean the right answer is always zero." - **Stated framing:** The speaker says the talk is "really going to be talking to you about AI safety," with MCP Gateways as the vehicle. --- ## 2. Motivation: Why Safety Now - **Observed trend (personal experience):** Agents are doing more than expected and running longer. The speaker no longer sits and approves each step. - **Reasoning:** Less supervision is a sign of a well-designed task, but reduced supervision raises concern about "what it's going to get up to." - **Implied tension:** Longer autonomy is desirable, and it is the reason safety matters. --- ## 3. Agent Harnesses - **Description:** A harness takes in context and emits tool calls. The speaker calls this "an oversimplification" but says it has "a little bit of truth." - **Position:** The harness is "not the most complex part" of the system. - **Position on harnesses as a category:** - Many harnesses will be used and swapped, and they "will evolve pretty quickly." - A harness alone is "in a little bit of a dead room" without context or tools. - **Position on sandboxing the harness:** The speaker says "we're not trying to sandbox the harness itself. The harness is kind of already sandboxed." The focus is on the **tools and context flowing into** the harness. --- ## 4. Sandboxes - **Definition (as stated):** "Sandbox is a place for an agent to do work." - **Trajectory described:** - Early practice: the sandbox was the user's entire laptop. - Current direction: making sandbox boundaries "small enough that they can actually just do the task." - **Reasoning:** Smaller sandboxes make it safer to let agents run longer. - **Design principle:** Give each sandbox only the resources and tools required for the task. The speaker argues this "would make you feel safer" and "limited the blast radius." --- ## 5. Example One: The Newsroom Analogy The speaker splits a single capable agent into three sandboxed roles. | Role | Access (as stated) | Stated rationale | |---|---|---| | **Researcher** | Broad web access; few tools; no write access to corporate systems; writes to a private local temp directory | Allowed to "go crazy, do research" | | **Fact-checker** | No network; read access to research; access to a fact database | Works only on material already gathered | | **Reporter/Publisher** | No network ("shouldn't have any"); a Notion or publisher MCP; reads only filtered research | Publishing requires tools but not untrusted input | - **Core reasoning:** A single agent with internet access and publishing tools has a "dangerous combination" of reading unfiltered context and acting with tools. Splitting roles avoids that combination at every point. - **Note on the publisher role:** The speaker says the publisher "shouldn't have any" network access, then says "we do want to give it our notion MCP." Both statements are preserved. The network restriction and tool access are described as separate. --- ## 6. Example Two: The Coding Agent and Commit Signing - **Scenario:** A coding agent runs for about an hour. Most of that time is spent on work other than committing. Signing keys might be needed for "like 2 minutes of that time." - **Stated position:** The sandbox should be "modeled after the intent of what I'm doing." > "If I'm not going to make a commit, I don't want my commit signatures, my commit signing keys inside that sandbox." - **Generalization:** The speaker says this "can map across a lot of different tasks." If agents know the intent of a task, capabilities should be granted to match that intent. > **Tension to note:** The "zero credentials" maxim and this example differ. The speaker's wording suggests the ideal is zero credentials, but this example implies signing keys are present during the commit phase. The record preserves both. The transcript does not clearly reconcile them beyond the intent-based framing. --- ## 7. MCP Gateway - **Proposed architecture (described for Docker's sandbox product):** - Each sandbox contains a harness and a single gateway endpoint. - All MCP traffic, resources, and tool calls pass through that one gateway. - An example internal URL is given: `mcp.gateway.docker.internal`, described as "or something like this." - **Stated benefits:** 1. **Control point:** The gateway manages which tools, resources, and prompts each sandbox receives. 2. **Harness agnosticism:** Harnesses don't need separate MCP configuration. The speaker says "you almost make the harness a parameter of the sandbox." 3. **Credential management:** The speaker argues MCP is "a good place to manage things like credentials." --- ## 8. Cross App Access (XAA) - **Described as:** A joint effort by Docker and the partners named in the transcript ("Entropic," "Octo"). - **Mechanism (as the speaker describes it):** - Enterprises already have an identity provider, SSO, and OAuth-based resource servers (examples given: Notion, Atlassian, GitHub, Slack). - The harness, sandbox, and gateway define the agent's identity, meaning who the agent acts on behalf of. - By exchanging identity claims with the existing identity provider, the system obtains an "ID jag, an authorization grant," described as part of "the latest version of MCP." - This grants access to the same authorization servers without new consent screens. - **Stated benefit:** Centralized administration of what agents can do across existing resource servers. The speaker calls this "a huge simplification." - **Note:** The speaker says "there's nothing new here" and "we're leveraging all this existing investment." The mechanism is described at a high level. No technical detail beyond what is quoted is supplied. --- ## 9. Progressive Disclosure - **Source of the term:** The speaker attributes it to "skills." - **Application:** Tools, resources, and MCPs are disclosed into sandboxes progressively, as needed. - **Stated benefit:** Keeps context size down. A workflow may use 50 MCPs at some point, but "each sandbox" does not need all 50. - **Principle:** "Give your agents room to solve problems, but let individual sandboxes represent the intent of the task." --- ## 10. Orchestrators The speaker assigns orchestrators the following responsibilities, framed as questions to ask per task: - What is the task? - Which sandbox should it go in, and what capabilities does it need? - Which harness? - Which MCPs are allowed? - Which network rules apply (for example, access to `api.github.com`, open web, or none)? - Which resources and worktrees? **Stated conclusion:** Each individual loop "is safer because it has less access than the entire workflow effectively has." --- ## 11. Containers and Role Separation - The speaker links the approach to containerization, which he gives as the reason he is "at Docker." - He describes it as "a kind of like role separation": identify the roles agents have, map them to containers, and give each container a sandbox that expresses its intent. --- ## 12. Summary of Stated Principles 1. **Never** place credentials inside a harness or sandbox ("the right answer is always zero"). 2. Disclose capabilities **progressively** as agents need them. 3. Let sandboxes **represent intent**, and split workflows by role. 4. Longer agent runs feel safer when the sandbox is more constrained. --- ## 13. Qualifications and Hedges The speaker uses hedged language in several places: - "I think" (framing the problem, the sandbox concept, and the newsroom structure) - "I like to think" (progressive disclosure as a current development) - "I don't think it's an oversimplification" (on orchestrator responsibilities) - "a little bit of truth" (on the harness definition) - "Maybe" and "probably" (on the sandbox trajectory and the "last 6 months" experience) These are preserved as expressed. Several central claims (for example, "that's where safety comes from") are stated more firmly. --- ## 14. Promotional and Self-Reported Context - **Tooling disclosure:** The speaker says the slides were made with Claude Code using the Codex model, with Marp and Mermaid MCPs. - **Product references:** - A demo by "our EVP of engineering, Tushar Jain," described as covering sandboxes in the cloud and orchestrators, scheduled "at 4:00." - A booth where attendees can see the command-line tool, described as "sbx," installable via `brew install sbx`. - The speaker says "everything I've been talking about today is this tool sbx," and that it is "how we build containers." - **Note:** These are the speaker's own product claims and invitations. They are not independently verified in the transcript. --- ## 15. Open Questions and Unresolved Tensions - **Zero credentials vs. commit signing:** The maxim says zero, but the commit example implies keys are present briefly. The transcript does not explain how the keys are scoped at that moment beyond the intent principle. - **Publisher network access:** The speaker says the publisher "shouldn't have" network access, then gives it a Notion MCP. Whether MCP calls involve network egress is not addressed. - **XAA maturity:** The speaker describes the spec as appearing "in the latest version of MCP" and a joint partnership, but does not give status, adoption, or specification details. - **Sandbox boundaries:** The speaker says sandboxes should be "small enough" but gives no criteria for where that boundary should be drawn. - **Slide-dependent content:** Several examples refer to slides ("on this slide," "this whole slide") that are not present in the transcript. Those references cannot be verified from the transcript alone. # Speaker & Provenance Record ## Video Identification - **Video ID:** `01a15ca6-ecab-7dfa-b50d-12ddda75316e` - **Title:** *How Many Credentials Should Your AI Agent Have? Zero. — Jim Clark, Docker* - **Format:** Conference/technical talk transcript ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | **Jim Clark** | Main presenter; self-identified engineer at Docker | Transcript opening: *"my name's Jim. Uh I'm a engineer at Docker"*; title attribution confirms "Jim Clark, Docker" | | **Tushar Jain** | Mentioned only — Docker's EVP of Engineering; scheduled for a separate demo session (referenced as "at 4:00") | No direct speech attributed in this transcript | - A second transcribed voice marker (`>> [applause]`) indicates audience reaction only; no other identified speaker appears. - Jim Clark notes his slides were made with **Claude Code** (Codex model) using **Marp** and **Mermaid** MCPs — tooling disclosure, not a co-author claim. ## Referenced Sources & Third-Party Claims - **Partnership claim:** Docker, Anthropic ("Entropic" as transcribed), and Okta ("Octo" as transcribed) are partnering on **XAA (Cross App Access)** — a spec introducing an "ID-JAG" (identity/authorization grant) appearing in the latest version of MCP. *Attribution caveat:* these names are as-given in the raw transcript and may contain transcription errors; flag for verification. - **Named products/tools mentioned:** Docker sandbox product, MCP gateway (`mcp.gateway.docker.internal`-style internal URL), `sbx` CLI, Claude Code, Codex, Gemini, "Open code," Notion, Atlassian, GitHub, Slack, OAuth/SSO/identity-provider infrastructure. - **Concepts cited:** progressive disclosure ("a term we learned from skills"), MCP (Model Context Protocol), agent harnesses, sandboxes. - All claims above are presenter statements in the talk; no external citations or links are provided in the transcript. ## Promotional Segments (flagged) - **Closing product promotion:** Invitation to visit the Docker booth; installation instruction `brew install sbx` for the tool discussed; offer to demo the "command line that's available today." - **Cross-promotion:** Announcement of Tushar Jain's upcoming live demo session on sandboxes in the cloud and orchestrators. - Both segments occur in the final portion of the talk and are explicitly flagged per policy. ## Availability & Access Notes - Transcript is provided; **no curated metadata** beyond title/ID was supplied. - No comment availability information is present. - The referenced demo session and booth material are **external to this video** and unavailable in this source. - No timestamps, links, or on-screen source references appear in the transcript. \>\> 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 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 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." 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 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 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 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. 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 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 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 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. 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 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 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 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. 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. 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 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. 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 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 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. 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. 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 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 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. 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, 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 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 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 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 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 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 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 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 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\]