Skip to main content

​
First governed change

The goal of your first real session is not to touch every provider. The goal is to understand the two modes that make Keycli interesting:
  1. a low-risk path that can apply directly
  2. a high-risk path that stops and waits for approval

​
Step 1: prove the trust model first

Run the hosted self-demo: 
npm run demo:hosted:self
That gives you the cleanest first explanation of why Keycli exists.

​
Step 2: run one low-risk live change

If you want real provider execution, use the preview-safe Vercel flow from Vercel. What you are looking for in the plan response:
  • plan.risk.level: "low"
  • nextAction: "apply_plan"
  • plan.execution.mode: "provider-api"
That is the cleanest first governed change because it is live without immediately turning into a prod-approval story.

​
Step 3: then run the approval-gated path

Once the low-risk path makes sense, create a mixed-provider or production-oriented plan and inspect the policy result. What you are looking for:
  • plan.risk.level: "high"
  • nextAction: "wait_for_approval"
  • live execution only if every target has a supported connected adapter

​
Why this matters

The product wedge is not “agent can change infra.” The wedge is:
  • agent proposes the change
  • Keycli structures it
  • Keycli decides whether approval is required
  • a human approves when needed
  • the change applies through constrained adapters
  • the run is auditable afterward

​
Minimal manual flow

​
Create an agent token

AGENT=$(curl -s -X POST http://localhost:8788/v1/tokens \
  -H "authorization: Bearer $KEYCLI_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"principalKind":"agent","principalName":"codex","label":"first-governed-change"}')

​
Create a plan

The exact body depends on provider and target, but the important inputs are:
  • action type
  • secret/config name
  • targets
  • optional deployAfter
  • request channel

​
Inspect the response before doing anything else

Check:
  • risk
  • next action
  • execution mode
  • execution reason
  • any approval metadata
That response is the control plane doing its job.

​
What a good first session should teach you

By the end, you should understand:
  • why scoped provider connections matter
  • why agents are not allowed to self-approve
  • why live-vs-simulated status must stay visible
  • why approval and audit are first-class product features, not admin leftovers

​
Best next reads