Sandboxes for AI agents and a new Git: how I ship kononov.dev through local checks

In one week of October, several pieces of news came out about the same thing: AI agents write code faster than the infrastructure can check it and ship it safely. Anthropic replaced Git with its own system, GitLab is rewriting the server side of Git for agents, and Docker and Pulumi are showing sandboxes from which an agent can't reach the production database. For a business owner this matters for a simple reason: if your developer or contractor already uses an agent, the question “where can the agent reach” is about your data.

What came out and from whom

On October 13, Simon Willison broke down Anthropic's article about its own version control system, Scion. In May 2026, about 2,500 changes a day were landing in the company's monorepo; in September, more than 30,000. The main branch history is almost 100 GB, with around 25 million checkouts a day for CI alone. A team of seven built the system, and the move off Git took five months.

GitLab on October 13 answered with its next-gen SCM: the Git protocol stays, with a new architecture and a shared object store underneath. By their numbers, a single agent call in ordinary Git can mean 5 to 10 GB of traffic and more than 30 seconds of setup for one question. In early internal tests they got up to 50 times faster and up to 1,000 times less traffic, with the caveat that these are peak values under specific conditions. The product is in closed beta.

Two days later, on October 15, GitLab described its automated review, Code Review Flow: it runs as a CI job on your own runners, costs $0.25 per review, and can be turned on for a project, a group or a whole instance at once. Giving the agent the right to approve changes or ask for rework is on the roadmap.

Docker on October 16 retold the 2026 Stack Overflow survey, more than 30,000 respondents from 169 countries. Only 7% of developers trust AI output in important work decisions, and 48% trust it only if they can check it themselves. Against that backdrop Docker launched Cloud Sandboxes and the Sandbox Kit specification, which it promises to hand over to the CNCF.

Pulumi on October 21 published a workshop recording, and that is where the most useful story is. In April, an agent at the company PocketOS, working on a routine task in staging, deleted a production data volume in 9 seconds: it took an API token from an unrelated file and assumed the deletion was limited to staging. The hosting provider restored the data two days later. The company's founder wrote that a system prompt only advises the agent. So in the workshop the Pulumi Neo agent ran inside a Docker Sandbox microVM, saw only the allowed files and hosts, and a proxy substituted the real token on the way out.

Vercel on October 19 showed a durable harness: a log of every agent step, so that after a crash the task continues from where it broke off. One detail there matters to me: every agent tool is marked as to whether it can be retried after a failure. Reading a file can be retried; refunding a customer can't.

What this means for a company with one server

Take a service company where a contractor maintains the website and the CRM integration. He connected an agent to the repository, and the repository holds a file with the CRM token and database access. The agent gets the task “clean up the test requests,” finds the token and cleans up requests everywhere it can reach, like the PocketOS agent, only on a smaller scale.

The conclusion from the news is simple: the limit has to sit where the agent can't argue with it, in the token's permissions and in the release process. The PocketOS agent read the instruction in the prompt and deleted the volume anyway.

How I do it

The kononov.dev site runs on Next.js, Node.js 24 and SQLite in Docker, on a shared server with 2 GB of memory behind Nginx, next to the “Coffee Together” service. AI has sped up my development several times over, but the architecture and the main decisions are mine, and I check what the tools produce. For code it looks like this: a change goes through a local pipeline of checks in Docker, tests and a build, and only then lands on the server. On the server the old instance stops before the new one starts, and if the build runs out of memory, the image is built off the server and uploaded ready-made.

At the PDR company in the US, where I have been the technical partner since 2021, security questions come to me: the system has several layers of protection and backups, and since 2022, when we got our own server on Debian in Google Cloud, there have been no serious failures that needed a recovery. Sandboxes for agents are something I would test: the task is the same one PocketOS had, and for me it is currently handled by permissions and the release process.

What I would do

Check what the agent sees. Remove tokens and passwords from the repository and from the working machine's environment variables; leave the agent access only to the code and a test database.

Run the agent in a separate container or sandbox with no network access to the production server. Docker Sandboxes from the news is one option; an ordinary container with a restricted network works too.

Put the agent's changes through the same pipeline of checks as a human's changes: tests and a build.

Leave irreversible actions to a person: releasing to the server and deleting data. That is the same “never retry” mark from the durable harness, only at the process level.

Keep backups with a tested restore. What saved PocketOS was that the hosting provider could bring the data back two days later. I prefer to keep the restore in my own hands.

Related materials

I wrote about running long tasks outside the request and controlling retries in the article Workers: background tasks and retries. Direction: infrastructure you can ship and restore, with a live example in the case about technical partnership with a PDR company. From other reviews: what I allow an AI agent on a production server and how I split work with an agent. Earlier I looked at API mocks and separate databases for checking a release and preview environments without access to working data. If your contractor already works with an agent and you don't know where it can reach, tell me how your release process works today. Discuss your task.