Agents

What Changes When Coding Agents Can Act?

By Omer DemirOct 6, 2026⏱ 7 min read👁 — reads⧉ — copies

AI disclosure: This article was moderated by AI.

Coding agents can research a repository, edit code, run tests, and prepare a pull request quickly. Once they can execute commands and publish changes, however, speed is no longer the hardest problem. The harder problem is deciding what they should be allowed to do and proving what they actually did.

That question came up during a customer workshop about Agentic SDLC, the software development lifecycle when agents do more than suggest the next line of code. The teams in the room already had workflows they trusted. They did not need another diagram showing an agent calling tools in a loop. They needed to know how agents could join those workflows without replacing the controls around them.

I had run into a smaller version of the same problem in my own work. A coding agent would finish a task with a polished summary, but the summary was not an execution record. It could not tell me which commands ran, what the agent could reach, whether the tests came from the final revision, or which identity had authorized an external action.

The workshop turned those annoyances into a research agenda. I left with six requirements:

• Adapt to the team’s workflow instead of replacing it.
• Make every meaningful action observable and traceable.
• Treat the agent, its instructions, and repository content as untrusted.
• Isolate execution without making every team operate a new platform.
• Let teams bring their own agents, skills, tools, and evaluation suites.
• Put evaluation in the promotion path for every agent version.

Those requirements led me through incident reports, sandbox architectures, agent frameworks, governance projects, evaluation tools, and coding-agent products. They also led to Autodev, a pet project I used to test how the pieces behave when they have to share one control plane.

This is the introduction to that research, not an argument that Autodev has solved it. The project made the questions concrete. The series shares what I found so readers can judge the conclusions and the implementation separately.

Four questions became four parts

Splitting the research into four parts avoids pretending that “agent governance” is one feature. Each part asks a different question:

1. What changes when coding agents can act? This introduction explains the workshop problem, the research method, and why I built an integration project.
2. Isolated execution for coding agents. The next post covers sandbox incidents, containers, gVisor, Kata Containers, Firecracker microVMs, Docker Sandboxes, managed execution, and the current coding-agent product landscape.
3. Agent governance and evaluation. This will cover identity, delegated authority, policy, evidence, and evaluation as a promotion decision rather than a final scorecard.
4. User experience and the collaboration space. This will examine how people supervise agent work, inspect evidence, intervene, approve risky actions, and collaborate without watching a terminal scroll all day.

Parts three and four are upcoming. I am naming them now because they put boundaries around this series. Isolation cannot answer who authorized an action, and policy cannot make a poor collaboration experience usable.

The workshop question was bigger than orchestration

Most agent demos focus on the loop inside the agent: think, call a tool, observe, and continue. That is useful, but an organization has to answer questions outside that loop:

1. Which agent version and instruction set produced this change?
2. Which repository paths, tools, network destinations, and credentials could it reach?
3. Which tests, scans, and policy decisions actually ran?
4. Who approved the irreversible actions?
5. Is the candidate agent measurably safer than the version it would replace?

A prompt cannot be the final authority for any of these. Prompts are input to the same model we are trying to constrain. Repository instructions, imported skills, model output, and tool descriptions can also contain mistakes or hostile text. The control has to sit elsewhere.

That became my working definition of a governed Agentic SDLC: the agent may propose actions, but a separate system decides what it can do, where it can do it, when approval is required, and what evidence must exist before the result moves forward.

The model proposes work. The control plane owns authority, execution boundaries, evidence, and release. That separation became the core of Autodev.

The pieces only make sense at their boundaries

I started by researching each requirement separately. That worked until the boundaries began to overlap.

A sandbox can keep a process away from the host, but it does not decide whether the agent should be allowed to push a branch. A policy engine can deny git.push, but it needs a trustworthy identity, task context, and evidence about the request. An evaluation can show that an agent usually follows instructions, but it cannot contain the next run. An activity log can record an action without making it understandable to the person who has to approve it.

The same coupling appears in failure handling. Detecting suspicious network traffic is useful, but the execution layer must be able to stop the workload. Stopping it is not enough if the evidence disappears with the sandbox. Preserving the evidence is not enough if every agent shares one API key and nobody can determine which definition acted.

This is why bringing the pieces together seemed useful. The value was not a longer feature list. It was being forced to define the contracts between execution, identity, policy, evidence, evaluation, and human approval.

Autodev became a test bench, not the answer

I could have ended the research with a comparison table. Instead, I built enough of a system to find out where the abstractions stopped agreeing.

Autodev gave me one place to connect agents, isolated worktrees, execution providers, typed tools, policy decisions, telemetry, evaluation runs, and human approvals. Implementing those connections exposed questions that product documentation alone did not answer. What happens when an agent definition changes after evaluation? Which evidence survives sandbox cleanup? Does a denied tool call appear in the same timeline as an allowed one? Can an imported skill request authority, or only describe behavior?

Some choices held up. Keeping authority outside the model still makes sense to me. Treating imported agents and skills as untrusted data also held up.

Other choices are provisional. Local Docker containers are convenient, but they are not the isolation boundary I would choose for hostile multi-tenant workloads. Identity and delegation are only partially implemented. The control plane still has privileged access that would need a narrower broker in a hosted deployment.

That is the role of Autodev in this series. It is an open, inspectable composition of the ideas, including the unfinished parts. It is not a reference architecture, a compliance claim, or proof that these components belong together in exactly this form.

I separated product claims from implementation evidence

The research used three kinds of source, and I tried not to treat them as interchangeable.

Incident reports show how boundaries failed in practice. They are useful because failure paths rarely match the simple threat model. Shared artifact services, DNS, package infrastructure, credentials, and delayed shutdown all matter.

Product and project documentation explains intended architecture. I used it to compare isolation boundaries, network controls, credential handling, audit features, agent identity, and evaluation workflows. Documentation can tell me what a product claims, but not whether every control behaves that way under attack.

Implementation work tests whether the ideas compose. For claims about Autodev, I used source code, tests, manifests, and generated evidence rather than its overview. The repository’s pyproject.toml, web package.json, and compose.yaml remain the source of truth for dependencies. Missing and partial controls are tracked in an evidence-based governance status matrix.

This method has limits. I did not independently penetration-test the commercial products in the comparison. I have not benchmarked every isolation technology under the same workload. Some of the incident material describes fast-moving systems whose mitigations will change.

My starting verdict: integration is the research problem

I began by asking how agents could fit into existing engineering workflows. My current verdict is that no single sandbox, policy engine, evaluation framework, or interface answers that question. The difficult work sits between them.

An execution boundary needs policy and a tested stop path. Policy needs identity and task context. Evaluation needs to affect promotion rather than produce a report nobody uses. Evidence needs a collaboration surface where a person can understand and act on it. Prompts can help at every stage, but they should not own authority at any stage.

Building Autodev was useful because it made those dependencies impossible to ignore. Whether its particular implementation is useful is a separate question, and the code is open for that reason.

Part two examines isolated execution and the coding-agent product landscape. It starts with recent sandbox incidents, then works through the trade-offs among shared-kernel containers, userspace kernels, microVMs, and managed environments before returning to what Autodev currently does and where that choice falls short.

#agents#agentic-sdlc#governance#sandboxing#evaluation#autodev