Who is accountable when stolen identities are used to exfiltrate data through SaaS?

Accountability usually spans IAM, cloud platform owners, and data governance teams because the abuse crosses authentication, authorization, and information handling boundaries. Organisations should assign clear ownership for delegated access, token lifecycle, and privileged cloud activity so the same gap is not left between three different teams.

Why This Matters for Security Teams

When stolen identities move data through SaaS, the incident is rarely confined to one control domain. Authentication may have been legitimate, the token may have been valid, and the exfiltration may have occurred through approved connectors or delegated access. That is why accountability must extend across IAM, cloud platform ownership, and data governance, rather than stopping at the team that first issued the identity. NHIMG’s research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that identity abuse is often operational, not exotic.

The practical risk is missed handoffs. One team owns sign-in, another owns the SaaS tenant, and a third owns the data set, yet no single owner is clearly responsible for abuse detection, token lifecycle, or privileged API activity. The result is delayed containment and unclear post-incident remediation. Cases such as the Salesloft OAuth token breach and the Snowflake breach show how stolen credentials can translate into SaaS data access without a clean boundary between identity security and data protection. In practice, many security teams discover the accountability gap only after data has already left the tenant, rather than through intentional access design.

How It Works in Practice

Accountability works best when it is assigned to the control point that can actually stop or limit the abuse. For SaaS exfiltration scenarios, that usually means a shared model: IAM owns identity issuance and revocation, the cloud or SaaS platform team owns session and tenant controls, and data governance owns sensitivity, retention, and egress classification. Current guidance suggests treating these as linked responsibilities, not separate problem statements.

Practitioners should define ownership across the full identity-to-data path:

• IAM should own token issuance, rotation, revocation, and anomaly detection for non-human identities.
• Cloud or SaaS platform owners should own privileged configuration, audit logging, connector restrictions, and admin alerts.
• Data governance should own which datasets may be accessed, exported, shared, or synchronized externally.
• Security operations should own cross-domain correlation so stolen identities are detected when authentication, authorization, and data movement line up suspiciously.

This is where NHI governance becomes a force multiplier. NHIMG notes that only 5.7% of organisations have full visibility into their service accounts, which helps explain why ownership disputes persist during response. The issue is not just technical control, but traceability. The Ultimate Guide to NHIs — Why NHI Security Matters Now frames visibility, rotation, and offboarding as core operational duties, while the Anthropic report on AI-orchestrated cyber espionage reinforces how quickly automated abuse can chain across tools once a valid identity is obtained.

In practice, teams should document who can disable the identity, who can freeze the SaaS session, who can quarantine the data store, and who must approve emergency export restrictions before an incident occurs. These controls tend to break down when a contractor-managed SaaS tenant uses shared admin roles because the investigation cannot easily separate tenant ownership from data stewardship.

Common Variations and Edge Cases

Tighter identity control often increases operational overhead, requiring organisations to balance faster response against delegated administration and SaaS autonomy. That tradeoff becomes more visible in multi-tenant environments, partner-managed integrations, and business-owned SaaS tools where no central platform team wants to accept incident ownership. Best practice is evolving, but there is no universal standard for this yet.

One common edge case is OAuth abuse. A stolen token may not look like a password compromise at all, so responsibility can be misassigned to the application owner while the real failure sits in token scoping, consent governance, or lack of revocation automation. Another edge case is read-only exfiltration: the attacker may never alter records, which means traditional integrity alerts do not fire, yet sensitive data still leaves the tenant. The 52 NHI Breaches Analysis is useful here because it shows that identity compromise often cascades across multiple systems before anyone confirms the initial entry point.

Organisations should therefore pre-assign incident ownership for SaaS data theft by scenario, not by team name alone. If the environment relies on ephemeral tokens, third-party connectors, or shared service accounts, accountability should be written into runbooks and RACI matrices in advance. Otherwise, the breach becomes a debate about ownership at the exact moment speed matters most.

Related resources from NHI Mgmt Group

• Who is accountable when a stolen session is used to pivot into SaaS platforms?
• Who is accountable when compromised identities are used to move through the environment?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?