Who should be accountable for suspicious infrastructure changes?

Accountability should sit with the team that owns the asset and the identities that can modify it, including infrastructure, security operations, and identity governance. If a service account or privileged admin can change critical controls, that entitlement must be reviewable and traceable. Ownership should be explicit before a failure forces the question.

Why This Matters for Security Teams

Suspicious infrastructure changes are rarely just a configuration issue. They are an accountability issue, because the real question is not only what changed, but which asset owner, privileged identity, or automation path was allowed to make that change. In environments with service accounts, CI/CD runners, and agentic tooling, the change may look “technical” while the control failure is actually in ownership, traceability, or entitlement design.

That distinction matters because infrastructure changes often blur the line between operations and identity governance. If a privileged identity can modify critical controls without clear ownership, incident response slows down and blame shifts instead of root cause. NHI Management Group’s Ultimate Guide to NHIs shows that only 5.7% of organisations have full visibility into their service accounts, which makes accountability difficult to enforce after the fact. The practical answer is to assign responsibility before change occurs, not after the blast radius is known.

Practitioners should treat every suspicious change as a question of “who had authority, who approved it, and who can revoke it.” In practice, many security teams encounter misattributed responsibility only after a failed rollback or an access review, rather than through intentional ownership design.

How It Works in Practice

Accountability should map to the asset owner and the identity owner together. The asset owner is responsible for the system being changed, while the identity owner is responsible for the service account, admin role, or agent that performed the action. That shared model is important because infrastructure changes often originate from automated pipelines, not a human on a console. A change made by a deployment service account should still be traceable to the team that created, approved, and can revoke that access.

For operational control, teams should tie every critical change to a reviewable identity and an approval trail. That usually means:

• Using named ownership for infrastructure components, not informal team queues.
• Binding privileged actions to short-lived credentials and identifiable workload identities.
• Recording who requested the change, which identity executed it, and what policy allowed it.
• Separating routine operational access from break-glass access so exceptions are visible.
• Reviewing service accounts and automation privileges on the same cadence as human admin access.

This is where standards-based control helps. The NIST Cybersecurity Framework 2.0 reinforces governance and asset accountability, while the NHI lifecycle guidance in Ultimate Guide to NHIs shows why unmanaged service accounts become a blind spot. In mature environments, change tickets, policy decisions, and identity logs should all converge on the same owner record so investigators can answer the question without guessing. These controls tend to break down when infrastructure is heavily automated but ownership records are still maintained manually, because the identity that changed the system and the team that owns it drift out of sync.

Common Variations and Edge Cases

Tighter change accountability often increases operational overhead, so organisations have to balance fast deployment against clear control ownership. That tradeoff becomes sharper when agentic systems, shared platform teams, or external integrators can make changes across multiple environments.

There is no universal standard for this yet, but current guidance suggests three common edge cases. First, in platform engineering models, the platform team may own the mechanism while the application team owns the impact, so both should be named in the response path. Second, if a service account is shared across several workloads, accountability becomes weaker and usually should be replaced with workload-specific identities. Third, for emergency fixes, break-glass access should be accountable to a specific on-call role, with automatic post-event review and revocation.

Suspicious changes made by AI-assisted automation deserve extra scrutiny because the question is not just “who clicked approve” but “which identity was authorised to act autonomously.” NHI Management Group’s research shows that organisations continue to rely on static credentials even as autonomous infrastructure use grows, which makes attribution and revocation harder when a change looks abnormal. The safest operational pattern is explicit ownership, short-lived access, and a revocation path that matches the speed of the system itself.

Related resources from NHI Mgmt Group

• Who is accountable when compromised credentials are used to access personal or infrastructure accounts?
• Who is accountable when privileged activity in virtualised infrastructure is not attributable?
• Who is accountable for access control evidence under SOC and SOX?
• Who is accountable when access controls fail in SOX-scoped systems?