Is sandboxing the agent enough?

Sandboxing bounds the blast radius of execution and is worth doing. It does not address the actions that are meant to leave the sandbox — the commit, the push, the pull request — or the credentials the agent legitimately needs to do its job. Sandboxing and action governance solve adjacent problems.

Will this slow developers down?

It depends entirely on how many actions trigger a decision point. A policy that confirms on a narrow, well-chosen set of destructive or irreversible actions is close to invisible in daily use. One that confirms on every file write will be turned off within a week, which is the outcome to design against.

How do you tell an agent's action from a human's?

By observing the tool and the workflow in the development environment rather than inferring it from the change itself. This matters because the appropriate policy differs: a human typing a destructive command has already thought about it, and an agent proposing the same command mid-task has not.

Do we still need code review?

Yes. Review evaluates whether a change is correct and appropriate; runtime governance evaluates whether an action was permitted. Neither substitutes for the other, and the actions that most need governance are precisely those that never reach a review.

Threats

Securing AI Coding Agents

Oconee Runtime TeamPublished September 6, 20264 min read

Short answer

How do you secure AI coding agents that can run commands and edit files?

You secure an AI coding agent by governing its actions rather than its prompts. The agent already holds the developer's credentials and repository access, so identity controls cannot help; what you can control is which commands it runs, which files it writes, where it pushes, and which of those require a human to confirm. The decisive variable is autonomy: the same action carries different risk when a developer approves each step than when the agent is running unattended.

Definition

AI coding agent: An AI coding agent is a system that pursues a software-engineering goal by taking actions in a development environment — reading and writing files, running commands, and using developer tooling — rather than only producing text for a human to apply.

Diagram

Governing an agent's proposed action

The prompt is not the control point. What the agent attempts to do is, and the same attempt is judged differently depending on where and how it happens.

Step 1
Goal delegated
A developer states an outcome, not a sequence of steps.
Step 2
Agent proposes an action
Run a command, write a file, stage a commit, push a branch, call a tool.
Step 3
Action + context evaluated
Repository sensitivity, target path, destination remote, and current permission mode.
Step 4
Outcome recorded
What was attempted, which rule applied, and whether it ran — regardless of the decision.

Possible outcomes

Allow
Routine action in a low-sensitivity context. Proceeds and is logged.
Confirm
Elevated risk, so a human decision point is inserted before it runs.
Block
Protected path, prohibited destination, or an action not permitted unattended.

Why the usual controls do not reach this

A coding agent runs as the developer. It inherits their filesystem access, their repository permissions, their credentials and their shell. Every action it takes is authorized in the identity sense, so an access review will never flag it.

Code review is the other control people reach for, and it catches a great deal — but only what arrives as a diff. Commands the agent ran, files it touched outside the change, packages it installed and network calls it made are not in the pull request.

The gap is specific: authorized identity, unreviewed actions. That is the space a runtime control occupies.

Autonomy is the variable that changes everything

Agents run in different modes, and the terminology varies by tool, but the spectrum is consistent: the human confirms every action; the human confirms risky actions; the agent proceeds without confirmation; the agent runs in a loop unattended.

Risk does not increase gradually along that spectrum — it steps sharply at the point where nobody is looking at each action. An unattended agent can take many actions between the moment something goes wrong and the moment a human notices.

A governance model that ignores mode ends up either too strict for supervised work or too loose for unattended work. Treating the mode as an input to the decision is what lets one policy serve both.

Interactive with per-action approval — a human is the control; policy can be advisory.
Approval for elevated actions only — policy defines what counts as elevated.
Unattended within a session — policy is the only control in the path.
Background or scheduled execution — additionally, nobody is present to see a warning at all.

The action classes worth governing first

Not everything an agent does needs a rule. A small number of action classes account for most of the irreversible outcomes, and they are the right place to start.

Command execution, especially anything destructive, privilege-changing, or reaching the network.
File mutation in protected paths: infrastructure definitions, CI configuration, secrets files, deployment manifests.
Git operations: force pushes, history rewrites, commits to protected branches.
Destination control: which remote a push targets, so work does not leave for an unexpected repository.
Dependency changes, where a single added package is a supply-chain decision.
Credential and secret handling anywhere in the above.

Untrusted content reaches agents more often than it reaches people

An agent that reads issue text, fetches a web page, or ingests a dependency's documentation is processing content the organization did not write. Instructions embedded in that content can be picked up as if they came from the user — the indirect prompt-injection problem, which OWASP places at the top of its Large Language Model risk list.

This is a strong argument for governing actions rather than prompts. If enforcement depends on the prompt being trustworthy, injected content defeats it. If enforcement evaluates the action that results, the origin of the instruction stops mattering.

What Oconee Runtime governs here

The IDE extension covers VS Code and its forks, including Cursor and Windsurf, and observes AI-assisted engineering activity within them. Command execution, file mutation, git operations and repository context are the categories it evaluates, with policy applied against repository sensitivity and the detected permission mode.

Command enforcement and file-mutation controls are Growth+ tier capabilities; detection and activity visibility begin at the entry tier. The tier comparison on the pricing page states which capability sits where.

Examples

An agent asked to 'make the tests pass' modifies a CI workflow file to skip the failing suite.
The change is small, plausible in a diff, and defeats the control it touches. A file-mutation rule on CI configuration turns it into a confirmation prompt or a block, and records the attempt.
During a refactor an agent runs a command that removes an untracked directory containing local environment files.
Destructive command classes are evaluated before execution. Under per-step approval this may warrant a warning; running unattended, it warrants a block.
An agent resolves a merge conflict by force-pushing to a shared branch.
History rewrites on protected branches are a distinct action class. The governance decision does not depend on interpreting the agent's intent, only on the operation and its target.

Frequently asked questions

Is sandboxing the agent enough?: Sandboxing bounds the blast radius of execution and is worth doing. It does not address the actions that are meant to leave the sandbox — the commit, the push, the pull request — or the credentials the agent legitimately needs to do its job. Sandboxing and action governance solve adjacent problems.
Will this slow developers down?: It depends entirely on how many actions trigger a decision point. A policy that confirms on a narrow, well-chosen set of destructive or irreversible actions is close to invisible in daily use. One that confirms on every file write will be turned off within a week, which is the outcome to design against.
How do you tell an agent's action from a human's?: By observing the tool and the workflow in the development environment rather than inferring it from the change itself. This matters because the appropriate policy differs: a human typing a destructive command has already thought about it, and an agent proposing the same command mid-task has not.
Do we still need code review?: Yes. Review evaluates whether a change is correct and appropriate; runtime governance evaluates whether an action was permitted. Neither substitutes for the other, and the actions that most need governance are precisely those that never reach a review.

Sources

Coding agents
AI security
Policy enforcement
IDE