Skip to main content

HITL Governance & Approval Modes

How k8s-autopilot keeps your infrastructure safe by asking before acting

k8s-autopilot follows a simple, fundamental operational rule: look before you touch. Before doing anything that could alter your infrastructure — deploying software, scaling workloads, modifying traffic routes, or deleting resources — it stops and asks for your permission first.

Think of it like a co-pilot in an aircraft. They can read flight instruments, check pressure gauges, and monitor engine telemetry all flight long without interrupting the captain. But before touching the primary flight controls — throttle, flaps, landing gear, or navigation autopilot — they always call out the action and wait for clear confirmation.

What Needs Approval and What Doesn't​

Not every operation requires human confirmation. k8s-autopilot divides all actions into two clear categories:

Runs Automatically (No Approval Needed)​

  • Listing pods, deployments, services, namespaces, or custom resources
  • Checking Helm release status, viewing installed values, or searching chart repositories
  • Querying Prometheus metrics via PromQL or exploring logs in Loki
  • Searching distributed traces in Tempo with TraceQL
  • Reading configuration files, inspecting code, and browsing local workspaces
  • Any operation that strictly reads or inspects state without changing anything

Pauses and Asks You First​

  • Installing, upgrading, rolling back, or uninstalling Helm charts
  • Creating, modifying, scaling, or deleting Kubernetes resources
  • Synchronizing ArgoCD applications or advancing progressive canary deployments
  • Modifying Traefik IngressRoutes, traffic split weights, or middleware
  • Executing shell commands that mutate system state
  • Creating Alertmanager silences or provisioning OpenTelemetry collectors
  • Pushing commits to GitHub or modifying Git repositories

Three Levels of Oversight​

You choose how much control the agent is granted. k8s-autopilot provides three approval modes that you can switch between at any time from the Settings UI:

ModeOperational BehaviorWhen to Use
🛡️ Manual (Default)Pauses and displays an interactive approval card before every action that could change your cluster. Nothing runs without your explicit say-so.Production clusters, shared environments, and any environment where mistakes are costly
🤖 AutoSmart multi-layer filter: safe read-only queries execute instantly; dangerous operations are gated; intermediate actions are evaluated by an AI safety classifier.Staging and daily development operations
⚡ YOLOEvery command and tool executes immediately without prompting. Requires explicit initial confirmation.Disposable test sandboxes and automated CI/CD pipelines

Manual Mode (Default)​

In Manual mode, every action that could change your infrastructure pauses and displays an interactive Approval Card in the chat UI. You see:

  • The exact operation proposed
  • The target resource, namespace, and parameters
  • A visual risk level badge (Low, Medium, High, or Critical)
  • Diagnostic justification explaining why the action is needed
  • Parameter diffs highlighting changes

You click Approve to proceed or Reject to cancel.

Rejection Handling

If you reject a plan, the agent does not stubbornly retry the same action. It asks what you would like to change. If you reject plans twice in succession, the agent steps back and asks you to rephrase your overarching objective.

Auto Mode​

Auto mode lets the agent handle routine operations on its own while still stopping for anything risky. It operates as a three-tier decision funnel:

                  ┌─────────────────────────────────────────┐
                  │          Incoming Operation             │
                  └────────────────────┬────────────────────┘
                                       │
                                       ▼
                  ┌─────────────────────────────────────────┐
                  │ 1. Instant Decisions (Known Patterns)   │
                  │    • Read-only ──► Auto-Approve         │
                  │    • Known Dangerous ──► Pause for User │
                  └────────────────────┬────────────────────┘
                                       │ (Intermediate / Unknown)
                                       ▼
                  ┌─────────────────────────────────────────┐
                  │ 2. AI Safety Classifier                 │
                  │    Evaluates blast radius & context     │
                  │    • Classified Safe ──► Auto-Approve   │
                  │    • Risky / Uncertain ──► Step 3       │
                  └────────────────────┬────────────────────┘
                                       │
                                       ▼
                  ┌─────────────────────────────────────────┐
                  │ 3. Human Fallback                       │
                  │    Presents Approval Card to User       │
                  └─────────────────────────────────────────┘
  1. Instant Decisions: Known read-only commands (kubectl get, kubectl describe, kubectl logs, helm list, helm status, git status, cat, ls, grep) and Tier 1 MCP tools are approved immediately without LLM overhead. Known destructive verbs (delete, destroy, drain, purge, uninstall) always pause for human review.
  2. AI Safety Classifier: For operations in the grey area (such as applying an updated manifest or bumping replica counts), the agent's LLM evaluates the target namespace, resource type, and blast radius.
  3. Human Fallback: If the classifier is uncertain, unavailable, or encounters an unrecognized command, it fails safe — never failing open — and routes the action directly to you for approval.
Security Boundary

Auto mode is a smart operational safety filter, not a substitute for Kubernetes Role-Based Access Control (RBAC). Always configure least-privilege service accounts for agent execution.

YOLO Mode​

Everything runs without pausing to ask. The first time you activate YOLO mode in a session, k8s-autopilot displays a modal explaining the risks and requires you to explicitly acknowledge them before proceeding.

Destructive Capability

YOLO mode allows the agent to execute mutating and potentially destructive operations autonomously. Only use it in disposable development environments where data loss is inconsequential.

Asking You Questions​

Beyond approval gates, the agent can also ask you questions during a task. This is different from approvals — it uses a dedicated ask_user tool when the agent proactively seeks information it cannot determine on its own:

  • "Which namespace should I deploy this to — staging or production?"
  • "I found three matching services. Which one did you mean?"
  • "Do you want me to reuse existing values or override with these new settings?"

Questions appear as interactive UI cards with clickable options or text inputs, preventing errors and parameter typos.

How Shell Commands Are Checked​

When an operator needs to execute a shell command, it passes through four rigorous validation stages:

  1. Pattern Check: Verifies if the command matches known-safe inspection commands or known-destructive patterns.
  2. Deep AST Analysis: For complex commands with pipes (|), boolean chains (&&), or subshells, the engine parses the complete Abstract Syntax Tree (AST) to catch dangerous commands hidden inside benign pipelines (e.g. echo "starting" && kubectl delete ns prod).
  3. Injection Detection: Commands containing variable expansion tricks, backtick execution, unexpected redirections, or process substitution are flagged for human approval.
  4. Allowlist Validation: If you configure pre-approved command prefixes (such as kubectl, helm), commands matching those prefixes can bypass manual prompts — provided they contain zero injection patterns.

How MCP Tools Are Classified​

Every tool from every connected MCP server is automatically profiled into one of four security tiers at registration time:

TierClassificationOperational BehaviorExample Tools
Tier 1 — Read-onlyStrictly idempotent inspectionRuns automatically in all modesget_pods, query_metrics, list_releases
Tier 2 — Low-impactReversible or transient mutationsAuto mode decides; Manual mode asksdry_run_install, add_label, annotate
Tier 3 — MutatingModifies live infrastructureAlways asks you (except in YOLO)install_chart, scale_deployment, apply_manifest
Tier 4 — DestructiveIrreversible deletion or evictionAlways asks with elevated warningsdelete_namespace, uninstall_release, drain_node

Headless Mode Safety​

When k8s-autopilot runs unattended without a web UI (e.g. via Slack integrations or CI/CD pipelines), the HeadlessMCPGuardMiddleware automatically blocks all Tier 3 and Tier 4 tool calls that lack an explicit readOnlyHint=true annotation. Unattended mutations are strictly prevented.

Operator Domain Safety Rules​

In addition to framework-level guardrails, each operator enforces its own specialized safety policies:

  • 🎡 Helm Operator: Asks before installing, upgrading, rolling back, or uninstalling any release. Always executes a dry-run diff first.
  • 📦 App Operator: Asks before syncing or deleting ArgoCD applications. Limits autonomous canary promotion to 50% traffic split — any higher percentage requires explicit human approval. Never creates TCP routes without confirmation.
  • ☸️ K8s Operator: Asks before creating, updating, or deleting any Kubernetes resource. Elevates risk alerts for production namespaces (prod, production, kube-system), always masks secret values, and requires confirmation for kubectl exec.
  • 📊 Observability Operator: Previews the blast radius of alert silences before creation (capped at 24 hours maximum). Warns before sending test alerts that trigger external notifications. Runs OpenTelemetry modifications in dry_run mode first.

The Double-Gate Pattern​

When an operator wants to execute an action, it must pass through two independent gates:

[ Operator Plan ] ──► Gate 1: Operator Asks You ──► You Approve
                             │
                             ▼
[ MCP Tool Call ] ──► Gate 2: Framework Middleware Verification ──► Cluster Execution

Even after you approve a plan, the underlying middleware independently verifies the actual MCP tool call against security tier policies before sending it to the subprocess. Neither layer can bypass the other.

Built-in Protections (Always Active)​

These protections run continuously in the background across all approval modes — including YOLO mode:

Invisible Unicode & Homoglyph Detection​

Before any command executes, k8s-autopilot scans for hidden Unicode characters: zero-width spaces that alter command interpretation, look-alike Cyrillic characters that mimic Latin letters (e.g. Cyrillic "а" vs. Latin "a"), and bidirectional text overrides (RTL tricks) that visually invert command syntax.

SSRF & Network Safety​

When fetching external URLs or web resources, the network validator blocks requests to internal RFC1918 subnets, loopback addresses, and cloud provider metadata endpoints (169.254.169.254). DNS resolutions are pinned before socket creation to prevent DNS-rebinding attacks.

Subagent Tool Isolation​

Operators can only execute tools belonging to their declared domain. The Helm Operator cannot delete pods via the Kubernetes MCP server. The Observability Operator cannot modify ArgoCD sync policies. No operator can escalate privileges or cross domain boundaries without an explicit Supervisor handoff.

Next Steps​