{"id":4580,"date":"2026-07-14T13:14:46","date_gmt":"2026-07-14T13:14:46","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/07\/14\/ai-engineer-worlds-fair-2026-the-runtime-is-where-agent-trust-is-won\/"},"modified":"2026-07-14T13:14:46","modified_gmt":"2026-07-14T13:14:46","slug":"ai-engineer-worlds-fair-2026-the-runtime-is-where-agent-trust-is-won","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/07\/14\/ai-engineer-worlds-fair-2026-the-runtime-is-where-agent-trust-is-won\/","title":{"rendered":"AI Engineer World\u2019s Fair 2026: The Runtime Is Where Agent Trust Is Won"},"content":{"rendered":"

We spent the week at AI Engineer World\u2019s Fair in San Francisco, on stage and on the floor. Here\u2019s what we heard, and where we think it lands for anyone building with agents.<\/p>\n

\n The SDLC is being rebuilt in public
\n <\/h2>\n\n

This week at AIE felt like a synthesis of what\u2019s been playing out in developer tools for the last few years, for anyone who\u2019s been watching. The software development lifecycle is reshaping itself into an AI-native SDLC, and the industry is naming the new jobs and developer concerns that come with this rapid transformation.<\/p>\n

The proof was in the track list: Evals, Context Engineering, Harness Engineering, Memory, Sandbox & Platform Engineering, Inference, plus a whole thread on \u201csoftware factories.\u201d Two years ago most of these phrases were far from being thought of as categories. Now each one is a discipline with its own sessions, its own vocabulary, and its own crop of companies on the expo floor built to solve that single problem.<\/p>\n

So what were most talks about? A little bit less of \u201ccan agents and AI do this,\u201d and more of \u201cgiven this way of building, what decisions and trade offs do we need to think about?\u201d Evals, loops, harnesses, context, memory, isolation, cost. None of this is brand-new, but it\u2019s all getting a whole new level of mindshare, as developers work out the new shape of creating software with AI. Even the model labs spent much of their stage time on how you build with<\/em> the model: the integration API, the harnesses, the ergonomics, rather than the model itself.\u00a0<\/p>\n

\n The job we care most about: securing where agents run
\n <\/h2>\n\n

Of all those emerging disciplines, sandboxing is the one that hit critical mass this year. There was a full track dedicated to sandbox and platform engineering, and the sessions inside it were still working out what a sandbox should even be: full VM, lightweight runtime, Kubernetes, something purpose-built. Talks focused on concerns such as running agentic sandboxes at scale and comparing isolation technologies head to head.\u00a0<\/p>\n

This is the job Docker showed up to talk about, across three sessions.<\/p>\n

Give agents more freedom by giving them less surface<\/h3>\n

Our EVP of engineering, Tushar Jain, gave the mainstage talk: \u201cUnlock Agent Autonomy: The Runtime for AI-Native Systems.\u201d The actors have changed \u2013 agents read and write whole codebases, spawn subagents, install dependencies, and call APIs across laptops, CI, cloud, and org boundaries, often unsupervised. Teams leaning into this shift are moving fast, but most organizations still won\u2019t let agents run autonomously, not because the model isn\u2019t capable, but because trust isn\u2019t there yet. This thinking draws on a concept security researcher Simon Willison has written about, the \u201clethal trifecta\u201d: any useful agent tends to end up with access to private data, exposure to untrusted content, and the ability to act in the outside world, all three, by design. No prompt or policy doc gets rid of that. The durable fix lives one layer down, at the runtime, which is where we spent the last decade: isolation, network policy, trusted images, credentials. Agents are just the next workload.<\/p>\n

An agent doesn\u2019t have to be malicious to be dangerous<\/h3>\n

Rowan Christmas, a staff product manager at Docker, made the risk concrete. In \u201cYOLO Mode, Safely: microVM Sandboxes for Any Agent,\u201d he ran a coding agent on his own laptop with nothing but read access, and no sandbox or unusual permissions. Within a few minutes it had pieced together a surprising amount about his online banking activity from what it could passively see. A destructive command like rm -rf is the obvious fear, but the mundane can bring risk: read access, plus untrusted content, plus the ability to act, is already enough to do damage. An agent doesn\u2019t have to be malicious to expose you. It just has to be able to see. The alternative Rowan showed puts each session in its own Docker sandbox based on a microVM, with a boundary you define across filesystem, network, and tools. It can run Claude Code, Cursor, Codex, or whatever you\u2019re driving.<\/p>\n

Once an agent can install packages, run Docker, and reach the network, which describes most genuinely useful agents, a hardware boundary buys you something you can\u2019t easily bolt on later. And where much of the scale conversation is cloud-first, built for fleets of agents running server-side, Docker\u2019s approach starts first on the laptop the developer already uses, because that\u2019s where most people actually run agents today. (We go deeper on the reasoning in \u201cWhy microVMs\u201d<\/a> and our comparison of sandboxing approaches<\/a>, including what the isolation costs you, because it isn\u2019t free.)<\/p>\n

Nobody\u2019s reviewing what your agents just installed<\/h3>\n

The third talk covered the tool layer. Jim Clark, a principal software engineer on our MCP team, spoke about \u201cWho Approved That MCP Server? Governing the Tool Layer,\u201d and opened with a line that got knowing laughs: \u201cshadow MCP\u201d. Developers install MCP servers faster than security can review them, and an unvetted server is a direct line to your data. That worry was all over the event, not just our session. Jim\u2019s demo put every server behind one org-managed catalog, vetted, signed, default-deny on anything unapproved, with the policy enforced live on stage.<\/p>\n

\n Where this leaves us
\n <\/h2>\n\n

So how does it come together? An agent is only as trustworthy as the boundaries around it, and those boundaries live in three places: what it builds on, where it runs, and what it can reach. Miss any one of them and the other two won\u2019t cover for you. A hardened image dependency is no help if the agent can still read your whole filesystem unsandboxed, and a locked-down sandbox is no help if the agent can call an unvetted MCP server straight out of it.<\/p>\n

That was the case Docker made all week: harden what agents build on, isolate where they run, control what they can reach, and govern all three from one place. We think this is the part that has to be solved first, because it\u2019s where AI-native developers will start building the apps of the future.<\/p>\n

Further reading:\u00a0<\/p>\n