An AI agent decides the fastest fix for a failing rollout is to delete the namespace and let the controller rebuild it. Technically defensible. Operationally a disaster if the agent is wrong about what is in that namespace. The question is not whether the agent can reason; it is whether a destructive action on production should ever execute without a human seeing it first. Approval workflows answer that: the risky command pauses at the boundary and waits for a person.
Approval workflows for AI agents on EKS put a human decision in front of the operations that deserve one, without slowing the routine ones to a crawl.
Not every command, just the ones that matter
Gating everything an agent does would make it useless, so the goal is selective. Read operations and routine restarts flow through. Destructive or high-blast-radius operations, deleting resources, scaling to zero, exec into a sensitive pod, stop and wait for approval. The control has to recognize the difference and pause only where it counts. Get this wrong in the broad direction and you train your approvers to rubber-stamp; get it wrong in the narrow direction and the dangerous commands slip past.
Where the approval workflows gate sits
hoop.dev is an open-source Layer 7 access gateway. Its kubernetes-eks connector proxies kubectl and exec to the cluster through a network-resident agent that assumes a configured IAM role, the EKS_ROLE_ARN, mapped to Kubernetes RBAC. Because every command crosses the gateway before it reaches the cluster, the gateway is the right place to hold a risky one for approval. The agent cannot route around it, because the gateway is the only path the agent has to EKS.
Building the workflow
- Configure the EKS connection with cluster URL, region, cluster name, and the scoped IAM role ARN.
- Define which operations require approval, for example any
deleteorexecin production namespaces. - Set the approver group and how many approvals a request needs.
- Point the agent at the gateway. When it issues a gated command, the gateway pauses and notifies approvers.
- Verify by having the agent attempt
kubectl delete namespace testand confirming it blocks pending approval, then runs only after a human approves.
request: agent-oncall wants
kubectl delete namespace payments-staging
status: PENDING APPROVAL -> approver: sre-oncall
on approve: command dispatched and recorded
on deny: command never reaches the clusterThe deny path is as important as the approve path. When a human declines, the command simply never reaches EKS. There is no half-executed state to clean up, because the gateway held the request before dispatching it to the cluster, not after.
