Keycli — product spec / manifesto
One-line pitch
Keycli is the trust layer between autonomous coding agents and production systems.Short pitch
AI agents should not mutate production directly. They should propose intent, receive a structured plan, pass policy and approval, execute through constrained provider adapters, and leave a full audit trail. That is what Keycli is for.The problem
Teams are starting to let agents and CLIs touch real systems, but the workflow is a mess:- provider CLIs all work differently
- credentials are scattered
- secret rotation is ad hoc
- deployments are fragmented
- approvals happen in random places
- auditability is weak
- agents can easily become too powerful
- either you move fast and accept unsafe prod mutation
- or you lock everything down and agents become glorified suggestion engines
The thesis
The winning product is not “better secret storage.” The winning product is agent-safe production change orchestration. Keycli should become the consistent layer that sits between:- top: agents, CLIs, APIs, developer workflows
- bottom: Vercel, Render, GitHub Actions, and other providers
What Keycli is
Keycli is a multi-provider control plane for production changes. It should give users one normalized flow:- connect provider
- test readiness
- create plan
- inspect risk, policy, and live-vs-simulated support
- approve when needed
- apply through adapters
- inspect run + audit trail
What Keycli is not
Keycli is not:- a generic secret vault
- a wrapper around provider CLIs
- arbitrary remote shell execution
- a no-code automation toy
- a dashboard-first CRUD app
The user outcome
The user should stop thinking:- “Which CLI do I run?”
- “Which API endpoint updates this secret?”
- “Where do I ask for approval?”
- “Did this deploy happen after the env var changed?”
- “Can I prove what the agent just did?”
- rotate this key across Vercel + GitHub Actions
- add this preview env var
- update this Render service secret
- remove this stale credential safely
- deploy after change
- show me exactly what happened
The normalized product model
Keycli should unify the control flow, not pretend providers are identical. That means the top-level product should always revolve around:- one plan object
- one policy decision
- one approval model
- one run object
- one audit trail
- many provider-specific adapters underneath
Normalized lifecycle
The long-term lifecycle model should be:- create config/secret
- update config/secret
- rotate secret/credential
- delete stale config/secret
- deploy / restart when needed
- verify / drift-check afterward
Design principles
1) Safety beats breadth
A narrow real flow is better than many fake integrations.2) Truth beats marketing
If something is simulated, say so. If something is live only when a provider connection is valid and in scope, say so.3) Workflow matters as much as API coverage
A product is more real when approval and execution happen where engineers already work. That is why GitHub comment approvals and plan posting matter.4) One control plane, many adapters
The value is in consistent plan/policy/approval/apply/audit semantics. Not in mirroring every provider API 1:1.5) Scope everything
Provider connections should be scoped where possible:- Vercel → project
- GitHub → repo
- Render → service
6) Re-check before apply
Never trust stale planning assumptions. Readiness, scope, and policy should be checked again at execution time.Best first user wedge
The most compelling wedge is: safe secret/config changes across real provider surfaces, with approval and audit built in. Example:- agent proposes rotating
STRIPE_SECRET - Keycli plans changes across Vercel + GitHub Actions
- human approves in GitHub
- Keycli applies through provider APIs
- Keycli records run + audit summary
Who it is for
Best near-term users:- AI-forward startup engineering teams
- teams already using coding agents or internal automation
- teams willing to automate real but bounded production workflows
- teams that care about trust, auditability, and control more than shiny UX
Canonical demo story
Explain Keycli in this order:- Hosted self demo → proves the trust model
- Vercel preview live demo → proves real provider mutation safely
- Vercel + GitHub mixed-provider flow → proves the bigger wedge
The rule for future work
Before building something new, ask:- Does this make Keycli a better trust layer?
- Does this improve multi-provider production change management?
- Does this strengthen the normalized lifecycle of create/update/rotate/delete/deploy/audit?
- Does this stay honest about live vs simulated support?