Who is accountable when access evidence is spread across multiple clouds?

Why This Matters for Security Teams

When access evidence is distributed across cloud consoles, identity providers, CI/CD systems, and workload platforms, accountability becomes an evidence problem rather than a simple ownership question. Security teams are often expected to prove who approved access, which identity exercised it, and when it was removed, even though each platform records only part of the story. That is why evidence-oriented governance matters more than platform-by-platform admin rights.

The issue is especially visible in non-human identity programs, where machine access is frequently over-provisioned, short-lived, and operationally invisible until an incident forces reconstruction. The 2024 Non-Human Identity Security Report found that 35.6% of organisations cite consistent access management across hybrid and multi-cloud environments as their top challenge. That aligns with the practical gap between policy and proof. Frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls and the OWASP Non-Human Identity Top 10 both support a model where accountable access is demonstrable, not assumed.

In practice, many security teams encounter missing accountability only after an audit, breach review, or privilege escalation has already exposed the gaps.

How It Works in Practice

The operational answer is to assign accountability to one organisation-level control owner, then require every platform involved in the access chain to emit correlated evidence. That means the approver, the identity, the entitlement, the activity, and the expiry all need to be traceable in a single case record or evidence bundle. The organisation may use multiple clouds, but the accountability model cannot be fragmented across them.

Good practice is to standardise on a minimal evidence set:

• who requested or approved access
• what identity or workload assumed it
• what resource or API was used
• which policy or control authorised it
• when the entitlement started and when it expired
• what logs prove revocation or session end

This is where identity-centric logging becomes essential. For NHI and agentic workloads, the identity primitive is the workload itself, not the cloud account that hosted it. Teams often combine cloud audit logs with workload identity proof, token issuance records, and secret manager events so that the evidence chain survives cross-platform movement. The Ultimate Guide to NHIs explains why workload identities, ephemeral credentials, and short TTLs are becoming the practical baseline, especially in environments where access is issued per task rather than per team.

For multi-cloud operations, the key is not to search every platform manually after the fact. It is to make the evidence portable up front through central policy, consistent naming, time synchronisation, and immutable audit retention. That aligns with the control intent in NIST guidance and with current industry guidance from the Aembit report, which notes that organisations increasingly need dynamic, ephemeral access rather than static secrets. These controls tend to break down when teams rely on separate cloud-native logs that do not share a common identity correlation key.

Common Variations and Edge Cases

Tighter access evidence collection often increases operational overhead, requiring organisations to balance auditability against engineering speed. That tradeoff becomes sharper in federated cloud environments, where one team owns IAM, another owns the platform, and a third owns the workload. Current guidance suggests the accountability owner should still be singular, but the evidence sources can be distributed if the correlation method is stable and repeatable.

There is no universal standard for this yet, especially for agentic workloads that can chain tools across services and assume multiple identities in one session. In those cases, best practice is evolving toward runtime policy evaluation, short-lived credentials, and context-aware logging rather than static role assignments. That is consistent with the Replit AI Tool Database Deletion and Snowflake breach analyses, where execution authority and access evidence mattered more than nominal ownership.

For organisations with managed service providers, shared platforms, or delegated admin rights, the practical question is not who touched the console last. It is who can produce the complete chain of evidence on demand and revoke access when the entitlement no longer matches the task. Where that chain cannot be reconstructed across clouds, accountability becomes disputed by default.

Related resources from NHI Mgmt Group

• Who is accountable when remote cluster access spans SSH, kubectl, and compliance evidence?
• How should security teams audit privileged access across multiple clouds?
• How should security teams govern access when sensitive data is spread across multiple systems?
• What breaks when audit evidence is spread across multiple systems?