The objection arrives in the first ten minutes of every one of these conversations: our developers already have production access, so what exactly is the agent adding? It is a fair question, and it has a precise answer. The agent is not the developer. It is a second actor exercising that same access — at machine speed, across chained tools, and on instructions that did not all originate inside your organisation.
The framing the rest of the page rests on. Assess the capability graph, not the product label. A coding assistant wired to Jira, GitHub, a database and a monitoring stack over MCP is not an autocomplete feature with extras. It is a development agent holding organisational tool access, and it should be assessed as one.
Governance guidance · 2017 TSC with revised 2022 points of focus · ISO/IEC 42001:2023 · OWASP Top 10 for LLM Applications 2026 · Vendor capabilities change — verify current documentation · Last reviewed August 2026
Govern the agent separately because it is a separate actor, and govern all three tools with one framework because the questions are identical even where the answers are not. The unit of assessment is the capability graph — what this configuration can reach and what it can do — not the product name on the invoice. Two configurations of the same product can sit in different risk classes, and two different products configured the same way usually sit in the same one. That single move settles most of the arguments that follow. It tells you why a sandboxed editor with no network egress is a low-risk endpoint tool while the same editor connected to your ticket tracker and a production replica over MCP is an organisational actor. It tells you why the answer to “does every command need approval?” is no. And it tells you why a provider-hosted execution environment that clones your repository into a virtual machine you do not administer is a new processing environment to assess rather than a faster way to run the same tool.
Key Takeaways
- The agent is a second actor exercising the developer’s access. Rate, tool-chaining, and the fact that part of its instruction can arrive from untrusted text change the risk profile of the same permission — which is why the developer already having access is not an answer.
- Assess the capability graph rather than the product label: filesystem reach, command execution, network egress, credential reach, connected systems, execution locus and autonomy. A coding assistant connected to Jira, GitHub, databases and monitoring over MCP is a development agent with organisational tool access.
- All-or-nothing approval fails in both directions, so no, not every command needs review. Layer sandboxing, deny rules, scoped permissions and step-up approval instead: reversible in-scope commands run freely and are logged, a small set of high-consequence actions requires explicit approval each time, and inherently destructive actions are blocked by a permission the agent’s identity does not hold — so the client-side deny rule is never the only thing holding.
- The agent’s repository scope can legitimately be narrower than the developer’s, because a developer’s broad access exists for reasons — incident response, mobility, review — that a task-scoped agent does not have. Narrowing is ordinary least privilege and costs almost nothing operationally.
- A cloud execution environment that clones your repository into a provider-operated VM is a new processing environment: assess the code that lands there, the credentials injected, dependency resolution, network paths back to your systems, retention, and the provider’s own independent assurance for that specific service.
- Three tools, one framework. Identity, boundary, connected tools, execution locus, data handling, change management, logging and joiner-mover-leaver are the same eight questions for every coding agent. Only the answers and the enforcement mechanisms differ, so the per-tool work is an appendix rather than a programme.
The developer already has access
This objection deserves a straight answer rather than a lecture, because it is substantially correct. Your senior engineers can already deploy, already read the database, already hold the cloud credentials. Nothing about installing an agent grants a permission that did not exist. What changes is the character of the actor exercising it, and six properties account for the whole of the difference.
| Property | The developer alone | The developer with an agent |
|---|---|---|
| Rate | A developer with production credentials exercises them a few dozen times an hour at most, and each action passes through a person who knows why they are doing it. | The same credentials can be exercised hundreds of times in a minute across files, repositories and APIs. Rate is not a philosophical difference. It is the difference between a mistake you interrupt and a mistake you discover afterwards. |
| Chaining | A person performs one step, observes the result, and decides on the next. The pause between steps is itself a control, even though nobody wrote it down. | Steps are chained without that pause. Read a ticket, clone a repository, install dependencies, run a migration, open a pull request — a single instruction produces a sequence, and only the sequence as a whole was ever authorised. |
| Instruction source | The developer decides what to do. Their intent is formed inside your organisation, by someone accountable to it. | The agent acts on text, and some of that text arrives from outside — an issue body, a dependency README, a web page, a file in a repository. Prompt injection is LLM01 in the 2026 OWASP Top 10 for LLM Applications because it turns content into instructions. |
| Breadth of reach | A developer uses the systems their current task needs, because opening five tools they do not need is effort with no reward. | An agent connected to a ticket tracker, a repository host, a database and a monitoring stack can traverse all of them in one turn. Nothing about the design creates the friction that kept a person in one place. |
| Attribution | The log records a named person. Access reviews, joiners-and-leavers processes and disciplinary routes all attach to that name. | If the agent runs under the developer’s own token, the log records the developer for actions the developer did not choose. That is an accuracy problem in your audit trail before it is a security problem. |
| Recoverability | A person who realises mid-action that something is wrong usually stops. Regret is a genuine, if unreliable, control. | An agent that has misread the task completes it. The stopping condition has to be built into the boundary rather than hoped for, which is exactly what OWASP’s Least-Agency principle argues. |
None of that is an argument for prohibition, and a governance programme built on suspicion of the tooling will be routed around within a quarter. It is an argument for a boundary. The 2026 OWASP Top 10 for LLM Applications puts Excessive Agency at LLM03, up three places from the previous edition, and decomposes it usefully into three root causes: excessive functionality (where the agent can reach tools beyond its task), excessive permissions (where those tools operate with broader rights than the task needs) and excessive autonomy (where high-impact actions proceed without human approval). Those are three separate design decisions, and most organisations get one of them right and assume it covers the other two.
The capability graph, not the product label
Ask most security teams to classify a coding assistant and they will classify the product: this one is an IDE plug-in, that one is a terminal tool, the other is a platform feature. The classification is then wrong within a month, because the product acquired a new integration and nobody re-ran the assessment. The durable question is what a given configuration can reach and what it can do — the graph of capabilities reachable from the agent, one hop at a time.
Seven axes are enough to place any configuration. Answer them per tool per team, write the answers down, and re-run them when a capability changes. This is the same test we apply to the broader question of when a tool becomes an agent, applied to the coding case specifically.
| Axis | The question to answer, in writing | Criteria |
|---|---|---|
| Filesystem reach | Which directories can it read, and which can it write? Is it confined to a working tree, or can it reach the home directory, SSH keys, cloud CLI profiles and other checkouts? | CC6.1 · CC6.7 |
| Command execution | Can it run shell commands at all? Under which user and shell? With which environment variables inherited from the parent process? | CC6.1 · CC6.8 |
| Network egress | Can it make arbitrary outbound requests, or only to an allow-listed set of hosts? Egress is the difference between a bad edit and an exfiltration path. | CC6.6 · CC6.7 |
| Credential reach | What can it authenticate as — its own identity, the developer’s token, or a shared service account? What does that identity hold in the systems behind it? | CC6.2 · CC6.3 |
| Connected systems | Which MCP servers, extensions or integrations are attached, and what does each of those confer? This is the axis that moves a tool from assistant to organisational actor. | CC9.2 · CC6.3 |
| Execution locus | Does it run on the developer’s laptop inside your boundary, or in a provider-operated environment that clones your repository somewhere you do not administer? | CC9.2 · CC6.6 |
| Autonomy | Is a human present for each turn, or does it run unattended from a queue, a webhook or a schedule? Unattended is a different control class, not a setting. | CC5.2 · CC7.2 |
Two consequences fall straight out of this. First, the same product occupies different risk classes in different teams, so a single organisation-wide verdict on “is Cursor approved?” is the wrong shape of decision — the approval attaches to a configuration. Second, the moment an integration is added, the graph changes and the assessment is stale. That is why a capability change belongs in change management rather than in a preferences pane, and why the connected-tool list is one of the few things on this page worth reviewing monthly.
Neither all-or-nothing, but five tiers
The two failure modes are symmetrical. Approve everything, and there is nothing between a misread instruction and an irreversible action. Approve every command individually, and within a week the operator is approving without reading — which is worse than the first case, because now there is a control in the description that does not exist in practice. The way out is not a better prompt. It is a boundary with tiers, where the scarce resource of human attention is spent only on actions that cannot be undone.
| Tier | Action classes | Posture | What enforces it | Evidence produced |
|---|---|---|---|---|
| Run freely | Reading files inside the working tree. Searching and listing. Running the test suite, linter, type-checker and formatter. Git status, diff, log and branch. Reading build output. | No prompt. Logged, not gated. | An allow-list of commands and arguments in the agent’s own configuration, inside a workspace-scoped sandbox that already bounds the filesystem. | Session transcript or agent log showing the command, the working directory and the exit code. |
| Run inside a scope | Writing and deleting files within the working tree, creating branches, committing, installing dependencies from the configured internal registry, and running a local database container. | No per-command prompt, but bounded and reviewable after the fact. | Sandbox path restrictions, a registry proxy that refuses unknown upstreams, and the fact that nothing here reaches a shared environment without passing the change-management gate below. | Diff of the working tree, the lockfile change, and registry proxy logs showing which packages were resolved and from where. |
| Step-up approval | Pushing to a shared branch, opening or updating a pull request, adding a new dependency from a public registry, calling an external API that costs money or sends messages, reading files outside the working tree, and enabling a new MCP server. | Explicit human approval each time, with the specific action shown. | The agent’s approval prompt for the action class, plus a server-side control that does not depend on the client — branch protection, registry policy, or a scoped token that simply cannot perform the action without a second step. | The approval record with actor and timestamp, and the resulting platform event (push, PR, package addition) correlated to the session. |
| Denied outright | History rewrite and force-push to protected branches. Deleting branches, repositories or buckets. Reading .env files, private keys and cloud credential profiles. DDL or DML against production data stores. IAM and role changes. Disabling logging. Deploying to production. | Blocked. Not prompted, because a prompt is a decision you have delegated to a tired person at 6 p.m. | Deny rules in the agent configuration as the first layer, and — critically — an identity that lacks the permission at the platform, so that the deny rule is a convenience rather than the only thing standing between you and the outcome. | The deny-rule configuration captured at two points in the period. The IAM policy or permission boundary that makes it structural. Platform logs showing attempts, if any, and their refusal. |
| Human-only, always | Approving the merge of agent-authored code, granting the agent new capabilities, accepting a new MCP server into the approved set, and releasing to customers. | A named person, who is not the requester, performs the action. | Branch protection requiring a non-author approving review, a change record for capability grants, and the release pipeline as the only deployment path. | Merge export showing author and approver as distinct accounts, the capability-grant change record, and the deployment log. |
The fourth column is the one that separates a real boundary from a described one. An agent-side deny rule is a client-side control: it is configuration on the machine you are trying to constrain, and anything that can rewrite that configuration has removed it. It earns its place as a first layer because it stops accidents cheaply and immediately. It does not earn the weight of being the only layer. Every row in the denied tier should also be a permission the agent’s identity simply does not hold — no IAM write, no production data-store role, no force-push right on a protected branch. Then the deny rule is convenience and the identity is the control, which is the arrangement an assessor can actually test.
Does every command need a human
No. And the case for no is a control argument rather than a productivity one. A gate that fires on every event stops being read, and a gate that is not read is not a gate. If you want the approval on the migration to mean something, the agent has to be able to run the test suite without asking.
Two tests sort almost every command into the right tier, and they are worth running explicitly rather than by instinct. The first is reversibility: if this action is wrong, can it be undone from within the working tree, from version control, or not at all? Editing a file is reversible. A force-push that rewrites shared history is not. Dropping a table is not. The second is reach: does the effect stop at this workspace, or does it touch a shared system, a customer, a bill or a third party? Installing a package into a local container stops at the workspace, but posting to a production webhook does not.
Run both tests and the tiers assign themselves. Reversible and local runs freely. Reversible but shared is reviewable after the fact. Irreversible or externally visible is step-up. Irreversible and destructive is denied at the identity. The one category that deserves a third test is anything that can move data outward, because exfiltration is not undone by a rollback: a command that reads broadly and sends anywhere belongs in step-up or denied regardless of how reversible the local effect looks, which is the practical content of the transmission and movement restrictions under CC6.7.
Two operational cautions. Command allow-lists match on strings, and strings compose: approving a test runner does not approve a test runner invoked with a flag that executes an arbitrary script, and approving a version-control command does not approve every subcommand it carries. Prefer allow-lists that are narrow and specific over patterns that are broad and clever, and accept the friction of adding entries. Equally, an approval prompt that appears twenty times an hour is a design defect in your allow-list, not evidence of diligence — the fix is to widen the freely-running tier for genuinely reversible commands, not to widen it for everything.
This is also where sandboxing earns its keep. A sandbox changes the default outcome of an action nobody anticipated, which is precisely the class of action an allow-list cannot enumerate. But be specific about what yours does: containment of the filesystem and containment of network egress are different properties, and a sandbox that provides only the first leaves the confidentiality question entirely open. Ask which one you have, then test it.
Why the agent’s reach can be narrower
Engineers reasonably ask why the agent they operate cannot see everything they can see. The answer is that the two access decisions are made for different reasons. A developer holds broad repository access partly for today’s task and largely for everything else: investigating an incident in a service they do not own, reviewing a colleague’s change, moving between teams next quarter, reading a shared library to understand an interface. Those are real needs and they justify breadth. An agent has none of them. It has a task, and when the task ends so does the reason for the access.
Narrowing therefore costs almost nothing and buys two specific things. It bounds what a single mis-instruction can reach, which matters most where the instruction may be partially attacker-controlled. And it bounds what can be drawn into context, which is the part teams underestimate: a repository the agent can read is a repository whose contents can be assembled into a prompt, and a prompt leaves your machine. Scope is a confidentiality control before it is an integrity one.
Three scoping rules hold up well in practice. First, agent access is a subset of the operator’s access by default — never a superset, and never a shared token that some operators would not have qualified for individually. Second, maintain a named exclusion list: the repositories that no agent tooling touches at all, chosen for what they contain rather than for how sensitive they feel — key management, payment-rail integrations, anything carrying regulated personal data in fixtures. Write down the rationale, because the exclusion will be challenged. Third, treat a monorepo as the hard case it is. Where the platform cannot express sub-repository scope, the practical substitutes are sparse or partial checkouts that bound what is materialised locally, plus code-owner rules that make a change to a protected path require a specific reviewer.
One more distinction is worth holding on to. Read scope and write scope are separate decisions, and they fail differently. Over-broad read is a confidentiality and context problem that leaves few traces, while over-broad write is an integrity problem your change gate catches. Most teams instinctively debate write access and hand out read access by default, which is the wrong way round for the risk that actually materialises.
When the repository is cloned into a VM
All three vendors now offer some form of provider-hosted execution — background or cloud agents that take a task, clone your repository into an isolated virtual machine or container they operate, work for minutes or hours, and return a pull request. The availability and naming of these modes changes, but the governance question does not. Your source code, your dependencies and often a set of credentials are now processed in an environment you do not administer. That is a third-party processing environment, and it is assessed like one under CC9.2 — not adopted like a feature flag.
| Dimension | The question to settle before the first run | What a defensible answer looks like |
|---|---|---|
| What lands there | Which repositories, branches and files are cloned into the environment, and does the clone include history, submodules, large binary assets and any secrets ever committed to that history? | A named, minimum set of repositories. Shallow clones where the task allows. A secret-scanning pass over history before the repository is ever eligible for cloud execution. |
| What the build needs | To install, build and test, the environment usually needs registry credentials, and sometimes API keys for integration tests. Which of those are injected, by whom, and with what scope and lifetime? | Short-lived, least-privilege credentials injected at run time by the platform, scoped to a read-only registry mirror and to test-tier services — never a copy of a developer’s personal token. |
| Dependency resolution | Where does the environment fetch packages from, and can that path be steered to an unexpected upstream? ASI04 in the 2026 OWASP Top 10 for Agentic Applications names agentic supply-chain risk directly. | Egress restricted to an internal proxy or mirror, lockfiles honoured, and a policy that a dependency the agent adds is a reviewable change rather than a side effect. |
| Network path back to you | Can the environment reach your VPC, your staging APIs, your identity provider or your ticket tracker? Every inbound path is a route from a machine you do not administer into one you do. | Default-deny egress with a documented allow-list, no standing network route into production, and anything the agent needs from your systems mediated by an API with its own authorisation. |
| Retention | How long does the workspace, its container image, its logs and its transcripts persist after the run? Retention of the prompt and completion record is a separate question from retention of the workspace. | A documented retention window for each artefact, confirmed against current vendor documentation, and a decision recorded on whether it is acceptable for the data classes in scope. |
| Provider controls | What independent assurance does the provider hold over the execution environment specifically — not over the marketing site — and does it cover the region and service you are using? | A current SOC 2 Type 2 or ISO/IEC 27001 certificate obtained and actually read, with the scope statement checked and the complementary user entity controls extracted rather than filed. |
| Who can trigger a run | Can anyone with repository write access start a cloud agent run? Can an external contributor’s comment on a public issue start one? | Trigger rights enumerated and restricted to named internal identities, and untrusted inputs never able to start a run that holds credentials. |
| What it can push back | Does the environment open pull requests, comment on issues, or write to any of your systems directly? Under which identity? | A distinct machine identity with pull-request-only rights, no merge permission, and no ability to alter branch protection or workflow definitions. |
One consequence reaches further than most teams expect. If provider-hosted execution becomes part of how your own service is built and maintained, and the description of your system says so, you have a decision to make about whether that provider is a vendor you manage under CC9.2 or a subservice organization in your system description, with the carve-out or inclusive treatment and complementary user entity controls that follow. For most organisations, a build-time tool used by engineers is vendor management rather than a subservice organization — but that is a determination to make deliberately, with your service auditor, before fieldwork rather than during it.
Common framework, named differences
Organisations that write a Claude Code policy, a Cursor policy and a Copilot policy end up maintaining three documents that drift apart, three review cycles nobody completes, and no answer at all for the fourth tool that arrives next quarter. The correct shape is one framework of eight questions, plus a short per-tool appendix recording the answers, the enforcing mechanism, and the date each was verified. The left column is fixed. The right column is what you look up.
| Control question | Common requirement — identical for all three | What you determine per tool |
|---|---|---|
| Identity | The agent acts under an identity you can enumerate, review and revoke, and its actions are distinguishable from a human’s in the log. | Whether the tool runs under the developer’s own credentials, a separate machine identity, or a platform-managed app identity — and whether that is configurable on your plan. |
| Filesystem and command boundary | A defined sandbox, an allow-list of low-risk commands and a deny-list of destructive ones, with the deny-list mirrored by a permission the identity does not hold. | The mechanism and its granularity: OS-level sandboxing, container isolation, per-command approval rules, workspace trust prompts, or a combination. Verify what your version actually enforces rather than what the documentation aspires to. |
| Connected tools | An approved list of MCP servers, extensions and integrations, with each addition treated as a capability change that goes through review. | Whether connections are configured per user, per workspace or centrally. Whether an administrator can pin an allow-list. And whether a repository-level configuration file can add a server without anyone approving it. |
| Execution locus | Local execution is assessed as an endpoint control problem. Provider-hosted execution is assessed as a third-party processing environment. | Which cloud or background execution modes exist for that tool, whether they can be disabled organisation-wide, and which region the environment runs in. |
| Data handling | A recorded determination of what leaves your boundary, whether it is retained, whether it is used for model training on your tier, and what the contract says. | The plan tier, the contractual instrument and the administrative toggles. Enterprise and consumer tiers differ structurally here. The specifics change often enough that the only safe answer is a dated check against current vendor documentation. |
| Change management | Agent-authored code enters the codebase through exactly the same gate as human-authored code — non-author approving review, protected branches, CI as the only path to production. | Nothing. This one is genuinely identical across all three tools, and it is the control that carries the most weight with an assessor. |
| Logging and observability | You can answer, for a given date, which sessions ran, under which identity, which tools were invoked and which approvals were granted — and the log is retained longer than your observation period. | What the vendor exposes: an admin audit log, an API, local session files, or nothing. Where the vendor exposes nothing, the control has to be built from the platform side — repository, cloud and registry logs. |
| Enablement and offboarding | Access to the tool is provisioned and de-provisioned through the same joiner-mover-leaver process as any other privileged system, and appears in the periodic access review. | Whether licences are managed through your identity provider with SCIM, or bought on a card by a team lead — which is a shadow-AI question as much as an access one. |
The three tools do differ in ways that matter, and it is worth being precise about the shape of the difference rather than the detail. A terminal-native agent such as Claude Code tends to make command execution and filesystem reach the dominant axes, so sandboxing and command policy carry most of the weight. An IDE-native agent such as Cursor tends to make workspace trust, indexing and repository-level configuration the dominant axes, so what is indexed and where configuration comes from carry most of the weight. A platform-native agent such as GitHub Copilot tends to inherit the repository host’s own identity and policy model, which makes central administration easier and makes the platform’s permission model the thing you actually have to get right. Those are structural tendencies. The specific settings, plan tiers and administrative toggles change frequently enough that any page asserting them as fact will be wrong within months — so record what your organisation verified, and the date it verified it.
If you are certifying to ISO/IEC 42001:2023, this appendix is also the artefact that satisfies the inventory-and-roles expectations of an AI management system without a separate exercise: each tool is an entry in the AI system inventory with a named owner, a recorded capability graph and a review date. ISO 42001 certificates are issued by accredited certification bodies, while SOC 2 reports are attestations issued by licensed CPA firms. Tranquility Cybersecurity designs and implements the programme and coordinates both, and does not certify, attest or audit.
Six months at forty engineers
An illustrative sequence, at the pace this work actually moves when it is not being driven by an incident. Note the ordering: inventory precedes policy, the boundary precedes the ban, and everything lands before the observation period opens.
| Starting position | January 2026 | A forty-engineer payments platform. Three tools in use, none approved: Copilot bought centrally, Cursor bought on team cards, Claude Code installed by individuals. Every agent runs under the developer’s own credentials, in the developer’s own shell, with whatever the developer’s shell can reach. Nobody can answer which MCP servers are connected. |
| Move 1 — inventory before policy | 12–30 January | Two weeks spent enumerating rather than drafting. Licences reconciled against the identity provider. MCP servers enumerated by asking each engineer to export their configuration. A one-page capability graph produced per tool. Result: eleven MCP servers in use, four unknown to the platform team, one with write access to the production ticket tracker. |
| Move 2 — the boundary, not the ban | 2–27 February | One permission model published for all three tools: the five tiers in the table above. Deny rules mirrored by a platform permission in each case — the agent identity loses IAM write, production database access and force-push before the deny rule is written. Approval prompts reserved for the step-up tier, deliberately rare enough to still be read. |
| Move 3 — the gate that does the work | 2–13 March | Branch protection tightened on all repositories: non-author approving review required, bypass disabled for administrators, CI the only deploy path. A separate machine identity created for agent-opened pull requests, with no merge rights. This is the control that later carries the buyer conversation. |
| Move 4 — repository scope | 16 March – 10 April | Agent access narrowed from the developer’s full organisation reach to a per-task repository set. The payments-core and key-management repositories are excluded from all agent tooling and from all cloud execution. Two engineers object. The exclusion holds, and is documented with its rationale. |
| Move 5 — cloud execution assessed, then permitted | 13 April – 15 May | Provider-hosted execution assessed as a processing environment: report obtained and read, retention confirmed against current documentation and recorded with the date of the check, egress restricted to an internal proxy, trigger rights limited to named internal identities. Permitted for the service tier of repositories only. |
| Move 6 — the observation period opens | 1 June 2026 | Everything above is in place before day one, because a control that starts in month three of a six-month period did not operate throughout it. Monthly review of the connected-server list and the agent identities begins, performed by the platform lead rather than the engineers who configured the tooling. |
The observable result at the end of the sequence is not that engineers use the tools less. It is that a question which took three weeks and produced a guess in January — which agents are running, under what identity, reaching what — is answered from a register in an afternoon, and the answer is evidenced. That is the difference an assessor is looking for, and it is also the difference a customer’s security team is looking for.
What the CPA firm actually requests
In a SOC 2 examination under AT-C 205, no trust services criterion mentions coding agents. What happens instead is that your existing controls over logical access, change management and vendor risk are tested against a population that now includes agent activity — and the request list is unforgiving about populations you cannot produce. These seven requests cover almost everything we see asked.
| The request | What satisfies it | What gets rejected |
|---|---|---|
| Define the population of agent activity | A system-generated list, for the full period, of every agent session or run — identity, start time, repository, and execution locus — produced before any sample is drawn, with the query and date range visible. Where the vendor exposes no export, the population is reconstructed from platform-side logs and stated as such. | A count nobody can reproduce. A list assembled from memory of which teams use the tool. A vendor dashboard showing the last thirty days when the period was six months. |
| Prove the population is complete | The session list reconciled to an independent source — the licence roster from the identity provider, the machine identities present in the repository host, the registry proxy’s client list — with counts stated and any difference explained. | A licence count that exceeds the session list with no explanation, which usually means someone is running the tool outside the managed path. An unexplained gap is the finding. |
| Show agent-authored changes went through the gate | A merge export for the period showing, for each selection, the author identity, the approving reviewer, the timestamps, and that the two are different accounts — plus branch-protection settings captured at two in-period dates and the organisation audit log proving they were not relaxed in between. | A merge where the machine identity is both author and approver. A protection rule with bypass enabled for administrators. A single screenshot of settings taken during fieldwork. |
| Show the permission boundary was configured and held | The agent configuration — allow-list, deny-list, sandbox and connected servers — captured at the start and end of the period, plus the platform-side control that backs it: the IAM policy, the scoped token definition, the registry policy. | A policy document describing rules nobody applied. A configuration file in one developer’s home directory offered as evidence of an organisational control. |
| Show step-up approvals happened | For each selected high-risk action, the approval record naming the approver and the specific action, correlated to the resulting platform event — the push, the pull request, the dependency addition. | A blanket approval covering a whole session. An approval where the approver is the agent’s own operator on a control the description said required a second party. |
| Show the cloud execution environment was assessed | A dated vendor review record for the provider-hosted environment, naming the report or certificate relied on, its scope and period, the complementary user entity controls extracted, and the data classes permitted into it — completed before the first run, not after. | A trust-centre page bookmarked. A review dated after the environment went into use. A report whose scope covers a different service to the one you are running. |
| Show someone reviews this on a cadence | A dated periodic review of the approved tool and connected-server list, the agent identities and their permissions, and the exceptions raised — performed by someone who does not administer the tooling, with the outcome recorded and actions closed. | A review with no artefact. A review of a list curated by the person being reviewed. Twelve months of reviews signed in one sitting the week before fieldwork. |
Two arithmetic points worth planning for. Sample sizes are a matter of professional judgement rather than a prescribed table — AT-C 205 requires sufficient appropriate evidence and leaves the quantity to the auditor — but the shape is predictable. Merged agent-authored pull requests are usually a large population, so expect a sample of roughly twenty-five selections and expect an expanded sample if a deviation appears. Capability grants, cloud-environment reviews and periodic connected-server reviews are small populations, frequently tested in full, where a single miss is a deviation rate of a third or a half with no sampling risk to absorb it. That asymmetry is the argument for running the cheap reviews monthly rather than quarterly, and for collecting evidence as you go rather than reconstructing it. Second: check log retention before the period opens. Agent session logs, repository audit logs and registry logs all have retention windows set by plan or configuration, and a control described against a log that expired in month one is a control you cannot evidence.
The seven arguments worth having early
The model above covers the ordinary case. These are the situations that produce genuine disagreement between a platform team, a security team and an assessor, and where settling the answer in advance is worth several days later.
The agent runs as the developer, and the log cannot tell you apart
This is the most common starting state and the hardest to unwind, because the developer’s token is what makes everything work on day one. It produces an audit trail that attributes machine actions to a person, which corrupts your access reviews and your incident timelines simultaneously. The workable answer is a separate machine identity for anything that touches a shared system — pull requests, registry writes, ticket updates — even where local file editing continues under the developer’s own session. Where the tool genuinely cannot separate them, say so in the control description and compensate: the platform-side gate on merges becomes the control you rely on, because it is the one that can tell the difference.
A repository configuration file adds a capability nobody approved
Several tools read configuration from the repository itself, which means a merged pull request can attach a new MCP server or change an approval rule. That is a capability change arriving through the code path rather than the change path, and it is precisely the shape of ASI02 tool misuse. Treat those files as protected: require a code-owner review from the platform team on any change to them, and pin an administrator-managed allow-list of servers where the tool supports one. Where it does not, the compensating control is a scheduled diff of the effective configuration against the approved set, with the difference raised as an exception.
A contractor’s laptop is not your endpoint
Agent governance assumes you control the machine the agent runs on. For contractors and agencies you frequently do not, and the sandbox is only as good as the operating system underneath it. The choices are honest ones: issue a managed device, require cloud execution in an environment you have assessed so the local machine holds nothing, or accept that the contractor cannot work on the repositories that matter. What does not work is extending the same policy language over a device you cannot inspect and treating that as coverage.
Untrusted content is the instruction source
An agent asked to triage a public issue is reading text written by someone outside your organisation. That is not a hypothetical: it is the mechanism behind LLM01 prompt injection and ASI01 goal hijack. The boundary question is not whether the model can be fooled — assume it can — but what it can reach once it is. An agent triaging public issues should hold no credentials worth stealing, no egress beyond the ticket API, and no ability to modify code. Where a workflow needs both untrusted input and real capability, split it into two runs with a human between them.
Sandboxing that only bounds the filesystem
Teams often adopt a sandbox, confirm it stops writes outside the working tree, and consider the problem closed. Filesystem containment without egress containment leaves the exfiltration path open: the agent can still read everything inside the sandbox and send it anywhere. Egress restriction is the harder half and the one that matters for confidentiality commitments under CC6.6 and CC6.7. Ask specifically which of the two your sandbox does, and test it rather than assuming.
The agent needs a database to do the work
Debugging a data-shaped bug genuinely benefits from schema access, and a blanket denial pushes engineers into copying production rows onto laptops, which is worse. The defensible middle is a seeded non-production database with representative structure and no real personal data, plus read-only access to production schema metadata where it is truly needed. If production data access is unavoidable for a specific incident, it is a step-up action performed by a human with the agent switched off, and it is logged as an access event rather than a coding session.
Unattended runs on a schedule
The moment an agent starts from a cron, a webhook or a queue rather than a person, the approval tier that assumed a human present is empty. Every step-up action either becomes a deny or needs an out-of-band approval mechanism, and the run needs a bounded budget, a time limit and a stopping condition. Treat unattended execution as a separate entry in your inventory with its own risk assessment — it is a different control class, not a different setting, and assessors read it that way.
Two adjacent decisions have their own pages, because they generate more argument than anything here: whether the agent should read your .env file and whether it should deploy to production.
What buyers push back on and the answer
These seven now appear in most enterprise security reviews of a software vendor, and several have started appearing in security questionnaires as standing questions. The difference between a good answer and a defensive one is specificity about the mechanism.
“Your developers already have production access. What does governing the agent add?”
It adds a control over a second actor exercising that access. The developer’s access is bounded in practice by human attention: a person performs a few dozen privileged actions an hour, and each one passes through someone who knows why. An agent exercises the same rights at machine speed, chains steps without the pause between them that acted as an informal control, and forms part of its intent from text that may have arrived from outside your organisation. We are not claiming the developer is safer than the agent in some moral sense. We are saying the risk profile of the same permission changes when the thing holding it can use it a thousand times before anyone looks.
“Do you approve every command the agent runs?”
No, and a programme that claims to is either untrue or unusable. A prompt on every command trains the operator to approve reflexively, which converts a control into a habit and leaves you worse off than an honest boundary. What we do instead is define classes. Low-risk, reversible, in-scope commands run freely inside a sandbox and are logged. A middle tier runs within a bounded scope and is reviewable afterwards. A small set of high-consequence actions requires explicit approval each time. And inherently destructive actions are blocked by a permission the agent’s identity does not hold. Approval is a scarce resource, and it is spent on the irreversible.
“How do we know AI-written code is not going straight to production?”
Because the gate is on the merge, not on the author. Agent-authored changes enter the codebase through the same protected-branch path as human-authored ones: a non-author approving review is required, direct pushes to the release branch are disabled, bypass is switched off for administrators, and CI is the only deployment path. A point of focus under CC8.1 speaks to restricting unilateral development and implementation by a single user, and it applies identically whichever hand — or process — wrote the diff. What we can evidence is a merge export showing author and approver as distinct accounts, with the protection settings captured inside the period.
“Is our source code being used to train a model?”
That is a plan-tier and contract question, and the honest answer is a dated one. Consumer and enterprise tiers of these products generally differ in retention and in contractual protection, which is a durable structural difference. The specific behaviour on a specific tier changes often enough that any answer stated as permanent fact is unreliable. What a mature programme holds is a recorded determination per tool: which tier is licensed, what the current documentation and the executed agreement say about training and retention, the date that was checked, and who checks it again. We would rather hand a buyer that record than an assurance nobody re-verified.
“Why does the agent have less repository access than the developer using it?”
Because the two access decisions answer different questions. A developer’s organisation-wide read access exists partly for reasons that have nothing to do with today’s task — investigating an incident in another service, moving teams, reviewing a colleague’s change. An agent has none of those needs. It has a task. Narrowing to the repositories the task requires is straightforward least privilege under CC6.3, and it materially reduces what a single mis-instruction can reach. It is also the one narrowing that engineers rarely fight for long, because the operational cost is close to zero.
“You are running agents in someone else’s cloud. Where is our code?”
In a provider-operated environment we assessed before permitting it, and the assessment is a document we can share the substance of. It records which repositories are eligible, what credentials the environment receives and with what lifetime, where dependencies resolve from, what network paths exist back to our systems, how long the workspace and its logs persist, and which independent report or certificate we obtained and read for that specific service. Where our commitments to you do not permit a data class into that environment, those repositories are excluded from cloud execution entirely rather than covered by a caveat.
“Three tools means three risk assessments and three policies, doesn’t it?”
One framework and three determinations. The control questions are the same for every coding agent — identity, filesystem and command boundary, connected tools, execution locus, data handling, change management, logging, joiner-mover-leaver. What differs per tool is the answer, the mechanism that enforces it, and what the vendor exposes to you. Writing three parallel programmes produces three sets of drift and three review cycles nobody completes. Writing one framework with a per-tool appendix means a fourth tool next quarter is an appendix, not a project — which is the practical test of whether your model was built at the right altitude.
Frequently Asked Questions
Our developers already have production access. Why govern the coding agent at all?
What is the capability graph, and how do I actually assess one?
Does every command an agent runs need human approval?
Are agent-side deny rules enough on their own?
Should the agent have less repository access than the developer operating it?
Is a cloud or background coding agent a third-party processing environment?
Do we need separate policies for Claude Code, Cursor and GitHub Copilot?
How do we stop AI-written code reaching production without review?
What evidence will a SOC 2 auditor ask for about coding agents?
Where do ISO/IEC 42001 and the OWASP lists fit into this?
Related Reading
Reviewing AI-Generated Code
Same security outcome, different failure modes — and the review gate that has to stay meaningful at volume.
Read moreShould a Coding Agent Deploy to Production?
Separating code-generation rights from deployment authority, even when one human holds both.
Read moreCoding Agents, .env Files and Secrets
Why the agent usually needs the capability, not the secret — and the escape paths that matter.
Read moreThe Ten Questions That Govern Any AI Agent
Scope, ownership, data, capability, identity, oversight, failure detection, evidence, reassessment and how to stop it.
Read moreISO 42001 Knowledge Hub
AIMS controls, EU AI Act mapping, risk assessment and guides.
Read moreISO 42001 (AI Management)
The world's first AI management system standard, for AI builders.
Read more