The Problem: Powerful Agents, Weak Guardrails
CLI agents are now fast enough to execute real infrastructure work end-to-end. That is great for throughput, but risky without controls. One bad command can destroy state, leak data, or push half-finished changes into production. Prompt instructions alone are not enough once sessions get long and context drifts.
OpenKeel was built to make agent operations boring in the best way: predictable, bounded, and auditable.
What OpenKeel Actually Is
OpenKeel is a two-module governance system for terminal-first AI workflows:
- Constitution: executable policy rules that classify commands as SAFE, GATED, or BLOCKED.
- Keel: mission state and progress control that keeps the agent aligned to declared goals.
In v0.2, OpenKeel adds profiles, timeboxing, command history, phase gates, and a proxy shell runtime.
How It Works in Practice
OpenKeel installs hooks and runs a proxy shell (openkeel-exec) so every command can be evaluated before execution. The command flow is:
Agent proposes command
|
v
OpenKeel classifier
- BLOCKED patterns (hard deny)
- GATED patterns (require approval path)
- SAFE patterns (allow)
- profile default policy
|
v
Timebox + phase checks + mission context
|
v
Execute or block, then append audit event
This gives a single choke point for policy and telemetry, instead of hoping every prompt stays perfect forever.
Profiles: Security by Use Case
OpenKeel ships with multiple profiles, each tuned for a different operating mode:
engineering: balanced safety for software development.pentesting: strict default-deny with approved offensive tooling patterns.monitoring: read-heavy operations with tight write restrictions.data-pipeline: controlled data and automation workflows.
This avoids one giant policy file that does everything badly.
Mission State and Drift Control
A mission has objective, constraints, plan items, and findings. OpenKeel injects this state into session start and periodically reinjects a compact capsule every N commands. It also emits drift summaries on stop hooks.
The result is less thrash. Agents spend more time finishing scoped work and less time exploring irrelevant branches.
Auditability and Review
Every event is logged to JSONL. Session history can be indexed with SQLite FTS for post-mortem review:
- what command was attempted,
- which rule matched,
- what was blocked,
- what executed and when.
For teams, this becomes the missing layer between "we trust the model" and "we can prove what happened."
Example Safety Outcomes
openkeel constitution test "rm -rf /" -> DENY
openkeel constitution test "git push --force" -> DENY
openkeel constitution test "ls -la" -> ALLOW
These are simple examples, but in production they prevent the exact classes of failures that cost days.
Design Principle
OpenKeel does not try to make agents less capable. It makes capability conditional on policy, mission state, and explicit phase progress.
Current Status
OpenKeel is live at v0.2 with a working CLI, profile system, proxy shell runtime, and governance hooks for Claude-style workflows. Generic adapter support is scaffolded for other agent CLIs, and the next iteration focuses on stronger gated approval UX and richer dashboards.
Repository: github.com/benolenick/openkeel