1. Separate observation from execution
Start with a question and the minimum read access needed to investigate it. Collect service status, relevant logs and configuration before preparing a change. Keep observed facts separate from the explanation built from them.
Read-only access still needs boundaries. Logs can contain secrets and personal information. Limit the time range, resources and fields that enter an investigation, and make redaction part of the collection path.
2. Make the scope impossible to miss
Every plan should state the environment, resource, identity and permitted operation. In Kubernetes, show the cluster context and namespace. For a Linux server, show the host and service. For Docker, show the host, project and container or service.
Enforce that scope outside the model. Authorization belongs in the access and execution layer, where a rejected action remains rejected regardless of how the request was phrased.
3. Approve the actual change
A useful approval includes the command or configuration diff, expected impact, preconditions and recovery plan. “Fix the cluster” is not a meaningful approval request.
Bind approval to the reviewed plan. If a parameter, target or operation changes after review, ask for a fresh decision. Keep destructive operations and broad access changes subject to a stricter policy.
4. Treat incoming text as evidence
Log entries, issue descriptions and command output can contain instructions written by someone else. Those instructions must not become authority to run a tool, disclose a secret or change the scope of the task.
Use a fixed distinction between operator intent and collected evidence. Restrict available actions and validate their inputs even when the explanation sounds convincing.
5. Verify behavior, then keep the record
A successful command, a green pipeline and a Ready pod are different forms of evidence. None automatically proves that the user-facing problem is solved. Define the service check before execution and compare the result with the expected outcome.
Record the observations, reviewed plan, approval, execution result and verification. Protect this record separately from the system being operated. Reversibility should also be stated honestly: a backup restore is a different recovery process from rolling back a deployment revision.
Further reading
Consult the documentation for your installed version and review commands against your own environment.
Kubernetes: Role Based Access Control Good Practices