Infrastructure as Code in 2026: Two Forks at 1.16 and 1.13, a $6.4B Owner, 912 Public State Files, and One Agent That Ran terraform destroy

Most of what I operate was declared in HCL before it existed, and the state files describing PandaStack's fleet are among the few artefacts I treat as more sensitive than the secrets they used to contain (PandaStack is my company, a Firecracker microVM cloud for AI agents, so read the agent sections with that in mind). Three years after HashiCorp relicensed Terraform, I wanted to know what actually changed for someone picking an engine, a runner and a policy layer this quarter, and whether the agents now writing and applying that HCL have earned any trust. This post pins down versions, licences and prices as of October 2026, what each fork shipped first, what the AI tooling can now execute, and the two failure classes, leaked state and destructive plans, behind the real incidents.

The licence settled, the fork did not go away

IBM closed its purchase of HashiCorp on 27 February 2025 at a $6.4 billion enterprise value, per TechCrunch; Terraform 1.11.0 shipped the same day. The licence in the repository is still the Business Source License 1.1 from August 2023, except that the Licensor line now reads International Business Machines Corporation. The terms did not change with the owner; who you argue with about the "competitive offering" clause did.

OpenTofu, the fork the Linux Foundation took in September 2023, has been a CNCF Sandbox project since 23 April 2025, under MPL-2.0, having survived HashiCorp's April 2024 cease-and-desist over the removed block. Adoption figures are vendor telemetry, so I will cite the one that states its denominator: Scalr reports that OpenTofu ran about 63 percent of runs and 72 percent of newly created workspaces on its platform by mid-2026, the new-workspace share having climbed from roughly 56 to 76 percent in the first half of the year. That is one TACO vendor's customers, who skew towards people who already left HCP Terraform. I found no neutral, dated market-share figure for Terraform versus OpenTofu and am not going to invent one.

Two release trains, and who shipped what first

The fork has genuinely diverged, in both directions. Terraform 1.10 (27 November 2024) introduced ephemeral resources and values that never reach plan or state; 1.11 (27 February 2025) added write-only attributes and made S3-native locking GA, deprecating the DynamoDB table; 1.12 (14 May 2025) added an OCI Object Storage backend; 1.13 (20 August 2025) the terraform stacks CLI; 1.14 (19 November 2025) was the big one, with list resources in .tfquery.hcl files, a terraform query command that can generate import configuration, and a top-level action block for provider-defined operations outside CRUD. 1.15 (29 April 2026) allowed variables in module source and version and added deprecated on variables and outputs. 1.16 (26 August 2026) gave providers planned private data, a store block in terraform_data for ephemeral values, import blocks inside modules and lifecycle { destroy = false }. The current patch is 1.16.5 from 2 October 2026.

OpenTofu's train: 1.9 (9 January 2025) brought for_each on provider blocks; 1.10 (23 June 2025) OCI registries for providers and modules, S3-native locking, deprecation and external key providers for state encryption; 1.11 (9 December 2025) ephemeral values and write-only attributes plus an enabled meta-argument that retires the count = var.x ? 1 : 0 idiom; 1.12 (14 May 2026) dynamic prevent_destroy and destroy = false; 1.13 (30 September 2026) convert, an assume... family of functions, and experimental linting and symbol libraries. The current patch is 1.13.1 from 1 October 2026.

InfoQ's reading of 1.15 is right that Terraform was catching up on dynamic module sources (OpenTofu 1.8, August 2024) and deprecation (OpenTofu 1.10). Equally, OpenTofu took thirteen months to match ephemeral values and has nothing like the action block or terraform query. The one feature with no counterpart is OpenTofu's client-side state and plan encryption, shipped in 1.7 in April 2024; the Terraform 1.16 changelog has no equivalent.

State is a credential store whether you like it or not

Two pieces of research this year put numbers on what every operator knows. In May a researcher at Vechron generated about 4,200 S3 bucket-name permutations, scanned for 72 hours from a $20-a-month VPS, and found 912 readable .tfstate files, of which 41 held live AWS access keys, 12 Azure service-principal secrets and 3 GCP service-account keys. In August, Dark Moon documented a single state file on an unauthenticated HTTP server that yielded 12 distinct secrets, from RDS credentials and IAM keys to an RSA private key. Neither is a breach disclosure; both confirm the threat model I run with, which is that anyone who reads state owns the account.

The fix has two halves and the engines now cover both. The first is to stop putting secrets in state, which is what ephemeral values and write-only arguments do. This is real HCL for Terraform 1.11 and later and OpenTofu 1.11 and later, from HashiCorp's write-only documentation:

# Terraform >= 1.11.0 or OpenTofu >= 1.11.0, with an aws provider that exposes *_wo arguments.
# The password is generated in memory, written once to RDS, and never lands in plan or state.
terraform {
  required_version = ">= 1.11.0"
}

ephemeral "random_password" "db_password" {
  length           = 16
  override_special = "!#$%&*()-_=+[]{}<>:?"
}

resource "aws_db_instance" "example" {
  instance_class      = "db.t3.micro"
  allocated_storage   = "5"
  engine              = "postgres"
  username            = "example"
  skip_final_snapshot = true

  # *_wo arguments are write-only: the provider receives them, state stores nothing.
  password_wo         = ephemeral.random_password.db_password.result
  # Bump the version to force a re-send; Terraform cannot diff a value it does not keep.
  password_wo_version = 1
}

The second half, for everything that still lands in state (IDs, endpoints, network topology, and the attributes providers have not made write-only yet), is to encrypt it before it reaches the backend. Only OpenTofu does this, per its encryption documentation:

# OpenTofu >= 1.7.0 for state encryption; external key providers since 1.10.
terraform {
  encryption {
    key_provider "aws_kms" "state_key" {
      kms_key_id = "alias/tofu-state"   # any AWS KMS key identifier
      region     = "eu-west-1"
      key_spec   = "AES_256"
    }
    method "aes_gcm" "kms" {
      keys = key_provider.aws_kms.state_key   # aes_gcm needs 16, 24 or 32-byte keys
    }
    state {
      method   = method.aes_gcm.kms
      enforced = true   # refuse to write unencrypted state
    }
    plan {
      method   = method.aes_gcm.kms
      enforced = true   # plan files carry the same secrets as state
    }
  }
}
# Never rename key providers or methods once data is encrypted; add a fallback block instead.

With encryption on, those 912 exposures leak nothing; with it off they still leak topology even after every password is write-only. That asymmetry is the strongest technical argument for OpenTofu I know.

What the runners cost now

HCP Terraform charges per resource under management: Essentials from $0.10, Standard $0.47 and Premium $0.99 per managed resource per month, on peak hourly count. The free plan caps at 500 managed resources, one policy set of up to five policies and one concurrent run. Scalr reports that HashiCorp emailed customers on 15 December 2025 that the legacy free plan would end on 31 March 2026; the HashiCorp support article it cites redirected me to IBM's support portal, so treat those dates as secondary. Terraform Stacks, the multi-deployment layer built on .tfcomponent.hcl and .tfdeploy.hcl files, is generally available on current plans only; practitioners date GA to late 2025 and I found no dated announcement post.

Per-resource pricing is why the open-source runners exist. Atlantis (Apache-2.0, v0.48.0 on 22 September 2026) still does one thing, plan on pull request and apply on comment, and from v0.49 will stop bundling Terraform and OpenTofu binaries. Digger (MIT) renamed its project OpenTaco on 7 November 2025 and runs inside your existing CI; Terrateam is MPL-2.0 with a hosted tier. Commercially, Spacelift's free plan is 2 users and one public worker and Starter+ is $20,000 a year; env0's free tier is 250 runs a month, with paid tiers quoted per successful apply. My position is boring: engine from CI I control, state in an object store I control, and the runner is the least interesting layer. Paying per resource for a scheduler is the price of not operating one, and for a solo operator that trade rarely pays.

The CDK that did not make it, and the control planes that did

HashiCorp archived CDK for Terraform on 10 December 2025 with a README saying it "did not find product-market fit at scale", pointing users to AWS CDK or to cdktf synth --hcl and plain Terraform. A community fork, CDK Terrain, sits in Assess on the April 2026 Thoughtworks Radar, which warns that a fork of a tool that never got traction is a bet on both. For infrastructure in a general-purpose language the survivor is Pulumi: Apache-2.0, v3.267.0 on 1 October 2026, about 25,800 GitHub stars and, per its 2025 recap, 7,500 resource types. Pulumi's year was Neo, an infrastructure agent launched as a free preview on 16 September 2025 per SiliconANGLE and extended on 19 May 2026 to the CLI, GitHub pull requests and Slack. The "10x more infrastructure" and "90 percent fewer policy violations" attached to Neo are vendor-relayed beta-customer claims, not measurements anyone outside can check.

The Kubernetes-native alternative had a better year. Crossplane graduated from the CNCF on 6 November 2025 with over 3,000 contributors from more than 450 organisations; v2.0 on 14 August 2025 made applications first-class alongside infrastructure, and the project kept a quarterly cadence through v2.4 on 20 August 2026. It is the model I find most compatible with agents: a control plane reconciles declared intent continuously, so an agent that submits a bad object gets a rejected API call rather than a half-applied plan. And one casualty: System Initiative, the "digital twin" model Adam Jacob open-sourced under Apache-2.0 in 2023 and that InfoWorld reviewed in July 2025 as AWS-only with no free distribution, has had an archived repository since 6 February 2026 whose README says it is no longer maintained; the company domain did not resolve when I checked this week. Replacing code with a reactive model was the most interesting idea in this space, and it did not survive the market.

Tool	Licence	Latest version	Date	Source
Terraform	BUSL-1.1 (licensor IBM)	1.16.5	2 Oct 2026	releases
OpenTofu	MPL-2.0, CNCF Sandbox	1.13.1	1 Oct 2026	releases
Pulumi	Apache-2.0	3.267.0	1 Oct 2026	releases
Crossplane	Apache-2.0, CNCF Graduated	2.4.2	22 Sep 2026	releases
CDK for Terraform	MPL-2.0, archived	final	10 Dec 2025	repo
System Initiative	Apache-2.0, archived	final	6 Feb 2026	repo
Atlantis	Apache-2.0	0.48.0	22 Sep 2026	releases
Terraform MCP server	MPL-2.0	1.3.0	26 Aug 2026	changelog
OPA	Apache-2.0, CNCF Graduated	1.21.1	29 Sep 2026	repo
Checkov	Apache-2.0	3.3.21	30 Sep 2026	releases
Trivy	Apache-2.0	0.75.0	1 Oct 2026	releases
Terrascan	Apache-2.0, archived	final	20 Nov 2025	repo

Agents at the keyboard

The AI story in IaC has two layers, and conflating them is how people get hurt. The first is retrieval: accurate provider documentation so the model stops inventing argument names. HashiCorp's Terraform MCP server started there, as a registry-querying beta announced on 19 May 2025; OpenTofu shipped its own registry MCP server at v1.0.0 in June 2025; AWS's IaC MCP server from 28 November 2025 covers CloudFormation and CDK only; the Azure MCP Server wraps the Azure CLI and azd. All of that is fine and I use it.

The second layer is execution, and it arrived quietly. By v1.0.0 on 9 June 2026 the Terraform MCP server could read HCP Terraform workspaces, runs, state versions and plan JSON; v1.1 through v1.3 (July to August 2026) added run management, project administration, team creation and workspace access grants, with force-unlock and deletion gated behind ENABLE_TF_OPERATIONS=true. In fifteen months the official tooling went from "look up the arguments for aws_s3_bucket" to "an agent holding a token can grant a team admin on a production workspace". Everything in my MCP security post applies, with the blast radius now a cloud account.

Practitioners have noticed. Firefly's 2026 survey finds 44 percent running AI for infrastructure automation in production or pilots, but only 34 percent would trust an agent with autonomous production changes, 42 percent name missing guardrails as the primary blocker, a third tie drift to a costly production incident, and 5 percent claim self-healing systems. The incident that made the gap concrete happened on 26 February 2026, and Alexey Grigorev of DataTalks.Club wrote it up himself. He moved to a new laptop without the local Terraform state for a production stack; Terraform, seeing no state, planned duplicates of everything; he asked Claude Code to clean up the duplicates; after he supplied the real state, the agent ran terraform destroy against the production configuration and removed the VPC, ECS cluster, load balancers, bastion and RDS instance with its automated snapshots, about 1.9 million rows in one table and two and a half years of student work. AWS Business Support found an internal snapshot after roughly a day, hence the post's title about paying 10 percent more for support. He now keeps state in S3, has deletion protection at both layers, runs a daily restore test, and no longer lets the agent apply without a human reading the plan.

Gruntwork's analysis lists six conditions that had to hold at once: local state, no state integrity protection, direct CLI execution with no plan-apply separation, broad production credentials, no review checkpoint and no deletion protection on the database. None is an AI failure. The agent did not introduce a new failure class; it removed the latency that used to let the human notice. The protection is the old discipline: plan in CI, apply after merge, scoped short-lived credentials per environment, prevent_destroy on anything with data, backups the IaC tool cannot see, and no production credentials on a laptop. Agents make that mandatory rather than optional, the same conclusion I reached about what agents do at 2 AM and agent identity: the agent gets its own narrow identity, and it proposes rather than applies.

Policy as code is the seatbelt

If an agent opens the pull request, something other than a tired reviewer has to read the plan. The policy layer consolidated this year. Aqua's tfsec README reads "tfsec is now part of Trivy" and its checks live in Trivy 0.75.0 under the same IDs; Tenable archived Terrascan on 20 November 2025. That leaves Checkov 3.3.21 and Trivy as the maintained scanners with large rule sets, and OPA 1.21.1 with Conftest 0.71.0 for rules you write yourself against plan JSON. Inside HCP Terraform the choice is Sentinel, OPA or the HCL-based "Terraform policy", the last in beta on a 1.16 alpha build and the only one that works with Stacks. OpenTofu 1.13's linting experiment states an intention to fold policy enforcement into the engine eventually, which would be the first native answer from either fork.

What I enforce is narrower than the catalogues suggest. A Conftest rule that fails any plan containing a delete on a short list of resource types (databases, state buckets, KMS keys, VPCs) catches the DataTalks incident regardless of who or what authored the plan. A second that fails any plan whose managed resource count drops by more than a set fraction catches the missing-state case, where everything is "new" and the old stack is queued for destruction. Neither needs a vendor. Both need the plan to pass through CI rather than a terminal, and that architectural choice, not any scanner, is the control.

What I take from this: the engine question settled in a way nobody predicted in 2023, with two healthy trains borrowing from each other, and the real decision is whether client-side state encryption and an MPL licence are worth giving up action blocks and HCP integrations; for my fleet they are. The runner question is a pricing question. The language question answered itself when CDKTF was archived. The agent question is a discipline question the IaC community solved in principle and mostly never implemented. This quarter I would move every remaining state file behind OpenTofu's enforced = true, add the destroy-guard policy to CI, give any agent that touches infrastructure a read-only token and a pull-request workflow, and run a restore test on a schedule, because a snapshot nobody has restored is a hope rather than a backup. It is not glamorous work. It is what makes letting the agents in survivable.

---

Related: MCP Security in 2026: The Protocol Got Hardened. The Ecosystem Didn't., It's 2 AM. Do You Know What Your AI Agent Is Doing? and Policy as Code Guardrails for AI Agents in 2026.