Approval workflows for AI coding agents on Kubernetes

When an AI coding agent pushes a manifest directly to a Kubernetes cluster without human oversight, the lack of approval workflows means a single typo can cascade into a production outage that costs minutes of downtime and weeks of remediation. The financial impact of a failed rollout is magnified when the change touches dozens of services, triggers cascading restarts, or violates compliance windows. Organizations that let autonomous agents run with broad cluster credentials often discover that they have no way to pause, review, or roll back a change before it reaches the control plane.

In many teams the current workflow looks like this: a service account with cluster‑admin scope is stored in a CI secret, the AI agent reads the secret, generates a command that applies the manifest, and sends it straight to the API server. The agent never asks for a human sign‑off, the request bypasses any gatekeeper, and the audit trail is limited to a single line in a CI log. The setup provides identity (the service account) and authentication (the kubeconfig), but it does not give anyone the ability to intervene, mask sensitive fields, or record the full interaction for later review.

Why approval workflows matter for AI‑driven Kubernetes automation

AI agents excel at generating code quickly, but they lack contextual awareness of operational policies, change windows, or risk tolerances. An approval workflow forces the agent to pause before executing any command that could affect cluster state. The workflow should capture who approved, what command was approved, and under what conditions. Without a central point that can enforce this pause, the approval step becomes a manual checklist that can be ignored or bypassed.

The precondition we need is a gateway that sits between the AI agent and the Kubernetes API. The gateway must be the only place where the request can be inspected, approved, or blocked. The identity system (OIDC, service accounts, RBAC) decides who the request originates from, but it cannot enforce policy on its own. The data path – the network hop that carries the request – is the only place we can reliably apply approval logic, mask sensitive response fields, and record the full session for replay.

How the gateway sits in the data path

Deploy a layer‑7 gateway that runs a network‑resident agent close to the Kubernetes control plane. The agent holds the cluster credential, so the AI coding agent never sees the secret. When the AI attempts to connect, it authenticates via OIDC or a service account token. The gateway validates the token, extracts group membership, and then forwards the request to the Kubernetes API only after the required approval workflow has completed.

Because the gateway is the sole conduit, it can enforce three key outcomes:

• Approval enforcement: hoop.dev presents an approval request to a designated reviewer before allowing any mutating API call. The reviewer can grant or deny the operation, and the decision is logged.
• Command‑level audit: hoop.dev records every request and response, creating a replayable session that includes the exact manifest the AI generated.
• Inline masking: Sensitive fields such as secrets or tokens that appear in API responses are masked in real time, preventing the AI from harvesting credentials.

All of these actions happen inside the data path, meaning they cannot be circumvented by reconfiguring the AI agent or by changing the service account token. The gateway’s policy engine is the only place where approval logic lives, satisfying the requirement that enforcement outcomes exist only because the gateway is present.

Setting up the gateway for Kubernetes approval workflows

Start with the getting started guide to spin up the gateway using Docker Compose or a Kubernetes deployment. Register your Kubernetes cluster as a connection, providing the API endpoint and the bearer token that the gateway will use. Configure OIDC authentication so that the AI agent can obtain a short‑lived identity token. In the policy definition, specify that any request that creates or updates deployments, services, or other mutable resources must trigger an approval workflow. For details on writing policies, see the learn section. The policy engine will then pause the request, route it to an approver, and only forward it once a positive decision is recorded.

Because the gateway holds the credential, the AI agent never sees the underlying token. This satisfies the principle of least privilege at runtime while still allowing the agent to act on behalf of a human when approval is granted. The same pattern can be extended to read‑only operations, where you might only want to mask secret fields without requiring approval.

Operational benefits

With the gateway in place, teams gain:

• Deterministic change control – every change to the cluster passes through a documented approval step.
• Full forensic record – replayable sessions let you trace exactly what the AI agent attempted and what was actually applied.
• Reduced blast radius – risky commands can be blocked automatically if they do not match an approved pattern.
• Credential protection – inline masking prevents the AI from learning cluster secrets.

These outcomes are only possible because hoop.dev sits in the data path and actively enforces policy. Removing the gateway would instantly eliminate approvals, audit, and masking, leaving the original insecure direct connection.

FAQ

Do I need to change my existing CI pipelines?

No. The pipeline simply points its Kubernetes client at the gateway endpoint instead of the raw API server. The gateway handles authentication and forwards approved requests, so the rest of the pipeline remains unchanged.

Can I use multiple approvers for a single change?

Yes. The policy engine supports multi‑step approvals, where each step can require a different reviewer or group. The request proceeds only after all required approvals are recorded.

What happens if an approval is denied?

hoop.dev immediately aborts the request and returns a clear denial response to the AI agent. The denial, along with the request details, is stored in the audit log for later analysis.

Ready to try it out? Visit the GitHub repository to explore the source code, contribute improvements, and see the full set of configuration options.