Mark Cavage on Agentic AI, Sandboxing & Enterprise Security

Chapter 1 — 03:01 | Introduction Raja introduces Mark Cavage, Chief Operating Officer at Docker, and kicks off the episode.

Raja Iqbal: Okay, let’s go ahead and get started.

Raja Iqbal: Hello and welcome to another episode of Future of Data and AI. I’m Raja Iqbal. My guest today is Mark Cavage. Mark is the Chief Operating Officer at Docker. Welcome to the show, Mark.

Mark Cavage: Thanks, Raja, it’s great to be here.

Raja Iqbal: Great to have you.

Chapter 2 — 03:19 | Career Journey: From IBM to Docker Mark walks through his career arc from Nortel and IBM, to building early AWS, founding Oracle Cloud Infrastructure, and eventually landing at Docker via Joyant, Heroku, and Stripe.

Raja Iqbal: So Mark, you started your career at Amazon AWS?

Mark Cavage: I’m even older than that, actually. Once upon a time it was Nortel Networks, who doesn’t exist anymore, but I spent my early formative years at IBM, and then in the early 2000s — 2005 or 2006, I always get confused — I went to AWS.

Raja Iqbal: And then you transitioned through Stripe, and you were one of the early folks at Heroku.

Mark Cavage: Yeah, so I spent years at AWS and built out what I would call the first one, maybe V1 to V1.5, somewhere in there — the first couple versions of AWS. Believe me, it’s all been rewritten probably 10 times over by now. But through that early wave of AWS turning into the exponential growth hockey stick. I left there, I went to Joyant, which was the betamax of cloud computing and big data, but we also did Node.js — I think that’s what a lot of people remember the company for. And then I left there and founded what’s now Oracle Cloud Infrastructure.

Mark Cavage: And it was actually after that that I found myself at Heroku, after Salesforce had acquired Heroku, years later. I worked on translation to serverless and all the rest.

Mark Cavage: Stripe after that, and a small healthcare startup, before coming to Docker. That’s the arc in 60 seconds or less.

Chapter 3 — 04:53 | Building OCI: Taking on AWS a Decade Late Mark describes the intensity of building Oracle Cloud Infrastructure a decade behind AWS and Azure — the architecture conviction they had from day one, and the years of being laughed at before proving it out.

Raja Iqbal: What was the pitch like internally at Oracle to take on AWS and Azure? Do you think you guys were a bit late?

Mark Cavage: We were a decade late, so it was very frenzied and very much a constant sprint as fast as we possibly could. But the funny thing is, from the day we got there, we knew we were doing the right architecture.

Mark Cavage: There was a small set of us from AWS who had founded it. At the time we called it the Gen 2 cloud — whatever the marketing messages were — but the real innovation was building it as a bare metal first cloud. True L2/L3 network virtualization, like a VPC, but with the ability to get ephemeral bare-metal instances of any shape, size, and configuration on that kind of network in a cloud-like way. And so, beyond the normal virtualization things you’d expect in VMs, I could get very high-scale computers, run very large databases, run ML workloads. That was the genesis of it. But to answer your question on the pace —

Mark Cavage: We were in market, and everybody was laughing at us for at least three or four years. I would enter countless meetings and conversations — the press would basically say, “You guys are kind of fools, I don’t know why you’re even here.” And I would walk into customers and they’d say, “What do you mean by purchasing descriptions?” So it was both a grit and grind of perseverance, as well as a race to catch up. There were a lot of sleepless nights.

Raja Iqbal: I can imagine. I joined Bing fresh out of college, early days of Bing, and the internal joke was they’re hiring people so they can have more users. That early. But at the same time, when you’re working on such a major initiative within a company, you get to work with the smartest talent in the industry because it becomes imperative for the company. I got to meet some of those people — the diaspora is all over the industry now.

Mark Cavage: I definitely don’t consider myself one of the smartest people, but we definitely got to work with a lot of the smartest people. At all these different arcs — Amazon, Oracle, Stripe, Docker — when you’re onto something, and you have conviction of mission, and you have belief in what you’re doing, and it’s actually something ambitious, that attracts a lot of smart people.

Mark Cavage: Smart people want to work on hard problems, and those are some of the most rewarding points of my career — not just the technology we accomplished, but working with the people, learning from them, learning from the problems. Smart people motivate you to want to be better yourself, which then makes it a virtuous flywheel across people.

Raja Iqbal: And you get to meet people who are not just smart, they work incredibly hard. You’re always trying to catch up with them.

Mark Cavage: It’s healthy competition.

Raja Iqbal: It is healthy competition, I can relate to that. And you met Don Johnson there?

Mark Cavage: Don and I were actually office mates, along with Tushar — who’s also now at Docker — back in 2005 at AWS. That’s where we first met, way back in the early AWS days, and have known each other and been lifelong friends since then.

Chapter 4 — 08:38 | Lessons from Building Cloud Twice Mark reflects on what he learned from building cloud infrastructure twice — the value of studying history at AWS, and the cultural challenges of building OCI from a mixed team.

Raja Iqbal: What are some of the lessons? I know it’s an open-ended question, but anything you can share. You built this hyperscaler cloud platform for the second time. You were one of the early people at AWS. What are some of the lessons? How is it different from building from scratch?

Mark Cavage: What are the lessons of having done a cloud once, then doing a cloud again?

Raja Iqbal: Or building from scratch?

Raja Iqbal: First line of code, I would assume, right?

Mark Cavage: They’re similar and different in some ways. The interesting thing about the first time around — kind of like now in the AI era — the cloud was very greenfield. If I go back to 2005, when AWS was getting off the ground, I left my job in enterprise software at IBM, and everybody I worked with told me, “You’re gonna go work for the bookseller, and the bookseller’s gonna go sell computers? What?”

Mark Cavage: Nobody really got it. But if you were paying attention, it was really obvious this was going to be totally transformational.

Mark Cavage: And it was completely greenfield. We didn’t know what we were doing, we didn’t know what we were solving. I can still look at AWS today and see things I’m very proud of, and some things I look at and think, “Why did we get that wrong?” You’re kind of still half living with it, because these things get baked in.

Mark Cavage: From the lessons of those two parallels — when you’re doing something greenfield, you have to do your best to learn everything you can from the people who came before you. I’m a big fan of history, and I think people underappreciate it. When I was at AWS, I was spending my time reading mainframe papers from the 1960s and 70s, and Sun Microsystems papers on grid computing from the 1990s. The art of AWS was taking ideas that existed in history and making them work on commodity infrastructure at scale.

Mark Cavage: A very valuable lesson: many of these core ideas have been solved before. The assumptions and primitives have changed, but the ideas are there. Lesson number one — do your homework on history, because even if you’re going to throw away the implementation, even if you’re going to throw away 50% of the assumptions, there are valuable things you can apply. So that was…

Mark Cavage: The OCI one is a little bit different. The funny thing was — you show up thinking, “I know what we got wrong before, we’re going to do this totally differently this time.”

Mark Cavage: The two-fold lessons for me in OCI — by now I had transitioned from IC to manager and leader. The hardest part of Oracle was the cultural amalgamation of different groups. You have this cohort of people from AWS who know exactly what to do — it’s monoculture, they’re coming out of AWS, “Great, we’re gonna go do that stuff, here are the things, and we’re gonna change these assumptions.”

Mark Cavage: Injecting that with people who were not from that domain was actually the hardest part to work through. The biggest lesson I learned there: don’t underestimate how important it is to get people on the same page with the principles and the cultural way of working.

Mark Cavage: Because that almost dictates and drives your success more than anything. Looking back at the early days of AWS, they did a really good job — letting a bunch of youngsters run around and do crazy things, but actually being very focused on culture. Those are the juxtaposed lessons from the same problem domain with two different solutions.

Chapter 5 — 13:22 | What Docker Got Right: The Unix Philosophy and Platform Thinking Raja asks what Mark would do differently building from scratch a third time. Mark ties Docker’s durability back to the Unix philosophy — small, composable, purpose-built primitives — and why building a true platform means being surprised by what gets built on top of it.

Raja Iqbal: Let’s say you’re getting a third chance at building something similar from the ground up. What did you get right so far? And if you had to start from scratch, what would you do differently?

Mark Cavage: When I look at what we’re doing now with Docker — we’ll talk about AI in a second — AI gives you not just the latitude and the mandate, but the necessity to rethink a lot of first principles, because everything about the user you’re serving changes.

Mark Cavage: What did we get right? I’ll liken it to the Unix philosophy. Unix has served us for 40 years. Sure, some config files are rough, but for the most part it’s a fairly beautiful system — there’s a certain elegance to how you compose things, how you think about small tasks that do simple things.

Mark Cavage: When I look at AWS, or the best SaaS architectures, the best big data architectures — they all sort of figured out the same thing: build services that are purpose-built, do a small thing, don’t do surprising things, and can be composed with other things. And that’s the real way that you get to something that looks like a platform.

Mark Cavage: The thing I’ve told people for a long time: you know you have a platform when the next three things built on it have surprised you — things you never thought of.

Mark Cavage: When I look back at AWS, Docker containers, Oracle — the surprising, rewarding thing is when people start figuring out, “This unlocks a lot of capabilities for me.” I’m most proud of the fact that the constructs and the primitives we set forth in 2005, 2006, 2007 are still with us now.

Mark Cavage: The most exciting thing looking forward: we get the opportunity to build a new platform again for the agentic world. It’s easy to look at it and say, “We’re gonna do a bunch of infrastructure and it’ll be the same as the last five times.” But I love platforms — it’s like playing nine-dimensional chess. You have to think through all of your own problems, your users’ problems, your users’ users’ problems. When you get it right, you’ve actually thought through layering top to bottom and unlocked compounding use cases.

Mark Cavage: That’s what was rewarding about it then, and what’s exciting about it now.

Raja Iqbal: When did you join Docker?

Mark Cavage: About a year and a half ago. Don and I are lifelong friends — we both joined around the same time.

Raja Iqbal: Okay, and Don has been around at Docker for quite some time now, right?

Mark Cavage: He and I joined at the same time, about a year and a half ago.

Raja Iqbal: You and him joined at the same time. By the time you joined, it must have been already clear to both of you how important containerization and Docker would be in agentic AI — the separation, sandboxes, security isolation.

Mark Cavage: Absolutely. Basically you’re asking: why come here? What do you see?

Raja Iqbal: I have some sense of it, but for a general audience — why is Docker so uniquely positioned in agentic AI?

Chapter 6 — 17:33 | Why Docker Unlocked the Mass Move to Cloud — and Why That Matters Now Mark explains what Docker really solved in the early cloud era — getting code from laptop to production — and why the same ethos of portability, isolation, and ease of use positions Docker at the center of the agentic world.

Mark Cavage: I’ll get to agents in a second, but what is Docker really and why does it matter? If I go back to the very beginning — you’re talking to somebody who built the first couple of clouds — I actually think Docker is what unlocked the mass move to the cloud.

Mark Cavage: It solved this fundamental problem. Before Docker, the cloud was already fairly mature. If I looked at AWS alone, you had the bleeding-edge companies on it doing amazing things — we literally could not keep up building data centers and racking servers fast enough, just off-the-charts demand. But it still felt like less than 10% of the market that could actually move to the cloud was on it, because it required specialists and experts who understood distributed systems and operations.

Mark Cavage: A huge part of the problem was: developers would write code on their laptop, and getting that code from the laptop to production was really hard. AWS is not like your laptop. That’s what Docker solved.

Mark Cavage: The real notion of Docker: build once, run anywhere. Isolation, ease of use, and a runtime that lets you run on any different infrastructure. That was the original Docker, what containers were really all about.

Mark Cavage: Since then, the container world has blossomed into an enormous ecosystem. I read a stat the other day — I don’t know if it was Gartner or IDC — but 93% of the world now runs containers in production, and containers are the main direction for production workloads. Much like Unix, they’re ubiquitous — they’re the lingua franca.

Mark Cavage: Docker was the company, the technology, and the ecosystem that made the transition to cloud possible, because it unlocked a massive wave of developers being able to use the cloud much more easily and accessibly.

Mark Cavage: So that’s Docker in the rearview mirror. We’re cemented, containers are cemented, everybody’s workflows are cemented in production. We have many problems to solve around supply chain security and maturing that ecosystem further.

Mark Cavage: But the real giant opportunity — the exciting thing — is that the ethos of Docker has always been portability, agnosticity, isolation, ease of use, and developer friendliness. The agent world needs a lot of the same things. We want to help everybody access not just using agents, but building agents.

Mark Cavage: Giving them the same story: I can use any model, any harness, any cloud, any device. Docker is both the ethos of the technology that allows that, and the technology people already use and trust.

Mark Cavage: The real reason why Docker is compelling — was compelling, is compelling, and will be compelling — is that core ethos: build once on anything, with anything, run anywhere.

Mark Cavage: We have a lot of features and product names in market, but that’s the real evergreen identity of Docker.

Chapter 7 — 21:26 | Docker Hardened Images and Supply Chain Security Raja asks how Docker ensures the integrity of anything it publishes and distributes. Mark explains Docker Hardened Images — and why developer laptops have become the new attack surface.

Raja Iqbal: If you look at agent APIs, and the connectors we write — MCP and all those protocols — a lot of things are autonomous, non-determinism is there, and that’s not the most exciting combination from a security standpoint. A lot of security issues, permissions, authorization, all of those. How do you ensure the integrity of anything published and distributed by Docker, so it meets customers’ expectations and doesn’t create unnecessary problems?

Mark Cavage: Great question. There are actually two things in there: how do I ensure anything built by Docker meets customer expectations — and separately, agents have all these different properties.

Mark Cavage: There are two things here. One is about containers and images, the other is about agents. They come together but they’re a little bit separate.

Mark Cavage: From the image side: Docker has been a core element of the supply chain for a decade. The big investment we’ve been making is Docker Hardened Images. We think this is the right thing for the world.

Mark Cavage: We ourselves run on pretty hardened supply chain and build processes. That allows us to guarantee the provenance of any given piece of source, make sure that what we produce is not just secure but tested and high quality, and ultimately give customers something they can build on that actually improves their own security posture.

Mark Cavage: In the past we had Docker Official Images — a contract you could trust from Docker: you want MySQL, you want Python, whatever you want, we’ll give you bit-for-bit compatibility with upstream, built on good infrastructure. You can trust it doesn’t have malware.

Mark Cavage: But the reality is the vulnerability count in open source is doing nothing but going up. Developer laptops are the new goldmine and honeypot of the world, effectively. All the recent vulnerabilities we’ve seen are people breaching into that space. So it’s actually insufficient to just have official images. We need to go further and help our customers — and users and developers everywhere, whether they pay us or not.

Mark Cavage: DHI is free and open source, with enterprise features for businesses that need compliance and regulations. Every developer out there has a baseline they can build on that gives them a more secure, minimized foundation with the principle of least privilege — no malware, CVEs mitigated faster. That’s the baseline at which we’re now rebuilding the container world on top of.

Mark Cavage: Now, the agent side, excuse me, is a little bit different, because as you said, agents require mutability — and now you get into containers versus sandboxing, which is a very complicated topic that I feel like we answer all the time, because sandbox is a very overloaded word that is thrown around everywhere.

Chapter 8 — 25:06 | Containers vs. Sandboxing: A New Runtime Primitive for Agents Mark breaks down the difference between containerization and sandboxing — explaining why containers, built for immutability, are fundamentally incompatible with how agents want to operate, and how Docker built a new micro VM-based primitive to solve this.

Mark Cavage: Sandboxing, if you go look up the computer science definition, is just a way to run untrusted code. Docker containers, the Docker engine and Docker daemon — that’s a sandboxing engine. The browser has a sandbox in it. Many databases have a sandbox engine in them. Operating systems ship with sandboxes. There are sandboxes all over the place.

Mark Cavage: So Docker, the engine, already gives you some nice primitives and isolation. You can run many different workloads on the same host, you get OS virtualization — they share a kernel, but restricted down via kernel-level isolation. There aren’t really breaches in Docker today from that at all, but you share a kernel, you do share hardware boundaries.

Mark Cavage: But the funny thing about the Docker daemon — or the container ecosystem — is it’s not so much that Docker itself can’t do this. It’s that the entire ecosystem was built around immutability. Kubernetes controllers watch if containers have drifted, and if they do, they kill them and restart them. People have scanners watching every container in production — the slightest change to the file system, the scanner wall goes red and somebody gets paged. The entire ecosystem is basically built around the container being an immutable unit of software that I ship. Which is a good property.

Mark Cavage: So the reality of an agent is — the very first thing an agent wants to do when you run it is mutate its environment. Think about Claude or Copilot or anything else. You run it, you ask it to do something, and it’s like, “Great, I’m gonna run this package install, I’m gonna download this from the internet, I’m gonna do that.” It immediately breaks the social contract of containers, number one.

Mark Cavage: And two — they’re a very vicious adversary, actually. If you set them loose on your machine to try and break it, they’ll probably find a way. So you need the hardest level of isolation boundary you can possibly have, to truly put it in a contained box.

Mark Cavage: For us, sandboxing is that core primitive. What we did is take the core bits out of the engine and effectively rewrite them with a micro VM technology, so they run with all the properties you’d expect on Mac and Windows and Linux and Cloud. But they’re fundamentally built to look, feel, and act like the same developer experience as Docker, while giving a hardware isolation profile — so now you don’t have shared anything.

Mark Cavage: You put the agent in a box, let the agent do whatever it wants in the box, but you have god-like control over it — you can see the file systems, the network calls, keep secrets out of the box and use proxying. You can control anything about the outside of the box and let the agent run around, but you can kill-switch it or stop it any way you want.

Mark Cavage: We have deep conviction this is the right base primitive — the base turtle in the turtles-all-the-way-down metaphor. This true sandbox gives you the unit of execution you can run anything in. You can put Claude Code in there, you can put open Claude in there, whatever you want, and then build the rest of your trust profiles up on top of that.

Mark Cavage: This all sounds academic and security-focused, but the most pithy one-liner of why you should care as a developer or data scientist:

Chapter 9 — 28:39 | YOLO Mode and the Docker MCP Catalog Mark introduces “YOLO mode” — running an agent with all permission checks off inside a secure sandbox — and explains why the Docker MCP catalog of 300+ vetted servers is a fundamentally different trust model from the wild west of the open MCP registry.

Mark Cavage: To adopt agents productively, you need to run what I call YOLO mode — where the agent can run with all permission checking off and just go wild and do whatever it wants. The problem is, when it does whatever it wants, it can do very bad things. The real benefit you get is you can actually put any agents you want in YOLO mode, let them cook — but actually have safety and control and isolation boundaries around it. It’s a long-winded answer, but that’s basically the answer to two separate questions on two sides of the world.

Raja Iqbal: So, I’m building an agentic AI application, I need an MCP server, something from the Docker…

Raja Iqbal: Is it called Docker Marketplace? I think Docker has a…

Mark Cavage: We have Docker Hub, and then there’s a catalog — there’s an MCP catalog.

Raja Iqbal: MCP catalog, right. We actually use the Docker MCP catalog all the time.

Raja Iqbal: Give me some comfort — why should I actually go and install from Docker? Will it protect me against anything inadvertent, something sloppy done by someone?

Mark Cavage: My legal team would tell me there’s a disclaimer here somewhere, but in all seriousness — saying you can protect against anything is a journey, not even a destination. It’s not even where we are. It’s a journey.

Mark Cavage: So what I can tell you is: why do this today? What can we do today? What are we working on, and what can we do tomorrow? And what should you still be worried about even after that? That’s how I’d answer, because I think we’re all going through this weird, wacky world of agents and AI, figuring it out together, kind of week by week.

Mark Cavage: The world keeps changing, it’s very fast-paced, and anyone that shows up and tells you you should feel 100% safe, they have all the answers — [redacted]. I don’t know if I can swear on your podcast. But…

Mark Cavage: Let’s start with the Docker MCP catalog and work our way up.

Mark Cavage: If you go to the official MCP registry, there might be 20,000 things in there, probably more — tens of thousands. And if you look through it, it is pretty wild west. You have the same name for the same package nine times over. We use Notion internally — if I go to the official MCP registry, there are at least seven or nine different entries that come up when you say “I would like Notion.”

Mark Cavage: The real question is: what do you actually want? Do you know what’s in there? Do you trust it?

Mark Cavage: Like anything in a community, it has to be built on trust and knowing what you’re getting. I, for one, don’t know what I’m getting from those, so I tend not to run them. When I think about what I’d want — taking Notion as the example — I want one of two things: either access to attach to the remote service (Notion has mcp.notion.com — great), or some stateful application that can do something useful on my laptop, where now I have to run it and trust that software.

Mark Cavage: To answer your question on Docker’s catalog: we have 300-plus servers. We have either handmade every one ourselves, or gone through our Docker Verified Publisher program. Getting a checkmark on there is a meaningful step — you have to legally agree, you have to get audited by us. We actually have trust and assurance in there.

Mark Cavage: The Docker MCP catalog: we can make a strong assertion — either we built it, and you should trust us because we’ve been doing this forever and you already trust us with all your other open source, or we’ve already worked with a partner and hand-verified it — with humans, not just agents — and made sure it matches our bar for how they publish software. The Docker MCP catalog has hundreds of things, not tens of thousands. And those hundreds are safe.

Mark Cavage: Now, what you want beyond that — you asked a kind of loaded question about protecting against anything that goes wrong. We can definitely protect you from namespacing collisions — somebody saying “I’m Notion” but not actually being Notion. We can protect against bad software getting in.

Mark Cavage: But in the world of agents, you have this non-deterministic, unpredictable actor that does whatever it wants. Getting into prompt injection protection, data loss protection, and all the rest — that’s the next evolution of what we’re working on. What that will look like is both a set of servers more advanced than what you see today, and a set of platform building blocks that let you build for yourself.

Mark Cavage: Because I assume the number of custom MCPs you’re building is greater than zero. As soon as the answer is greater than zero, you have all these same problems and want the ability to go create and ship them. And ultimately, you’re going to want your custom internal one that accesses HubSpot or Snowflake or whatever, to have filtering and protections both built into the image and running in line. And so that’s the spectrum.

Mark Cavage: Will it ever be 100% secure? I think that’s like asking will we reach AGI? Will the agent ever be 100% intelligent? You can’t say 100% of anything and be credible.

Raja Iqbal: I did not expect a different answer. If you’d told me it was 100% secure, I would have called it. So the way we look at it: Docker is vetting them out, and the publisher — only get official MCP servers from the publisher. Notion would be the official Notion MCP server, vetted out by Docker.

Raja Iqbal: But the non-determinism in the agents — there is so much that can still happen. That’s how we use it, and…

Mark Cavage: And you get back to: you need to trust every facet of your stack. Sandboxing is the most root primitive — it puts everything in a bounded box you can control and reason about.

Mark Cavage: You then need tools to be secure and trusted, any code the agent generates to be secure and trusted. These things are all complementary. And even together, they’re necessary but insufficient. You really want something semantic-aware — where you can say, I want to run this tool but it can only access this part of my inbox, or these Slack channels, but not others.

Mark Cavage: I read something — I think 20% of the open Claude marketplace is malware at this point — so you can’t trust everything. But I want to run a tool, it does very useful things for me, and I need to say: you can only access this part of my inbox, that part of my spreadsheets, these Slack channels but not others.

Mark Cavage: The world is a very rich place with lots of data and lots of protocols. You need expanding circles of complexity that you can reason about and secure, so you can actually trust that your agent didn’t delete your database or send your Bitcoin wallet to scammers — whatever is possible in the wild world of things that are possible.

Chapter 10 — 37:18 | Will Containerization Survive the Agent Era? Raja asks whether containerization as we know it is the right primitive for the agentic world. Mark argues containers will remain the universal unit for shipping software, but the agent runtime needs sandboxing as a new, separate primitive.

Raja Iqbal: A more philosophical question — do you sometimes feel that containerization as we know it right now is the right primitive for the agentic world? Or do you think it will evolve? What might Docker look like three years from now?

Mark Cavage: It’s a very fair question. Containerization has been around for about a decade now, and it’s ubiquitous — much like Unix, it’s an entire ecosystem. 93% of the world runs containers in production. They’re everywhere.

Mark Cavage: Containers are absolutely an essential part of the agentic world, and these things can be complementary technologies. But agents actually require a different first principle, because the ecosystem has matured around containers being immutable. Agents, by definition, want to mutate everything about their world, all the time.

Mark Cavage: It’s not that you can’t use containers for agents — of course you can put agents in containers. I run every MCP server, whether from the Docker catalog or built myself, wrapped in containers. I build agents, I want to share one with a friend, I put it in a container. Containerization gives you a useful way to build, package, and share software. That was true yesterday and will be true tomorrow, whether for humans or agents.

Mark Cavage: The runtime execution — you need something that actually supports and embraces mutability. That’s where the sandboxing piece comes in. You can of course run containers inside a sandbox — you could call that double nesting or whatever — but containerization is always going to be the unit by which you ship secure software. It gives you a nice packaging artifact, the ability to describe deterministically what gets put together, what gets shared, it makes it repeatable and reproducible. It has a million great properties.

Mark Cavage: The running of most software will continue to be containers, and the 93% number will asymptotically approach 100%. But the agent runtime itself — at least the part that has the thinking — needs a primitive that is rethought with sandboxing. The sandboxing is consistent with the Docker toolchain and ethos, but it has a different primitive because the agent requires a fundamentally new one.

Chapter 11 — 40:21 | Building a Business on Mindshare in a Saturday Morning Development World Raja asks how Docker builds a business on top of enormous mindshare while the industry shifts under their feet. Mark introduces “Saturday morning development,” explains the durable evergreen problems beneath the chaos, and describes where the vast majority of the market actually is today.

Raja Iqbal: When I look at it now — this applies to the entire industry, every knowledge worker — but more so for Docker, you have an estimated 20 million-plus developers, billions of Docker pulls. And on top of that, add how quickly the industry is shifting at every layer: models, infrastructure, tools, frameworks, scaffolding. How do you build a business on top of that kind of mindshare and trust, while things are changing so quickly?

Mark Cavage: It is a curveball. I have this running joke — Tushar, who runs engineering at Docker, and I call it Saturday morning development. You wake up Saturday morning, read Twitter, Hacker News, Reddit, catch up, and suddenly you’re like, “I guess we’re throwing out everything and starting over next week.”

Raja Iqbal: Absolutely.

Mark Cavage: It’s very chaotic trying to keep up. The downside is I have very low confidence that any one feature you build isn’t going to be deprecated a week or two later.

Mark Cavage: The flip side, though: I think many of these problems are actually evergreen. Tying it back to what we discussed around building AWS — I went back and read papers from the mainframes. As ancient as that sounds, the durable problems are here.

Mark Cavage: I’m in a very privileged position — I get to talk to customers, up-and-coming developers, communities, anybody and everybody, because Docker is so ubiquitous. The vast majority of the world is in this mindset right now: we definitely like AI, great. We’ve gone through the era of Copilot and Cursor and tab complete — we like that.

Mark Cavage: We’ve adopted Claude Code and everything else. And it feels like right now, everybody’s in the mindset of: the actual unlock we’re trying to get to is true agentic development — where the agent can run autonomously and make decisions on your behalf. The bleeding-edge people are currently ahead of that, but the vast majority of the market is right there.

Mark Cavage: The things you have to solve are fundamentally around trust and safety — having confidence that what you’re running is what you think you’re running, and that it can’t actually do bad things. That’s unlock number one. And two: getting more of the population of people who want to write code — which has been 10x to 100x’d, because anybody can now pick up an agent and learn to write some code — to make the jump from “I talked to ChatGPT and I have this idea” to “I can actually build my stuff.”

Mark Cavage: When I look at that, there are some fairly evergreen problems: hard isolation boundaries, observability, controls, the ability to package and describe what you want. These core primitives of what made Docker Docker are still going to be the right things tomorrow.

Mark Cavage: For building a business around it — it’s very hard to predict which features any given developer or cohort will use. But most people understand we’re going to live in this world of agents. Agents cannot be 100% trusted. One could make a fairly cynical argument — perhaps they’re no worse trusted than humans, and maybe I never should have trusted all the people in the first place — but there’s a social contract.

Mark Cavage: Nobody thinks we’ll get to 100% trust anytime soon, so you have to build a new layer of defense. What we’re trying to do is balance the Saturday morning development with the evergreen problems. We have to help people scale, help more of the workforce adopt agents, help companies and individuals — whether it’s an individual or a CISO — sleep well at night knowing it’s not going to run amok.

Mark Cavage: We’ll change probably 50 times between now and when the market stabilizes, but it’s comforting to keep in mind: durable problems are durable for a reason.

Chapter 12 — 46:19 | CISOs, Tech Debt, and the 1000x Risk Problem Raja raises the CISO panic happening across enterprises. Mark shares a conversation with Docker’s own CISO that morning — and explains why 1000x productivity also means 1000x risk accumulation, from vibe-coded personal agents to “authored by Claude” pull requests overwhelming open source maintainers.

Raja Iqbal: I’ve interacted with a few CISOs, and they’re going crazy right now. It’s a completely new paradigm — not something they’re used to.

Mark Cavage: I was actually talking to our own CISO this morning, and he had a really astute point: for all of time, we’ve produced tech debt. If you’re a CISO, you go to sleep at night thinking, “There’s all this tech debt, I’ll pay it off later — I know I’ve got this orphan stuff, and that’s where all the risk is. The risk is in the things you don’t understand, can’t see.”

Mark Cavage: The more velocity goes up, the faster you accumulate tech debt and risk. And now we have this explosion where it is 100x — not even 10x, but 100x to 1000x more productive — which means you also 1000x the risk, because things are happening outside of your control and you’re accumulating tech debt.

Mark Cavage: Think of every single person in the company now vibe-coding their favorite personal agent. How on earth do you wrangle that? I think most CISOs — and most of us, whether you’re a CISO or not — should be sleeping a little bit worse at night right now. The entire supply chain seems like it’s collapsing around us. We’re seeing this explosion of what is effectively temporary code — who knows what happens to it over the next year or two.

Raja Iqbal: We’ve seen something very similar. Take LangChain — you implement one thing, and six months later LangChain completely re-architects, rewrites everything. What do you do with the way you were doing things before? In addition to how AI itself works — the non-determinism, the autonomy — on top of that, things move so quickly. It makes it very hard to keep things stable and secure.

Mark Cavage: Yeah, it’s…

Raja Iqbal: …and secure.

Mark Cavage: It’s hard for everybody. It’s really hard right now to be an open source maintainer. Docker is a very open source first company, and when I talk to other open source maintainers, everybody tells me the same thing: the number of pull requests that say “authored by Claude” — I can’t keep up, I don’t know what to do with this.

Mark Cavage: It’s hitting everybody — CISOs, maintainers. If you want to not have your own laptop credentials leaked and end up causing the next Axios-style breach, it’s hitting anyone, no matter what software you run. Everything we’ve built as an industry and in a society for software has been built on the notion of societal trust and humanity, and now you have these agents that can do 1,000 times what you could do before. We haven’t all figured it out yet. But it’s a fascinating place to find your way forward.

Chapter 13 — 50:09 | From Engineer to COO: Technical Background as a Superpower Raja asks whether Mark’s deeply technical background helps him as COO. Mark argues becoming an agentic company is fundamentally an engineering problem — and describes his own agent stack of 23-plus bots, including a PM agent and engineering agent that argue with each other.

Raja Iqbal: You’ve been deeply technical throughout your entire career, and now you’re Chief Operating Officer. Is that technical background helping you in any way?

Mark Cavage: Yes. My identity is my identity — I was born an engineer and I’ll be an engineer forever. A long time ago I transitioned to management, and I’m very intellectually promiscuous — I find myself interested in sales processes and marketing and legal and everything else. I like perennially learning.

Mark Cavage: But to answer your question on the engineering side: we’re almost engineering companies now, because if you want to think through how to actually have the agents do something and help us in some way — every facet of a business and company has to change. If you think about what it means to become an agentic company, whether in marketing, sales, or anything else — that’s an engineering and process problem.

Mark Cavage: To some extent I find yes, the engineering discipline helps — building agents into the flow of how something hits the website, to actually getting a call from somebody, to support tickets, the entire lifecycle of how we build and deliver and run a company. Introducing agents at every step of that feels like an engineering problem. Maybe I’m just self-justifying, but I find it helps. It’s a little bit of a superpower.

Raja Iqbal: If I look at it — deploying agents throughout your organization is also an operations problem, right? How do you organize them, allocate budgets, train them, handle compliance? Just like you have your human workforce, you have this AI workforce. And you’re the Chief Operating Officer for the AI workforce. There are parallels there.

Mark Cavage: Maybe a more pithy way of putting it — the budget one is funny, believe me, I worry about that — but the new skill required is that everybody has to be a little bit of a product manager and a little bit of a people manager. The new bar is: you’re now going to have a team that works for you. The team is not humans — it’s a bunch of robots.

Mark Cavage: For myself, I have my own agent stack — I think I have 23 or 24 now. I watch them. I’ve got a PM agent that competes with an engineering agent, and they argue, and they come back. It’s surreal — watching them, PM wants to ship more, engineering wants to cut scope, and the agents come back to me and tell me about the argument they had and what they settled on. “I can’t believe I’m watching you all do this. Okay, whatever.”

Mark Cavage: But the point is: that requires everybody to have that skill set and be able to manage a team. There’s a transition of culture and people needed to be able to work that way.

Mark Cavage: And then you have the company-level agents — sales forecasting, support reporting, engineering velocity, whatever it is. All those things need to be coupled together. We don’t have all the answers yet either. We’re still fumbling our way through: which do you pick, how long do they live, the one that was useful six months ago is no longer useful.

Chapter 14 — 54:19 | CFOs, Token Spend, and the Coming Optimization Wave Mark predicts the next 12 months will see CFOs demand ROI on token spend — and explains why right model, right task, right time will become the new engineering discipline. Raja and Mark also debate whether AI actually frees up human time or just fills it with more work.

Mark Cavage: On the budgeting topic — I think the next 12 months is the time when the CFOs of the world wake up and say, “Everybody’s spending thousands, or tens of thousands, a month on tokens. I would like my money back.”

Mark Cavage: We’re going to start seeing a real focus on optimization — I don’t always need to use Opus for a spell check on my email. You’ll see people doing specializations: right model, right task, right time.

Mark Cavage: All of my career I’ve been listening to the debate of how productive engineers actually are. How do you measure ROI? How do you measure velocity? You have pigs and chickens and all the scrum stuff — as an intern I was like, “Are you kidding me? I’ll just make more bugs and fix more bugs.” But there are always ways to try to measure productivity and ROI of engineering. It’s fairly easy with salespeople, it’s very hard with engineers and R&D.

Mark Cavage: Agents are forcing us to revisit a lot of that and take a harder look at: if I’m going to spend money on X, what’s the right amount, and what do I get back for it? The rate of growth of token expenditures is not going to stop, and it shouldn’t. But we’ll start seeing specialization — moving to more fine-grained models to actually control the growth of spend.

Raja Iqbal: From a CFO standpoint — maybe you’re spending tokens getting some job done. But what do you do with that time? What are humans doing with the time they’re reclaiming from AI? Are we having more meetings? Writing longer emails? What are we doing with that?

Mark Cavage: There’s a lot of rhetoric about none of us having jobs anymore. I don’t subscribe to that. We’ll all have a hard time going through this transition collectively, but like every other revolution before us, it should actually unlock a new level of productivity.

Mark Cavage: There’s a really good post on AI burnout — the addiction of being able to always ship one more feature at 11pm. But put that aside for a second. Instead of having more meetings, you should actually be able to increase the overall productivity of what exists in the world, and that should be a net benefit. Like any economic theory, we’ll have to figure out the balance, but my personal belief is: as the dust settles, we net it all out, and we look backwards — we should collectively be in a better place. At least that’s the theory.

Chapter 15 — 57:42 | Rapid Fire Raja closes with rapid-fire questions covering Mark’s daily tools, his bet on open models as the most impactful open source project in five years, a hot take on AGI, and a book recommendation from the 1980s that he says every technologist should read.

Raja Iqbal: Sure. We are way over time — let me close with rapid-fire questions. What is a tool you use every day that is in Docker?

Mark Cavage: Does Claude Code count? Does open source count? Docker. We use Docker, we use sandboxing, we use MCP — we use a lot of tools.

Raja Iqbal: Of course, Docker wasn’t excluded there. Most engineers bump into Docker almost every day.

Mark Cavage: We use Docker, we use sandboxing, we use MCP, we use a lot of tools.

Raja Iqbal: If you had to bet on one open source project that’s going to matter most in five years — which one?

Mark Cavage: Pick your favorite child? That’s a hard one.

Raja Iqbal: Maybe two or three, then.

Mark Cavage: Honestly — open models. I don’t think they’re quite all there yet, but that’s the one. If I look back in five years, I love UV, I love various tooling projects, I love Docker, but if I think about what’s actually going to be the transformational one we look backwards at — the day of open models is coming. Whether it’s Mistral, DeepSeek, or something we don’t know yet — today they feel like fringe, and I think that will change.

Raja Iqbal: Do you think they’ll evolve into small language models, or actually improve and catch up with the frontier models?

Mark Cavage: There’s so much money and so much access to chips going into the frontier models. I think open models will get good enough that you can use them for increasingly more — you’ll see a mix of SLM and “good enough.” We’ll always have frontier models, but today open models feel like fringe, and I think that will change.

Raja Iqbal: What is the most overrated thing you see right now?

Raja Iqbal: Right now.

Mark Cavage: AGI. I just don’t think transformers are going to get us there. Maybe I’m wrong — we’ll see if this podcast proves I’m the biggest idiot on the internet — but it does not seem to me that transformers are going to get us there. I want to see some belief that we’ll actually get there on the technology that will actually make it happen.

Raja Iqbal: Are you alluding to the fact that with the current state of architectures, hardware, computing — we may not get there?

Mark Cavage: Oh, God.

Raja Iqbal: …not get there?

Mark Cavage: We may eventually get there. I just don’t think we’ll get there in the next year. We’re on this aggressive timeline where the current LLMs will get us there, and I think we’ll need to see some new unlock — which I’m sure will eventually happen. I just think it’s not currently at the timeline of the expectations we have.

Raja Iqbal: Okay. Any book, article, or paper you’ve read recently that you’d recommend?

Mark Cavage: I’m going to give you the one I tell everybody. You should read The Soul of the New Machine. It’s an old book from the 1980s, about the era of going from many computers to microprocessors. I started this call talking about history, and everybody should read that book. You can read about the fascinating culture of what Silicon Valley and the technology industry were like in the late 70s and early 80s — and just apply the pattern in your brain: there’s them, there’s now, there’s them, there’s now, there’s them.

Chapter 16 — 01:01:53 | Closing Thoughts Mark closes with one piece of advice to his 25-year-old self: always be curious. Nothing is magic — you can always go a layer deeper.

Raja Iqbal: Maybe we’ll close here. One piece of advice you can give — maybe to your 25-year-old self.

Mark Cavage: Always be curious. People have asked me for a long time: what’s the one trait that tells you if somebody’s going to be successful? It’s curiosity.

Mark Cavage: Nothing is magic. It doesn’t matter if it’s an LLM, how an operating system works, or how a browser works — you can always go a layer deeper. Nothing is magic. Be curious, and don’t accept an answer as magic and stop there. Always be curious.

Raja Iqbal: Thank you so much, Mark. It was great having you.

Mark Cavage: Likewise. Thanks for having me.

Raja Iqbal: Thank you.