TL;DR: Infrastructure as Code is pushing platform teams toward reusable templates, policy-as-code, drift detection, and self-service, while also exposing a governance gap when identity and access processes do not keep pace with infrastructure change, according to ControlMonkey. The operational question is no longer whether automation works, but whether access control, compliance, and accountability can keep up with version-controlled delivery.
At a glance
What this is: This guide explains how Infrastructure as Code changes the operating model for platform teams and DevOps, and why identity governance becomes harder to ignore as delivery becomes more automated and self-service.
Why it matters: IAM, IGA, and PAM teams need to understand that platform-level automation changes where access decisions happen, how control is enforced, and which governance checks can be embedded before deployment.
Context
Infrastructure as Code makes infrastructure changes repeatable, versioned, and easier to ship at scale. That same consistency also shifts control away from manual approvals and into templates, pipelines, and reusable modules, which is where identity governance starts to matter.
For platform teams, the problem is not simply provisioning speed. The real governance gap is that access, policy enforcement, and compliance checks must now travel with the infrastructure definition itself, or drift and exception handling will accumulate outside the intended control model.
Key questions
Q: Where does infrastructure as code fail if identity governance is left out?
A: IaC fails when teams treat templates as the only control surface and ignore the identities that author, approve, and execute those templates. In that model, access becomes embedded in pipelines and reusable modules without a clear ownership boundary, so drift, over-permissioning, and untracked privilege changes can spread faster than manual governance can respond.
Q: Why do self-service portals create governance risk when access is involved?
A: Self-service creates risk when it exposes more entitlement than the organisation has already risk-reviewed. The portal can improve speed, but it also makes it easier to approve exceptions, expand standing privilege, and obscure accountability unless the catalog is tightly constrained by role, attribute, and lifecycle policy.
Q: What signs show that IaC automation is creating access sprawl?
A: Warning signs include shared deployment identities across teams, broad write access to modules or pipelines, stale automation accounts, and repeated exceptions for the same infrastructure patterns. When the same privileges keep appearing in different places, the platform is standardising exposure as well as standardising delivery.
A: Yes. CI/CD systems, orchestration tools, and infrastructure automation all exercise delegated access on behalf of the organisation, so they need inventory, least privilege, rotation, and offboarding controls. The practical difference is that their blast radius can extend across environments, making lifecycle discipline and entitlement scoping even more important.
Technical breakdown
How IaC changes the access control boundary
Infrastructure as Code moves control points from ticket-driven operations into code, pipelines, and platform templates. That means permissions are often granted to roles, service accounts, CI/CD identities, and automation layers that can deploy repeatedly without human review. The result is a narrower but more technical governance boundary: whoever can modify the template, pipeline, or module can shape downstream infrastructure behavior. In practice, this makes identity governance part of the delivery substrate, not a separate approval layer. When access is embedded in code paths, the control objective becomes limiting who can change the control plane itself.
Practical implication: Treat pipeline and template privileges as governance-critical access, not just engineering convenience.
Policy-as-code and self-service need identity guardrails
Policy-as-code lets teams encode security and compliance rules directly into provisioning workflows, while self-service lets developers consume approved patterns without waiting for manual intervention. That combination can reduce friction, but only if the identity model underneath is precise. Platform teams still need to decide which identities may publish modules, approve changes, trigger deployments, or assume cloud roles. Without that discipline, self-service becomes a bypass for review rather than a replacement for it. The technical challenge is less about automating checks and more about binding those checks to the right actor, stage, and permission boundary.
Practical implication: Map every self-service path to an identity and approval boundary before expanding developer autonomy.
Drift detection depends on a clean lifecycle for automation identities
Drift detection compares intended state with actual state, but it cannot solve identity sprawl on its own. If automation identities, deployment roles, or platform service accounts are overused, reused, or left active after a workflow changes, the environment can remain compliant on paper while access quietly outlives the purpose that justified it. That is why IaC governance and identity lifecycle management are linked. Reusable templates standardise infrastructure, but reusable credentials can standardise risk if ownership, scope, and offboarding are not managed with equal rigour.
Practical implication: Pair drift detection with access lifecycle controls for the identities that create and modify infrastructure.
Breaches seen in the wild
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
- EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
IaC pushes identity governance into the delivery path, not beside it. Once infrastructure is defined as code, the people and systems that can change that code effectively control the environment. That means platform teams are governing access through repositories, pipelines, and templates whether they acknowledge it or not. The governance model has to follow the execution path, or it will miss the real control surface.
Self-service changes the question from approval volume to privilege design. The article’s platform engineering model is built on reusable blueprints and reduced friction, which is exactly where IAM teams need to be precise about who can author, approve, and execute those blueprints. If those boundaries are vague, self-service becomes standing delegated access with a nicer user experience. Practitioners should treat module publishers and pipeline operators as privileged actors.
Version control is only an audit trail if identity remains attributable. IaC improves traceability, but traceability is not the same as governance. When multiple actors share deployment paths or automation identities are reused across teams, the audit record becomes harder to map back to accountable ownership. The practical takeaway is that identity attribution must be preserved from commit to deployment, or auditability becomes cosmetic.
Platform engineering is quietly expanding the scope of NHI governance. CI/CD identities, deployment roles, and infrastructure automation accounts are now part of the same governance surface as service accounts and workload identities. ControlMonkey’s framing shows why NHI programmes can no longer stop at vaults and secrets. They have to extend into platform engineering operating models, because the highest-risk identities may be the ones that build the environment itself.
Reusable infrastructure creates reusable access assumptions. The same template logic that makes delivery efficient can also make privilege patterns repeat across teams and environments. That is why identity governance in IaC environments is not a one-off hardening exercise. It is a lifecycle problem tied to who can create, change, and retire the automation that controls production infrastructure.
What this signals
Identity governance now belongs inside the platform operating model. As IaC, self-service, and policy-as-code become the default delivery pattern, access control can no longer sit in a separate governance lane. Platform teams need to design identity boundaries into templates, pipelines, and automation identities from the start, or they will keep rediscovering the same control gaps after deployment.
Template standardisation can either reduce or multiply privilege risk. If reusable modules carry well-governed identity assumptions, they simplify enforcement across teams and environments. If they carry shared credentials, broad roles, or vague ownership, they standardise exposure at the same scale as they standardise infrastructure.
Version-controlled infrastructure is only as accountable as the identities behind it. Commit history and drift detection improve visibility, but they do not replace identity attribution. Security and identity leaders should expect platform engineering to become a core governance domain rather than a downstream consumer of IAM policy.
For practitioners
- Audit pipeline and template privileges Identify who can modify IaC modules, CI/CD workflows, and deployment roles, then remove any broad write access that is not tied to a clear ownership model.
- Bind self-service to approved identity paths Require every self-service provisioning path to map to a named approval boundary, a specific automation identity, and a documented rollback path.
- Separate publisher and executor duties Split the identities that author infrastructure templates from the identities that execute deployments so that no single automation path can both define and push change.
- Extend lifecycle controls to automation identities Review service accounts, deployment roles, and platform automation credentials on the same cadence you use for privileged human access, including offboarding when pipelines are retired.
Key takeaways
- Infrastructure as Code changes where governance happens by moving control into code, pipelines, and reusable modules.
- The main risk is not automation itself but weak identity boundaries around who can change, approve, and execute infrastructure definitions.
- Platform teams need lifecycle, attribution, and least-privilege controls for automation identities if they want self-service without losing accountability.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | IaC automation identities and deployment roles are often granted more access than they need. |
| NHI-01 — Improper Offboarding | Retired pipelines and automation accounts often remain active after platform changes. | |
| Recommendation — Review automation and deployment identities for excessive permissions and reduce them to task-scoped access. Retire platform automation identities when workflows are decommissioned and revoke their access immediately. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | IaC pipelines and template authors need least-privilege access to prevent uncontrolled infrastructure change. |
| Recommendation — Apply least privilege to template authors, pipeline operators, and automation roles. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article centers on managing human and non-human accounts that drive infrastructure delivery. |
| Recommendation — Inventory and review platform automation accounts with the same rigor used for privileged user accounts. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article’s governance gap is about permissions embedded in delivery and provisioning paths. |
| Recommendation — Define and enforce access permissions for IaC authors, approvers, and executors. | ||
Key terms
- Infrastructure as Code coverage: The share of infrastructure that is created, changed, and governed through code rather than manual console actions. In practice, it measures how much of the environment can be reviewed, reproduced, and remediated through a controlled delivery path instead of ad hoc operator behaviour.
- Policy as Code: Policy as code stores authorization logic in version control and evaluates it through testable, reviewable rules. For agent governance, it makes runtime decisions reproducible and measurable, which is critical when actions can be triggered by untrusted content and executed at machine speed.
- Self-Service Provisioning: Self-service provisioning is a model where users request access or apps through a portal instead of waiting for manual fulfillment. It can reduce friction, but only when the request path is tied to role rules, approval thresholds, logging, and revocation logic.
- Deployment Identity: A deployment identity is the non-human identity a CI/CD system uses to reach production resources. In practice, it should be uniquely owned, narrowly scoped, time-bound, and revocable, because it can modify live systems and becomes a high-value target when shared or long-lived.
Deepen your knowledge
NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or platform governance programme, it is worth exploring.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org