Reducing Attacker Dwell Time in SaaS Breaches

Attacker dwell time is the total number of days between an intruder's initial access and the moment defenders remove them completely. That single number is the strongest predictor of breach cost. The longer an intruder operates, the more data leaves the building, the more identities they pivot through, and the more the recovery bill grows.

Boards track attacker dwell time because it reads as a leading indicator of program maturity. A shrinking number tells directors the team is catching real threats faster. A flat or rising number tells them prevention spend is not keeping pace with attacker tradecraft. The metric is blunt on purpose. It cuts through tool inventories and control counts to one question: how long can something hostile live inside your environment before you notice.

In SaaS, that question got harder to answer. Attackers no longer grind through network segments to reach data. They ride OAuth tokens, embedded agent credentials, and third-party integrations straight into the sensitive objects. The perimeter they cross is an identity boundary, not a firewall.

How long attackers actually stay

Published benchmarks from the recurring Mandiant M-Trends and IBM Cost of a Data Breach reports place median global dwell time in the low tens of days. SaaS-specific intrusions tend to run longer, because native audit logs sit siloed per tenant and per app, and correlating them is manual work nobody does until an incident forces it. When the intrusion runs through an AI agent or a compromised integration, the timeline stretches further, because the malicious activity is authenticated and looks routine.

The Salesloft Drift campaign in 2025 is the clearest recent case. Attackers used stolen bearer tokens from a single integration to reach connected data across roughly 700 organizations. Legitimate and malicious calls carried the same credential and the same shape, so most victims learned of the intrusion only when disclosure reached them. That is not one company's detection failure. It is a category failure across the shared SaaS fabric.

Most detection stacks were built for humans logging into apps. That world is gone. AI agents, service accounts, and integrations now generate the bulk of authenticated activity inside enterprise SaaS. These non-human identities move roughly 16x more data than human users, and by most current estimates around 90% of them carry more permission than their job requires. They are exactly where an attacker wants to hide.

Four specific gaps stretch dwell time in 2026.

• Maker-mode agents. An agent built with a creator's admin credentials runs at that creator's privilege for every user who invokes it. Compromise the invoker and you inherit admin-level reach without ever tripping a privilege-change alert. Identity governance built for humans never sees the escalation.
• Orphaned agents. The creator's account is deactivated after they leave, but the agent keeps running on its embedded credentials. No owner watches its behavior, and no lifecycle process shuts it down.
• Unsanctioned MCP servers. Model Context Protocol servers wire agents to tools and data. Ones stood up outside review widen the attack surface quietly, and their tool calls are visible only while they happen. Retroactive log review cannot reconstruct them.
• Cross-platform action chaining. One agent calls another across Copilot, Vertex, Bedrock, and homegrown platforms. Each platform's native log sees only its own slice, so no single source shows the full chain.

This is the visibility gap in one line: configuration tooling reports what an agent was set up to do, and says nothing about which agent was actually invoked, by whom, and what data it touched.

The fastest lever on attacker dwell time in a SaaS-heavy estate is to correlate effective access against runtime behavior for every agent and non-human identity you run. Periodic access reviews and posture snapshots will not close the gap, because they answer a hypothetical. Correlation answers the fact.

Traditional response burns days on the question "what could this token have done?" Effective-access correlation replaces it with "what did this token actually do, on whose behalf, against what data?" and answers in minutes. The mechanism is where the difference lives. Obsidian's identity graph resolves a runner's identity against the agent's maker-mode credentials against the entitlements that actually resolve inside each connected app: which service account the agent authenticates as, which tables and objects it can read, which actions it can take. That is effective access, not the vendor's theoretical configuration page. When the runner should never have reached that data even through the agent, the confused-deputy pattern surfaces on the spot, and the blast radius shows up in one view instead of a cross-tenant log-stitching project.

An operations-first reduction sequence

The point of the graph is fewer fire drills and evidence that generates itself. A working sequence:

1. Build an authoritative inventory. Discover every agent, MCP server, and integration across Copilot Studio, Agentforce, Bedrock, Vertex, ChatGPT Enterprise, n8n, and any low-code platform a business team can reach. Capture creator, owner, permissions, and connected tools.
2. Map effective access, not theoretical configuration. For each agent, resolve what it can actually reach inside each app after every entitlement resolves. Flag maker-mode, orphaned, and publicly reachable agents first.
3. Instrument runtime observability. Record real invocations, tool calls, and data touched, and correlate the invoker against the inherited credential on every call.
4. Surface toxic combinations. A shadow agent with org-wide sensitive access is not medium risk plus medium risk. It compounds into a critical one.
5. Rehearse eviction. Table-top the exact steps for a confirmed stolen agent token. Most teams cannot answer that in under an hour, and the drill is where they find out.

A note on enforcement so the operating model is clear. Obsidian is not an inline proxy sitting in the traffic path. Runtime works on an "Intel Inside" model: the identity graph acts as the decision engine a platform consults. Autonomous runtime enforcement that can block an action today runs on Claude and Microsoft Copilot only. For Agentforce, Snowflake Cortex, ServiceNow and Now Assist, Moveworks, Bedrock, Vertex, and n8n, the capability today is discover and govern, and deterministic runtime enforcement is on the roadmap rather than in production. Discovery and effective-access mapping are what compress dwell time across all of them right now.

Dwell time, MTTD, and MTTC measure different windows of the same incident. Confusing them produces metrics that look healthy and change nothing.

MTTD is a subset of dwell time. You can detect fast and still carry long dwell time when containment drags, and in SaaS breaches containment usually drags for one reason: the compromised token or agent holds entitlements nobody mapped before the incident. The team loses days reconstructing blast radius while the attacker keeps working. The practical rule for the board deck is short. If MTTD is small but dwell time is large, the problem is response, not detection, and the fix is knowing effective access before the alert fires, not after.

Discovery is not a one-time inventory project. Agents get created weekly by people who are not in security, MCP servers appear and disappear, and integrations accumulate scopes over time. A snapshot taken last quarter is already wrong. Continuous discovery of every agent and non-human identity is the insurance policy under every other control, because an agent you have never seen is a dwell-time extender by definition.

Identity segmentation is the SaaS equivalent of network segmentation. Attackers rarely cross network segments in these breaches. They cross OAuth scopes, agent-to-agent trust, and delegated permissions. Translated into controls:

• Apply least privilege to every non-human identity, not only human users, and revisit it as scopes drift.
• Segment agents by function so a compromised one cannot chain into unrelated domains.
• Treat maker-mode credentials as privileged accounts that require rotation and monitoring.
• Assume a SaaS vendor may not detect or disclose a supply-chain intrusion in time to help you, and inventory your own exposure accordingly.

Zero Trust language applies here only when it is anchored to non-human identities and agents. Anchored to human users alone, it does not touch the blind spots that stretch SaaS dwell time.

Most SaaS-heavy organizations cannot calculate their own dwell time, because they have no complete inventory of non-human identities to measure against. Start there. Build the agent and non-human identity inventory, instrument runtime observability, then measure. In that order, because the number is meaningless without the first two.

A three-question test tells you where you stand:

• Can you list every AI agent operating in your environment right now, with its owner and effective access?
• Can you show what any single agent actually did in the last 24 hours, and on whose behalf?
• Can you cut a specific agent's access in under an hour without breaking legitimate work?

If any answer is no, dwell time in your environment is longer than your dashboard suggests, and the gap is not a tuning problem. It is a visibility one. The dwell-time figure on your next board deck reflects a choice you make now about where you look and what you can prove.