An alert wakes the on-call operator. The obvious automation is to let an assistant inspect logs and restart the failing service. The hard question arrives one step later: what stops a plausible but wrong diagnosis from becoming a production command? SeeP was built around that question. It is an operations agent for a fleet, reachable through a local terminal or messaging channel, whose investigation tools can read state but cannot mutate it.
The early architecture had a damaging exception. SeeP's local terminal once had its own confirmation path. A command typed locally could bypass the policy applied to the same request made through chat. The current architecture sends both through a single sequence: read-only investigation, structured plan, policy verdict, human decision when required, signed bundle and node-side execution. Scripts and incoming incidents converge on the same path.
The agent can investigate; a node decides whether to act#
The agent's tool registry has no mutating tools. When it proposes a change, the policy engine scores the actual steps rather than accepting the model's own severity label. The requested approval covers a hash of the steps, arguments and resolved node list. An executing node recomputes that hash, checks the signature and expiry, and burns a run-scoped nonce in a durable ledger so a captured approval cannot be replayed.
The resolved node list is important. An approval for env=prod role=web would be ambiguous if those labels matched a different set of machines at execution time. SeeP resolves the selector before asking for approval and binds the concrete targets to the plan. The node keeps its own verification material. It does not accept the gateway's statement that the plan was approved at face value.
A multi-step plan exposed another subtle problem. If the nonce were consumed on the first mutating step, the second step of the same approved plan would look like a replay and stop after a partial change. SeeP's ledger binds the nonce to the run, plan hash and expiry. Later steps of that run can proceed; a second run presenting the captured bundle cannot.
What the audit can prove#
The audit chain makes alteration detectable, but it does not prevent someone with storage access from deleting the log. Chat-channel approvals also have a different assurance level from signatures made on an operator's device; SeeP records that distinction. Those limits belong alongside the guarantee, especially for an operations system whose value depends on explaining who authorized a production change.
Alerts are normalized and deduplicated by fingerprint so a repeating monitor event stays one incident. A recurring issue can reopen its original record instead of losing the earlier investigation. Those mechanisms make the system useful between emergencies, but they do not weaken the action gate: the unattended agent remains limited to reading and proposing.
The next operational proof is to exercise the whole path against a real managed fleet: enrollment, an alert, a policy denial, an approval, an expired approval and a replay attempt. The SeeP system record traces investigation, policy and execution in more detail.