Safety is a property of the loop, not of the LLM.
OpsKeeper does not trust any single agent. The closed loop enforces read-by-default, write-by-proposal, approve-by-a-human, and verify-by-an-independent-worker — at the orchestrator, not at the prompt.
The safety model in six lines.
The principles below are enforced at the manager level. Every skill and worker in OpsKeeper is bound by them.
Read by default
Diagnosis tools — metrics, logs, traces, git, topology, RCA reports — are always available to every worker. There is no implicit gate.
Write by proposal
Mutating tools require a pending proposal with an explicit blast radius. The control plane refuses to dispatch a recovery without one.
Approve by a human
A human approver is required before any recovery command runs. The approval is bound to a specific proposal and resource.
Exact-match guards
Resource, command, and payload hash must match the approved proposal exactly. Unknown tools and cross-resource targets fail closed.
Independent verifier
The actor and the judge are different workers. recovery.verify uses a four-metric allowlist and three warning tiers — never the same call path as recovery.dispatch.
Hash-chained audit
Every dispatch appends to loop_event_log (DB-enforced append-only). Every mutating-proposal transition appends to a SHA256 hash chain — tamper-evident and verifiable in-repo.
What we defend against.
These four classes of attack are explicitly covered. Red-team playbooks extend the set; the mitigations live in the manager, not in the prompt.
| Threat | Mitigation |
|---|---|
| Tool injection | A worker is tricked into requesting a tool outside its allowlist. Mitigated by the explicit tool_allowlist per skill_meta.yaml. |
| Role escape | A worker tries to take on a phase it is not contracted for. Mitigated by phase → role binding in the manager. |
| Blast-radius bypass | A proposal is approved for one resource and executed against another. Mitigated by exact match on resource, command, and payload hash. |
| Replan loop | An agent loops on planning without ever executing. Mitigated by max_turns budgets and the verified-only rule on recovery.verify. |
Please email security@opskeeper.dev or open a private security advisory on GitHub. See SECURITY.md for disclosure timelines.
OpsKeeper supports the latest release and the previous minor. Older releases receive critical fixes only.
loop_event_log is append-only at the DB layer. chat_proposal_audit chains every mutating-proposal transition with SHA256 — the in-repo verifier walks the chain and reports the first tampered entry.