Why I Am Building InfraOrcinus: The Future of Governed Infrastructure in the Era of AI

By Chirag Panchal · Founder & Lead Architect · 2026-10-01 · 12 min read

Large-scale infrastructure delivery remains one of modern computing's most brittle frontiers. Here is why passive automation fails, why unconstrained AI agents pose severe risks, and how InfraOrcinus bridges autonomous speed with sovereign, human-in-the-loop governance.

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.

"In software development, a bad pull request breaks an application build. In cloud infrastructure, an ungoverned apply command can destroy a multi-region database, drop live traffic, or leak sensitive keys in seconds. Software code has versions; real infrastructure has state."

Every generation of computing believes it has solved infrastructure delivery. First came shell scripts and runbooks. Then came declarative configuration management, followed by Infrastructure as Code (IaC) with tools like Terraform, OpenTofu, and Pulumi. Most recently, GitOps promised that git commits alone would steer the fleet.

Yet, after speaking with dozens of engineering leaders, platform architects, and site reliability engineers across Europe and globally, an uncomfortable truth emerges: large-scale infrastructure deployment remains fraught with friction, anxiety, and operational fragmentation.

Today, with the rapid emergence of generative AI and autonomous coding agents, the stakes have escalated exponentially.

Here is the diagnosis of why modern infrastructure deployment is broken, why we cannot simply unleash autonomous agents without boundaries, and why I am building InfraOrcinus.

1. The Anatomy of Modern Infrastructure Friction

If declarative IaC tools are so capable, why do engineering teams in enterprises and scaling companies still dread Friday deployments?

The challenge is rarely the syntax of HCL or TypeScript. The failure occurs in the organizational boundary between intent, policy, cost, and execution.

A. The "Plan Blindness" Problem

In an active production environment, a terraform plan output for a shared VPC, Kubernetes cluster, or database tier easily reaches thousands of lines of terminal output.

Platform engineers are expected to review these diffs in pull requests under intense delivery pressure. Over time, human reviewers succumb to plan blindness - they scan the summary line (Plan: 14 to add, 3 to change, 1 to destroy), miss that the single destruction is a critical subnet recreation or an encrypted storage volume replacement, and approve it. The resulting outage is catastrophic, yet entirely preventable.

B. The Fragmented Pipeline Circus

To protect themselves, organizations duct-tape disjointed tooling into their CI pipelines:

• One tool for static linting
• Another separate SaaS for cost estimation
• A third proprietary policy engine for compliance
• Scattered webhook notifications in messaging channels
• An isolated secrets vault

Each tool operates in a silo. None of them share a unified semantic model of the blast radius, nor do they keep a clear, reviewable record of who made the decision and why.

C. The State Locking & Concurrency Nightmare

When multiple autonomous pipelines or engineers attempt concurrent operations across shared backends, state locks collide, pipeline runs timeout, and dirty partial states poison the workspace. Recovering from a tainted state often requires manual state file surgery - an unnerving task for even veteran engineers.

2. The Mirage of "Unconstrained" AI Agents

With the advent of Large Language Models and autonomous coding agents, a naive solution quickly gained popularity: "Let an AI agent write the Terraform, trigger the pipeline, and deploy it autonomously."

This approach fundamentally misunderstands the physics of cloud infrastructure.

In pure application code, an autonomous agent making a mistake is tolerable: tests fail, the pull request is rejected, or the bad commit is reverted. Software code is cheap to undo.

Infrastructure is not code. Infrastructure is physical reality represented as code.

• A database volume destroyed via API cannot be magically "reverted" with git revert.
• An improperly open security group or public S3 bucket exposes sensitive customer data immediately.
• An errantly provisioned fleet of GPU instances or provisioned IOPS racks up hundreds of thousands of euros before the billing cycle alerts anyone.

Furthermore, within the European Union and regulated global markets, deploying unconstrained autonomous agents directly into critical infrastructure runs afoul of regulatory standards. Under the EU AI Act, high-impact automated systems require human oversight (Article 14), transparent explainability, risk management, and rigorous auditability. Relying on an opaque external AI service to execute cloud changes without verifiable boundaries violates both legal obligations and basic engineering prudence.

3. What We Are Building: The Governed Delivery Plane

InfraOrcinus is not another static IaC syntax. It is an AI-governed infrastructure delivery plane that unifies the tools organizations already rely on - Terraform, OpenTofu, and Pulumi - under a closed-loop, verifiable lifecycle.

We solve the fundamental friction points through four architectural pillars:

I. The Named Human-in-the-Loop Gate

No AI agent - and no unreviewed pipeline - is ever permitted to execute an infrastructure modification autonomously.

An agent can synthesize changes, diagnose drift, and simulate the outcome. However, execution requires an authenticated, named human approver. The run records who approved or rejected it, when, and why, and the audit trail records the request with its source address. For Terraform, OpenTofu and CloudFormation, the apply runs exactly the plan that was approved. Binding each approval to a plan fingerprint is on our roadmap and is not shipped yet.

II. Native Multi-Engine Agnosticism

We refuse to lock teams into proprietary DSLs or walled gardens. InfraOrcinus supports:

• Terraform (managed or self-hosted state backends)
• OpenTofu (drop-in open-source engine)
• Pulumi (modern programming languages)
• Azure Bicep and AWS CloudFormation (native cloud provider formats; see Azure Bicep and AWS CloudFormation in InfraOrcinus)

Because every engine is normalized into one canonical plan model (see Unifying Terraform, OpenTofu, and Pulumi), policy, cost, and approval rules are written once and apply to all of them. Your existing modules and blueprints remain your assets. InfraOrcinus provides the delivery control plane without forcing you to rewrite your codebase.

III. Comprehensive Policy & Blast-Radius Pre-flight

Before a human ever sees a plan, InfraOrcinus runs multi-dimensional policy checks:

• Security Guardrails: Encryption at rest, VPC boundaries, IAM least-privilege.
• Cost Impact: Explicit delta reporting ("This change will increase monthly spend by €340.00").
• Destructive Mutation Warnings: Highlighted detection of stateful resource recreations.

IV. Sovereign & Self-Hosted Intelligence (BYOM)

Enterprises cannot - and should not - send their internal infrastructure topologies, credentials, and network maps to third-party public AI APIs.

InfraOrcinus is self-hosted. It can connect to local models running on your own GPU or CPU clusters, or on private endpoints. When you use a local model, your operational data stays inside your perimeter, which supports GDPR requirements, data sovereignty mandates, and enterprise IP confidentiality. Hosted model providers are optional and are your decision.

4. Why We Are Focusing on "Maturing the Agent"

One of the questions I am asked most frequently is: “If you insist on human approvals, why invest so heavily in an AI agent at all?”

The answer lies in cognitive augmentation and blast-radius minimization.

The human brain is exceptional at strategic decision-making, understanding business context, and weighing systemic risk. The human brain is terrible at reading 6,000 lines of HCL JSON diffs to notice that a route table association was inadvertently deleted.

What "Maturing the Agent" Really Means

For us, maturing the agent does not mean giving it more permissions or letting it run wild. Maturing the agent means making it more disciplined, predictable, and context-aware:

1. Semantic Explanation over Raw Diffs: Instead of handing an engineer a raw plan, the matured agent translates the plan into plain, actionable engineering realities:

   "Warning: Modifying line 42 changes db_subnet_group_name. AWS does not allow in-place modification for this parameter; this plan will destroy the primary database instance and recreate a new empty one, causing an estimated 20-minute outage."

2. Policy Boundary Adherence: The agent understands organizational guardrails as immutable laws, not polite suggestions. If a proposed change violates a company policy (such as opening port 22 to 0.0.0.0/0), the policy engine flags it as soon as the plan is calculated, before any human is asked to approve.

3. Demarcation of Agency: We have established a formal boundary of what the agent may and may never do:

   • The Agent May: Parse logs, detect drift, explain diffs, draft blueprints, compute cost deltas, and suggest remediation steps.
   • The Agent May Never: Hold production cloud credentials, self-approve plan gates, bypass policy checks, or apply mutations without human sign-off.

By maturing the agent, we eliminate the tedious toil that causes engineer burnout, while elevating the human approver to high-leverage architectural supervision.

How the Agent Handles Credentials

The boundary above is enforced structurally, not by prompt. The AI assistant runs in the control plane and has no path to cloud credentials:

• Credentials live in the credential store, encrypted at rest (AES-256-GCM or HashiCorp Vault transit) and never returned by the API after they are saved.
• Only the runner receives them, injected into a single-use container for one job. For AWS, a Vault secrets-engine credential lets the platform broker short-lived keys at run time instead of storing long-lived ones.
• Agent output is a draft. A generated blueprint is checked against policy and terraform validate in a credential-free sandbox, and a person must still save it. Anything it provisions then goes through plan, policy, cost, and approval like any other change.
• Registry documentation is untrusted data. Retrieved text is sanitized, size-capped, and wrapped so a model treats it as data, never as instructions.

The deep dives on runner isolation and the approval gate explain each of these controls.

Drift: The Problem After the Apply

Governance does not end at apply. Real infrastructure changes underneath you: console edits, emergency fixes, and autoscaling side effects all create drift between declared state and reality. A governed delivery plane must detect drift and route remediation through the same plan, policy, and approval path rather than patching around it. Drift detection and reconciliation get their own article in this series.

Mapping the Design to EU AI Act Article 14

Article 14 asks high-risk systems to support effective human oversight. This is how the design maps to that goal. It is an engineering mapping, not legal advice.

5. Where InfraOrcinus Fits

Teams usually assemble delivery from one of three approaches, and each leaves a different gap:

InfraOrcinus's position is the combination: self-hosted, multi-engine, with a hard human gate and a local-AI option. If your pipelines are already healthy and you have no sovereignty or audit pressure, you may not need it.

6. What InfraOrcinus Does Not Claim

Trust requires honest limits:

• It does not remove the need for judgment. A human who approves without reading is still a failure mode; the system exists to make the review informative and accountable, not automatic.
• It cannot undo physical reality. A destroyed database is destroyed. The controls reduce the odds and record the decision; backups and recovery plans remain your responsibility.
• A compromised approver or a compromised control plane is out of scope for the approval protocol alone. Defense relies on SSO, least-privilege roles, the audit trail, and network isolation around the platform.
• It is in active development. Interfaces and behavior evolve; the status notice at the top of each article applies.

7. The Road Ahead

Building infrastructure tooling is not for the faint of heart. It demands respect for uptime, reverence for security, and a relentless focus on stability.

InfraOrcinus is being built from the ground up on modern engineering standards:

• Clear separation of control plane and runner execution.
• Sovereign data boundaries.
• Transparent, reproducible workflows.
• Absolute respect for the engineer's autonomy.

Large-scale infrastructure delivery does not have to be an exercise in anxiety. By combining the speed of matured AI analysis with the certainty of governed policy and named human approval, we can finally give platform teams the velocity they need and the peace of mind they deserve.

We are just getting started. If you share this vision - or if you have fought these battles in your own production environments - I invite you to join the discussion below.

Summary

Infrastructure friction is a governance problem as much as a syntax problem, and unconstrained AI agents move faster than production change can safely tolerate. InfraOrcinus is being built as a governed delivery plane for Terraform, OpenTofu and Pulumi: AI assists with analysis and drafting, while a named human approves every change that reaches production. The project makes no claim to replace the underlying engines, remove human judgement, or be finished, and it will be judged on the evidence it produces.