Sub-Hour SaaS Breach Detection

Security teams keep finding SaaS breaches long after the damage is done, and the reason saas breach detection lags is structural. SaaS logs are siloed per tenant, formatted per vendor, and almost never correlated against identity context. A stolen OAuth token or a compromised agent produces audit entries that look identical to legitimate integration traffic. Nothing in the raw log says "this credential is acting outside its normal pattern." That is why the average time to identify a breach has sat near 194 days in IBM's published research, and SaaS-specific incidents often run longer because no single team owns the telemetry end to end.

The UNC6395 campaign against Salesloft Drift made the failure mode concrete. Attackers used stolen OAuth tokens to reach Salesforce data across roughly 700 organizations. No password was cracked. No MFA prompt fired. To every downstream tool, the malicious token use and legitimate integration traffic were the same events. Detection took weeks to months at most affected orgs, not because the signals were missing, but because nothing correlated the token's activity against the identity's baseline in real time.

There is a second accelerant now: non-human identities. Agents and service accounts move roughly 16x more data than a human user in the same window, and studies of production estates put around 90% of agents in an over-permissioned state. When an over-scoped machine identity is the top of your blast radius stack and its normal traffic is already high-volume, a classic log pipeline has no way to separate a bad day from a Tuesday. The implication is direct: if you cannot see what a token or agent actually did inside the app, you cannot detect its misuse at sub-hour speed.

SIEMs, CASBs, and native SaaS audit logs generate volume, not clarity. They capture the surface event and rarely the effect that matters.

What classic tools see:

• Login events, IP addresses, user agents
• OAuth grant creation timestamps
• API rate spikes
• Aggregate file download counts

What they miss:

• Which specific objects a token queried, and whether that set matches the token's own history. "Read Salesforce" is not the same signal as "this service account pulled 40,000 opportunity, quote, and contract records at 3 a.m."
• Whether an agent built in maker mode is executing with the creator's privileges on behalf of a lower-privilege runner who should never reach that data.
• Whether one tool call chained into a second app and moved data downstream, turning a read in one system into an export in another.
• Whether the human who triggered the agent was authorized to trigger that action at all.

A CASB will show you a spike in API calls. It will not tell you the calls came from an orphaned agent whose creator was offboarded six weeks ago, or that the export hit tables this identity has never touched. That gap between "an event happened" and "here is exactly what it did, to which objects, and who is responsible" is why MTTD stays measured in months.

Sub-hour detection is a correlation problem. The moment you can connect an identity event to the specific in-app effect it produced, the detection window collapses from months to minutes.

The correlation needs three streams stitched together:

1. Identity context. Who is the human runner? Who created the agent or integration? Is either one disabled, external, or elevated?
2. Agent or token activity. What action did the non-human identity execute, which tools did it call, and which downstream apps did it reach?
3. Effective access. What could this identity actually do inside the target app once every role, group, and inherited permission resolved, not what the config page claims.

When those streams meet, an analyst answers a specific question in one lookup: "A user with no standing Salesforce access invoked an agent in maker mode that exported 12,000 opportunity records at 3:04 a.m. Is that consistent with the agent's normal pattern, and is the runner authorized?" That question is unanswerable in a log-only SIEM, because the SIEM never resolved the runner against the maker's privileges or the agent's own history. In a system built on effective access, it is a five-second query. This is the machine insider problem stated plainly: the credential is trusted, the behavior is not, and only the correlation exposes the gap.

You cannot define abnormal without a definition of normal, and for saas breach detection the baseline has to be the identity's effective access pattern, not its configured scope.

Configuration baselines fail for a simple reason. An OAuth token might be scoped to "read all Salesforce objects." That scope is a permanent superset. In practice the token reads about 200 account records a day for a reporting workflow. When it suddenly queries 40,000 records spanning opportunity, quote, and contract objects, the configuration has not changed at all. The behavior is the entire signal, and a tool watching only configuration sees nothing move.

An effective-access baseline answers different questions. What does this identity typically touch, at what volume, at what hours, from which downstream systems, chained with which other actions? Deviation from that profile is what produces a high-signal alert instead of noise. A configuration-only tool cannot see the deviation because it never watched the runtime pattern to begin with.

Start where the blast radius is largest. Trying to baseline every identity at once is the common mistake. Begin with high-privilege non-human identities, connector-authenticated agents, and tokens holding sensitive data scopes. Those sit at the top of the blast radius stack, and a bad day there is the incident you most need to catch inside the hour.

Getting to sub-hour is an operational discipline, not a single purchase. Five things have to be in place, and most enterprises fail on correlation and ownership rather than on raw capture.

Sub-hour is a chain: capture, correlate, prioritize, route, respond. If any link runs longer than about fifteen minutes, the whole chain misses the window. The teams that hit sub-hour are rarely the ones with the most log sources. They are the ones who correlated first and assigned an owner to each identity class before the incident, so the evidence generates itself and the alert lands on a named desk.

The old pattern was an inline CASB proxy or an endpoint agent on every device. Both break in agentic environments. Agents call SaaS APIs directly from platforms like Copilot Studio, Bedrock, and Vertex, which never touch an endpoint agent, and inline proxies add latency that AI platforms will not tolerate.

Connector-free runtime visibility takes a different route. It reads runtime evidence from the AI platforms and correlates that activity against the identity graph and effective access inside each app. No proxy, no endpoint agent, no dependency on the SaaS admin team enabling one more integration. The security team can deploy on its own and see runtime truth across the estate. This is the "Intel Inside" decision-engine model: Obsidian sits at the control plane and identity graph layer, correlating what an agent did against what that identity could actually reach, rather than parsing a vendor's theoretical config page. For known attack patterns, that pre-built correlation is what pulls detection latency from months to under an hour.

Read the enforcement boundary carefully. Detection here is Discover and Govern: it applies broadly across sources, and its job is to see the effective-access deviation and route it fast. It is not autonomous prevention. Runtime guardrails that deterministically block a malicious action exist today only for Claude and Microsoft Copilot. For Agentforce, Snowflake Cortex, ServiceNow and Now Assist, Moveworks, Bedrock, Vertex, n8n, and every other source, autonomous blocking is on the roadmap, not present tense; sub-hour detection means alert and route, and a human or existing control performs the containment. Treat any vendor claim of universal auto-block across all SaaS sources with skepticism.