Claude Code Governance
Govern Claude Code Before It Acts
Control commands, file changes, repository actions and tool calls with organizational policy before Claude Code executes them — in the IDE where your developers already work.
Allow. Warn. Require approval. Block.
No sales call required. Works with Claude Code in VS Code.
- Claude Code action
- Oconee Runtime
- Policy + context
- Allow / Warn / Approval required / Block
Runtime enforcement
Every governed action takes the same path.
Claude Code proposes an action. Oconee evaluates it against your policy and the context it targets. A decision comes back before anything executes.
Shell command
A destructive command against infrastructure the agent was not asked to touch.
Command intent is classified, then matched against organizational policy.
Block
File change
Edits to application code in a workspace your organization has classified as development.
The workspace classification and the change itself both resolve as low risk.
Allow
Repository action
A push or branch change affecting a protected branch.
Repository context raises the action above what policy clears automatically.
Approval required
Where this fits
Native permissions are the floor, not the governance layer.
Claude Code ships real permission controls and you should use them. What they are not designed to be is your organization's policy system.
Consistent across engineers
Local settings are per-developer and drift. Organizational policy is defined once and applies to everyone who connects.
Aware of your context
Whether an action is acceptable often depends on which repository or workspace it targets — context your organization defines, not the tool.
Evidence you can produce
Governance you cannot evidence is difficult to assert. Decisions are recorded as they are made.
Use both, deliberately. Our own guidance is to pair centralized policy with Claude Code's managed deny rules. Rules Claude enforces itself hold regardless of whether any extension is running, which makes them the right place for the handful of things that must never happen. Oconee is the layer above that: the organizational policy, the context and the record.
Coverage
What your organization can control.
Enforcement sits on Claude Code's prompt and tool-use path, so coverage follows the actions an agent actually takes.
Command execution
Shell commands Claude Code proposes are classified by intent before they run, so a destructive command is treated differently from listing a directory.
File operations
Writes and edits are evaluated against the change itself and the sensitivity of the workspace it targets.
Repository and Git activity
Git commands, commits, branch and remote changes, pushes and merge intent are all governed as actions rather than inferred after the fact.
Tool invocation, including MCP
Enforcement sits on Claude Code's tool-use path, so it evaluates the tool being called and its arguments — not a fixed list of names. MCP tool calls are governed as invocations; Oconee does not sit in front of an MCP server.
Prompt submission
A prompt can be evaluated before it is sent, which is where sensitive content is caught earliest.
Secrets in tool arguments
Where a secret appears in the arguments of an otherwise reasonable call, the arguments can be rewritten to remove it instead of failing the whole action.
Workspace and repository context
The same action can resolve differently depending on which repository or workspace it targets, using classifications your administrators set centrally.
Agent autonomy
Oconee records whether a human was approving each tool call, so unattended agent activity is visible as such.
Decisions
Four outcomes, and the difference matters.
Most governance stories are told as a binary. Velocity comes from the two decisions in the middle.
Allow
The action clears policy and proceeds. Developers notice nothing, which is the point.
Warn
The action proceeds with policy guidance surfaced to the developer, for the cases where a nudge is enough.
Approval required
The runtime holds the action for human authorization, and the request is recorded for an authorized reviewer to approve or deny.
Block
The action is denied before it executes, and the decision is written to the audit trail.
Developer workflow
Govern Claude Code Where Developers Already Work
Adoption is an extension install, not a platform migration. Nobody changes how they work.
01
Install the extension
The Oconee Runtime extension installs from the Visual Studio Marketplace like any other.
02
Connect your organization
Sign in once. The extension picks up the organization you belong to.
03
Policies arrive
Your organization's policies apply without each developer configuring anything.
04
Keep using Claude Code
No change to how anyone works. Oconee evaluates governed actions as Claude Code proposes them.
For engineering leadership
Let teams use AI agents without giving every agent unlimited authority.
The question a CTO is actually asked is not whether engineers may use AI. It is what the AI is permitted to do, and how that is evidenced.
One set of controls, every engineer
Policy lives with the organization, not in each developer's local settings, so the controls are the same across the team.
Different rules for different repositories
Classify workspaces and repositories centrally. That classification reaches the Claude Code integration and changes how actions there are judged.
Evidence, not anecdotes
Governed actions and their decisions are recorded, so what agents did and what was stopped is answerable after the fact.
Guardrails instead of bans
Let engineering teams use AI agents without giving every agent unlimited authority.
Not a single-tool plugin
Start with Claude Code. Extend the same governance model.
Claude Code is the clearest use case today, and it is not the boundary of the product. The same policy engine and the same four decisions govern AI activity in the editor and in the browser, so the model you adopt here is the one you keep.
Coding agents
Claude Code activity governed on the prompt and tool-use path, in the IDE.
The editor itself
AI activity inside VS Code is governed by the same extension and the same policies.
The browser
AI tools used in the browser are covered by the published browser extensions, reporting into the same policy and evidence layer.
Start governing Claude Code today.
Create an account, complete the onboarding wizard, install the extension, and begin governing agent activity. No demo to sit through and no procurement call to book first.
No sales call required.
Questions
Claude Code governance, answered.
- What is Claude Code governance?
- Claude Code governance means applying your organization's policy to what a coding agent does — the commands it runs, the files it changes, the repository actions it takes and the tools it calls — rather than only to what it is allowed to read. Oconee Runtime evaluates those proposed actions before they execute.
- How does Oconee Runtime work with Claude Code?
- Oconee installs as a VS Code extension and registers with Claude Code's hook interface. When Claude Code is about to submit a prompt or use a tool, Oconee evaluates the action against your organization's policy and the context it targets, then returns a decision: allow, warn, require approval, or block.
- Does Oconee replace Claude Code's own permissions?
- No. Oconee is an additional organizational layer, not a replacement. Claude Code's native permission settings still apply, and Oconee's own documentation recommends pairing centralized policy with Claude Code's managed deny rules, because rules Claude enforces itself cannot be affected by a failure in any extension.
- Can Oconee block Claude Code actions?
- Yes. A blocked action is denied before it executes and the decision is recorded. Oconee can also rewrite a tool call's arguments — for example to remove a secret — so that a reasonable action can proceed without the sensitive value.
- Does Oconee work in VS Code?
- Yes. VS Code is the primary adoption path. The Oconee Runtime extension is published on the Visual Studio Marketplace, and it governs both Claude Code activity and AI activity in the editor itself.
- Can policies be managed centrally?
- Yes. Policies are defined for the organization and apply to developers without per-machine configuration. Administrators can also classify workspaces and repositories centrally, and that classification changes how actions targeting them are evaluated.
- Does Oconee support coding agents other than Claude Code?
- Claude Code is the most direct integration, but Oconee is not Claude-specific. The same policy engine and decision model govern AI activity in the editor and in the browser, which is why starting with Claude Code does not mean adopting a single-tool product.
- Do I need to schedule a demo?
- No. Onboarding is self-service: create an account, complete the onboarding wizard, install the extension and begin governing activity. No sales call is required.
Related
- Securing AI Coding AgentsHow do you secure AI coding agents that can run commands and edit files?
- Prompt InjectionWhat is prompt injection, and what actually defends against it?
- AI engineering governance demoAI-assisted engineering activity evaluated against repository context and organizational policy.
- AI Agent Risk ScannerA free, open-source CLI that scans a repository for AI coding-agent governance gaps and scores the risk. Runs entirely locally.