Who is accountable when cloud exposure comes from service accounts or third-party access?

Accountability should sit with the business owner of the data and the owner of the identity or integration that can reach it. That is why cloud risk programmes need lifecycle ownership, access review, and offboarding rules for non-human and external identities, not just infrastructure controls.

Why This Matters for Security Teams

Cloud exposure rarely becomes a simple infrastructure problem once service accounts or third-party access are involved. The real issue is accountability: who approved the access, who owns the data, who can revoke it, and who is monitoring for misuse. That is why identity governance has to extend beyond human users into non-human identities and external integrations, a point reflected in the OWASP Non-Human Identity Top 10. If ownership is unclear, remediation slows down and exposure can persist long after a project, vendor, or automation pipeline should have been removed.

Security teams often assume the cloud provider, IAM platform, or application team will “own” the problem, but that assumption fails when an exposed token is tied to a business process outside normal admin workflows. Service accounts often outlive the workload they support, and third-party access can remain active because no one is explicitly assigned to review it. Current guidance suggests treating these identities as governed assets with named owners, approval paths, and expiry rules. In practice, many security teams encounter the blast radius only after a leaked token, stale integration, or vendor account has already been used to reach sensitive data, rather than through intentional review.

How It Works in Practice

Accountability in these cases usually needs to be split across three layers. The business or data owner is responsible for the risk of the exposed asset, the platform or identity owner is responsible for the identity lifecycle, and the third party is responsible for the behaviour of any external access they operate under contract. That division matters because cloud exposure is often created by one team and discovered by another. A service account may be embedded in CI/CD, while a vendor account may be provisioned for support, analytics, or managed operations.

Operationally, the control set should cover ownership, review, and removal. At minimum, teams should be able to answer: who approved the access, what system or process requires it, when was it last used, and what triggers revocation. NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls maps well to this problem because it emphasises access enforcement, account management, and auditability. For cloud and integration-heavy environments, the practical steps usually include:

• Assign a named owner for every service account, API key, and external integration.
• Require business justification and an expiry date for third-party access.
• Review permissions on a fixed cadence, especially for privileged or production access.
• Log authentication, token use, and key rotation events for investigation and offboarding.
• Revoke access automatically when the workload, contract, or support relationship ends.

This becomes especially important as AI-enabled automation expands the number of identities that can reach cloud data. Reporting on real-world abuse, including the Anthropic — first AI-orchestrated cyber espionage campaign report, reinforces that machine-speed activity can accelerate misuse when identities are over-permissioned or poorly governed. These controls tend to break down in fast-moving DevOps environments where credentials are embedded in automation, ownership changes frequently, and no single team is responsible for offboarding.

Common Variations and Edge Cases

Tighter identity governance often increases operational overhead, requiring organisations to balance revocation speed against workflow continuity. Not every access path should be treated the same, and best practice is evolving for hybrid estates where SaaS, cloud-native services, MSPs, and internal automation all intersect. There is no universal standard for this yet, so accountability models need to be explicit rather than assumed.

One common edge case is shared service accounts used by multiple applications or environments. These are difficult to attribute cleanly, but that is not a reason to leave them unmanaged. Another is delegated third-party access, where the vendor administers the account but the customer still owns the data risk. In those situations, contractual controls, access review evidence, and logging obligations should be aligned. For highly privileged or sensitive access, teams should consider whether the identity should be converted to a narrower, time-bound model instead of remaining standing. The accountability question also changes when automation triggers access on behalf of a workload, because the owner may be a platform team rather than an application team.

The practical test is simple: if no one can revoke it quickly, no one truly owns it. That is the point where cloud exposure becomes a governance failure rather than a technical misconfiguration.

Related resources from NHI Mgmt Group

• Who is accountable when third-party or service access is still routed through a VPN?
• Who is accountable when third-party cloud access is abused in a data breach?
• Who is accountable when third-party remote access is overused in public safety environments?
• Why do service accounts and third-party identities complicate compliance reviews?