Skip to main content

​
Approvals

Approvals are the point. If an agent can plan and apply a risky production change with no human checkpoint, you do not have a trust layer. You just have a faster way to make mistakes.

​
Current approval paths

Today, Keycli has two practical approval paths:
  1. Hosted API / service approval — explicit approve calls on the hosted control-plane path.
  2. GitHub comment approval capture — a narrow but real workflow for issue/PR threads.

​
What is true today

  • risky plans can require approval before apply
  • agents cannot self-approve if they do not have approval permission
  • agents cannot mint stronger tokens for themselves
  • approval status changes the plan’s next action
  • approval and apply show up in the audit trail

​
When approval usually matters

Approval is the right default for:
  • production-facing env var changes
  • shared secret rotation
  • coordinated multi-provider changes
  • anything with deployAfter: true on meaningful targets
The exact policy is still early, but the boundary is real.

​
Hosted approval path

For a plan that returns nextAction: "wait_for_approval", a human principal can approve it through the hosted API flow. This is the simplest path to understand because it keeps the mechanics obvious:
  • create plan
  • inspect policy result
  • approve as a human
  • apply as the actor allowed to execute

​
GitHub comment approval path

The current GitHub-native wedge works like this:
  1. create an approval-gated plan with requestChannel: "github-comment"
  2. attach GitHub repo + issue/PR context
  3. provide an allowlist of approvers
  4. if a GitHub connection exists, Keycli posts a summary comment into that thread
  5. a user comments /keycli approve <plan-id>
  6. Keycli verifies the signed webhook, repo/context match, and approver allowlist
  7. the plan is approved

​
What GitHub approval is not yet

Keycli is not claiming:
  • a full GitHub App install flow
  • broad PR-native workflow automation
  • delivery retries and reconciliation at production depth
  • approver inference from repo membership
The current wedge is real, useful, and intentionally narrow.

​
What to inspect before asking for approval

Check:
  • plan.risk.level
  • plan.nextAction
  • plan.execution.mode
  • approval metadata
  • request comment status when using GitHub comments

​
Suggested first learning loop

Do not overcomplicate the first session. The best first loop is:
  1. low-risk preview change
  2. high-risk approval-gated change
  3. inspect audit trail
That sequence makes the product boundary obvious very quickly.