Oconee Runtime logoOconee RuntimeEnterprise AI Governance

Coding agents

Govern what AI coding agents are allowed to do.

AI coding agent governance is the practice of deciding which actions an AI agent may carry out, rather than only which prompts it may receive. Oconee Runtime evaluates a proposed action — a shell command, a file change, a dependency install, a tool call — against the actor, the agent, the repository and the applicable policy, then resolves it to allow, warn or block. Generating an action and being authorised to execute it are different things.

No sales call required.

The gap between suggestion and execution has closed

A code assistant that returns a diff leaves a person between the model and the repository. A coding agent does not: it proposes a command and then runs it, reads files it decides are relevant, installs what it thinks it needs, and calls tools on its own initiative. The review step that used to sit in the middle is now optional and frequently skipped.

That changes what a control has to inspect. Reviewing the prompt tells you what someone asked for. It does not tell you which repository the agent ended up in, what the dependency it chose actually pulls, or whether the command it assembled is the one a person would have approved.

Example scenario

One action, evaluated

Proposed action

Claude Code

npm install package-x

Context

Actor
Developer
Agent
Claude Code
Repository
Production API
Environment
Production
Action
Dependency install
Signals
command_execution_intent, dependency_risk_detected

Policy decision

BLOCK

A dependency install proposed by an agent inside a repository the organisation has classified as sensitive resolves to block; the same action in a sandbox does not.

Recorded as evidence

  • actor
  • agent
  • action
  • resource
  • context
  • policy
  • decision
  • timestamp
Examples illustrate Oconee Runtime workflows and policy scenarios.

How Oconee evaluates the action

The decision is made from the conditions that exist when the action is attempted, not from the conversation that led to it. Oconee resolves the actor and the agent, the repository and its sensitivity classification, the type of action, the resource it targets, and the policies that apply — then returns a decision and records it.

  • Actor and agent identity, where the surface reports it
  • Repository, and the sensitivity the organisation assigned to it
  • Action type — command execution, file change, dependency install, tool call
  • Named signals such as command_execution_intent and destructive_command_intent
  • The matching policy, and the enforcement mode the plan permits
  1. Actor
  2. Agent
  3. Action
  4. Resource
  5. Context
  6. Policy
  7. Decision
  8. Evidence

Relevant capabilities

  • Claude Code hook — evaluates a proposed tool call before it runs
  • VS Code and Cursor extension — in-editor AI activity
  • Repository sensitivity set in the dashboard, not inferred from a folder name
  • Allow, warn, block and redact decisions, recorded per action
  • Exception requests for a blocked action, time-limited or single-use

What Oconee does not do

Oconee governs the surfaces it integrates with: the Claude Code hook, the VS Code and Cursor extension, and supported browser AI tools. It does not silently intercept every AI product on a machine, and it does not read another extension's private chat panel. A control that claims to be everywhere is a control nobody can verify.

Common questions

What is AI coding agent governance?
Deciding which actions an AI coding agent is permitted to carry out — commands, file changes, dependency installs, tool calls — rather than only filtering what is typed into it. The control sits at the point of action, so the decision is made with the repository and environment known.
How can organizations govern Claude Code?
Oconee installs a hook that Claude Code calls before it runs a tool. The proposed action is evaluated against organisational policy and resolves to allow, warn or block, and the decision is recorded with the context it was made in.
Why is prompt filtering not enough?
A prompt filter inspects the request. An agent's risk comes from what it does afterwards — the files it reads, the dependency it selects, the command it assembles from information gathered along the way. A safe prompt does not guarantee a safe execution path.

Related

Other use cases

Protect critical repositories

The same command is routine in a sandbox and unacceptable in production.

Prevent sensitive AI actions

Risk appears after the prompt, in what the agent reads and assembles.

For engineering leaders

Blanket restrictions push engineers to unmanaged tools and lose you the visibility.

AI proposes. Policy decides.

All use cases