TL;DR: Platform state now has to be governable by both humans and AI coding agents without losing auditability or drift control, as Kong’s kongctl 1.0 makes Konnect management more declarative by combining plan-based GitOps, self-describing schemas, and agent-driven CLI workflows for APIs, portals, control planes, and organization structure, according to Kong.
NHIMG editorial — what this means for AI and NHI governance
Questions worth separating out
Q: How should teams govern declarative CLI tools that change API platform state?
A: Treat them as privileged change channels, not developer conveniences.
Q: When does an agent-ready admin tool become a security risk?
A: It becomes risky when the tool can generate valid configuration faster than the organisation can review scope, intent, and entitlement.
Q: What do teams get wrong about GitOps for API governance?
A: They often assume a plan document equals control.
Practitioner guidance
- Separate plan approval from apply rights Limit who can generate plans, who can approve them, and who can execute them in Konnect.
- Scope agent-facing CLI access by task Define which kongctl verbs, nouns, and output modes an AI coding agent may use.
- Add automation identities to access reviews Include service accounts, tokens, and developer tooling identities that can run kongctl in the same recertification cycle as human administrators.
What's in the full announcement
Kong's full product release covers the operational detail this post intentionally leaves for the source:
- The exact kongctl command patterns for querying, scaffolding, and applying Konnect resources.
- The bundled agent skills workflow and how the tool expects coding agents to consume them.
- The full list of Konnect resources and organisation objects now managed through the declarative engine.
- The integration points between kongctl and decK for control plane management.
👉 Read Kong's kongctl 1.0 release details for Konnect automation →
kongctl 1.0 and declarative Konnect governance for AI agents?
Explore further