Human Approval for SRE Agent Actions

We asked an AURA agent to delete one pod. It inspected the target, built the exact pods_delete call, and stopped. The tool name, the pod, the namespace, and the arguments were all on screen, waiting for a person.

We denied it. Nothing changed, and both original pods were still running.

Then we asked again and approved the same call. The pod was deleted, the deployment replaced it, and the agent confirmed the result with a read-only check.

Reads never paused. Only the call we had marked as needing approval did. This page shows how that boundary is defined, and how to route approvals to whoever should make them.

TL;DR

• What it is: Two example configs that put specific AI agent tool calls behind a human decision. Everything else runs uninterrupted.
• Two routes:
  • In-chat. The person talking to the agent approves or denies.
  • Webhook. The request goes to an approval service, an on-call engineer, or a policy engine.
• What gets gated: Only tools matching the glob patterns you list, such as *_delete, pods_exec, and helm_install.
• What happens on no answer: The call fails closed. Denials, timeouts, and transport failures don't execute the tool.
• What you need: kubectl access to a cluster, Node.js, and a model provider API key. The webhook route also needs an HTTP endpoint that answers allow or deny.
• Cost: AURA is free and open source (Apache 2.0). You pay only for your model usage.
• Source: hitl-conversational.toml and hitl-webhook.toml

What these examples do

Both examples configure a Kubernetes operations agent with full cluster tools, including tools that can delete, exec, update, and install. A [hitl] block decides which of those tools need a person.

1. Choose what's gated. require_approval lists glob patterns matched against tool names. A tool is gated if it matches any pattern.
2. Park the call. When the agent calls a gated tool, AURA holds the exact call, with its arguments, before it reaches the MCP server.
3. Route the decision.
   
   1. Conversational route. The prompt appears in the aura CLI session (default wait 60 seconds; this example uses 120).‍
   2. Webhook route. AURA POSTs the request to your approval service (default wait 300 seconds).‍
4. Release or refuse. If the call is approved, it runs exactly as reviewed. If it's denied, the agent is told and stops, or offers a read-only alternative.

The webhook example also shows two integration options:

• Static headers. Headers such as a tenant ID are sent on every approval request.
• Forwarded headers. headers_from_request passes the caller's Authorization header through, so your approval service can see who asked.

Who it's for

Jobs to be done

• On-call engineer: When the agent proposes a fix, I want to see the exact command before it runs, so I can catch a wrong namespace or pod name.
• Platform engineer: When we let an agent change infrastructure, I want approvals routed to where my team already works, so nobody has to watch a terminal.
• SRE lead: When AI gets write access, I want the riskiest operations gated by name, so routine reads stay fast and dangerous calls stay deliberate.
• Security reviewer: When an agent acts, I want the approval tied to a real person's credentials, so the downstream system enforces what that person is allowed to do.

Pain points it removes

• All-or-nothing access. The usual choice is a read-only agent that can't help, or a write-enabled agent nobody trusts. Gating by tool name sits in between.
• Approval fatigue. Reads and safe calls never pause. Only the patterns you list do.
• Vague confirmations. Reviewers see the real tool and arguments, not a summary of intent.
• Silent failures. If nobody answers, the call doesn't run.
• Disconnected approvals. Webhook routing and header forwarding fit approvals into chat-ops, paging, or policy services you already run.

What it replaces, and why it's better

The value it drives

• Safer adoption of AI that acts. Teams can let agents propose and run changes with a checkpoint on the riskiest calls.
• Faster remediation without a blind spot. The agent does the investigation and prepares the command. A person spends seconds reviewing instead of minutes typing.
• Accountability built in. With header forwarding, the approver's own credentials reach the downstream service.
• One policy across tools. Glob patterns apply the same rule to every MCP server the agent uses.

What to measure in a pilot: how many gated calls are approved vs denied, how long approvals take, and whether any denied call would have caused an incident.

Why AURA

• Production-tested. AURA started as Mezmo's internal harness for operating our own SaaS. Our engineering and SRE teams still use it in production, and it powers thousands of agent sessions each month in Mezmo's hosted platform.
• Gating enforced by the runtime. Approval lives in the harness, not in a prompt the model might ignore.
• Fails closed. Denial, timeout, and transport failures all stop the call.
• Runs inside your security boundary. Deploy in your own infrastructure, including air-gapped environments.
• Model-agnostic. OpenAI, Anthropic, Bedrock, Gemini, Ollama, or OpenRouter.
• Traceable end to end. Every request, model turn, and tool call can be exported as OpenTelemetry traces.

Start from where you are

• The approver is the person chatting with the agent? Use hitl-conversational.toml.
• The approver is someone else (paged on-call, a chat channel, a policy service)? Use hitl-webhook.toml.
• Not ready for any writes? Start read-only with the Kubernetes agent team example and add gating later.
• Using a client other than the AURA CLI? Conversational approvals stream an aura.approval_requested event, and any client can answer by POSTing to /v1/approvals/{decision_id}.

Look inside the config

The gate and the route are two short tables:

[hitl]
require_approval = [
  "*_delete",
  "pods_exec",
  "resources_create_or_update",
  "helm_install",
  "helm_uninstall",
]

[hitl.route]
mode = "webhook"
url = "{{ env.HITL_WEBHOOK_URL }}"
timeout_secs = 300
headers_from_request = { "authorization" = "authorization" }

The agent's instructions tell it not to ask for permission itself:

system_prompt = """
You are a Kubernetes operations assistant. You may inspect any resource
freely. Mutating operations (delete, exec, apply, helm) require human
approval. The platform will pause the call and ask; you do not need to
ask yourself. If an approval is denied, explain what you intended to do
and stop.
"""

Important: gating isn't automatic for tools that change state. A tool that can change state but doesn't match a require_approval pattern runs without a pause. Review your patterns against your MCP servers' tool lists.

Try it in four steps

1. Install AURA (Linux or macOS):

curl -fsSL https://raw.githubusercontent.com/mezmo/aura/main/scripts/install.sh | bash

2. Start the Kubernetes MCP server without --read-only, so the gated tools exist. Use a dev cluster.

npx -y kubernetes-mcp-server@latest --port 8081

3. Set your keys. For the webhook route, also set your approval endpoint and a signing secret:

export OPENAI_API_KEY="sk-..."
export HITL_WEBHOOK_URL="https://approvals.example.com/aura"
export AURA_HITL_WEBHOOK_SECRET="$(openssl rand -hex 32)"

4. Download the example, start the server, and connect the CLI. The conversational route shows the approve or deny prompt in the CLI session:

curl -fsSLO https://raw.githubusercontent.com/mezmo/aura/main/examples/complete/hitl-conversational.toml
AURA_CUSTOM_EVENTS=true aura webserver --config hitl-conversational.toml

# in a second terminal
aura --api-url http://localhost:8080

For the webhook route, start the server with hitl-webhook.toml instead. More detail: AURA human-in-the-loop docs.

Then ask it to list pods in a test namespace, and to delete one. Deny the first request, then approve the second.

FAQ

Does every action that changes state require approval?

Only the tools that match your require_approval patterns. This is deliberate: you decide where the checkpoints go. Tools you leave off the list run without pausing.

What happens if nobody responds?

The call fails closed after the timeout and doesn't run. The defaults are 60 seconds for conversational and 300 for webhook.

Can the model skip the approval step?

No. Gating happens in the AURA runtime between the model and the MCP server. The model's instructions don't control it.

Can different people approve different actions?

Webhook routing and header forwarding give your approval service the context to decide. These examples show one gated route at a time. Role-based rules are yours to implement in the approval service.

Are webhook requests signed?

Yes, when you set AURA_HITL_WEBHOOK_SECRET. AURA signs outbound requests with HMAC-SHA256, and the secret must be at least 32 bytes.

Next steps

• Engineers: Clone the examples and run the deny-then-approve test on a dev cluster.
• Leads and security reviewers: Read the security and data-handling model, then draft the list of tools your team would gate.
• Everyone: Join the AURA Slack community.