The Named Human Approval Gate: Human-in-the-Loop Governance in InfraOrcinus

By Chirag Panchal · Founder & Lead Architect · 2026-10-02 · 9 min read

Why InfraOrcinus deterministically halts before applying infrastructure changes. An exploration of the named approval protocol, separation of duties enforced on every run, attribution of each decision, and applying the exact plan that was approved.

Development Status & Architectural Evolution: InfraOrcinus is in active development. Architecture specifications, internal interfaces, and operational protocols described herein reflect our current engineering design and are continuously refined to make InfraOrcinus robust, resilient, and enterprise-grade.

The central promise of early Infrastructure as Code was full automation: commit to Git, trigger the pipeline, and let continuous delivery automatically update production.

However, in critical enterprise infrastructure, unsupervised continuous delivery creates catastrophic blast radius risks. A minor syntax error, an overlooked destroy action in a multi-thousand-line plan, or a hallucinated parameter from an AI agent can drop live customer databases, break peering connections, or expose private storage buckets in seconds.

In software, a broken build fails tests. In cloud infrastructure, an errant apply mutates physical resources.

This is why InfraOrcinus enforces the Named Human Approval Gate Protocol.

1. The Principle of Deterministic Halting

In InfraOrcinus, the delivery pipeline moves through discrete, observable phases:

Validate  →  Plan  →  Policy & Cost Gates  ‖  Approval Gate  →  Apply

Between planning and execution, there is a hard, deterministic halt (‖).

No autonomous agent - and no unsupervised GitOps trigger - is permitted to cross this boundary alone. While automated tools can synthesize code, compute cost deltas, and evaluate compliance policies, the decision to mutate production infrastructure requires an authenticated, accountable human actor.

2. Separation of Duties: What Is Enforced Today

A common compliance failure in modern engineering is self-approval: the same person starts a change and approves it. Under SOC 2 Type II, ISO 27001 and financial regulations, that violates basic separation of duties. InfraOrcinus enforces it in two places:

• Single runs: the person who started a run cannot approve its apply, whatever their role, administrators included. Approval requires the writer role, or the administrator role for environments that require one. Runs started by the system rather than a person, such as a scheduled trigger, have no creator to compare against.
• Change plans (multi-stack, waves): the person who drafted a plan cannot approve it, and the approver must hold the administrator role. Two different administrators are needed for every plan.

Stronger controls (dual sign-off for high blast radius, role names such as "EnvironmentAdmin") are on the roadmap. They are not shipped.

Small Teams and Emergencies

A two-person team has no second approver on hand, and an outage at 3 a.m. cannot wait. Keep the rule and make the exception visible:

• Small teams: you need at least two people who can approve. A single-person installation cannot approve its own runs, by design.
• Emergencies: a second person, typically an on-call administrator, approves the run. The record names who approved and when, and the run page shows the same detail as any other approval. The approve request does not yet take a rationale field, so record the reason in your ticket and link it from the run.

2b. The Approver Experience

A gate people dread gets bypassed in spirit. The goal is a review that is fast because it is informative:

• Discovery. Runs awaiting approval appear in the top-bar approval list, which refreshes every 10 seconds and shows a toast when a new run needs a decision. The API is GET /api/jobs/pending-approval, which returns a canApprove flag per run for the caller.
• Review context. The approver sees create, update and delete counts, the per-resource changes, policy results, the cost estimate, and a resource graph where each resource is coloured by what will happen to it. Sensitive values are masked on the server.
• Destructive changes ask twice. A destroy run, or any plan that destroys resources, asks for a second click to confirm.
• Approve or reject. POST /api/jobs/{id}/approve unblocks the apply. POST /api/jobs/{id}/reject ends the run without applying anything, with an optional reason of up to 500 characters. The run then shows who rejected it, when, and why.
• Visibility is scoped. An approver sees only runs for environments they can access. A run from a project they do not belong to never appears, and guessing its ID returns 404.
• Timing is visible. The run page records how long the plan waited for a human, so slow approvals are measurable.
• Not yet: approval requests are not pushed to chat or webhook channels. Notification channels today carry job, apply, drift and policy events only.

Policy and Cost Come Before the Human

• Mandatory policies that fail block the apply and the approve action everywhere in the product, including the bell. A blocked run can still be rejected.
• Advisory policies appear as warnings beside the plan.
• Cost is estimated and shown to the approver. A cost estimate does not block approval. Budget limits are not yet enforced at approval time.
• Environment-level rules can require an administrator. Non-admins see "Requires an admin to approve" instead of an approve button.

Delegation and Availability

Approval authority comes from roles, so a reviewer on leave does not stall delivery, provided more than one administrator exists. Keep at least two administrators for each production environment.

Routine Changes (design option, not shipped)

Low-risk, advisory-clean changes could be routed to a lighter review. This is a design option. Every change today goes through the same approval.

3. Plan-to-Apply Integrity: Where We Are

A subtle vulnerability in distributed CI/CD is the "plan-apply gap":

1. A plan is generated at 10:00.
2. A human reviews and approves it at 11:30.
3. Meanwhile the cloud changes, or the plan artifact is altered.
4. The apply executes something different from what was approved.

The control that closes this gap is to apply the exact plan that was approved. How close InfraOrcinus gets depends on the engine:

What is still missing is a fingerprint on the approval itself: a SHA-256 over the normalized plan, the commit SHA, the resolved variables, the engine and provider versions and the state version, checked again before apply. That is planned, not shipped. For Bicep and Pulumi especially, keep the approval window short, and reject and re-plan if variables or credentials change while a run waits.

4. The Audit Trail

When an approval or rejection is recorded, the run stores who acted and when: approvedBy and approvedAt, or rejectedBy, rejectedAt and the reason. The HTTP audit log records each approve, reject and state-changing request with the actor's name, the path, the status code, the source IP address and a timestamp.

Identity comes from the authenticated session, which is carried in an HttpOnly token. Accounts come from local login, LDAP, OAuth2, or SAML 2.0 single sign-on, with accounts provisioned by an administrator or SCIM. The identity on a record is the authenticated account, not free text.

What the audit trail does not yet guarantee:

• Not hash-chained. Records are not linked by SHA-256 to their predecessor, so truncation or edits are not detectable by the product itself.
• Not database-immutable. The application database account is not yet restricted from updating or deleting audit rows.
• Not signed per approval. Approvals are attributed to the session, not to a per-approval digital signature.

Make these part of your hardening plan, or export the audit log to an append-only store you control, until they ship.

What "Cryptographic" Means Here

Precision matters in a security article. Today the strongest claims are:

• Authenticated identity of the approver, from the session and SSO.
• Attribution of each approval and rejection to that identity, with time and source IP.

The checksum binding and the hash-chained ledger are on the roadmap. Teams that need approvals to be non-repudiable by signature, for example with hardware-backed keys, should add that as a control on top.

5. Mapping to Oversight and Compliance

The gate is the concrete mechanism behind the human-oversight argument made in the opening article of this series. This is an engineering mapping to support your own compliance work, not a certification or a legal interpretation.

Summary

In an era of increasingly autonomous systems and generative AI agents, governance is not about slowing teams down - it is about providing rock-solid guardrails. InfraOrcinus's Named Human Approval Gate ensures that automation moves at machine speed, but production changes remain firmly under human oversight.