Ruan, a quantitative analyst on the rates desk at Fynbos Capital Bank, a fictional South African bank, asked a coding agent on his laptop to "fix the failing reconciliation script". The agent read the script, ran it, read the error, opened a configuration file to find the database connection, and tried again. It worked. The script now ran cleanly.
When the security team later reconstructed the session, the code change was the least interesting part. To get there, the agent had read a configuration file holding a connection string with a password, executed commands under Ruan's identity, connected to a database that held confidential trading positions, and installed a package from a public registry to parse a date format. Each step was reasonable. None had been decided by anyone. Fynbos had approved the coding assistant as a productivity tool. In practice it had approved a process that could run arbitrary commands with Ruan's access, wherever Ruan's laptop could reach.
Everything about Fynbos, its people and its systems is invented. The pattern is common.
A chat window that runs code
Most AI tool governance was designed for chat: a person types, a model answers, and the person decides what to do with the answer. The controls follow from that shape. Which data may be typed in? Where does the prompt go? Who checks the output?
A coding agent has a different shape. It is a loop that reads, decides, acts and observes, and its actions run on a machine. The agent loop in plain English explains the loop. What matters here is where the actions land. When an agent edits a file, runs a test, installs a dependency or calls an API, it does so with the permissions of the process it runs in, which is usually the permissions of the person who started it.
That makes a coding agent an execution environment in the same sense as a build runner, a developer workstation or a scheduled job. It should be governed like one. The question is not only what the person may ask it, but what the process may touch.
The execution surface
It helps to list what a coding agent can reach, because most organisations have never written it down.
- Filesystem. Source code, but also configuration files, environment files, local credential stores and anything else in readable paths.
- Shell. The ability to run commands, start processes and install software.
- Credentials. Whatever the environment holds: cloud sessions, database connection strings, repository tokens, signing keys.
- Network. Package registries, internal services, databases and the open internet, unless something restricts egress.
- Repositories. Read and write access to branches, and sometimes the ability to open or merge pull requests.
- Extensions. Skills, plug-ins and MCP servers, each of which may add more reach. Agent skills and MCP servers are executable dependencies covers why these belong in supply-chain review.
The OWASP Top 10 for LLM Applications names the general risk as Excessive Agency and gives three root causes: excessive functionality, excessive permissions and excessive autonomy. A coding agent on a developer laptop tends to have all three by default, not because its designers were careless, but because a developer laptop is built to let a trusted person do almost anything.
What the products provide, and what they do not
Vendors have recognised this. As two dated examples, checked on 5 November 2026:
- Anthropic's Claude Code documentation describes a sandbox for shell commands, enforced by the operating system, that limits filesystem writes and routes network traffic through a proxy with an allow-list of domains. The same page sets out its limits. The sandbox is off by default. It runs on macOS, Linux and WSL2, and on native Windows commands run unsandboxed. Where the platform does not support it, commands run without it unless the
sandbox.failIfUnavailablesetting is turned on. Default read access covers most of the machine, including credential files, unless they are explicitly denied. The sandbox covers shell commands only: the file tools, MCP servers and hooks run outside it. And the page warns against relying on its restrictions to stop a malicious command, which matters particularly where commands are auto-approved. - GitHub's documentation for Copilot cloud agent, which from 28 October 2026 is part of the newer "Copilot in the cloud" experience for paid plans, describes sessions that run in a cloud sandbox or a GitHub Actions-based environment, work on one branch at a time and open one pull request per task, and that branch protection and rulesets can block. It advises reviewing and testing output before production use.
These are useful controls. They are also product features with their own scope and limits, and they are configured per user, per repository or per organisation. A regulated firm cannot assume they are switched on, or that they cover the paths that matter to it. The bank has to decide the boundary, then check that the product enforces it.
Three environment tiers
Fynbos now offers coding agents in three environment tiers. The entitlement from part 1 names the tier, and the tier determines the boundary.
Tier A: local sandbox. The agent runs on a managed workstation, with the vendor's sandbox switched on by central configuration and set to fail closed where it is unavailable. On Windows workstations that means running the agent inside WSL2, a virtual machine or a development container, because the native Windows client does not sandbox commands. Explicit deny rules stop the agent reading credential files. Writes are limited to the project directory. Network access is limited to an internal package mirror and the approved model endpoint. No production credentials exist on the machine; developers use synthetic or masked data. This is the default for anyone entitled to the coding capability.
Tier B: ephemeral cloud workspace. The agent runs in a short-lived workspace created for one task and destroyed afterwards. The workspace has its own workload identity with read access to the repositories named in the task, permission to push to one task branch and open a pull request, and no merge rights. Egress is restricted at the network layer, not only by proxy settings. Output leaves the workspace only as a pull request. This tier is for longer or unattended tasks, including the background work described in Let the agents take the night shift.
Tier C: controlled pipeline. Changes that may reach production are prepared by an agent but executed only through the normal delivery pipeline: build, tests, security scans, review and approval by a named person, then deployment by the pipeline's own identity. The agent never holds production credentials. It proposes; the pipeline and the approver act.
The tiers follow one principle: the agent should never have more reach than the task needs, and reach to production should belong to the pipeline, not to the agent or the person who started it.
Attended and unattended sessions are different risks
One more distinction matters when placing work in a tier: whether a person is watching. In an attended session, the person sees each command or file change as it happens and can stop it. Many products also ask for approval before risky actions, which gives the person a chance to say no, although approval prompts lose their value quickly when people click through them dozens of times a day.
In an unattended session, nobody is watching. The agent may run for an hour, take dozens of actions and return only a result. Every boundary that a person would have enforced by noticing something odd must instead be enforced by the environment. That is why Fynbos allows unattended work only in tier B, where the workspace is created for one task, holds only the access that task needs and is destroyed afterwards. A laptop session left running over lunch is, in practice, an unattended session in tier A's weaker boundary, and the bank's guidance says so explicitly.
Ruan's script, redone
After the review, Ruan's work moved to tier A, and the reconciliation script itself was split from the data it touched.
- The script now runs against a masked extract of positions in the sandbox. The agent can read and edit it, run tests and iterate freely, because nothing it can reach is sensitive.
- The real connection string moved into the bank's secrets service and is injected only into the scheduled job that runs the approved script, under a service identity.
- The public package the agent had installed was replaced with an equivalent from the internal mirror, after a dependency review.
- When Ruan wants the improved script promoted, he opens a pull request, which an engineer on the markets technology team reviews. Part 5 of this series discusses why this pairing is the core of the hybrid-role problem.
Ruan lost nothing he needed. He lost the ability to have an agent connect to production positions from a laptop, which he had never been entitled to in the first place.
Controls to require
| Boundary | Default to require | Evidence a reviewer should see |
|---|---|---|
| Filesystem | Writes limited to the project; credential files not readable | Sandbox configuration, managed centrally |
| Credentials | No production credentials in tiers A and B | Secrets inventory shows production secrets only in pipeline identities |
| Network | Egress limited to the model endpoint, package mirror and named services | Network policy, not only proxy variables |
| Dependencies | Installs only from the internal mirror | Mirror logs; blocked requests to public registries |
| Repositories | Agent identities cannot merge or push to protected branches | Branch protection and ruleset configuration |
| Extensions | Only registered skills and MCP servers | Registry entries with owners |
| Production | Changes only through the pipeline with named approval | Pipeline records linking change, approver and deployment |
None of these is specific to AI. They are the controls a bank already applies to build systems and privileged workstations. The step that matters is recognising that a coding agent belongs in that category. Guides, guards, checks and sensors covers the harness inside the environment. This article is about the walls around it.
Key points
- A coding agent is a loop that runs actions with the permissions of its environment. Govern it as an execution environment, not as a chat tool.
- Map the execution surface: filesystem, shell, credentials, network, repositories and extensions.
- Vendor sandboxes are useful, dated product features with their own limits. Decide the boundary first, then check what the product enforces.
- Offer coding agents in tiers: local sandbox, ephemeral cloud workspace and controlled pipeline, named in each entitlement.
- Keep production reach with the pipeline and a named approver. The agent proposes; it does not hold production credentials.
Next: Part 4, Shadow AI is an architecture signal. All parts are on the series page.
How CloudNala can help
CloudNala reviews how coding agents are deployed in regulated engineering environments. We map each agent's execution surface, design the environment tiers and their boundaries with your security and platform teams, check what the vendor controls actually enforce in your configuration, and route production change through your existing pipeline, so that coding agents can be offered widely without widening anyone's reach.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Access Review or write to us at consult@cloudnala.co.za