Operate

Security model

OpsKeeper's safety guarantees are properties of the orchestrator, not the LLM. This page is the canonical statement; the higher-level overview lives on the marketing Security page.

Trust boundary

The trust boundary runs around the OpsKeeper control plane. Workers, webhooks, and plugin endpoints sit outside it. Every crossing is authenticated and audited.

Inbound: HTTP API (Bearer JWT), MCP plugin (Bearer + HMAC), webhooks (HMAC-signed).
Outbound: read-only by default. Mutating calls require a sealed proposal.

Safety levels

Every worker declares a safety_level:

L0 — read-only. No proposal required. Examples: alerter, investigator, critic, reviewer, verifier.
L1 — annotates state. No external side effects. Examples: reporter (writes reports, never touches infra).
L2 — proposes; never executes. Used by planning workers.
L3 — mutates with proposal + human approver. The only L3 worker today is repairer.

The manager refuses to assign a worker whose level exceeds what the phase allows.

Proposal contract

A proposal is a contract. The control plane dispatches a recovery only when:

Resource, command, and payload hash match the approval exactly.
The tool is in the worker's tool_allowlist.
A human approver signature is present on the proposal.
The proposal is not expired (default TTL: 30 minutes).

Otherwise the call fails closed and an audit event is appended.

loop_contract.yaml

phase: approved
proposal:
  incident_id: INC-PG-POOL-001
  worker: repairer
  blast_radius: pg.connection_pool / one-db
  ttl: 30m
guard:
  required_approval: human
  exact_match: [resource, command, payload_hash]
  tool_allowlist:
    - execute:approved-only
audit:
  on_dispatch: ledger.append
  on_complete: ledger.seal

Audit ledger

Every dispatch and completion appends to loop_event_log, which the database enforces as append-only (a trigger rejects UPDATE/DELETE; corrections are new events). Separately, every mutating-proposal transition appends to chat_proposal_audit, a SHA256 hash chain:

hash chaining

hash_n = SHA256(prev_hash || canonical_json(payload) || proposal_id || action)

The in-repo verifier walks the chain in created_at order, recomputes each hash, and reports the first tampered entry. External anchoring of a daily root hash (transparency log) is a roadmap item, not a shipped feature.

Threat model

The mitigations below are part of the manager, not the prompt. They hold even if a worker is fully compromised.

Threat	Mitigation
Tool injection	Explicit per-skill `tool_allowlist`
Role escape	Phase → role binding in the manager dispatch table
Blast-radius bypass	Exact match on resource, command, payload hash
Replan loop	max_turns budgets + verified-only rule on recovery.verify

Vulnerability disclosure

See SECURITY.md in the repo for the disclosure timeline and contact information.