Skip to main content

​
Why Keycli

The problem Keycli is trying to solve is simple: agents are getting good enough to suggest and execute production changes, but most teams still do not have a safe control plane between agent intent and provider mutation. Without that layer, the trade-off is ugly:
  • give agents direct provider access and accept too much risk
  • or lock everything down so hard that agents become glorified autocomplete
Keycli exists to make that trade-off less stupid.

​
The product wedge

Keycli is the trust layer between autonomous coding agents and production systems. Instead of letting an agent call provider CLIs and APIs directly, Keycli makes the workflow explicit:
  1. express intent
  2. turn that intent into a structured plan
  3. classify risk and next action
  4. require approval when needed
  5. apply through constrained provider adapters
  6. record the run and audit trail

​
What users should stop doing

Users should not need to think in raw provider trivia like:
  • which CLI command mutates this setting
  • which token updates this Actions secret
  • which deploy step should happen after the env change
  • where approval happens
  • how to reconstruct what the agent actually did
The top-level experience should stay about intent.

​
The normalized model

Keycli wants one consistent shape across providers:
  • workspace
  • provider connection
  • plan
  • policy / risk
  • approval
  • run
  • audit trail
The provider adapters sit underneath that model.

​
Core concepts

​
Workspace

A workspace is the top-level boundary for:
  • principals and tokens
  • provider connections
  • plans
  • runs
  • audit history
You bootstrap a workspace first, then operate inside it.

​
Principals and tokens

Keycli distinguishes between:
  • human principals
  • agent principals
  • service principals
That distinction matters because permissions differ. Current truth:
  • owners/operators can do more than agents
  • agents should not be able to self-approve
  • agents should not be able to mint stronger tokens for themselves

​
Provider connections

A provider connection is how Keycli gains constrained access to a provider. Current providers:
  • vercel
  • github
  • render
Connections can be scoped:
  • Vercel → project
  • GitHub → repository
  • Render → service
Keycli does not pretend a scoped token is magically global.

​
Plan

A plan is the structured version of a requested change. For the current strongest slice, plans usually involve:
  • secret or env-backed config mutation
  • one or more provider targets
  • optional deploy-after-change behavior

​
Policy, risk, and next action

Before apply, Keycli decides what should happen next. Typical outcomes:
  • apply_plan → low-risk path can proceed
  • wait_for_approval → risky path requires a human
  • live execution is blocked or downgraded when readiness/scope is invalid
That is one of the main product behaviors. The system should not say “sure” just because an agent asked nicely.

​
Execution mode

Keycli stays explicit about whether execution is real. You will typically see:
  • provider-api → a real supported adapter and valid in-scope connection exist
  • local-provider-simulation → the workflow still runs, but the provider mutation is not live
That distinction should stay visible everywhere.

​
Approval

Today there are two practical approval paths:
  1. explicit approval through the hosted API / service flow
  2. a narrow GitHub comment approval wedge
The GitHub wedge is real, but intentionally limited:
  • comment-based
  • tied to repo + issue/PR context
  • allowlist-driven
  • not yet a full GitHub App install flow

​
Run and audit

After apply, Keycli records:
  • the run
  • step outcomes
  • approval history
  • audit events
That gives users one place to inspect what happened instead of reconstructing the story from several providers.

​
What Keycli is and is not

​
Keycli is

  • a multi-provider control plane for governed changes
  • strongest today on secret/env-backed config mutation
  • built around plan → approval → apply → audit
  • honest about live vs simulated execution

​
Keycli is not

  • a generic vault product
  • arbitrary remote shell execution
  • a giant provider matrix already finished
  • a polished zero-to-cloud provisioning system

​
Good fit right now

Keycli is a good fit if you want:
  • agents to propose changes without getting prod god mode
  • one workflow across Vercel, GitHub Actions, and Render
  • real approval and audit semantics
  • a narrow but honest live slice today

​
Not the right expectation right now

Keycli is not claiming:
  • full infrastructure provisioning from scratch
  • full rollback and drift coverage yet
  • enterprise-complete policy and permissions
  • frictionless setup for every production edge case

​
Best next reads