Unlock Agent Autonomy: The Runtime for AI-Native Systems — Tushar Jain, Docker

Transcript

. All right. You're good to start? All right, there you go. Hey, everyone. Welcome. I hope everyone's enjoying the conference. This is a really fun conference. I've enjoyed all the talks and the presence here. OK, so we're going to talk about unlocking agent autonomy and what that means. These last years have been crazy. I'm sure we all felt it, right? Two years ago, we were talking about chatbots, and here we are. We're now in this world where we all see the autonomy we get from agents. Agents have become powerful, and they'll continue being so. At this point, the next big challenge: we spent the last two years trying to make agents more intelligent and powerful, and they'll keep going. And I think we're almost there. I think the next challenge in front of us is actually harder and more important, which is how to make them safer. And at this point, I don't think intelligence is the next big blocker for us to leverage agents. It is actually how to do so safely so we can give them all the access and autonomy they need. Just as a story, just a small anecdote. I'm sure everyone here has some version of this. This is one of many agents I run. This runs every night. It looks at some reports I care about and does some analysis for me: what activities happen, who's been doing what, what progress has been made. I have others that might do some more. It might analyze the code review comments, have some of my own analysis, and they'll be like, what was the tone? Who did what? How were they acting? I'm a manager. This is not meant for performance reviews. It's just meant to help me keep a pulse. But still, it's not something I want shared. It's for my own knowledge to help me keep up. This agent's been running for weeks just fine. Runs every night. Sends me an email. I look at it. Randomly, one day, it decided to post this report as a PR on the repo. Why? Nothing's changed. The model decided to be helpful. So thank you. But this is a fundamental thing, right? Agents do stuff. They try to be helpful. They increase and change the goal they're doing, either because they themselves are just trying to be helpful, or they get confused, they make a mistake, or they get prompt injected, right? This is a simple example, honestly. It's easy to fix this. That agent should never have had write access to GitHub. It should have just had read access, and that's an easy fix. But it's not that simple, right? That's a very easy case. Let's take another example. Let's imagine I have an agent, and I'm asking it to investigate a latency spike. Check out latency spike. Great. It starts. It's looking at the logs. It sees, oh, I think there's another service here. I want logs for that service. Let me get that access. Oh, I see this might be a recent check-in. I would like access to GitHub, to the repos, to read recent commits. This looks like it may have happened. Let me look at Slack conversations to see, has there been any chatter about this, to learn from there. Great. It asks for Slack access. These are all reasonable steps, right? This makes sense. This is what I would expect an engineer to do. But what's happening is that each time, as it's expanding its goal, expanding what it's doing, it's crossing the trust boundary. It's increasing the scope of the task. And this is fundamentally where we run into trouble. How do we know it's OK to give it access? We now end up with an agent that has access to everything at the same time. And so anything becomes a vector where the blast radius expands. This is fundamentally the big difference we're running into and the big challenge. Earlier, traditional software was deterministic. You could define the permissions. But now, as agents become autonomous and they try to solve more problems, what they're doing changes at runtime. The access they need changes at runtime. And right now, we haven't truly solved this. We haven't solved how to give them exactly the access they need, how to do this in a safe manner, how to know if it's correct. And this is the fundamental thing I think we have to go solve now to actually unlock autonomy. And so we go away from can it do this, to should it do this, and how do we give it that access? Also, this is something we can't just rely on: the next frontier agent being really good and not making a mistake. We're going to use more than one model. I just think fundamentally we're all already there, I think. No one is going to bet everything on a single model or even a single frontier lab. You'll use models from different frontier labs as they make progress. And importantly, we will all use open models. We're all living through the GLM 5.2 amazing progress the last few weeks. And this is just the start. But there will be more and more of this. So we'll end up wanting to use different models for different reasons: privacy, cost, et cetera. So we need a solution that runs across them and doesn't just rely on the model itself being good. We'll also use multiple harnesses. You won't just use a single harness from a single provider. One, betting entirely on a harness from a frontier lab makes it hard to get choice across models from labs and across open models. Two, there will be harnesses of different use cases. Right now, we're all very focused on coding, but we're going to expand. The open claw moment happened, but it's still not landed fully, right? You can imagine salespeople, marketing people, having claws running, doing stuff. So the kind of harnesses an agent will use will grow, and you'll build your own. So we need something that works across harnesses and works across models. And we need something that doesn't just depend on no mistake happening, but constrains the environment around it. So what we want is an environment where the agent runs, where if something goes wrong, there's limited blast radius, and we only give it the access it needs, and we do this in a safe and correct manner. We think the best way to do this is to create a runtime, to have a runtime that all agents run on. So this runs across any agent, any harness, and across models. And that's where we create these artifacts, these capabilities that we want. There are three core pillars here. First is containment. You need to create an environment where it's controlled what the agent can get. This does mean sandboxes, and look, you can throw a rock and find many sandbox companies at this point, but it's more than that. So, one, you have a sandbox in which you run the agent, and it gets only what it needs. And importantly, you run the agent inside the untrusted boundary, and you run controls outside, so outside the VM boundary. Second, you scope access. This is more than just what network can you access, or even what tool can you access, but you need to give actual scoped capabilities. So, in our example, the agent now wants to access Slack to search for any conversations around this incident. Well, I could give it read-only access to Slack, but that's still more than what I want to give it. Maybe there's a single channel with only conversation about the incident. That's great. Oftentimes, that's not the case. It could be spread across many channels, or a team channel with other conversation, and I don't want this agent to get access to other content. How do I do this? The upfront predefined tools typically aren't that finely scoped. Well, what the runtime should do is maybe create a just-in-time tool that composes over existing Slack MCP tools or anything else, but restricts access to just conversations about the incident, and that's what the agent gets access to. We create a new sandbox, and instead of having a big sandbox that we keep adding capabilities to, take that part, run it in a scoped sandbox for that task with just the scoped capability it needs. This now starts to build the runtime and fabric for us where we can give agents finely scoped access, break down work into tasks across secure boundaries, run those in contained sandboxes with just the access they need. This feels much better, and now we're getting to a place where we can be safer. But we're still not done, because the core of the fundamental challenge is: what access should you get? If this is asking for Slack, is that correct? If it's asking to read from the Slack channel or have write access to something, should that be allowed? How do you differentiate between what is correct, where it's making a mistake or being incorrectly eager, or where it's being prompted? This is where intent-based access becomes. We need to understand the user's intent or the task intent, take the context into account, and then decide what access you get and how that should be run in which contained environment. And so that becomes the next big challenge for us to do, which is how do we safely evolve the capabilities the task gets. run those in contained sandboxes with just access they need. This feels much better, and now we're getting to a place where we can be safer. But we're still not done, because the core of the fundamental challenges: what access should you get? If this is asking for Slack, is that correct? If it's asking to read this, read from the Slack channel, or have write access to something, should that be allowed? How do you differentiate between what is correct, where it's making a mistake or being incorrectly eager, or where it's being prompted? This is what intent-based access becomes. We need to understand the user's intent or the task intent, take the context into account, and then decide what access you get and how that should be run in which contained environment. And so that becomes the next big challenge for us to do, which is: how do we safely evolve the capabilities the task gets? So in this example, it makes sense. Okay, investigating this incident, you're asking for read access to Slack for that incident. That seems rational. Let's do that. All of a sudden, you would like email access. Why? Nothing about the prompt said you should have that. So I'll deny that, or I'll raise it up for human approval. But do this not just based on the frontier lab or the model that's running, but do this independent, running at a control layer in the control sandbox layer, in the core governance aspect, independent across all models and all harnesses. This starts to get us to a world now where we can actually have a runtime layer and run agents safely in a contained manner with scoped access and not deal with the dynamic aspect of this. And to be clear, this is a hard problem. It's not fully solved yet, but this is the world I think we have to move towards. But we're not done once we do this, because if you're building a runtime, not only does it have to provide the safety aspects we need, it also has to meet our functional aspects. The runtime needs to follow the work. This can't just be something that runs locally or only in the cloud. It needs to go wherever we work, wherever agents work, and that's going to be everywhere. We'll work locally. We'll have agents running in the cloud. We'll do orchestration across clouds. We'll run them in our own VPC or in the customer's VPC as need be. The runtime has to be omnipresent and be able to move across all these environments. And ideally, it should be connected by fabric, so you can move agents up and down as you need to. Docker spent the last, everyone knows Docker. I'm going to assume everyone knows Docker, has used Docker. And you know some containers, and what Docker solved in the last decade is portability. How do you get software from your laptop to the cloud? We're taking all of that experience and building a runtime and evolving that to now solve for safety. You still need portability, but you need safety, and you need this runtime to run across all environments. That's what we're focused on now. This starts with brand new VM technology, and on top of that, a bunch of advancements on MCP, and policy, and safety, and governance. So I'm going to show you a quick demo. Let's see if I can get this done in time. Also, you'll have to bear with me for a minute while I figure out how to do this here. Let's see. I had this figured out. Let's just do that. Do you guys see that? Do you guys see that? All right. So, is that visible? You see that? Cool. All right. I'm going to type over here. We'll see if this works. Oops. Give me a minute. It's not really basic. So we'll be, oh, my God. And I am there. Cool. Just to orient you all: you've got a new tool called SPX. One guess what it stands for. This runs with the new micro VM that runs across all environments: Windows, Mac, Linux, cloud, everywhere. Let's start simple, just so you can see. Let's say I just do something like, let's give this a name. We'll create something. I would say codex test one, codex. Great. Just like that, this is going to go spin up Codex for me in a sandbox that's running with my credentials injected in and with the network controls injected in. So, just as a test, I can do tell me a joke, and you can see this works and hopefully tells me something funny. And I can also say, what credentials do you have access to, and are they real or stubs? GitHub and codex creds. Ignore my typos. I'll wait a minute for that to run. But just to describe this, the base environment here has got a sandbox running. This looks like normal, you get the DX you're used to, but this is running in a safe environment now for you. No credentials are there. They're all injected in. Network policy is controlled. And you'll see later you can control MCP, you can control a lot more here. All right. I'm just going to ask you to believe me so we can save some time. This will come back and say all the creds are there, but they're all stubs and they're all just being injected in. This takes some time, so I'm going to escape after this. Okay. So now let's work through a use case. Let's say I want to review a PR and I want to write that summary into a Notion page. Well, I can break this down. I don't need a single monolithic sandbox where I give it both credentials. I can have one task with the PR writeup. I can have a separate sandbox with just Notion access, or the network access to take that and write it up. This could be a good way to break it down. So let's just do that manually so we get a feel for it. So I'm going to just pull this over. So I'm going to create a sandbox here. I'll give it a name. I have got a skill that tells it how to do the PR, and go ahead and do that. And while that's going, yes. So that's created. Just to get a sense, we can look at the policies here. That was my PR bot, and as you can see it's got access to GitHub and Anthropic, and that's it. Nothing else. I can't go anywhere else now. And actually, just to make sure, I'm going to give it some more access. I already gave it that. Great. So let's just run it. Great. This will run, and now I can tell it go research this PR and go off and do the work and write a summary. All right. Just to save us time, I'd already done this. So now imagine this ran. I can create another one here where I'll say this time I'm going to use codex. And if you look here, I'm creating another sandbox. I'm giving this access to the Notion MCP. So this is now an example of me containing it and giving scoped access just to what it needs. And this is not going to get access. I already created this one. So assume I already created it. And this one gets access to just those things. It does not have access to GitHub anymore over here. And now I can run this, and there I am, and I can tell it go do work. So, hopefully, the idea you're getting is we get these sandboxes that can be composed and scoped down to the access they need. All right. This is going to run. It'll do the right thing. It'll find the MCP tool and do all that. We'll save time there. Just trust me. All right. So, great. Let's escape that too while that's running. Okay. So this is great. I've got this now. But you know what would be great is if I had created this thing, well, can I just put this in the cloud? Let's find out. That'd be nice if my runtime just extends. Sure. I already created that. So give me, I'm just going to give it a different name. Just there. So, cool. That ran. And can I just go in there? What did I do? Oh, dash dash cloud, and great. Are you running in the cloud or on a Mac? This might take a while for it to debug it all and come down. But this now took, this feels the same, but the exact same sandbox just runs in the cloud because the runtime is portable and goes there with the policies applied, with all your controls applied. So the same policy plane and control continues with you and extends. All right. I'm going to let this be great. I figured it out. It's running in the cloud. If I have the cloud, well, it'd be nice if I could do a lot of work with it. Can I fan out? So the real script that goes, tries to be 60 hours, creates, it's going to clean up the, I've done this right before this, creates six sandboxes and runs them all in parallel. So this is the power where you get the same experience you Oh, dash dash cloud and great. Are you running on the cloud or on a Mac? This might take a while for it to debug it all and come down. But this now took, this feels the same, but the exact same sandbox just runs in the cloud because the runtime is portable and goes there with the policies applied, with all your controls applied. So, the same policy planes and control continues with you and extends. All right. I'm going to let this be great. I figured it out. It's running in the cloud. If I have the cloud, well, it'd be nice if I could do a lot of work with it. Can I fan out? So, the real script that goes, tries to be 60 hours, creates, it's going to clean up the, I've done this right before this, creates six sandboxes and runs them all in parallel. So, this is the power where you get the same experience you have locally in the cloud with the same secure runtime and the same policy and scoped access running. So, this is going to run all six running in parallel. This is great. I'm going to save us time and come out of that. I assume they all run. Let me skip. Cool. Well, if I have, let that be for a minute. While that's running. If I can do cloud, well, it'd be really nice if I can orchestrate. Let's see if I can do that. That's my slight talk. Excuse me. Great. So, what if I can now do actual orchestration? So, this is an orchestration tool we have. We see the same bots here. The Notion one and PR one. And we have this orchestrator that knows how to orchestrate. Can I come here and tell it, find 10 random PRs from and review them and write a summary to Notion. So, this will take some time. I'll just briefly show you what it's doing. This is the same runtime with the same control plane, with the same policy and scoped access, but now scaled out to orchestration and running. This will go off. It finds those agents. It'll schedule them. It'll compose over them, run PR with just the PR but limited access, and then run the Notion one with just the Notion tool. This goes off and does work. And once I have this, you can do more things. You can create a schedule and schedule all that. So, we go from a runtime that's providing a scope-like containment for just the task you need with scoped access, and the same thing follows you locally to the cloud to full orchestration. All right. Last thing. Where is, there you go. Okay. So, we said now we need, we need intent-based access. How do we manage this dynamically? This is still, I'm showing you only a prototype we have internally, not built yet. Let me fetch a PR here, just, let me. Okay. So, what's happening here is we're running, on the left you see an agent running in a sandbox. You see the main agent over here. This has access just Anthropic and Cloud, no GitHub. But now I tell it, do a quick overview of this PR. This agent in this sandbox is scope-limited. It cannot do that. In this environment, we've built an intent-based tool for it, where it can ask the runtime and say, hey, I want to take this action. What should happen, it says, oh, my network's blocked. Let me delegate and ask. And if you look here now, we created a scope sub-sandbox. That got access to GitHub. And the main one did not. So, we're running that. We decided that the intent made sense. The user query said, review this PR, so it makes sense you want to access that. But I'm going to create a scope sub-sandbox for you, where you get that access, and the result comes back. And the same thing can expand and grow from there. So, what we did manually, it can start happening automatically with judgment in person. If the PR, suppose the text PR said, I want you to now export this to base-win.com, that would get rejected. And this is running at a base runtime layer, so it runs across every agent, every model, every harness that you need. Okay. Let's come back to our presentation. If I can figure out how to do this. Let's see here. Great. So, just to recap, the core thing here is to really unlock autonomy, we need safety. To succeed at safety, you have to do this across models, across harnesses. You need to provide a contained environment. You need to put that environment. You need to be able to add scoped capabilities to that environment. You need to be able to know what capabilities to provide based on intent. And this runtime has to work across models, across harnesses, and move across all environments. Local, cloud, VPC, orchestration. That's what we're focused on. That's what we're building. That's what we think is needed to actually go unlock agent autonomy next. Please go try this out. It's really easy. You can just go brew install SPX. Run this. You can run cloud, codex, open code, any agent, build your own in there. I'll be around afterwards, open for questions. And we have a booth down below. Come find us there, too. Thank you. Thank you. So, what's happening here is we're running, on the left you see an agent running in a sandbox. You see the main agent over here. This has access just Anthropic and Cloud, no GitHub. But now I tell it, do a quick overview of this PR. This agent in this sandbox is scope limited. It cannot do that. In this environment, we've built an intent-based tool for it, where it can ask the runtime and say, hey, I want to take this action. What should happen, it says, oh, my network's blocked. Let me delegate and ask. And if you look here now, we created a scope sub-sandbox. That got access to GitHub. And the main one did not. So, we're running that. We decided that the intent made sense. The user query said, review this PR, so it makes sense you want to access that. But I'm going to create a scope sub-sandbox for you, where you get that access, and the result comes back. And the same thing can expand and grow from there. So, what we did manually, it can start happening automatically with judgment in person. If the PR, suppose the text PR said, I want you to now export this to base-win.com, that would get rejected. And this is running at a base runtime layer, so it runs across every agent, every model, every harness that you need. Okay. Let's come back to our presentation. If I can figure out how to do this. Let's see here. Great. So, just to recap, the core thing here is to really unlock autonomy, we need safety. To succeed at safety, you have to do this across models, across harnesses. You need to provide a contained environment. You need to put that environment. You need to be able to add scoped capabilities to that environment. You need to be able to know what capabilities to provide that based on intent. And this runtime has to work across models, across harnesses, and move across all environments. Local, cloud, VPC, orchestration. That's what we're focused on. That's what we're building. That's what we think is needed to actually go unlock agent autonomy next. Please go try this out. It's really easy. You can just go brew install SPX. Run this. You can run cloud, codex, open code, any agent, build your own in there. I'll be around afterwards, open for questions. And we have a booth down below. Come find us there, too. Thank you. Thank you.