← Real Cases
REAL CASEcase-kai-evolution
Kai — technical capability is not authorization
Kai’s evolution consolidated the boundary between what an agent can technically do and what it is authorized to do now.
Context
Kai was designed to interpret DCP Flow, analyze repositories, prepare handoffs and execute actions when tools and permissions allow.
Problem
A capability list could be mistaken for automatic permission to modify, merge, deploy or destroy.
Evidence
- Public capability definition.
- Human Gates in real repositories.
- Manual Fallback when direct action is unavailable.
Decision
Formalize Capability ≠ Authorization and require context, permission and a Human Gate for material actions.
What changed
Authorization became an independent dimension from technical capability.
What we learned
- CAN DO ≠ AUTHORIZED NOW.
- A manual fallback must also be verifiable.
- Autonomy is governed by risk and scope.
How to reuse it
- Internal agents.
- Codex/Antigravity handoffs.
- GitHub and infrastructure automation.
What NOT to generalize
- Permissions of a specific tool.
- Permanent access to every environment.