Repository context
Apply different policy to the same AI action based on context.
The risk of an AI-assisted action depends on where it lands. Oconee Runtime lets an organisation classify repositories by sensitivity, so the same proposed action can warn in a development sandbox and block against a production repository. The action does not change; the context does, and the policy follows the context.
No sales call required.
One rule for every repository is either too loose or unusable
A policy strict enough for the repository that serves customer traffic will stop work in a scratch project, and engineers will route around it. A policy permissive enough for the scratch project offers nothing where it matters. Teams usually resolve this by writing the permissive one and hoping.
Sensitivity is a property of the resource, not of the action. Once the organisation states which repositories are critical, a single rule can be strict exactly where it needs to be.
Example scenario
One action, evaluated
Proposed action
Claude Code
npm install package-xContext
- Actor
- Developer
- Agent
- Claude Code
- Repository A
- Development sandbox — low sensitivity
- Repository B
- Production API — classified critical
- Action
- Dependency install
Policy decision
WARN
In the sandbox the engineer is warned and keeps working. The identical action against the repository classified critical resolves to block, and the evidence names the rule that matched in each case.
Recorded as evidence
- actor
- agent
- action
- resource
- context
- policy
- decision
- timestamp
How context is resolved
Repository sensitivity is set by an administrator in the dashboard and takes precedence over any local guess. That ordering matters: a classification inferred from a folder name is wrong the first time somebody clones a critical repository into a directory called scratch.
- Repository sensitivity assigned in the dashboard, applied on the IDE and Claude Code surfaces
- Workspace identity derived from the repository, not the local path
- Action type and the resource it targets
- Git activity signals, including commit and push risk
- Actor
- Agent
- Action
- Resource
- Context
- Policy
- Decision
- Evidence
Relevant capabilities
- Repository and workspace sensitivity classification
- Dashboard classification overrides the local heuristic
- Per-signal enforcement posture, so one signal can warn while another blocks
- Decision evidence naming the policy that matched
On branches
Oconee detects git activity signals, including pushes and protected-branch activity, and those signals can inform a policy. Branch is not currently a first-class scope you select when writing a rule the way repository sensitivity is — worth knowing before you plan a policy around it.
Common questions
- How can AI agents be governed in critical repositories?
- Classify the repository as sensitive in the dashboard. Policies then resolve against that classification, so an action that warns elsewhere can block there, without writing a separate rule per repository.
- What is context-aware AI policy enforcement?
- Evaluating a proposed action against the conditions present when it is attempted — the repository, its sensitivity, the environment, the agent and the actor — rather than applying one fixed rule to an action type wherever it occurs.
Related
Other use cases
AI coding agent governance
Agents now run commands, change files and install dependencies, not just suggest them.
Prevent sensitive AI actions
Risk appears after the prompt, in what the agent reads and assembles.
For security teams
Dashboards report AI activity after the fact and change nothing about it.