When teams do not track both code and console activity, they lose the ability to explain why an environment changed. That makes drift harder to spot, investigations slower, and compliance evidence incomplete. It also creates blind spots where an apparently valid deployment can conceal an ad hoc console edit that changed access, networking, or production behavior.
Why This Matters for Security Teams
Infrastructure drift becomes a security problem the moment teams cannot prove whether a change came from version-controlled code or an ad hoc console action. Without that timeline, incident responders lose the chain of custody for configuration, access, and routing decisions. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls treats configuration management and auditability as baseline controls for a reason: when changes are not attributable, controls cannot be verified. In NHI-heavy environments, that gap also hides secret exposure, privilege creep, and unauthorized console edits that never passed through review. NHIMG’s Ultimate Guide to NHIs notes that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes untracked console changes even harder to detect. In practice, many security teams discover the drift only after access has already widened, not during the change that caused it.
How It Works in Practice
The practical failure mode is split-brain governance. Code repositories show intended state, while console activity shows actual state. If only one side is monitored, teams can approve a deployment that looks clean in Git while a console operator, automation user, or NHI quietly changes firewall rules, IAM bindings, load balancers, or environment variables. That is why current guidance suggests correlating deployment events, cloud audit logs, and identity activity into one evidence chain rather than treating infrastructure-as-code as the whole record.
For security operations, the useful pattern is:
- Track every change request against a commit, ticket, or pipeline run.
- Collect console, API, and CI/CD logs into a single audit trail.
- Flag any console mutation that has no matching approved code change.
- Compare effective permissions before and after the change, not just the diff in code.
- Require rollback logic that can restore both configuration and access state.
This matters because code review alone cannot catch runtime edits, and console-only controls cannot explain the intended design. The Schneider Electric credentials breach illustrates how identity and access issues become material when environment changes are not well governed. A second useful reference is NIST SP 800-53 Rev 5 Security and Privacy Controls, especially the expectation that organisations preserve audit evidence and control configuration changes. These controls tend to break down when console access is shared across operators, break-glass accounts, and automation because attribution becomes ambiguous after the fact.
Common Variations and Edge Cases
Tighter change tracking often increases operational overhead, requiring organisations to balance speed of remediation against the cost of more logging, more review, and stricter approvals. That tradeoff is manageable in stable environments, but it gets harder when teams use ephemeral infrastructure, autoscaling, or frequently recreated dev and test accounts. In those cases, best practice is evolving rather than settled, and the right answer is usually to log identity and change context at the orchestration layer instead of relying only on host-level artefacts.
Two edge cases deserve special attention. First, emergency break-glass changes are sometimes necessary, but they should still be auto-tagged, time-bound, and reconciled back into code as soon as the incident is over. Second, agentic automation can make the problem worse because an AI system can chain console actions faster than a human reviewer can notice. NHIMG’s Ultimate Guide to NHIs shows that NHIs outnumber human identities by 25x to 50x in modern enterprises, so even a small amount of untracked non-human activity can create outsized drift. For that reason, change controls should treat the identity behind the action as seriously as the configuration itself.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Untracked console edits obscure NHI ownership and provenance. |
| OWASP Agentic AI Top 10 | A01 | Autonomous agents can mutate infrastructure outside normal review paths. |
| CSA MAESTRO | GOV-02 | MAESTRO emphasizes governance and traceability for agent-driven operations. |
| NIST CSF 2.0 | DE.CM-8 | Monitoring for unauthorized changes is central to drift detection. |
| NIST AI RMF | GOVERN | AI governance must cover who can change infrastructure and how changes are recorded. |
Maintain an immutable record linking each infrastructure change to its requesting identity.
Related resources from NHI Mgmt Group
- What breaks when Infrastructure as Code governance depends only on manual review?
- Who is accountable when Infrastructure as Code changes create compliance or security failures?
- What breaks when organisations cannot see behaviour changes across traders, bots, and AI agents?
- What breaks when access paths are not mapped across regulated infrastructure systems?
