Build with Agents: Delegated Coding, Mandates and Sandboxes

A coding assistant waits for the developer to type. A coding agent does not wait: given a task, it reads the repository, plans, edits many files, runs commands, reads the output, tries again and opens a pull request. This chapter concerns D3 Build and D4 Prove: how a developer directs such an agent within a written mandate, what the sandbox, credentials and budgets around it must be, how a run is recorded, who can stop it from outside the pipeline it uses, and whether agents should write and merge the code. Chapter 7 treated the tools of the craft up to the agentic mode; Chapters 9, 10 and 11 treat review and tests, the toolchain as an attack surface and the release path. Here the question is narrower: what authority does the developer give, to what, and how is it taken back?

The chapter shows the mandate and the run record as artefacts that belong in version control, separates three acts that are often confused (writing, merging and deploying), and stages the debate on whether agents should write and merge the code, with a verdict by class of work.

A coding agent run: requester, one-run identity, sandbox, policy point, independent checks, named reviewer, merge rule and a stop path outside the pipeline

Figure 8.1: A coding agent run with its boundaries: the identity, the policy point and the stop path sit outside the agent, and the oracle and the reviewer are independent of the generator.

What a coding agent is

A coding agent is a program in which a model, given a task, repeatedly chooses a tool call (read a file, edit a file, run a command, search, query a service), receives the result and chooses the next call until a stopping condition is met. The model suggests the next step; the harness around it executes the step. That distinction matters for everything that follows, because the model has no authority of its own. All authority is whatever the harness, the sandbox and the credentials allow, and a mandate is the document that says what that is.

The agent differs from the assistants of Chapter 7 in four ways that change the risk. It acts over many steps without a person reading each one. It runs commands, so its effects are not limited to text. It touches many files, so the diff a reviewer receives is larger than any suggestion a developer accepted line by line. And it can be started by something other than a person: a ticket, a schedule, an event. The usage modes of the series (AI Governance, Chapter 2; AI Platform and Security, Chapter 2) place it in two modes that are easy to confuse.

Mode Coding form Identity it acts with Where this book treats it
Mode 2 Embedded workplace assistant Completion and chat in the editor The developer's own Chapter 7
Mode 3 Agentic work tool A person starts one task; the tool plans, edits several files, runs commands and opens a pull request Normally the developer's; this chapter recommends a task-scoped identity of its own This chapter
Mode 4 Built AI application A purpose-built assistant on the group platform, such as the test-drafting assistant HM-DEV-002 A service identity Chapter 9
Mode 5 Autonomous production agent Started by a trigger, with a standing identity and permissions of its own Its own, standing Neither organisation uses one for code

AI Red Team, Chapter 6, established that the usage mode, not the model, sets the risk: in Modes 1 to 3 AI acts with a person's identity, while a Mode 5 agent acts with an identity and permissions of its own and becomes a privileged machine insider (164, Nordqvist, 2026). For coding, the first half of that statement is a trap. A developer's credentials are broader than any one task needs: read access to many repositories, the ability to push, often access to test data and secrets. An agent that acts as the developer can do whatever the developer can, including what the developer would never do in this task. The design recommended here keeps the agent in Mode 3, since a named person starts every run and the authority ends with the run, but gives each run an identity of its own, issued for one task and one repository and expiring with the run. The mode is set by who starts the agent and how long its authority lasts, and not by the label on the product.

What the evidence says about agents so far

Four findings bear on how much weight an agent's output can carry, and none of them is about an organisation like Nordvik Region or Hansa Mutual.

First, benchmarks are narrow. SWE-bench, a benchmark of 2,294 software engineering problems drawn from real GitHub issues in 12 popular Python repositories, reported in 2023 that the best model tested, Claude 2, resolved 1.96 per cent of the issues (189, Jimenez et al., 2024). Later systems have scored much higher; the figure shows that a resolve rate depends on the benchmark, the date and the harness. Second, a benchmark's own checks can be weak. A 2025 empirical study of the patches of three issue-solving tools on SWE-bench Verified found that 7.8 per cent of all patches counted as correct still failed the developer-written test suite, and estimated that such weaknesses inflated reported resolution rates by 6.2 absolute percentage points (179, Wang et al., 2025). The lesson for a development organisation is general: a patch that passes the tests it was shown is not thereby right, and the tests must be better than the patch.

Third, perceived and measured effects can diverge. In a randomised trial of 16 experienced open-source developers working on 246 tasks in mature projects they knew well, allowing early-2025 AI tools increased completion time by 19 per cent; before the study the developers had forecast a 24 per cent reduction, and afterwards they estimated a 20 per cent reduction (63, Becker et al., 2025). The study concerned assistants of early 2025, not the agents of this chapter, and one trial of 16 people in their own codebases does not generalise to other developers or tasks; its use here is to show that a developer's impression of a run is not evidence about it. Fourth, the DevOps Research and Assessment (DORA) programme reported for 2025, from nearly 5,000 respondents, a positive relationship between AI adoption and delivery throughput and a continuing negative relationship with delivery stability, which the report attributes to increased change volume overwhelming weak controls (42, Harvey & DeBellis, 2025). Survey evidence shows association, not cause. Together the findings say that the checks must be independent and strong, and that the cost of weak checks shows up downstream.

The mandate

A mandate manifest (MND-*) is the written, versioned statement of what an agent may do, with what, on what, for how long and at what cost, and who can stop it. AI Red Team, Chapter 7, introduced it for security agents, The Transformed Security Architect, Chapter 13, for the architect's AI team, AI Purple, Chapter 14, for the loop's agents and AI Operations, Chapter 16, for operations agents; in each the mandate is a document that the agent's harness enforces and that the agent cannot edit (164, Nordqvist, 2026); (166, Nordqvist, 2026); (169, Nordqvist, 2026); (170, Nordqvist, 2026). For coding agents and assistants the identifiers are MND-NR-DEV-* and MND-HM-DEV-*.

The mandate is subordinate to the delegation profile. DLG-HM-DEV-01 sets the ceiling per class of development work (Chapter 4); a mandate may lower a level for one agent and may never raise it. A ceiling is not a licence: the mandate states what this agent, in this team, with this evidence, is allowed to do under the ceiling. The mandate of the agent pilot in the claims core delivery team of Hansa Mutual shows the fields.

mandate:
  id: MND-HM-DEV-02
  version: 2
  effective: 2030-10-07
  decision: AIDR-1158
  subject: agentic work tool, claims core delivery team, Mode 3, self-hosted models in Frankfurt
  owner: Stefan Brückner            # tech lead, ROLE-HM-TCL-01
  accountable: Dr. Philipp Reinhardt
  stop_holders: [Stefan Brückner, Lukas Frey, Hansa Forge on-call]
  review_due: 2031-01-07
  identity:
    issued_by: Hansa Forge identity service    # outside the agent and the pipeline
    scope: one run, one repository, expires with the run
    started_by: a named developer (the requester)
  delegation:                        # DLG-HM-DEV-01 is the ceiling; this mandate only lowers it
    generate: {level: 2, outside: [security-critical, payment]}
    refactor: {level: 2}
    test: {level: 1, note: drafts only, never the oracle for the same change}
    document: {level: 2}
    review: {level: 0}
    migrate: {level: 0}
    deploy: none
  may:
    - read the repository and its history
    - run build, unit tests and linters in the sandbox
    - read from the package proxy
    - push to one branch named agent/<ticket> and open one pull request
  never:
    - write to protected branches, CODEOWNERS, pipeline definitions or this mandate
    - write to verification/oracle/** or to any security-critical or payment path
    - read or write secrets, production data or the claims database
    - approve or merge a pull request
    - reach any host not on the proxy allow-list
  budgets: {wall_minutes: 45, tool_calls: 200, files_changed: 25, cost_eur: 6}
  notify_owner_when: [any package name is refused by the proxy]
  halt_when: [a write to a forbidden path is attempted, a budget is exceeded]
  record: RUN-HM-*, written by the sandbox host and not by the agent
  telemetry: by team, minimum group size 5, never by named developer

Three fields carry most of the safety. The never list closes the routes by which an agent could change its own governance: its mandate, its credentials, the pipeline gates, the review rules and the test oracles. This is the second of the Level 4 prohibitions of the book, applied at every level, since an agent that can edit the thing that checks it is not checked. The identity block makes the credential something the identity service issues and revokes, so that stopping the agent does not depend on the agent. And notify_owner_when records a lesson of March 2030, described in the profile: a coding agent in the Mode 3 pilot proposed a dependency whose name did not exist in the registry, the Hansa Forge package proxy refused it, and a later review found two further refused names that nobody had been told about (FND-HM-2030-0012). The proxy had worked; the owner had learned nothing. Version 2 of the mandate adds the notification. Chapter 10 treats package hallucination as a class of supply-chain risk.

Practical guide: writing a mandate for a coding agent

Purpose. Give a team a mandate for a coding agent that a platform engineer can enforce and an auditor can read. Roles. The tech lead (owner), the engineering manager or head of development (accountable), a platform engineer (enforcement), a test engineer (the oracle), the works council or union representative where the telemetry is covered by an agreement, and the data protection officer if personal data is in reach. Inputs. The delegation profile, the repository inventory with code-ownership records, the classification of the code (security-critical and payment paths, special-category data), the package and network policy. Steps.

  1. Name the task class the agent will be given (for example refactoring within a service, test drafts, documentation) and the repositories. Exclude the security-critical and payment paths and any repository without a living owner.
  2. Set the level per work class under the ceiling of the delegation profile, and write down the evidence for each level and its age.
  3. List what the agent may do and what it may never do; put the never list in terms of paths and actions the sandbox can enforce, not in terms of intent.
  4. Give the run an identity issued by a service the agent cannot reach, scoped to one repository and one run.
  5. Set numeric budgets and halt rules, and decide who is told when a rule fires.
  6. Name the stop holders, at least one reachable out of hours, and the mechanism outside the pipeline.
  7. Name who writes the record and where it is kept, and agree with employee representatives what the record contains about people.
  8. Set the review date. Lowering a level takes effect at once; raising one is the decision of the accountable person, recorded as an AI Decision Record.

Artefact. A versioned MND-*-DEV-* manifest in the repository that holds the team's governance records, with an AIDR for the decision.

Sandboxes, credentials and permissions

The sandbox is the harness that makes the mandate true. It is not a defence against a model that intends harm, since a model intends nothing; it is a boundary that holds whatever the model produces, whether the cause is an error, a misreading of the task, or text in a file that the agent read and treated as an instruction. AI Platform and Security, Chapter 19, set the general rule that containment must not depend on intent: task-scoped credentials, default-deny egress, control artefacts outside the agent's reach, budgets and a stop path outside the system they stop (163, Nordqvist, 2026). This section applies it to code.

Filesystem and process. The agent runs in an ephemeral container with a copy of one repository. It cannot read the developer's home directory, other repositories, shell history or credential stores. Anthropic's engineering team describes the same pairing for its own product: filesystem isolation so that a compromised agent cannot modify files outside the permitted directories, and network isolation so that it cannot exfiltrate data or fetch malware, and notes that either alone is insufficient (38, Dworken & Weller-Davies, 2025).

Network. Egress is denied by default. The only reachable host is the organisation's package proxy, which serves approved registries and refuses unknown names. Both organisations already run one: the platform team at Nordvik Region and Hansa Forge at Hansa Mutual. GitHub's documentation of its own coding agent describes a comparable control, a firewall that restricts the agent's access to the internet, together with a single pushable branch, simple push operations only and no direct Git commands, workflows that do not run on the agent's code until a person with write access has reviewed it, and a rule that the user who asked for a pull request cannot approve it (39, GitHub (n.d.), n.d.). These are one vendor's documented defaults and not an assurance for any organisation; they are useful as a checklist of the controls a mandate should demand of any product, including the last one, the separation of requester and approver.

Secrets. The agent holds none. Build and test run against fixtures and synthetic data. Where a task needs an internal service, the sandbox host injects a short-lived, narrowly scoped token for that service and for that run. The secret in the prompt, the case of March 2030 at Nordvik Region (INC-NR-2030-0071), is the same lesson from the other direction: a consultant pasted a connection string into an unapproved public assistant, the platform team rotated the credential within 40 minutes, and no access from outside was found. A boundary that never exposes the secret to the agent does not rely on a person remembering not to paste it.

Tools. The OWASP Top 10 for LLM Applications 2025 names Excessive Agency as one of its ten risks and traces it to excessive functionality, excessive permissions and excessive autonomy; its mitigations include offering only the extensions needed, preferring granular tools to open-ended ones such as a general shell, granting the minimum permissions downstream, enforcing authorisation in the downstream system instead of relying on the model, and requiring human approval for high-impact actions (230, OWASP, 2025). For a coding agent this means a list of tools (read, edit within paths, run named build and test commands, open a pull request) in place of a shell, and enforcement by the sandbox host, not by an instruction in the prompt.

Untrusted input and the rule of two. A coding agent reads content that other people and other systems wrote: issues, comments, documentation, dependency files, command output. Text in that content can be treated by the model as an instruction. This class of weakness, prompt injection, is listed first in the OWASP Top 10 (230, OWASP, 2025), and Chapter 10 treats it in detail; this chapter needs only the design consequence. Simon Willison named the combination to avoid, access to private data, exposure to untrusted content and the ability to communicate externally, the lethal trifecta (40, Willison, 2025), and Meta's security team proposed a working rule, the Agents Rule of Two: within one session an agent should satisfy no more than two of three properties, that it can process untrustworthy inputs, that it can access sensitive systems or private data, and that it can change state or communicate externally; if a task needs all three, it should not run autonomously and needs supervision such as human approval (37, Meta, 2025). Both are practitioner proposals and not tested standards; they are used here because they turn a vague worry into a design check. The agents of MND-HM-DEV-02 read untrusted content and can change state in a branch, so they must have no private data and no external communication: no secrets, no production data and egress through the proxy only.

Budgets. Wall time, tool calls, files changed and cost are limits that the sandbox host enforces, not targets. They bound the damage of a loop that does not converge, and they bound the review burden: a limit of 25 changed files per run is a statement about what a reviewer can read.

Approvals and fatigue. A sandbox also reduces how often a person must be asked. Anthropic reports that its sandboxing "safely reduces permission prompts by 84%" in its internal usage, without describing the method or the baseline, so the figure is a vendor claim (38, Dworken & Weller-Davies, 2025). The mechanism is independent of the number: a person asked to approve every step approves by habit, and a boundary that makes most steps safe leaves the person the few that are not. Human oversight depends on attention, and attention is spent by the number of requests; the automation-bias literature reports that reliance on automation reduces checking (57, Parasuraman & Manzey, 2010).

Stop paths outside the agent

An agent can be stopped in three places: inside the agent (it is told to stop), at the harness (the run is halted) and at the identity (the credential is revoked). Only the last two are stop paths in the sense of the series. AI Platform and Security, Chapter 19, and AI Operations, Chapter 17, set the rule that the stop path must work when the system it stops does not; AI Threat, Chapter 30, added that the right to stop must be cheaper to exercise than the right to continue; and AI Operations, Chapter 22, added that the stop right includes a holder reachable out of hours through a mechanism outside the platform, drilled within 90 days (163, Nordqvist, 2026); (165, Nordqvist, 2026); (170, Nordqvist, 2026). For a coding agent this has concrete consequences.

The stop must not run through the pipeline the agent's pull requests trigger. If the agent is stopped by a pipeline job, a broken pipeline leaves it running. The mandate therefore names two mechanisms outside the pipeline: revoking the run's identity at the identity service, which removes the agent's ability to push or read, and disabling the runner pool in the orchestration console, which halts all runs. Any holder named in stop_holders may use either without approval, and one holder must be reachable out of hours. A stop in good faith is not a failure, and the mandate says so.

Stopping an agent does not undo what it did. The Revert test of the stewardship principle is separate: the owner of the changed code must have the authority, access and time to roll back or fix the change, outside the pipeline that shipped it. For work that stays on a branch, revert is deleting the branch. For work that has been merged, revert is a revert commit and, if the change was released, the rollback of the release path (Chapter 11). For an irreversible action on production data, revert does not exist, and the only control is that the agent has no credentials that could take the action. The account of a coding agent that reportedly deleted a production database during a code freeze in July 2025, catalogued by the AI Incident Database from five press reports and no primary post-incident report, is read here with that caution: the reports disagree on whether a database or a codebase was affected, and the central claims come from the customer concerned (33, AI Incident Database, 2025). If the reported account is accurate, the instruction not to change anything was an instruction, and what was missing was a boundary. That is the series' conclusion on agents as well-meaning insiders: instructions lower the rate of unwanted behaviour, but only boundaries set a ceiling on its consequences (163, Nordqvist, 2026).

Run records

A run record (RUN-NR-*, RUN-HM-*) is the evidence of one agent run. It exists so that a reviewer can see what was done, so that an owner can reconstruct and revert it, so that an incident reviewer can follow it, and so that the organisation can measure outcomes instead of impressions. The sandbox host writes it, not the agent, since a record written by the thing it records proves little. It states the mandate under which the run happened, the inputs (task reference, base commit, model and version as the host recorded them), the actions (files read and changed, commands run, what was blocked), the checks and who wrote them, the named reviewer, the three stewardship tests and the outcome. The run below is a sample from the platform team of Nordvik Region, which restricts its agentic tools to drafting infrastructure code and runbooks and never to applying change.

run:
  id: RUN-NR-2030-0019
  mandate: MND-NR-DEV-01
  mode: 3
  level: 2        # mandate started at Level 1; AIDR-1116 (Chapter 16) raised drafting to Level 2 from 2030-11-18
  started: 2030-11-18T09:12:00+01:00
  ended: 2030-11-18T09:31:00+01:00
  requester: Maja Lindqvist
  task: PLT-2217, add a retention setting to the log-storage module of the Spring golden path, update the runbook text
  base_commit: a41f9c2
  model: open-weight coding model, self-hosted on the Region's reserved capacity (version as recorded by the host)
  sandbox: ephemeral container, egress only to the package proxy, no secrets
  actions:
    files_read: 14
    files_changed: [modules/log-storage/main.tf, modules/log-storage/variables.tf, runbooks/log-retention.md]
    commands_run: 9
    blocked: [fetch from an external module registry, denied by egress policy]
    outside_task: [README.md edited, reverted by the reviewer]
  checks:
    oracle: golden-path policy tests, written by the platform team on 2030-09-02, path write-denied to the agent
    result: pass
    plan_shows_changes_outside_module: 0
  review:
    reviewer: Joakim Wester
    minutes: 22
    understand: explained in the pull request without the tool, one paragraph
  owner: platform team, golden-path repository
  revert: git revert of the merge commit; the pipeline applies only after approval
  outcome: merged 2030-11-19, applied by the pipeline 2030-11-21
  prompts_retained: false      # pending MBA-NR-2030-03

Two things in the sample are deliberate. The run record holds the agent's actions and the task reference, and does not retain the engineer's conversation with the tool. MBL-NR-IT-2027-01 requires that a tool that logs engineers' queries or commands is negotiated before it is switched on, and the negotiation record MBA-NR-2030-03 on developer tooling and telemetry is open (Chapter 22). A run record that served as a log of what a named engineer typed would be a different instrument from one that records what an agent did on a ticket. And outside_task is a field because the sample is honest: the agent changed a file the task did not mention, and the reviewer, reading the diff against the task, removed it. Run records are also records under the Region's public-access and archives rules, and whether prompts to coding tools are archival records is an open question for its archivist and legal counsel.

One class that merges: patch-level dependency updates

The Hansa Mutual delegation profile contains one Level 3 Bounded class, patch-level dependency updates in repositories outside the security-critical and payment paths, merged by the pipeline after a human approval of the class and not of each update (MND-HM-DEV-01). It is the case on which the debate turns, because it is a class in which software merges code and the organisation has said so in writing.

mandate:
  id: MND-HM-DEV-01
  version: 1
  effective: 2030-10-14
  decision: AIDR-1153              # the class is approved within DLG-HM-DEV-01
  class: patch-level dependency updates
  level: 3
  level_name: Bounded
  owner: Lukas Frey
  accountable: Dr. Philipp Reinhardt
  conditions:
    update_type: patch version only
    list: approved-dependencies.yaml, changed only by two-person review
    repositories: outside security-critical and payment paths, each with a living owner
    required_checks: [build, unit suite, verification/oracle suite, licence and provenance diff, package proxy admission]
    merge: pipeline merge rule owned by Hansa Forge; the agent identity holds no merge right
    deploy: unchanged, the change process applies
    window: not inside a freeze for a critical or important function
  route_to_human_when: [new transitive dependency, change of publisher, licence change, any check fails]
  suspend_class_when: [two merged updates reverted within 14 days, evidence older than 90 days]
  stop_holders: [Hansa Forge on-call, any repository owner for their own repository]

What makes the class safe or unsafe can be stated as conditions. The set of eligible updates is closed by a list that humans maintain. The check that decides is the repository's own verification suite and a provenance comparison, none of which the update can alter. The merge is performed by a rule that the platform team owns, and the agent identity has no right to merge, so an agent that wanted to merge could not. The class stops at merge: release follows the change process that the DORA-based change policy of AI Operations requires, and Article 9(4)(e) of Regulation (EU) 2022/2554 asks for documented ICT change-management policies, procedures and controls so that changes are recorded, tested, assessed, approved, implemented and verified in a controlled manner (2, European Union, 2022). And the class carries its own suspension rule in numbers. What the profile does not contain is a measured result: the class is new, the evidence is not yet 90 days old, and the review date exists to find out.

The debate: should agents write and merge the code?

The question is put in its plainest form because that is how engineering managers and boards ask it. The four steps follow the structure the book uses for its debate chapters.

The case for concern

The concern is that responsibility leaks out of the system at the point of merge. Writing is a proposal; merging is the moment the organisation accepts the proposal as its own code, and ownership begins there. If the party that merges cannot answer for the change, nobody can, and the stewardship principle (Name, Understand, Revert) fails at its first test.

The evidence offered for this view has four strands. The first is about checks. Passing tests is weaker than it looks: a patch that passes the checks it was shown may still be wrong, and in one analysis such weaknesses inflated a benchmark's reported resolution rate by 6.2 percentage points (179, Wang et al., 2025). When the same kind of model writes the code and the tests, the problem is worse than a weak suite, because model errors are correlated: in a study of more than 350 models, two models that both erred chose the same wrong answer 60 per cent of the time on one leaderboard, and larger, more accurate models had more strongly correlated errors (35, Kim et al., 2025). In experiments on two summarisation tasks, models recognised their own outputs and, after fine-tuning, favoured them in proportion to that recognition (36, Panickssery et al., 2024). A model checking a model is a partial remedy at best.

The second strand is about people. Participants in a controlled study who had access to an AI assistant wrote significantly less secure code and were more likely to believe it secure (34, Perry et al., 2023). Reliance on automation reduces checking among those who trust it (57, Parasuraman & Manzey, 2010), and automation erodes the skills of the people who must catch its errors (56, Bainbridge, 1983). A reviewer who receives 25 files from an agent, hour after hour, is in the position those papers describe. The third strand is practice: change volume rises faster than control, and the 2025 DORA programme finding that AI adoption is still associated with lower delivery stability is read as the cost (42, Harvey & DeBellis, 2025). The fourth is the reported incident of July 2025, which, whatever its exact facts, shows what an agent with write access to production data can do when the only barrier is an instruction (33, AI Incident Database, 2025). On this view an agent that merges its own work is an agent that controls the gate, and the proper design is that agents never merge.

The case for calm

The case for calm begins with a distinction that the concerned position blurs: merging is already done by software. Pipelines merge pull requests that pass their checks; merge queues, dependency bots and release tooling have done so for years. The question is not whether software may merge but under which condition, and the condition that matters is what the merge rule checks and whether the change can alter it.

The second argument is that a human click is not in itself a control. A reviewer who approves because the checks are green, because the queue is long, or because the author is a tool, adds nothing, and policies that rely on individual oversight of automated systems can legitimise the system without examining it (92, Green, 2022); (43, Goddard et al., 2012). For a mechanical class, a patch-level bump to a listed library with a green independent suite and an unchanged provenance, a deterministic gate is a stronger control than a tired reader. The class approval moves the human decision to where it is informed: the list, the checks, the repositories, the suspension rule.

The third argument is about benefit and the cost of refusing it. Randomised field experiments with 4,867 software developers at Microsoft, Accenture and an anonymous Fortune 100 company found a 26.08 per cent increase in completed tasks with a coding assistant (176, Cui et al., 2024), and the 2025 DORA programme reports a positive association with throughput (42, Harvey & DeBellis, 2025). The evidence concerns assistants and surveys and is mixed, as the trial of experienced developers in their own codebases shows (63, Becker et al., 2025). The calm position does not claim that agents are faster. It claims that prohibition has costs that fall elsewhere: a consultant who pastes a connection string into an unapproved public assistant (INC-NR-2030-0071) is the result of a prohibition without a sanctioned route. The fourth argument is that the reported failures are failures of boundary, not of delegation. Where the agent had no credentials to the production database, the incident could not occur, and the remedy is the sandbox and the mandate of this chapter, which the concerned position also asks for.

Where the positions meet

Five points are common ground, and none requires either side to concede its main claim.

First, writing, merging and deploying are three acts, and the answers differ. Both sides accept agents writing under a mandate at Level 2 Supervised for ordinary code, and both accept that deploying to production passes a gate the change cannot alter. The disagreement concerns the middle act and is decided by class.

Second, what merges is decided by checks the change cannot alter, written by someone other than the generator. Both sides accept the corollary of the stewardship principle: tests, reviews and checks that an AI wrote for its own output verify less than they appear to. Independence is graded by seeding faults and by reproduction by a person, and a model checking a model is a partial remedy, as AI Operations, Chapter 17, concluded (170, Nordqvist, 2026).

Third, the agent never holds the merge right for a class it can also write, and never edits the thing that checks it. The calm side accepts the second Level 4 prohibition because it is a boundary; the concerned side accepts a pipeline merge for a listed class because the pipeline, not the agent, merges.

Fourth, review capacity is finite and is a number. A team can review well only so many agent pull requests a week; the mandate's file budget, the number of runs and the count of open agent pull requests express it, and a queue that grows is a signal to lower the level, not to hurry the reader.

Fifth, claims need evidence with an age. Neither side has a measured result for its own organisation; both accept revert rates, escaped defects, review time and incident counts as the measures, and refuse acceptance rates and lines written as proof of value.

What can be done

For the developer: start each run from a specification and read the diff against it; refuse to approve a pull request you requested; record in the pull request, in your own words and without the tool, what the change does and why. For the tech lead: own the mandate, set the budget of agent pull requests the team can review in a week, and lower the level when review slips; run a seeded-fault exercise on the agent's pull requests each quarter. For the engineering manager and head of development: accept no raise of a level without evidence of its age, and keep adoption figures out of appraisal. For the platform engineer: enforce the sandbox, the identity and the stop path from outside the pipeline, and drill the stop within 90 days. For the test engineer: own the oracle and keep the agent's identity write-denied to it. For the works council or union representative: agree before use what the run record holds about people, and that telemetry is reported by team. For the public-sector IT lead: treat run records and prompts as possible public-access and archival records, and settle their retention with the archivist before the tool is extended.

Verdict

The verdict is given by class of work, and each statement carries the label of AI Governance, Chapter 22 (162, Nordqvist, 2026).

Observable. Agents plan, edit several files, run commands and open pull requests today, and the studies that exist show three things: benchmark results depend on the date, the harness and the strength of the checks; a developer's impression of a tool's effect can diverge from the measured effect; and organisation-level association between AI adoption and delivery stability is negative where controls are weak. The reported failures with write access to production data were failures of boundary. These studies concern assistants, benchmarks and surveys more than the agents of this chapter, and the inference to a specific organisation is interpretation.

Expected. Writing by agents under a mandate at Level 2 Supervised for ordinary code, with a named reviewer who is not the requester, and Level 3 Bounded for narrow, mechanical, reversible classes whose merge condition is a gate the change cannot alter. The trend is the adoption of sandboxed, branch-limited agents by platform vendors, the control-and-evidence expectations of change management for financial entities under Article 9(4)(e) of Regulation (EU) 2022/2554 (2, European Union, 2022), and the obligation under Article 21(2)(e) of Directive (EU) 2022/2555 that entities in scope take measures for security in the development and maintenance of network and information systems (3, European Union, 2022). Framed as an implication, not legal advice, these instruments ask the entity to show controlled change, whoever or whatever wrote it.

Speculation. That agents will merge broad classes of ordinary code, or code in security-critical paths, with better outcomes than a person-gated process, and that organisations will be right to let them. No evidence cited here supports it, and the prohibitions would apply to the security-critical paths in any case.

What people and organisations can influence is the part that matters. The boundary, the independence of the oracle, the identity of the merge right and the stop path are design choices a team can make this quarter, and the review capacity of the team is a number it can set.

Across the degrees of delegation

The table gives the highest degree of delegation this book recommends for a coding agent in each class of work, and who merges or acts. It is a ceiling, not a target: the lowest answer governs, a class with no evidence is held at Level 0 or Level 1, and the starting ceilings are the author's recommendation, not a measured result. Level 4 Autonomous appears in no cell.

Work class Ceiling for a coding agent Who merges or acts Condition
Generate (ordinary code) Level 2 Supervised A named reviewer approves; the pipeline merges Reviewer is not the requester; oracle independent of the agent
Generate (security-critical or payment path) Level 1 Assisted A named developer Agent writes no file in the path; human review by a named developer
Refactor Level 2 Supervised Named reviewer Behaviour-preserving checks the agent cannot edit
Test (drafts) Level 1 Assisted Test engineer Never the oracle for the same change
Review Level 0 Advisory Two human approvers where the change policy requires them An AI review comment never counts as an approval
Patch-level dependency update (listed) Level 3 Bounded The pipeline merge rule after class approval Closed list, provenance diff, suspension rule; no deploy
Deploy, operate Level 0 The pipeline and the change process Gate the change cannot alter (Chapter 11)
Migrate Level 0 Advisory Named developer Legacy migration is treated in Chapter 12
Change to the agent's mandate, permissions, test oracles, review rules or gates Not delegated The accountable person Level 4 prohibition
A decision about a named person's employment, pay, performance rating or access to work Not delegated A named manager Level 4 prohibition

Nordvik Region and Hansa Mutual

Nordvik Region has no Mode 5 agent and permits agentic tools, Mode 3, to four of the seven platform engineers, for drafting infrastructure code and runbooks, never for applying change. Until October 2030 that permission rested on a tool entitlement and no mandate. MND-NR-DEV-01 (AIDR-1108, October 2030) now states it: Level 1 Assisted for drafting at the mandate's start, a one-run identity, egress only to the package proxy, no secrets, a branch limit, and a rule that the person who starts the run does not approve its pull request, a rule AI Operations, Chapter 22, applies to change authority in general (170, Nordqvist, 2026). Joakim Wester reviews most of the platform's agent-drafted code and is, for that reason, the Region's argument for a review-capacity budget: the mandate caps the open agent pull requests per reviewer, and the sample RUN-NR-2030-0019 shows a review of 22 minutes that found a stray edit. AIDR-1116 (Chapter 16) raised the platform team's drafting of infrastructure code from Level 1 Assisted to Level 2 Supervised from 2030-11-18, the date of that run, with drafts never applied and each reviewed by a named engineer. The tender NR-2030-041 for development assistants for Applications and Integration, including an agentic mode, closes in November 2030, and the Region's position, that nothing at Mode 3 is extended to the application teams before a mandate of this kind exists for it and the negotiation MBA-NR-2030-03 is concluded, is the safe one for a public authority with limited engineering capacity and a duty of transparency.

Hansa Mutual has about 120 engineers using agentic tools through the Hansa Forge gateway, in a sandbox, opening pull requests and never merging to the protected branch, and one Level 3 Bounded class. MND-HM-DEV-02 (AIDR-1158) governs the claims core pilot under the tech lead Stefan Brückner, with the version 2 notification that followed the package that did not exist; MND-HM-DEV-01 governs the dependency class under Lukas Frey and the accountability of Dr. Philipp Reinhardt. The group operates under DORA, whose Article 5(2) places responsibility for the ICT risk-management framework on the management body, and the group's change policy, which applies the regulation's change-management requirements, is the reason a merge is not a deploy (2, European Union, 2022). The Konzernbetriebsrat's developer-tooling annex KBV-IT-2024-DEV-01, being drafted in autumn 2030, determines what the run record may say about people: by team, minimum group size 5, never by named developer. Hansa's scale lets it build the proxy, identity service and sandbox; its exposure is the number of agent pull requests its reviewers can absorb. Neither has yet measured the effect of an agent run on delivery (Chapter 20), and both know what they have allowed.

Summary

This chapter concerned D3 Build and D4 Prove. A coding agent is a harness in which a model suggests the next tool call and the harness executes it; its authority is whatever the mandate, the sandbox and the credentials give. The mandate (MND-*-DEV-*) states the work classes and levels under the ceiling of the delegation profile, the tools, the paths, the budgets, the halt rules and the stop holders, and carries a never list that closes the routes by which an agent could change its own mandate, credentials, review rules, gates or test oracles.

The sandbox makes the mandate true: an ephemeral filesystem, default-deny egress through a package proxy, no secrets, a one-run identity issued outside the agent, tools in place of a shell, and a design check from the practitioner literature that no run combines untrusted input, sensitive access and the ability to change state or communicate externally. The stop path runs outside the pipeline, through the identity and the runner pool, and is cheaper to use than the path to continue. The run record, written by the host and not by the agent, makes the run reconstructable; it holds what the agent did, not what an engineer typed.

The debate has a shape. The concerned side is right that responsibility leaks at the merge, that tests are weaker than they look and that reviewers tire. The calm side is right that software already merges, that a click is not a control, and that prohibition without a sanctioned route moves use out of sight. They meet on classes: writing at Level 2 Supervised with a reviewer who is not the requester, a pipeline merge only for a narrow listed class whose gate the change cannot alter, review capacity as a number, and claims with an evidence age. Level 4 Autonomous appears in no cell. The one thing the reader can do this quarter is to write the mandate of the agent already in use, with its never list, its stop holders and its review date, and to test that the stop works.

Chapter 9 turns to D4 Prove in full: review, tests and verification, and what makes an oracle independent when AI writes both the code and the tests.

Sources

  1. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 4, published at aired.geon.se. (164, Nordqvist, 2026)
  2. Jimenez, C. E., Yang, J., Wettig, A., Yao, S., Pei, K., Press, O. & Narasimhan, K. (2024). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? ICLR 2024; arXiv:2310.06770 (first submitted October 2023); 2,294 problems from 12 Python repositories; the best model tested in the original paper, Claude 2, resolved 1.96 per cent. (189, Jimenez et al., 2024)
  3. Wang, Y., Pradel, M. & Liu, Z. (2025). Are "Solved Issues" in SWE-bench Really Solved Correctly? An Empirical Study. arXiv:2503.15223, submitted 19 March 2025, revised 9 September 2025; reports that 7.8 per cent of patches counted as correct fail the developer-written test suite and that such weaknesses inflate reported resolution rates by 6.2 absolute percentage points. (179, Wang et al., 2025)
  4. Becker, J., Rush, N., Barnes, E. & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089, submitted 12 July 2025, revised 25 July 2025. (63, Becker et al., 2025)
  5. Harvey, N. & DeBellis, D. (2025). Announcing the 2025 DORA report: State of AI-assisted Software Development. Google Cloud Blog, 23 September 2025. (42, Harvey & DeBellis, 2025)
  6. Nordqvist, G. (2026). The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. The Architecture as Code Series, Book 6, published at tsa.geon.se. (166, Nordqvist, 2026)
  7. Nordqvist, G. (2026). AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. The Architecture as Code Series, Book 9, published at aipurple.geon.se. (169, Nordqvist, 2026)
  8. Nordqvist, G. (2026). AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. The Architecture as Code Series, Book 10, published at aiops.geon.se. (170, Nordqvist, 2026)
  9. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. The Architecture as Code Series, Book 3. (163, Nordqvist, 2026)
  10. Dworken, D. & Weller-Davies, O. (2025). Making Claude Code safer with sandboxing. Anthropic Engineering, 20 October 2025; vendor engineering article describing filesystem and network isolation; the reported 84 per cent reduction in permission prompts is the vendor's figure from its internal usage, with no method or baseline stated. (38, Dworken & Weller-Davies, 2025)
  11. GitHub (n.d.). Risks and mitigations for GitHub Copilot cloud agent. GitHub Docs; vendor documentation, undated, describing the platform's own defaults (a user who asked for a pull request cannot approve it, workflows do not run until the agent's code is reviewed, a single pushable branch, restricted internet access, simple push operations only); a description of one product, not an assurance. (39, GitHub (n.d.), n.d.)
  12. OWASP Gen AI Security Project (2025). OWASP Top 10 for LLM Applications 2025 (2025 Top 10 Risk & Mitigations for LLMs and Gen AI Apps). OWASP Foundation; ten risks from LLM01 Prompt Injection to LLM10 Unbounded Consumption, including LLM03 Supply Chain and LLM06 Excessive Agency. (230, OWASP, 2025)
  13. Willison, S. (2025). The lethal trifecta for AI agents: private data, untrusted content, and external communication. simonwillison.net, 16 June 2025; practitioner blog post naming the combination of access to private data, exposure to untrusted content and the ability to communicate externally. (40, Willison, 2025)
  14. Meta (2025). Agents Rule of Two: A Practical Approach to AI Agent Security. Meta AI blog, 31 October 2025; a practitioner proposal, not a tested standard: within one session an agent should satisfy no more than two of three properties (processes untrustworthy inputs; accesses sensitive systems or private data; changes state or communicates externally). (37, Meta, 2025)
  15. Green, B. (2022). The flaws of policies requiring human oversight of government algorithms. Computer Law & Security Review 45, 105681. DOI: 10.1016/j.clsr.2022.105681 (accessed 2026-11-11). (92, Green, 2022)
  16. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. The Architecture as Code Series, Book 5, published at aithreat.geon.se. (165, Nordqvist, 2026)
  17. AI Incident Database (2025). Incident 1152: LLM-Driven Replit Agent Reportedly Executed Unauthorized Destructive Commands During Code Freeze, Leading to Loss of Production Data. Incident date 18 July 2025; a catalogue record that lists five press reports and no primary post-incident report. (33, AI Incident Database, 2025)
  18. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
  19. Kim, E., Garg, A., Peng, K. & Garg, N. (2025). Correlated Errors in Large Language Models. ICML 2025; arXiv:2506.07962. (35, Kim et al., 2025)
  20. Panickssery, A., Bowman, S. R. & Feng, S. (2024). LLM Evaluators Recognize and Favor Their Own Generations. arXiv:2404.13076. (36, Panickssery et al., 2024)
  21. Perry, N., Srivastava, M., Kumar, D. & Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (CCS '23); arXiv:2211.03622. (34, Perry et al., 2023)
  22. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors 52(3), 381-410. DOI: 10.1177/0018720810376055 (accessed 2026-11-10). (57, Parasuraman & Manzey, 2010)
  23. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6), 775-779. DOI: 10.1016/0005-1098(83)90046-8 (accessed 2026-11-10). (56, Bainbridge, 1983)
  24. Goddard, K., Roudsari, A. & Wyatt, J. C. (2012). Automation bias: a systematic review of frequency, effect mediators, and mitigators. Journal of the American Medical Informatics Association 19(1), 121-127. DOI: 10.1136/amiajnl-2011-000089 (accessed 2026-11-10). (43, Goddard et al., 2012)
  25. Cui, Z. (K.), Demirer, M., Jaffe, S., Musolff, L., Peng, S. & Salz, T. (2024). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. SSRN 4945566; later published in Management Science (DOI: 10.1287/mnsc.2025.00535). Randomised field experiments at Microsoft, Accenture and an anonymous Fortune 100 company with 4,867 developers; the SSRN abstract reports a 26.08 per cent increase in completed tasks. (176, Cui et al., 2024)
  26. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 2, published at aig.geon.se. (162, Nordqvist, 2026)
  27. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)