Skip to content
vops

Agent governance

vops lets a development agent understand the product, propose infrastructure work and invoke approved semantic operations. The agent does not receive the provider tokens or SSH private keys that make those operations possible.

The important choice is not “Codex or Claude Code?” It is how much authority the human wants to make available for this task.

The vops agent trust boundary An agent client such as Codex, Claude Code, OpenCode or Antigravity reaches a local MCP transport. Inside the vops trust boundary the request passes session and policy limits, an immutable plan and a human approval before vops services act on provider APIs and on hosts over SSH. Provider tokens and SSH private keys stay inside the boundary and are resolved locally at execution. Codex Claude opencode Antigravity AGENT CLIENT OUTSIDE THE BOUNDARY Codex Claude Code OpenCode Antigravity VOPS TRUST BOUNDARY Local MCP transport stdio, or authenticated loopback HTTP Redacted results return to the agent on this path. Secrets do not. Session and policy objective, repository, target, environment, expiry, operations, spend Immutable plan ordered semantic steps, expected effects, content hash Human approval the agent-facing surface has no approval tool vops services provider, host and application capabilities CREDENTIAL BOUNDARY Provider tokens SSH private keys resolved locally at execution Provider API Hosts over SSH
An agent request crosses one boundary; credentials never come back out. Preview Follows the documentation theme

The control loop

human selects approach and client
              ↓
human creates a bounded session
              ↓
agent inspects and proposes a semantic plan
              ↓
local policy allows, denies or requests approval
              ↓
human reviews the immutable plan
              ↓
vops executes with locally resolved credentials
              ↓
agent and human inspect operation and verification
              ↓
human revokes or lets the session expire

What vops owns

  • a versioned capability registry;
  • product knowledge and the flui.yaml schema;
  • short-lived sessions and policy limits;
  • immutable plans and human approvals;
  • semantic execution through the existing provider, host and app services;
  • redacted operation results;
  • a local append-only audit trail;
  • client adapters and local MCP transports.

What the human owns

  • selecting the repository and targets;
  • deciding whether the agent has any infrastructure path;
  • setting expiry, operation and spend limits;
  • reviewing effects rather than trusting a natural-language summary alone;
  • approving, denying, pausing and revoking;
  • deciding whether the OS-level execution environment is advisory or protected;
  • handling recovery when an operation has effects that cannot be rolled back.

What the agent never owns

The agent-facing surface does not provide:

  • raw provider credentials;
  • SSH private keys;
  • application or registry secrets as normal output;
  • a generic SSH or shell-execution capability;
  • a raw provider API;
  • an approval tool for its own request.

These are product boundaries, not instructions that depend on the model cooperating.

Human docs and agent material

This website explains choices and controls to people. The installed vops version ships the machine-facing material:

  • SKILL.md and its routed references;
  • the concise project bootstrap;
  • generated capability and error references;
  • MCP tool schemas.

That separation keeps the agent contract synchronized with the executable while letting the human documentation explain the larger trust model.

Continue with Choose an approach before configuring a client.