Notifications
Clear all
Topic starter
25/06/2026 1:29 am
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
25/06/2026 10:55 am
Declarative tooling is now an identity governance problem, not just an engineering convenience. kongctl turns platform changes into reviewable plans, but the security consequence is that change authority is concentrated in a single CLI path. That means privilege design, approval boundaries, and audit quality become the real control surface. For identity programmes, this is a reminder that infrastructure-as-code governance and identity governance are converging around the same execution model.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: How do workload identity and PAM apply to platform automation tools?
A: Any identity that can change production platform state needs workload identity discipline, privilege boundaries, and lifecycle tracking. That includes service accounts, tokens, and operator credentials used by CLI automation. If the identity can modify access, routing, or organisation structure, it should be governed like other high-risk administrative access.
👉 Read our full editorial: kongctl 1.0 makes AI-native Konnect governance more declarative
