What Is Blast Radius in SaaS?

Quick Answer

Blast radius in SaaS security is the measurable scope of data, applications, and actions a single identity can reach if it is compromised or misused. The term is borrowed from physical explosives, but in identity security it has nothing to do with physical damage: it describes reach, not force. A severity score tells you how bad a finding looks. Blast radius tells you what an attacker holding that identity could actually touch across your SaaS fabric, including multi-hop paths through integrations, OAuth grants, and AI agents.

Key Takeaways

• Blast radius scores reach. Severity scores a finding. Two critical alerts can have wildly different blast radius depending on what each identity can reach.
• Blast radius is a function of effective authority, not theoretical configuration. What the config says and what the identity can actually do inside an app often diverge.
• SaaS amplifies blast radius through inherited and transitive access: one identity, many apps, many integrations, many downstream tokens.
• SSO and OAuth compromises produce unusually large blast radius because they sit at trust-governance chokepoints.
• The gap between granted scope and used scope is the reducible part of your blast radius. Most organizations never measure it.
• AI agents and non-human identities now belong inside every blast radius assessment. Agents move more data than humans and are routinely over-permissioned.
• MFA reduces the likelihood of compromise. It does not reduce blast radius by a single record.
• You cannot compute blast radius from posture snapshots alone. You need runtime truth: what the identity actually reached, on whose behalf, and what data sat at the end of the path.

What is blast radius in SaaS?

Blast radius in SaaS security is the total set of applications, records, permissions, and downstream systems a single compromised identity can reach before containment. It is a scope measurement, not a severity measurement.

The metaphor comes from physical explosions, and that is where the comparison ends. In identity security, the "explosion" is one credential falling into the wrong hands, and the "radius" is everything that credential can touch.

Blast radius answers one question: if this identity is compromised right now, what can the attacker reach?

Three clarifications that matter for large enterprises:

• Identity includes non-human identities. Service accounts, OAuth integrations, bearer tokens, and AI agents all carry blast radius. Agents often carry more than the humans who built them.
• Reach is transitive. An identity with access to one app that holds tokens for three others has a blast radius spanning four apps, not one.
• Reach is weighted by data sensitivity. An identity that can read 40 low-value objects has a smaller blast radius than one that can read a single customer PII table.

How does blast radius apply to SaaS applications specifically?

SaaS collapses the distance between identities and data, which makes blast radius larger and harder to see than in network or endpoint environments. Every SaaS app is internet-facing, every integration inherits authority, and every OAuth grant creates a path that outlives the person who approved it.

In a traditional network, an attacker needed lateral movement. In SaaS, lateral movement is a built-in feature called integration. A single set of credentials can unlock multiple connected SaaS environments without any exploit at all.

Specific SaaS amplifiers:

• Inherited access. Admins clone permission sets. New hires inherit role bundles nobody has audited in two years.
• Transitive access. App A holds a token for App B. Compromise A, reach B.
• Integration sprawl. Marketing connects a tool. Sales connects another. Each connector holds scopes granted once and reviewed never.
• Maker mode agents. An agent built with its creator's credentials runs at the creator's privilege level for anyone who invokes it. The invoker's own permissions are never checked.

Edge case worth naming: a user with zero Salesforce provisioning can invoke a Copilot Studio agent built in maker mode by a Salesforce admin and extract restricted CRM records. Nothing broke. The IAM control was simply bypassed. That is blast radius expanding without a single misconfiguration alert firing.

How is blast radius different from severity, risk score, or attack surface?

Severity rates a finding. Risk score rates likelihood times impact. Attack surface counts entry points. Blast radius measures reach after entry.

These are complements, not substitutes. Attack surface asks "how many doors exist?" Blast radius asks "what is behind each door?"

Decision rule: choose severity-based prioritization when you are closing an audit finding. Choose blast-radius-based prioritization when you are deciding which of 400 "high" items to fix on Monday.

How do you measure blast radius rather than estimate it?

Measure blast radius by mapping what each identity can actually reach across applications, integrations, and data, then weighting each path by the sensitivity of the data at its endpoint. Estimation looks at roles. Measurement looks at resolved access and observed behavior.

A workable measurement approach:

1. Build the identity inventory. Humans, service accounts, OAuth integrations, and AI agents. Agents included, or the number is fiction.
2. Resolve effective authority per identity. Not the role name. The actual objects, records, and actions available inside each app.
3. Trace multi-hop paths. Follow every stored credential and connector from identity to secondary and tertiary systems.
4. Classify endpoint data sensitivity. Weight regulated, financial, and customer data heavily.
5. Compare granted scope to used scope. Pull runtime evidence of what each identity actually exercised over 30 to 90 days.
6. Produce one number per identity and one aggregate per tenant. Reachable sensitive data objects is the cleanest unit.

Why granted scope and used scope diverge

Granted scope reflects what someone asked for during setup, usually generous, usually permanent. Used scope reflects what the identity actually needed. The gap between them is pure, reducible blast radius.

• Integrations request broad scopes because it simplifies onboarding.
• Nobody returns to narrow them after go-live.
• Agents inherit the broadest scope available to their creator.
• Least privilege for AI agents is impossible to enforce until you can see used scope.

That gap is the highest-yield reduction target you have. It carries almost no business disruption risk, because you are removing access nobody is using.

Runtime security versus configuration-based measurement

Configuration-based tools show theoretical configuration: this connector exists, this scope was granted, this agent is org-wide. Runtime measurement shows what the identity actually reached, who invoked it, and whether the action succeeded. Blast radius computed from configuration alone overstates some risks and misses the ones that matter, including agent-to-agent paths and tools exposed inside MCP servers, which are only observable at runtime.

Why does blast radius grow silently over time?

Blast radius grows because access accumulates and nothing forces it to shrink. No alert fires when reach expands by one hop.

Common mistakes that quietly increase blast radius:

• Approving OAuth integrations once with broad scopes and never re-reviewing them.
• Cloning permission sets instead of building them from need.
• Leaving orphaned agents running after their creator leaves.
• Making agents org-wide or publicly accessible "temporarily."
• Storing hardcoded credentials in low-code workflows.
• Treating MFA rollout as blast radius reduction.
• Relying on native platform logs that are siloed per tenant and require manual correlation.
• Excluding non-human identities from access reviews.

How does MFA affect blast radius?

MFA reduces the probability that an identity is compromised. It does not reduce the blast radius of that identity by one record. A phished session token or a stolen bearer token bypasses the authentication step entirely, which is exactly why Palo Alto Networks argues for containing SSO blast radius beyond MFA.

Useful framing for the board: MFA is a likelihood control. Least privilege, scope containment, and identity separation are blast radius controls. You need both.

Shadow AI and shadow MCP servers as silent expansion

Shadow AI detection matters for blast radius because unsanctioned agents and shadow MCP servers add reach that never appears in any inventory. An agent created by a business user, connected to a production SaaS app, invokable by anyone in the tenant, is a blast radius expansion event with no ticket attached.

How do you reduce blast radius in SaaS without breaking the business?

Reduce blast radius by narrowing what identities can reach, not by blocking what people are doing. Start with unused access, which nobody will miss.

1. Remove the granted-minus-used gap. Trim OAuth scopes and entitlements that show no runtime usage in 90 days.
2. Separate identities by function. Admin work gets a dedicated identity. Integrations get purpose-built service accounts, not human accounts.
3. Shorten credential lifetimes. Short-lived, rotating credentials cap how long a stolen token stays useful.
4. Narrow connectors and define trust zones. Design integrations for one job with one scope, and keep high-sensitivity systems in a separate trust zone.
5. Fix maker mode. Require the invoker's permissions to be checked, not just the creator's.
6. Kill orphaned and org-wide agents. Ownership expires, agents should too.
7. Apply deterministic guardrails to probabilistic agents. Agents run on probabilities and can deviate from intent. Your access controls cannot. Fixed enforcement rules at runtime cut off action chaining before it completes.
8. Write revocation playbooks now. For a compromised OAuth integration, the play is chain-wide: revoke the grant, rotate downstream secrets, and audit every system the integration reached.

Decision rule: if removing access would break a workflow, gate it with elevation instead of leaving it standing.

How do zero trust and tenant isolation change blast radius?

Zero trust reduces blast radius only when it is extended to non-human identities. Verifying every human request while service accounts and AI agents hold permanent, unverified standing access leaves the largest contributors untouched.

On architecture: multi-tenant SaaS concentrates blast radius, because one platform compromise can expose many customers. Single-tenant and sharded designs contain data exposure by isolating tenants, so a breach of one shard does not reach the rest. As a customer, you rarely choose your vendor's architecture, but you can ask about isolation boundaries during third-party review and weight your own data placement accordingly.

What happens to blast radius when a SaaS vendor gets hacked?

When a SaaS vendor is compromised, your blast radius equals whatever authority you granted that vendor, plus every system their tokens can reach. This is the OAuth vendor pivot: attackers do not breach you, they breach a vendor and then use legitimate-looking integration tokens against your tenant.

Because the traffic looks legitimate, detection depends on behavioral signals rather than authentication failures. Reduce this exposure by inventorying every third-party grant, capping scopes at install time, and maintaining a revocation runbook per vendor.

What tools monitor and detect blast radius?

Blast radius monitoring requires correlating identity entitlements, application access, integration paths, and runtime behavior into one view. No single legacy category does this, which is why most teams stitch it together manually.

Obsidian sits in the last row. Obsidian builds an identity graph across AI platforms and SaaS entitlements to show effective authority for every agent and non-human identity, correlating the invoker's identity with the agent's inherited permissions. That correlation is what turns blast radius from an estimate into a measured number, without requiring a connector for every SaaS app you run.

What does a falling blast radius number look like quarter over quarter?

A healthy program shows blast radius declining even while agent and integration counts rise. The metric to trend is reachable sensitive data per identity, not total findings closed.

Quarter-over-quarter signals of a shrinking blast radius:

• Median reachable sensitive objects per identity: down
• Granted-minus-used scope gap: down
• Identities with standing admin authority: down
• Agents running in maker mode with sensitive access: down
• Orphaned agents with active credentials: zero
• Mean time to chain-wide revocation: down
• Agent and integration inventory coverage: up
• Toxic combinations, such as a shadow agent with org-wide sensitive access: down

If total agents doubled and median reachable sensitive data fell, the program is working. If findings closed went up but reach stayed flat, you closed paperwork, not risk.

Making blast radius a number you report, not a metaphor

Blast radius is the metric that makes SaaS and identity risk decisions tractable. Severity tells you a finding is bad. Blast radius tells you which of your 400 "high" findings can actually reach regulated customer data through a three-hop integration path. Only one of those helps you decide what to fix first.

Four actions worth taking this quarter:

1. Inventory every identity, including agents. Humans, service accounts, OAuth grants, AI agents, MCP servers. You cannot govern what you cannot see.
2. Compute the granted-minus-used gap for your top 50 integrations. Trim what nobody uses. This is the cheapest blast radius reduction available.
3. Find every agent running in maker mode with sensitive access. Correlate the invoker's identity against the agent's inherited permissions. That single check exposes privilege escalation your IAM stack cannot see.
4. Write and test one chain-wide revocation playbook. Pick your highest-reach OAuth integration and rehearse full revocation, including downstream token rotation.

Then set a baseline number and trend it. Reachable sensitive data per identity, reported quarterly, turns blast radius from a metaphor into a program.