A reviewer points at a line in your change log and asks who approved an agent deleting a production namespace last Thursday, where that approval is recorded, and what scope it covered. If the answer is "the agent is allowed to do that, so nobody approved anything," the finding is already written. Approval workflows are what turn a high-risk agent action on Kubernetes into a deliberate, recorded decision you can show a reviewer without flinching.
Rather than start from buttons and queues, build this backward from the review. Decide what an auditor needs to see, then construct the approval workflows that produce it.
The questions a review actually asks
An access review of an agent operating a cluster comes down to a short list:
- Which agent identity took the action, and was it distinct or a shared service account?
- Was the action one that required approval, and who or what decided that?
- Who or what approved it, and is that approval recorded next to the action?
- What exact scope did the approval cover, and did the action stay inside it?
- What happened during the session, captured outside the thing being reviewed?
An agent running on standing cluster-admin answers almost none of these. "It was permitted" is not an approval, and "check the chat history" is not a record.
How approval workflows answer them
Approval workflows turn each question into a recorded fact. A risky action, deleting a namespace, exec-ing into a production pod, reading a secret, routes to a human or a policy decision before the agent proceeds. The request carries the agent identity, the intended command, and the scope. The decision is recorded against the action, not in a side channel. Low-risk reads can pass automatically, so the agent stays fast where speed is safe and slows down only where the risk earns it.
This only holds if the approval is evaluated and recorded by something the agent does not control. If the agent decides for itself whether an action needs approval, the workflow is theater. The decision point has to sit outside the agent process. That is the model hoop.dev is built to. The agent reaches the Kubernetes API through hoop.dev, a Layer 7 access gateway and identity-aware proxy in front of the cluster's access path. A command that matches an approval policy is held at the gateway until the decision is made, access is brokered per task once approved, and each session is recorded outside the agent. The learn pages on approvals and per-task access describe the model, and the getting-started docs for fronting a Kubernetes cluster cover the setup.
A single approval, traced the way a reviewer reads it
An agent requested an exec into a production pod at 09:14 to pull a diagnostic. The command matched an approval policy, so the gateway held it. An on-call engineer approved a scope covering that one pod for fifteen minutes. The session recording shows the shell opened, the file read, and the session closed. The approval, the identity, the scope, and the recording sit together. The reviewer reads one record and every question above is answered, none of it relying on the agent's own account of events.
What changes for the team being reviewed
The quiet benefit is that the review stops being an event you brace for. When every high-risk agent action carries a recorded approval and a scope at the moment it happens, there is no scramble to reconstruct who allowed what. The evidence accumulated as the work ran. A review becomes a query against records that were correct the day they were written, instead of an export of six months of cluster logs you hope tell a coherent story.
Pitfalls that still produce findings
- Approvals in a side channel. An approval that lives in a chat message and not next to the action cannot be shown to a reviewer. Record the decision where the action is recorded.
- Approving everything. Route every action to a human and approvers stop reading. Gate the risky verbs and let safe reads pass, so an approval still means something.
- Shared agent identity. If many agents share a service account, "who acted" is unanswerable no matter how clean the approval workflow is.
FAQ
Do approval workflows slow every agent action down?
Only the ones you choose to gate. Scope approvals to high-risk verbs like deletes and production exec, and let low-risk reads pass automatically, so the agent stays fast where it is safe.
Can the approval be a policy instead of a person?
Yes. A policy decision is a valid approver as long as it is evaluated outside the agent and recorded against the action. Reserve human approval for the scopes that genuinely warrant a person in the loop.
hoop.dev is open source. To put approval workflows in front of your Kubernetes cluster, start from the repository on GitHub.
