Safety and approvals

vops assumes that the expensive failure is not a bad command-line message; it is an unexpected bill, a locked-out server or deleted data. Its safety model therefore sits in executable checks, not just documentation.

Research is cheap, mutation is explicit

Read-only commands can run directly. Operations with lasting effects use one or more of these gates:

• a plan or dry run that shows intended effects;
• an explicit --yes confirmation;
• an ownership check;
• a preflight that proves an access path remains;
• a scoped agent session and plan approval.

The exact gate depends on the operation. vops <topic> <command> --help remains the source for its flags.

Provider ownership

Destructive provider operations are limited to resources vops can identify as vops-managed. A server name or provider tag carries that ownership signal. This prevents a broad provider token from turning a mistaken ID into permission to delete an unrelated production server.

The rule is deliberately narrower than “the credential can do it.”

Lock-out protection

SSH and firewall changes are evaluated against the path vops is currently using. For example, SSH hardening first verifies key access and refuses unsafe transitions. Host-firewall rules preserve SSH reachability unless the requested rules explicitly account for it.

A passing preflight is not a permanent guarantee—the network can still change— but it prevents the common error of removing the ladder while standing on it.

Plans are approvals, not transcripts

A human should approve the objective and effects of a change, not every internal SSH command required to implement it. Deployment and controlled-agent flows use an immutable plan:

1. vops records the intended inputs and effects;
2. the human reviews that plan;
3. approval binds to that exact plan;
4. changing an input invalidates the approval;
5. execution and verification are recorded as an operation.

This keeps approval useful without turning it into click fatigue.

Destructive operations still differ

Some flags opt into a larger effect. Examples include deleting a provider server, purging application volumes, purging a backup repository or forcing ingress removal while routes remain. Treat these as separate decisions, even when the non-destructive form of the command is familiar.

Caution

--yes means “execute this reviewed operation.” It is not a general safe mode. Read the plan and the command-specific flags before using it in automation.

Agents never become the credential owner

In the controlled agent surface, a development agent receives a short-lived session token that names its objective, repositories, targets, environments, expiry and operation limits. The local controller resolves provider and SSH credentials only when an allowed semantic operation reaches execution.

Pausing or revoking the session cuts off that path without rotating every underlying provider token.