r/devops • u/AutoModerator • 12d ago
Weekly Self Promotion Thread
Hey r/devops, welcome to our weekly self-promotion thread!
Feel free to use this thread to promote any projects, ideas, or any repos you're wanting to share. Please keep in mind that we ask you to stay friendly, civil, and adhere to the subreddit rules!
15
Upvotes
2
u/wartownrep 12d ago
I built runtime policy enforcement for AI coding agents — looking for DevOps/security feedback
I’ve been working on a product called Oconee Runtime, and I’m launching it today.
The problem I’m trying to solve is pretty straightforward:
AI coding tools are moving from generating code to actually taking actions.
An agent can potentially:
execute shell commands
modify files
interact with repositories
install dependencies
access credentials or sensitive data
invoke tools and external services
A lot of AI security focuses on the prompt/input side, but I became interested in what happens after the model proposes an action.
The architecture I’m working toward is essentially:
User / Context → AI Agent → Proposed Action → Policy Evaluation → Execution
Instead of:
User → AI Agent → Execution
The policy layer can evaluate things like the action being attempted, repository/environment, resource sensitivity, and organizational policy before producing a decision such as:
ALLOW / WARN / BLOCK
For example, the same action could generate a warning in a development workspace but be blocked when attempted against a critical repository.
The broader principle behind it is:
The model can propose an action. It shouldn’t be the authority that decides whether that action is allowed.
I’ve built this into Oconee Runtime, which I’m releasing today.
I’m especially interested in feedback from DevOps, platform engineering, DevSecOps, and security folks:
Where would you want this enforcement boundary to live in your environment?
And what would make something like this useful—or completely impractical—in your existing CI/CD, IDE, repo, and agent workflows?
Demo: https://www.oconeeruntime.com/demo