kongctl 1.0 makes AI-native Konnect governance more declarative

At a glance

What this is: Kong’s kongctl 1.0 makes Konnect management declarative, adding plan-based GitOps, self-describing schemas, and AI-agent-friendly CLI workflows for APIs, portals, control planes, and organisation structure.

Why it matters: This matters because identity and access governance increasingly has to cover both human operators and AI coding agents, with auditability, drift control, and scoped authority preserved across changing platform state.

Context

Kongctl 1.0 is a CLI for governing Konnect resources through declarative configuration rather than manual platform clicks or one-off scripts. The primary governance problem is not simple automation, but how to let humans and AI coding agents change shared API platform state without losing traceability, reviewability, or drift control.

That matters for IAM and NHI governance because the resource being managed is not just application logic, but platform structure, organization assignments, roles, and system accounts. When the control plane itself becomes programmable, access paths and change paths start to converge, so the governance model has to treat machine-driven actions as first-class operational actors.

The article frames this as a developer-experience release, but the underlying issue is cross-actor control over live infrastructure. That makes it relevant to both identity teams and platform teams that need deterministic change management across human and non-human operators.

Key questions

Q: What breaks when AI coding agents are allowed to manage Konnect state without a plan review step?

A: Without plan review, agents can turn configuration generation into opaque change execution. That removes the human checkpoint where drift, over-scoped resource edits, and unintended organisation changes are caught before live state is altered, so the governance model loses its last reliable audit surface.

Q: Why do self-describing schemas matter for AI-assisted API platform governance?

A: They give the agent a machine-readable contract for what valid configuration looks like, which reduces malformed output and limits guesswork. For governance teams, that means fewer ambiguous changes and a tighter boundary between accepted intent and rejected configuration.

Q: How should teams govern delegated access for AI coding agents in platform tools?

A: Treat the agent as a scoped operational actor, not as a generic automation layer. Define read, scaffold, and write permissions separately, review which resource classes it can touch, and ensure its authority stops at the smallest set of Konnect objects needed for the task.

Q: What is the governance risk of managing APIs, portals, and roles through one declarative path?

A: The risk is shared blast radius. A single change can touch platform resources, organisation structure, and access assignments at once, so teams need explicit review gates and separation of duties around the declarative workflow rather than around each object type in isolation.

How it works in practice

Plan-based GitOps for Konnect state changes

kongctl computes the difference between declarative YAML and live Konnect resources, then stores that delta in a plan document before changes are applied. That is different from script-based management, where each execution can drift from previous intent and where review usually has to reconstruct what the script did after the fact. A plan gives operators a reviewable artefact, and it also gives automation a bounded change surface. In identity terms, the important detail is that the authorisation target is not a single API call, but a state transition across APIs, portals, control planes, and organisation objects.

Practical implication: Treat plan review as a governance checkpoint for all Konnect state transitions, not just an implementation convenience.

Self-describing schemas and agent-driven configuration

kongctl can emit JSON Schema for resource types and scaffold complete YAML starting points, which lets coding agents generate conforming configuration without scraping documentation. That reduces ambiguity in the tool-to-model interface, because the agent is not guessing resource shape from prose or inference. The governance value is stronger than convenience: when a model can read and emit machine-checked schema, configuration drift becomes more observable and malformed intent becomes easier to reject before it reaches production. For NHI and agentic workflows, schema awareness is a control boundary because it constrains what the agent can ask the platform to do.

Practical implication: Use schema-aware workflows to narrow the gap between generated intent and acceptable platform configuration.

Agent-enabled CLI access and delegated operational scope

kongctl is designed to be driven by AI coding agents through bundled skills, local output filtering, and CLI verbs that expose live resource state. That means the agent is not just writing text about infrastructure; it is participating in operational decision-making inside a defined tool interface. The governance issue is delegation scope. If agents can query, scaffold, and prepare changes, teams must know which parts of the platform they are allowed to observe, modify, or chain into other actions. This is where agentic access starts to resemble privileged operational identity, even if the tooling still looks like a CLI.

Practical implication: Define the exact Konnect actions an agent may perform before you let it operate against live resources.

NHI Mgmt Group analysis

Declarative control is now a governance requirement, not just an engineering preference. Once API platform state can be changed by both humans and AI coding agents, the old console-versus-script debate becomes too narrow. The real question is whether every change can be expressed, reviewed, and replayed as a governed state transition. That is the bar for identity-aware platform operations now.

Self-describing configuration narrows the gap between human intent and machine execution. When a CLI can publish its own JSON Schema and scaffold valid resources, it changes how authority is delegated to tools and agents. The value is not only speed. It is that machine-readable contracts make it easier to constrain malformed actions before they become live platform state.

AI coding agents inside platform tooling create an access-governance problem, even when no human account is shared. The assumption that a CLI is just an operator convenience breaks down when agents can query live state, propose changes, and drive workflows natively. That means platform governance has to account for delegated operational identity, not just interactive login sessions.

Identity blast radius becomes the right lens for declarative platform management. kongctl covers APIs, portals, control planes, teams, roles, and system account assignments, so a mistake is not isolated to one resource class. The governance challenge is to understand how far a change can propagate when configuration, access, and organisation structure are managed through one operational path. Practitioners should measure that blast radius explicitly.

Plan-based review is the control point that separates safe automation from opaque automation. A plan document is only useful if teams treat it as a required approval surface, not a by-product. That matters because plan review is where drift, overbroad scope, and unintended object changes become visible before the platform is altered. For Konnect governance, that review step is the practical trust boundary.

From our research library:

• More than 80% of enterprises will have used generative AI APIs or deployed GenAI applications by 2026, up from 5% in 2023, according to Gartner.
• Read next: AI Agent Authorisation Guide

What this signals

Declarative governance is becoming the control plane for AI-assisted platform work: when humans and coding agents both act through the same CLI, the security question shifts from whether automation exists to whether every action is expressed as reviewable state. That makes plan documents, schema contracts, and scoped privileges the practical controls that determine whether Konnect changes remain auditable.

Identity blast radius is the more useful lens than tool choice: kongctl touches APIs, portals, control planes, team mappings, roles, and system account assignments, so the governance problem is how far one change can propagate across operational and identity objects. Practitioners should evaluate whether their current review and approval process still works when access changes and platform changes are the same workflow.

For practitioners

• Define agent operating scope Document which Konnect resources an AI coding agent may query, scaffold, or modify, and separate read-only inspection from change-capable actions.
• Make plan review mandatory Require every declarative Konnect change to produce a reviewable plan document before merge or apply, so live-state differences are visible to humans.
• Validate schemas before execution Use the resource JSON Schema output to reject malformed configuration and to keep generated YAML aligned with the current Konnect object model.
• Limit delegated access paths Review roles, system account assignments, and portal team group mappings to ensure that machine-driven operations do not inherit broad organisational authority.
• Track drift across all managed objects Monitor whether APIs, portals, control planes, and organisation structure remain aligned with declared intent after each applied change.

Key takeaways

• kongctl 1.0 moves Konnect governance toward declarative, reviewable state changes that humans and coding agents can both drive.
• The main risk is not the CLI itself but the governance model behind it, especially when schema-driven agents can operate on live platform resources.
• Practitioners should separate read, scaffold, and write authority, and require plan review before any declarative change reaches production.

Key terms

• Declarative Control Plane: A declarative control plane is a management layer where operators define the desired end state and the system reconciles live resources to match. In identity terms, it shifts governance from manual intervention to controlled change intent, which makes review, entitlement scope, and audit evidence central to security.
• Plan-Based Change Management: Plan-based change management creates an intermediate document that shows the difference between declared configuration and live state before changes are applied. For NHI and platform governance, that plan becomes the audit point where drift, scope creep, and unintended access changes can be caught.
• Agent-Driven CLI Workflow: An agent-driven CLI workflow is a command-line process that an AI agent can use directly to inspect, prepare, or apply changes. The governance concern is not the interface itself, but whether the agent's authority, scope, and outputs remain constrained enough to preserve accountability.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.