KAi v2 makes agentic platform changes a governed write path

At a glance

What this is: KAi v2 is a Kong Konnect update that lets an agent propose and, after approval, execute platform changes, generate artifacts, and build dashboards inside governed guardrails.

Why it matters: IAM and security teams need to treat agent-assisted infrastructure work as a privileged identity problem because the control point has moved from advice to write access, approval flow, and scope-limited execution.

👉 Read Kong’s update on KAi v2 and governed agent writes in Konnect

Context

Agentic platform assistants change the identity problem from who can log in to what an approved agent can change at runtime. In Kong’s case, KAi v2 can now create, update, and delete Konnect resources, which means the governance question is no longer only about access to APIs but about delegated authority over production changes.

That matters for NHI, AI agent, and IAM programmes because the same assistant can now cross from read-only guidance into privileged execution. The practical issue is not whether the agent is helpful, but whether approval gates, role boundaries, and audit trails are tight enough to keep write operations inside policy.

Key questions

Q: How should security teams govern AI assistants that can make infrastructure changes?

A: Treat the assistant as a privileged non-human identity with narrowly scoped write permissions, explicit ownership, and mandatory approval for every state-changing action. The approval step must be enforced in the execution path, not just described in policy. Teams should also log the full request, proposed plan, and resulting artefacts for auditability.

Q: What fails when an agent can move from advice to write access too quickly?

A: Least privilege stops being meaningful if a read-only assistant can be promoted to a change-making identity without reclassification, scoped permissions, and transaction-level approval. The failure mode is privilege expansion by convenience, where the same workflow that answers questions also commits changes. That creates avoidable blast radius and weakens accountability.

Q: How do organisations know whether agent approvals are actually working?

A: Check whether every create, update, and delete request is blocked until an explicit human decision is recorded, and whether the logs show the proposed plan, the approval event, and the executed result. If the agent can proceed after a partial review, the control is only procedural, not enforced.

Q: What should teams do with agent-generated config files and dashboards?

A: Apply the same governance you would use for any operational change artefact. Review generated configuration before reuse, track provenance, and retain enough context to reconstruct why the agent created it. Dashboards and exported files are part of the control chain, not just convenience output.

How it works in practice

MCP tool exposure turns guidance into executable control

The release shows a narrow MCP tool surface, with discovery, schema lookup, and execution functions exposed to the agent. That matters because the agent no longer needs a human to translate intent into API calls one by one. Instead, it can compose a workflow from structured operations and carry it out in Konnect once approval is granted. This is still governed automation, not free-form autonomy, because execution is explicitly gated and the toolset is bounded. The security boundary therefore shifts from application UX to control-plane authorization and the trustworthiness of the agent instruction path.

Practical implication: audit which control-plane operations your agents can see, call, and chain before you enable write paths.

Human approval is the real control plane for write operations

KAi v2 keeps write actions behind an explicit approval step, which is the critical difference between a helpful assistant and a privileged operator. In governance terms, this is a delegated execution model: the agent can prepare the change, but a human must authorise the final act. That preserves accountability, but only if the approval step is actually mandatory for every state-changing operation and not just the common case. The deeper lesson is that approval gates must be enforced at the action layer, not merely described in policy text.

Practical implication: verify that every create, update, and delete path fails closed until approval is recorded.

Artifact generation and dashboards expand the identity surface

The assistant now produces decK files, Terraform output, and analytics dashboards from natural language requests. That extends the identity surface because the agent is no longer only changing configuration, it is also shaping the operational evidence and the observability view around those changes. For practitioners, that creates a second-order governance issue: the same identity that can propose infrastructure can also generate the artefacts used to recreate it or review it later. The risk is not just misconfiguration, but durable propagation of the agent’s decisions into downstream tools and workflows.

Practical implication: treat generated artefacts and dashboards as governed outputs that need review, retention, and provenance controls.

NHI Mgmt Group analysis

Governed agent writes are now a privileged identity pattern, not a novelty feature. KAi v2 crosses the line from advisory assistant to state-changing actor, which puts it squarely in the identity governance stack. The important question is no longer whether the assistant can understand requests, but whether its write authority is constrained like any other high-risk NHI. Practitioners should classify the assistant as an identity with operational blast radius, not as a simple productivity layer.

Human approval is only meaningful if the approval boundary is technically enforced. The release describes a plan-and-execute model, which is the right structure for controlled delegation. But approval text alone does not protect a control plane if the underlying execution path can bypass, replay, or broaden authorised actions. The governance lesson is that delegated change authority must be enforced at the transaction level, not assumed from workflow design.

Agentic platform assistants create identity blast radius through chained outputs. A single natural-language request can now produce live configuration, reusable artefacts, and operational dashboards. That means one privileged interaction can propagate through multiple downstream systems, each with its own persistence and review cycle. The implication is that change governance, artefact governance, and audit governance can no longer be treated as separate problems.

Runtime governance gap: This release shows how quickly a read-only assistant becomes a change-making identity once write paths are exposed. The control gap is not sophistication, it is scope. Once the agent can perform creation and deletion inside an administrative plane, teams need to rethink what they mean by least privilege for non-human actors.

OWASP-NHI and zero trust thinking both apply here, even though the subject is an AI assistant. The assistant is still a non-human identity with credentials, tool access, and policy boundaries. That makes workload-style identity governance relevant, especially where the agent authenticates with organisational tokens and respects role-based access controls. Practitioners should manage it as a governed workload identity with a sharper audit trail than a typical automation account.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• The same research says 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a governance lens on the broader identity lifecycle problem, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding controls that now need to extend to agentic identities.

What this signals

Runtime governance gap: as soon as an assistant can write into a control plane, the programme must move from access advisory to change governance. The right comparison is not manual versus automated, but read-only versus approval-gated execution, with provenance captured for every generated artefact.

With 80% of organisations already reporting AI agents acting beyond intended scope in our research, the pattern is no longer experimental. Teams should assume that the first failure will be scope drift, then audit ambiguity, then control-plane overreach if the tool surface is left broad.

This also reinforces why agent governance should be aligned to NIST AI Risk Management Framework and OWASP Top 10 for Agentic Applications 2026 thinking, especially where tool use and approval paths determine whether the assistant remains constrained.

For practitioners

• Classify the assistant as a privileged non-human identity Map KAi-style assistants into your NHI inventory with explicit owners, allowed operations, and escalation boundaries. If the agent can write to a control plane, it needs the same governance attention as any other privileged machine identity.
• Enforce closed-loop approval for all state changes Require human approval for every create, update, and delete action, and validate that approval is enforced in the execution path rather than only in policy documentation. Test the failure case where a write request is attempted without approval.
• Restrict the MCP tool surface to the minimum viable set Expose only the operations the agent genuinely needs, then verify that discovery, schema lookup, and execution cannot be chained into unintended administrative workflows. Review the tool surface whenever the assistant gains a new capability.
• Treat generated artefacts as governed outputs Apply review, provenance, and retention controls to decK files, Terraform exports, and dashboards generated by the agent. These artefacts can recreate configuration and influence operations, so they should not be treated as disposable by-products.

Key takeaways

• KAi v2 turns an assistant into a governed write-capable identity, which changes the security problem from usage to delegated control.
• The operational risk is not just configuration change, but the propagation of agent decisions into artefacts, dashboards, and downstream workflows.
• Teams should treat approval gates, scoped tool exposure, and artefact governance as the core controls for agentic platform access.

Key terms

• Agentic platform assistant: An agentic platform assistant is a non-human identity that can interpret intent and carry out platform tasks within defined guardrails. In this context, the key distinction is whether it only advises or whether it can also execute state-changing operations under governance control.
• MCP tool surface: The MCP tool surface is the set of structured actions exposed to an AI agent through Model Context Protocol. A narrow surface limits what the agent can discover and execute, which reduces the chance of uncontrolled chaining or overbroad access.
• Approval-gated execution: Approval-gated execution means an agent can prepare or propose a change, but a human must authorise the final action before anything is committed. For non-human identities, this is a core control because it preserves accountability and limits autonomous state change.
• Identity blast radius: Identity blast radius is the amount of systems, data, and downstream workflows an identity can affect if it is misused or over-permitted. For agentic systems, it expands quickly because one request can generate configuration, artefacts, and operational views that persist beyond the original session.

What's in the full announcement

Kong's full product release covers the operational detail this post intentionally leaves for the source:

• How the Code Mode MCP integration structures the exact tool chain behind create, update, delete, and execution flows
• How the approval workflow is implemented in Konnect before a write operation is allowed to proceed
• How decK and Terraform artefacts are generated, displayed, copied, and reused from agent output
• How org settings can disable write operations or MCP access for staged rollout and containment

👉 The full Kong release covers the MCP tool design, approval flow, and generated artefact handling in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.