Security model

vops reduces the number of places that can exercise infrastructure authority. It does not claim that local execution makes a compromised workstation safe.

Trust boundaries

Boundary	What vops relies on
Workstation	The operating-system user and local files are trusted unless an isolated agent launcher says otherwise.
Provider	A configured provider token can perform only what its provider permissions allow; vops adds product-level ownership and billing gates.
Host	SSH authenticates the selected access path; remote root authority remains powerful.
Local dashboard	Loopback binding and a one-time browser token prevent it from becoming an unauthenticated LAN service.
MCP HTTP	Loopback binding, Host validation and bearer authentication protect the local endpoint.
Watch relay	An explicit client token identifies the opt-in hosted notification identity.

Credential isolation

CLI, dashboard and MCP requests do not receive raw provider or SSH credentials. They request an operation from the local core; the credential resolver injects the required secret at the final execution boundary.

This design prevents a normal MCP tool result from becoming a credential exfiltration path. It cannot protect a process that already runs as the same OS user and is allowed to read the profile directory.

Ownership and spend

Provider deletion is limited to resources vops identifies as vops-managed. Creation is gated by billing model and explicit approval. An agent session can add a lower spend ceiling but cannot grant a provider capability that the configured token does not have.

SSH and firewall changes

vops checks the access path before applying SSH lockdown and preserves a timed recovery window while verifying the new configuration. Host firewall rules keep SSH reachable and the unified firewall reports another manager’s rules instead of pretending to own them.

These controls reduce lock-out risk. They do not replace provider recovery consoles or a tested emergency-access process.

Secret handling in applications

flui.yaml declares secret names, not their values. Plans can name which secrets are required without persisting the values in a reviewable artifact. Remote secret files use restrictive permissions.

Back up application data and credentials according to their own recovery needs. An application remove with --purge is allowed to destroy both.

Agent modes

Advisory mode means the agent uses scoped vops sessions and policies, but may still have an unrestricted shell under the user’s account. It can technically bypass vops if that shell can read credentials or invoke SSH.

Protected mode means the agent is isolated from provider tokens, SSH keys, the administrative CLI and unrestricted network paths. Only the scoped broker can reach infrastructure.

Current client integration is advisory. Protected launchers are a separate future control and must never be implied by a successful MCP setup.

If something looks wrong

1. Pause the affected session.
2. Use vops agent session stop-all if the scope is uncertain.
3. Lock the keyring with vops keyring lock.
4. Inspect the operation and local audit events.
5. Rotate the underlying provider or SSH credential only when exposure—not just an unauthorized request—is plausible.

The first three actions cut off vops-mediated authority without deleting the evidence needed to understand what happened.