Trace one run through the model as described and the ordering tells you what the design is for. The agent authors against approved modules and organisational standards, which is the only named layer acting before anything is written [4]. It opens a change and triggers a run. Policy-as-code and run tasks evaluate the proposed change [4]. A project-scoped identity exchanges an OIDC credential for cloud access, issued for that run and revoked afterwards [6]. Plans, policy decisions, approvals and execution records land in run history [4]. Four of the five layers act at or after the run request [15]. That follows from the premise: HashiCorp's argument is that engineers cannot supervise a machine loop action by action, so you gate the path the loop has to pass through [3].
The credential mechanic is the part that transfers regardless of whether you buy the governance framing. Permanent cloud credentials in an agent's environment are the failure mode; a per-run OIDC lease means a compromised agent yields something with an expiry rather than a key [6].
The identity question is where the two IaC vendors actually diverge. Pulumi's Neo agent operates within the initiating user's RBAC permissions and opens pull requests for human review, which Pulumi calls agentic infrastructure [8]. HashiCorp scopes the agent to a project identity of its own [6]. Inherit the prompting engineer's permissions and the agent's ceiling is whatever the most privileged person who talks to it holds. Give it a project-scoped identity and the ceiling is written down somewhere you can audit. Both answer a real question. They are not the same question.
HashiCorp names four things the agent must not be able to do: approve its own work, weaken policies, acquire broad credentials, or circumvent deployment controls [5][14]. Nothing in the guidance as reported makes those structural. Self-approval is prevented by an approval setting. Broad credentials are prevented by not issuing them. The plane governs the runs that reach it, and an agent already holding cloud keys in its shell never opens a run at all.
Worth stating plainly: both source blocks supplied here are the same InfoQ write-up [12], so this is one publisher's reading of vendor guidance, not a deployment report. The shipped artifact named alongside it is tfctl, a CLI for HCP Terraform [11]. AWS is pushing Amazon Q Developer toward agentic development workflows and Azure is wiring agents into its Developer CLI and Bicep or Terraform templates, which InfoQ reads as a different bet: tools that let AI touch cloud infrastructure, versus the IaC control plane claiming the governance boundary itself [9][10].
In my context this is the right trade, on one condition. If you already run workspaces, policy sets and dynamic provider credentials, the agent story costs you configuration rather than architecture. If you do not, the bill arrives as module curation and policy authoring before any agent is useful, and that work lands on the platform team [7]. The number to ask a vendor for is credential lifetime. The rest is an operating model, and operating models are only as good as the defaults someone set last quarter.
