Subscribe to the Non-Human & AI Identity Journal

How do security teams know whether a SaaS access event was read or exfiltration?

Teams need durable transaction logs, REST request metadata, and response-size visibility to tell the difference between a successful query and confirmed exfiltration. Without those records, you can infer that data was accessed, but you cannot reliably prove how much left the environment. That uncertainty directly affects notification and response decisions.

Why This Matters for Security Teams

For SaaS investigations, the question is not just whether a request succeeded. Security teams need to know whether the event was a normal read, an automated export, or a confirmed transfer of sensitive data. That distinction drives triage, legal notification, containment, and whether an identity should be rotated or revoked. The gap is familiar in NHI incidents: logs often prove access, but not intent or volume.

That is why NHI governance and SaaS telemetry belong together. NHIMG notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, and weak visibility makes it harder to interpret access events after the fact. The OWASP Non-Human Identity Top 10 also treats missing observability as a core control failure, not a minor logging gap.

In practice, many security teams discover exfiltration only after a third party asks what happened, rather than through intentional detection of the access pattern itself.

How It Works in Practice

Teams distinguish read from exfiltration by correlating transaction-level evidence. A single successful REST call may indicate only a record lookup, while a sequence of paginated requests, bulk export endpoints, unusual response sizes, or repeated retries can indicate collection at scale. The decisive factor is not one log line, but whether the SaaS platform records enough context to reconstruct what was requested, how much data was returned, and whether the session behaved like a human workflow or an automated pull.

Practically, that means capturing:

  • Durable request logs with timestamp, actor, endpoint, tenant, and object identifiers.
  • Response metadata, especially payload size, record count, and export job status.
  • Authentication context, including token type, source IP, device, and app identifier.
  • Correlation across sessions so one token cannot hide behind many small requests.

This is where NHI controls and SaaS monitoring meet. The State of Non-Human Identity Security found that inadequate monitoring and logging is cited by 37% of organisations as a cause of NHI-related attacks, which matches what responders see when an OAuth app or service account makes high-volume API calls. For implementation guidance, the OWASP Non-Human Identity Top 10 is a useful baseline for tying identity assurance to monitoring outcomes.

Security teams usually treat confirmed exfiltration as a higher bar than access because it requires evidence that data actually left the platform, not just that it was available. These controls tend to break down when SaaS platforms expose limited audit fields or truncate response metadata, because the team loses the ability to measure volume and reconstruct the transaction chain.

Common Variations and Edge Cases

Tighter telemetry collection often increases storage, parsing, and investigation overhead, requiring organisations to balance evidentiary value against operational cost. Best practice is evolving here, and there is no universal standard for every SaaS product yet.

Some environments make the read-versus-exfiltration distinction harder than others. API-driven analytics tools, BI platforms, and document systems may return large but legitimate payloads, so volume alone is not enough. In those cases, teams should combine payload size with endpoint sensitivity, query repetition, export actions, and the identity behind the request. A single download of a known report is very different from an unfamiliar token enumerating records across multiple objects.

Edge cases also arise when logs exist only in the SaaS admin console but not in a SIEM, or when response bodies are unavailable because the provider only records successful authentication. The 52 NHI Breaches Analysis shows how often identity abuse is only understood in hindsight, and the Snowflake breach is a reminder that access logs without strong query and volume context can leave investigators uncertain about actual data loss.

Current guidance suggests treating unresolved ambiguity as a response trigger: if the platform cannot prove the scope of data returned, teams should assume the event may have been exfiltration until evidence says otherwise.

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 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-08 Observability gaps make it hard to tell access from exfiltration.
NIST CSF 2.0 DE.CM-1 Continuous monitoring is required to spot unusual SaaS access patterns.
NIST AI RMF Risk governance should account for opaque, high-volume machine-driven access.

Log NHI requests, responses, and token context so investigators can reconstruct data movement.