Coding Agent Governance

Coding agent governance defines the authority, operating boundaries, and evidence requirements for AI agents performing software development work. It establishes which changes and operations a task permits, under which execution identity and environment, and when that permission must be reconsidered.

This operational definition applies AI agent governance to development. A useful delegation describes more than the desired code change. It identifies the repositories, tools, data, and external systems the agent may use to produce that change. Reviewing the resulting diff does not, by itself, establish what happened while the agent worked.

What is a coding agent?

A coding agent is an AI-based system that uses development context to select and carry out work toward a software development objective. Its available actions might include inspecting a repository, editing files, running tools, or requesting changes in another system. The particular implementation determines how much of that work it can perform without further human input.

The interface does not define the authority. An IDE assistant may propose text or invoke tools; a CLI agent may operate interactively or continue a delegated task; an autonomous workflow may run under a service identity. For governance, inspect the enabled operations and execution environment rather than treating these interface labels as permission levels. A generated suggestion does not establish that the system may execute it.

The same task can acquire a different execution scope

Consider a hypothetical task: adapt an API client to a revised response schema, update synthetic fixtures, run the agreed test target, and prepare a diff for review. The task does not authorize releasing a package or changing a shared environment.

Assume the initial workspace is configured so that only the task checkout and temporary test output are writable, no publication credential is available, and network access is limited to an approved dependency mirror. These are explicit conditions of the example, not properties implied by the word “workspace.”

Now assume the task resumes on a runner that also has a writable release directory, a shared build cache, broader network access, and a credential authorized to publish the package. Those are hypothetical conditions of this runner, not universal characteristics of CI. The requested change and even the proposed diff may remain identical. The authority available to code executed during the task has changed.

The environment owner could provide a runner with the original restrictions, or an authorized reviewer could approve a specifically justified extension. Continuing unchanged merely because the agent remembers the task skips that decision. Removing an unnecessary credential is a different measure from asking the agent not to use it.

Treat the checkout and the process as different boundaries

A repository identifies source material; a checkout identifies a working copy. Neither description alone tells you which files, services, or credentials the process can reach. Git's worktree documentation, for example, describes linked working trees that share repository data while keeping some state separate. That is a source-control arrangement; an execution boundary still needs its own definition and enforcement. Git worktree documentation.

Identify the effective process user, mounted directories, inherited environment, accessible credential mechanisms, and network destinations. Include writable shared resources that later jobs may consume. A change outside the task checkout may have no representation in the submitted diff, even when it affects another workflow.

Keep source access and source disclosure separate as well. Permission to read a private repository for a coding task does not automatically authorize sending its contents to an external service. Define which development context may leave the environment and through which approved destination. The relevant scope can include an account or repository within a service, not just a hostname.

Tests and package operations are execution decisions

A test command is a way to run code, not a guarantee about its effects. Depending on the project, tests can invoke setup routines, subprocesses, network clients, or integration environments. The task owner needs to know what the selected test target executes and what authority that execution receives.

Package operations need the same scrutiny. npm's version 11 documentation describes lifecycle scripts around installation and test execution, and explains that scripts are passed to a shell. A familiar command name can therefore represent additional repository or dependency code. Inspect the selected tooling, scripts, and configuration before treating an operation as a bounded check. npm scripts documentation.

In the API-client example, fixtures let the task test parsing behavior without requiring access to the real service. If the chosen target also runs an integration suite, that changes the requested operation. Decide whether to select a narrower target or approve the additional environment and data access. A failed test is not, by itself, permission to acquire a production credential.

Include tools and MCP in the development scope

Tool access may extend beyond the local terminal. A repository tool, issue tracker, build service, or MCP server can perform operations using an identity different from the agent's local process. Evaluate the actual operation, destination, and credential behind each interface.

The MCP tools specification requires servers to validate inputs and implement access controls. Those requirements do not establish that a particular server enforces the scope of a coding task. Passing schema validation, authenticating to a server, and being authorized to publish a package are distinct conditions. MCP tools security considerations.

For the hypothetical client update, a remote tool that starts a build needs an identified repository, revision, job definition, and execution identity. Calling it from a restricted workspace does not transfer that workspace's restrictions to the remote runner. The architecture guide explains how to locate these handoffs and the components that can apply decisions.

Delegate useful classes of work with explicit conditions

Productivity depends on giving agents enough room to complete a bounded task. Requiring confirmation for every file edit can obscure the decisions that change authority. Define routine work that may proceed within established conditions, and distinguish it from operations that need another decision.

For the API-client task, an organization could permit edits to the client and synthetic fixtures plus execution of a reviewed test target in the restricted environment. Changing the test harness, adding a dependency, opening an external connection, or modifying release configuration would require evaluating a different scope. This is an example policy, not a universal classification of development risk.

Make the requirements reviewable: the desired result and exclusions; repository and starting revision; permitted paths and operation classes; allowed test and build environment; data and destination limits; execution identity; and the person authorized to resolve a scope change. These conditions can live in an established task and policy system. They do not require a new manual checklist for every routine edit.

An exception should explain the additional operation and why the existing scope is insufficient. “The task needs more permissions” gives a reviewer too little information. “This test requires the designated integration environment under a restricted test identity” presents a concrete request that can be accepted, narrowed, or rejected.

Use the coding agent governance guide to turn these requirements into a pilot with validation cases and operational owners.

Reassess identity and context when work moves

The developer who requested a change, the agent session doing the work, and the identity used by an executing tool serve different roles. Preserve enough association to identify the task owner without assuming that the requester's full access should be inherited by the agent or runner.

For a resumed task, reassess material changes: a different checkout revision, an altered test script, a new remote executor, additional mounts, a wider credential, or a changed destination. A session identifier alone does not establish continuity of these conditions. If the organization cannot determine the new scope, it needs an explicit decision about whether and how execution may continue.

GitHub's secure-use guidance provides a concrete CI example: credentials used by workflows should carry only the privileges needed, and token permissions can be limited for individual jobs. The general design lesson is to assign execution authority to the work that needs it, rather than making release authority available to unrelated development steps. GitHub secure-use reference.

In the example, approval of the client change would not justify retaining the publication credential for parsing tests. If release later becomes a separate task, it needs its own authorized revision, destination, and execution conditions. That separates a legitimate development request from an accidental expansion of the environment available to it.

Place controls before the effect they need to restrict

Pre-execution control evaluates a proposed operation at a point that can still prevent that operation from starting. For a coding agent, that might be a file operation, shell-tool invocation, or remote build request. The control's scope depends on what that point sees and can affect.

A check on a top-level shell request does not automatically establish coverage of every subprocess, file access, or connection made after the shell starts. Combine the decision point with appropriate restrictions on the execution environment and destination. Record paths outside the integration and the actual response to evaluation failure. Runtime AI governance explains the timing and failure contracts in more detail.

For a scope-sensitive operation, decide in advance whether an unavailable evaluator means holding the work, rejecting it, or continuing under a separately justified policy. Verify that behavior for the installed mechanism. A declared governance requirement cannot substitute for the behavior the executor actually implements.

Preserve code review and repository controls

Code review assesses the proposed change. Execution controls constrain how the task may operate. Repository controls regulate changes accepted into protected branches. GitHub, for example, documents configurable review and status-check requirements for protected branches. These mechanisms answer related questions at different points in the workflow. About protected branches.

A branch restriction does not by itself constrain a test process's network access before a push. An execution approval does not establish that the resulting code is correct. Keep both reviews meaningful: inspect the change and its test coverage, while separately evaluating the authority under which tests, builds, and external operations run.

Pay particular attention when an agent changes the mechanism that validates its own work. Editing a test target or workflow may be justified, but a passing result from the modified mechanism needs review in that context. Preserve who approved the validation change and which revision was actually checked.

Make the development evidence answer specific questions

A useful task record connects the approved objective to the repository revision, effective execution environment, operations requested, decisions applied, and artifacts produced. Include the relevant test or build target and its result so a reviewer can distinguish “this check passed” from the broader claim “the change is safe.”

Keep the evidence proportional to the question. The record can identify a credential's role and scope without storing the secret itself. It can identify a fixture set without copying sensitive service responses. Track changes in environment or policy that explain why one execution was allowed and another required review.

When a remote operation's result cannot be confirmed, leave that outcome unresolved until there is appropriate evidence. A task completion message or final diff is not a complete account of external effects. For suspected misuse, the AI agent security pillar adds the threat model; the development record supplies the task and execution context needed to investigate it.

Where KonaSense fits

In the reviewed Claude Code PreToolUse implementation for Kona for Agents, proposed Bash-tool requests are represented as shell operations with the supplied command and working directory for policy evaluation. The adapter can return a denial, a user-approval request, or updated tool arguments. Its evaluation-error path falls back to Allow; the effect of its response depends on the installed host behavior.

This is a specific decision point within a development workflow. It does not establish isolation of the process or control of every effect after a shell starts. Evaluate the integration alongside the repository, runner, credential, and destination restrictions that define the task's real authority.