In March 2026, a B2B SaaS company in Austin gave their newly-built n8n customer success agent "full Salesforce access" because that was the only OAuth scope their connector exposed. The agent's job was modest: update lead status when a customer replied to an outreach email. The agent's blast radius was not modest: it could mass-update every account, delete every opportunity, export every contact, change every owner. The agent did not do any of those things. The agent did, however, in a confused loop on a Tuesday afternoon, mass-update the Account_Owner__c field on 2,847 accounts to the same wrong user — a former employee whose account had not yet been deactivated. Sales leadership found out at Wednesday morning's pipeline review when the entire West region had vanished from one manager's dashboard and reappeared on a ghost. The agent had not been told it could do this. It had not been told it could not. This lesson is about the concept that would have surfaced that risk before deploy: blast radius. We will build a 10-minute Blast Radius Score template, walk through three real worked examples (an n8n Salesforce agent, a Lindy Gmail agent, an Agentforce Stripe agent), and arm you with the question every operator should be able to answer about every agent on the first day: in the next hour, what is the worst this thing could do?

What "Blast Radius" Means for an Agent

Blast radius is a term borrowed from cloud infrastructure security. In AWS terms, the blast radius of a compromised IAM role is "every resource that role can touch." If a role can delete every S3 bucket in the account, that's the blast radius. If it can only read one bucket, the blast radius is one bucket. The discipline is to size the blast radius before the role is issued, not after the breach.

For agents, the same discipline applies, with one important difference: agents don't need to be compromised to cause damage. They can cause damage in their normal operating mode by hallucinating a tool call, looping on a misread instruction, or chaining writes in an unexpected order. The blast radius of an agent is what it can do by design, regardless of whether the design was sound.

The operator-facing definition we'll use throughout this lesson:

The blast radius of an agent is the worst-case impact, in the next 60 minutes of operation, of every permission you have granted it — measured in records, dollars, PII subjects, and external recipients.

That's the working definition. It's deliberately quantified. "Could do a lot of damage" is not a blast radius. "Can update 2.8 million Salesforce records, send to any of 47,000 Gmail recipients, and write up to $50,000 in Stripe charges per hour" is a blast radius. You can argue with numbers. You can't argue with vibes.

Why 60 minutes?

The one-hour window is a forcing function. Most write operations get noticed eventually — a mass update will show up in a sales review, an outbound email blast will trigger spam reports, a payment processor will flag unusual activity. The question is how much damage occurs before human notice. The 60-minute window approximates "between when the agent starts misbehaving and when a human is realistically going to be looking." Different orgs will use different windows (15 minutes for high-trust environments with active monitoring, 24 hours for off-hours runs with no monitoring), but one hour is the right anchor for first-pass thinking.

The four blast radius dimensions

An agent's blast radius isn't a single number. It's a vector across four operator-meaningful dimensions:

1. Records touched — how many rows in the source system can the agent modify or delete in an hour? Salesforce accounts, Zendesk tickets, HubSpot contacts, database rows.
2. Money moved — how much currency can the agent cause to be charged, refunded, transferred, or committed in an hour? Stripe charges, refunds, ACH transfers, PO writes, NetSuite journal entries.
3. PII exposed — how many distinct natural-person data subjects' personally identifiable information could the agent read, write, or transmit in an hour? Customer records, employee files, applicant data.
4. External recipients — how many external parties can the agent reach via outbound communication in an hour? Email recipients, SMS recipients, webhook endpoints, third-party API push targets.

Each dimension produces a number. The four numbers together are the agent's blast radius. They're what you put on a slide, what you put in a deployment checklist, and what you defend in a governance review.

The Blast Radius Score Template

Here's the template I have operators run in 10 minutes before any agent ships to production. You can run it as a spreadsheet, a Notion page, or a Jira ticket. It has six fields per dimension and asks one mandatory question at the end.

Step 1: enumerate every tool and every scope

Write down every tool the agent has access to. For each tool, write down the exact scope — the OAuth scope, the API key permission set, the row-level security predicate, the MCP server permissions, whatever the platform calls it. If you don't know the scope, the answer is "everything." Assume the worst until you can prove otherwise. This step alone catches half the over-privileged agents I see, because operators discover they don't know what scope their connector actually requested.

Step 2: for each tool, compute the four dimensions

For each tool, fill out:

• Records reachable (the upper bound, not the typical use): how many objects of the target type could this scope touch in an hour, assuming the agent's rate limits are at maximum?
• Dollar value reachable: what's the maximum dollar value of all the records reachable, plus the maximum dollar volume of any payment/transfer operations?
• PII subjects reachable: how many natural persons' PII does the scope grant access to?
• External recipients reachable: how many distinct external parties could receive a message through this tool in an hour?

Step 3: aggregate across tools

Sum each dimension across tools. The aggregate is your single-agent blast radius. If the agent has Salesforce write (2.8M accounts) and Gmail send (47K recipients) and Stripe charge (\$50K/hour), the aggregate is "2.8M records, \$50K, 47K external recipients, and 2.8M PII subjects (Salesforce accounts include people)." That's the number you defend.

Step 4: ask the one mandatory question

Then you ask the question that turns the score into a decision:

"If this agent made the worst plausible mistake in the next hour, would the answer to 'why didn't you scope it tighter?' be defensible to (a) your CFO, (b) your DPO, and (c) your regulator?"

If the answer is "yes" to all three, you can ship. If the answer is "no" to any, you're not done sizing the scope. There's no middle ground. The CFO question asks "is the financial exposure proportional to the value the agent delivers?" The DPO question asks "is the PII exposure proportional, and have we met our data minimization obligations?" The regulator question asks "could this be construed as deployer negligence under Article 26 if it failed in the worst way?"

The 10-minute version

For operators who don't have time for the full template, here's the 10-minute version: list every tool, write the max records and dollars each can touch, sum, ask the mandatory question. That's the floor. Anything less is hope as a strategy.

Worked Example 1: n8n Agent with Salesforce "Full Access"

Let's run the template on the agent from the lead. The Austin SaaS had built an n8n flow where a model decides which customer success action to take based on email replies. The Salesforce connection used the standard n8n connector with the "full access" OAuth scope because — and this is real, this is what their RevOps lead told me — "we didn't know how to restrict it."

Step 1: tools and scopes

One tool, one scope: full on Salesforce. In Salesforce-land, "full" means every object the connected user can see, with read/write/delete on all of them. The connected user was the RevOps lead, who happened to be a Salesforce admin. So the effective scope was "everything in the entire org."

Step 2: dimensions

• Records reachable: 2.84 million (every Account, Contact, Opportunity, Lead, Case, Task, custom object record in the org). At Salesforce's standard API rate limits — about 10,000 records per minute via Bulk API for an org their size — the agent could mass-update around 600,000 records in an hour. Mass-delete would be slower but still in the hundreds of thousands.
• Dollar value reachable: the Opportunity object alone held \$84M in pipeline. The agent could mass-close-lost every open opportunity, mass-change-amount every closed-won, or mass-reassign owners (which it did, on 2,847 accounts).
• PII subjects reachable: ~1.2M (every Contact and Lead). Email, phone, sometimes home address, sometimes credit card last-four.
• External recipients reachable: zero directly through Salesforce, but the org had outbound email integrations that fire on Account updates, so secondary exposure was non-trivial. We'll mark it 0 for direct reachability and flag the secondary.

Step 3: aggregate

600,000 records modifiable per hour. \$84M in pipeline value reachable. 1.2M PII subjects. 0 direct external recipients (with secondary exposure flagged).

Step 4: the mandatory question

Is it defensible to a CFO that an agent whose job is "update lead status when a customer replies" has the ability to modify 600,000 records in an hour, including the entire pipeline? It is not. Is it defensible to a DPO that the agent has read access to 1.2M PII subjects when its job touches at most a few hundred? It is not. Is it defensible under EU AI Act Article 26 that no log retention or scope binding was in place? It is not.

The right scope

What it should have been: a custom Salesforce permission set with read/write only on the Status and Last_Touched__c fields, only on Lead and Contact records the agent had been given a specific ID for, with a session-level rate limit of 100 records per hour. Blast radius after reshape: 100 records per hour, \$0 dollar value (status changes don't directly affect pipeline), bounded PII (only the records explicitly handed to the agent), 0 external. Same job, 99.99% smaller blast radius.

The reshaped agent is what they deployed in week two after the incident. The week-one version cost them three weeks of sales operations recovery, one terminated vendor contract, and the next quarter's RevOps budget — diverted to a "responsible automation review" that the CEO presented to the board. The blast radius template would have surfaced all of this in a 10-minute review on day one.

Worked Example 2: Lindy Agent with Gmail Send-As

The second example involves an agent built on Lindy — a popular no-code agent platform — given access to Gmail with the send-as permission. The job: route inbound recruiting inquiries to the right hiring manager and respond with availability. The platform's Gmail integration requested https://www.googleapis.com/auth/gmail.send and https://mail.google.com/ (full mailbox access) because that's what the connector's documentation recommended.

Step 1: tools and scopes

Three tools: Gmail send, Gmail read (full mailbox), Calendar read. Scopes: https://mail.google.com/ (which is "do anything with Gmail"), https://www.googleapis.com/auth/calendar.readonly.

Step 2: dimensions

• Records reachable: every email in the mailbox. The owner's mailbox had 184,000 messages going back to 2019, including HR exchanges, legal correspondence, and several years of executive communication the owner had been forwarded into.
• Dollar value reachable: indirect. No direct payment authority, but full read access to legal and HR mail is a serious financial liability if leaked or used as the basis for a fabricated outbound email. Estimate: not zero. Conservative bound: \$500K in potential litigation exposure if a leak occurred.
• PII subjects reachable: the email metadata alone reached every external party the owner had ever corresponded with — roughly 22,000 distinct recipients including 4,000 candidates with full applicant data. The DPO had not been consulted.
• External recipients reachable: with Gmail send rate limits at 2,000 messages/day for Google Workspace, the agent could send to ~83 distinct recipients per hour at the API limit. Practically lower, but the upper bound is what we use.

Step 3: aggregate

184K records readable, \$500K potential exposure, 22K PII subjects, 83 external recipients/hour (and they could be any external email address the agent decided to construct).

Step 4: the mandatory question

Is it defensible that a recruiting routing agent has read access to the CEO's legal correspondence? No. Is it defensible under GDPR (and now Article 26) that the agent has data access disproportionate to its purpose? No. Is it defensible to send arbitrary email to arbitrary recipients under the company's domain? No.

The right scope

Two changes. First, use a dedicated mailbox ([email protected]) with its own Workspace user, scoped to recruiting correspondence only. Second, restrict Gmail scopes to gmail.send (not mail.google.com/) and use gmail.readonly with a label-based filter that limits read to messages tagged recruiting/inbound. Blast radius after reshape: a few hundred recruiting messages, \$0 direct, ~500 candidate PII subjects (still significant but bounded), 83 external recipients/hour (still the rate limit, but now correctly scoped).

The reshape took the team an afternoon. The pre-reshape version was running in production for four months before someone in security asked what its OAuth scopes were. That's the silent risk profile of no-code agent platforms: the defaults are wide because they're optimized for "it works on the first try," not for "the blast radius is proportional to the job."

Worked Example 3: Agentforce Agent with Stripe Write

The third example is on Salesforce Agentforce, the platform Salesforce shipped to GA in 2024-2025 and which by 2026 has become the default agent layer for Salesforce-centric orgs. The agent's job: handle billing inquiries — verify customer identity, look up subscription state, process simple refunds within policy, escalate everything else to a human.

The Stripe integration was via an Agentforce Action wired to the Stripe API. The credential used was a restricted API key with the scopes customers.read, subscriptions.read, refunds.write. So far, so reasonable. The wrinkle: the refunds.write scope in Stripe has no built-in per-call dollar limit. You can refund \$5 or \$50,000 with the same API call.

Step 1: tools and scopes

Three tools: Stripe customers.read, Stripe subscriptions.read, Stripe refunds.write. Plus the underlying Salesforce data the Agentforce flow could read. Plus a CRM update action.

Step 2: dimensions

• Records reachable: Stripe-side, every customer in the Stripe account (52,000) and every active subscription. Salesforce-side, scoped via Agentforce's data binding to records the agent was working a Case on. Cross-system reach.
• Dollar value reachable: the Stripe rate limit for the standard API tier is 100 requests/second. The agent could issue a refund every 10ms in a worst-case loop. At a hypothetical \$500 average refund, that's \$18M/hour. The actual MRR running through the account: \$8.2M/month. So the agent could refund several months of revenue in an hour at the upper bound — practically, much less, but the theoretical upper bound is what blast radius asks for.
• PII subjects reachable: 52,000 Stripe customers, plus the Salesforce contacts in scope.
• External recipients reachable: zero direct via Stripe; CRM updates can trigger emails.

Step 3: aggregate

52K records, \$18M/hour theoretical refund exposure, 52K PII subjects, 0 direct external recipients. The number that should make you sit up: \$18M/hour.

Step 4: the mandatory question

Is \$18M/hour of refund authority defensible for a billing inquiry agent? Almost certainly not. Even at a fraction of the upper bound — say, the practical 1 request/second the agent would actually hit — that's \$1.8M/hour. Still not defensible.

The right scope

Stripe has a feature called "Restricted API Keys with custom scopes," but it does not let you set a per-key dollar limit on refunds. The fix has to be implemented at the application layer: wrap the refund tool in a function that enforces (a) maximum refund amount per call (e.g., \$200), (b) maximum total refund volume per hour per agent session (e.g., \$1,000), (c) hard escalation above the limit. This is exactly the pattern Agentforce supports via Action wrappers in Apex or via an external service.

The right scope sized the blast radius from \$18M/hour to \$1,000/hour — a 18,000x reduction — without changing the agent's job. The agent still handles refunds. It just can't accidentally refund every customer at once. The CFO can sleep.

Patterns for Shrinking Blast Radius

The three examples above show three flavors of blast radius reduction. Generalized, here are the patterns operators apply most:

Pattern 1: scope to the smallest field set, not the smallest object

Most platforms let you scope by object type ("agent can write to Account"). Few default to scoping by field ("agent can write only to Status and Last_Touched__c on Account"). Where the platform supports field-level security, use it. The blast radius difference between "can update any field on Account" and "can update two named fields on Account" is enormous.

Pattern 2: time-bounded, rate-limited tokens

OAuth tokens and API keys with short lifetimes and rate limits are far less dangerous than long-lived unlimited ones. A token good for one hour and 50 calls is a much smaller blast radius than a token good for a year and unlimited calls. Many platforms support this natively; few operators use it because it's slightly more work.

Pattern 3: value caps in the application layer

When the source system can't enforce dollar caps (Stripe refunds, NetSuite journal entries, large outbound transfers), enforce them in the agent's tool wrapper. The wrapper rejects calls above the cap and either escalates or denies. This is how every disciplined Agentforce, Lindy, or n8n deployment I see actually handles money in 2026.

Pattern 4: separate identities for separate agents

Don't share OAuth tokens or API keys across agents. Each agent gets its own credential with its own scope. When an agent misbehaves, the blast radius is bounded to that credential's scope, and the credential can be revoked without affecting other agents. Many no-code platforms make this difficult; insist on it anyway.

Pattern 5: human-in-the-loop above the threshold

Define a threshold per dimension above which a human must approve. \$500 refund? Auto. \$5,000 refund? Human approves. Bulk update of 10 records? Auto. Bulk update of 1,000? Human. The threshold reduces effective blast radius by routing the dangerous tail to human review. The Kiteworks 2026 survey found 41-44% of enterprises run agents with no HITL anywhere in the flow — this pattern is the cheapest way out of that statistic.

Pattern 6: dry-run and shadow modes

Run the agent in shadow mode (it computes what it would do but does not actually write) for the first weeks of deployment. Compare its proposed writes against what humans would have done. This doesn't shrink blast radius for the production flow, but it gives you visibility into what the blast radius would have been before you give it write permission. Most platforms support this with a simple flag.

Blast Radius in the EU AI Act Era

Starting August 2, 2026, EU AI Act Article 26 deployer obligations are binding. The Article 26 requirements include human oversight, log retention (six months minimum), and — for Annex III high-risk systems — a Fundamental Rights Impact Assessment (FRIA). Blast radius is the operator-facing translation of several of these requirements.

Consider: when a regulator asks "what oversight did you have?", the defensible answer is "we sized the agent's blast radius before deploy, scoped its permissions proportionally to its job, set a HITL threshold for high-impact actions, and retained six months of execution logs." When a regulator asks "what did you do to ensure data minimization?", the defensible answer is "we restricted the agent's PII reach to the records its job required." When a CFO asks "how did this much get refunded?", the defensible answer references the cap that should have been in place.

The blast radius score is not just an engineering artifact. It is a governance artifact. It's what you show the auditor. It's what you put in the FRIA. It's what you defend in the post-incident review. An agent without a documented blast radius is an agent without governance, regardless of what the platform vendor calls it.

When Blast Radius Grows Silently

One last warning. Blast radius is not a static measurement. It grows as the source system grows. The Salesforce agent that had 2.8M records reachable in 2026 will have 4M in 2028. The Gmail agent that could reach 22K external recipients will reach 50K once the team scales. Permissions you granted in year one have a wider blast radius in year three.

Re-score periodically. Quarterly is a reasonable cadence. Trigger a re-score when: the source system grows by more than 25%, a new tool is added to the agent, the agent's prompt changes substantially, or any incident occurs. The score is cheap to compute. The cost of not re-scoring is what got the Austin SaaS in trouble — their agent's scope had been "fine" when the org had 200K records, and it was still "fine" on paper when the org had 2.8M records, except now "fine" meant something very different.

The Question to Ask on Day One

The single question operators should be able to answer about any agent on the first day of deployment:

In the next hour, what is the worst this agent could do — to records, to dollars, to PII, to external recipients — and is that proportional to the value it delivers?

If you can't answer with numbers, you don't know the blast radius. If you can answer with numbers and the numbers are uncomfortable, you have a scoping decision to make. If you can answer with numbers and the numbers are comfortable, you have done the work that makes the rest of agent governance possible. The other lessons in this chapter build on this one. There is no shortcut.

The blast radius of an agent is what it can do by design, regardless of whether the design was sound. The discipline is to size it before deploy, not after the breach.

Key Takeaways

• Blast radius is the worst-case impact in the next 60 minutes of operation, measured in records, dollars, PII subjects, and external recipients. It's a quantified vector, not a vibe.
• An agent's blast radius is what it can do by design, not only when compromised. Hallucinated tool calls, loops, and chained writes can cause damage in normal operation.
• The 10-minute template: enumerate every tool and scope; compute the four dimensions per tool; aggregate; ask the CFO/DPO/regulator question.
• The n8n Salesforce "full access" example: 600K records/hour, \$84M pipeline reachable, 1.2M PII subjects. Real cost: 2,847 accounts mass-mis-owned. The right scope cut blast radius by 99.99%.
• The Lindy Gmail send-as example: full mailbox access exposed 184K messages and 22K PII subjects to a recruiting bot. The right scope (dedicated mailbox, narrow Gmail scopes) cut exposure dramatically.
• The Agentforce Stripe refunds example: \$18M/hour theoretical refund exposure with default refunds.write scope. Application-layer caps (\$200/call, \$1,000/hour) reduced it 18,000x without changing the job.
• Six reduction patterns: field-level scope, time-bound rate-limited tokens, application-layer value caps, separate identities, HITL thresholds, shadow/dry-run modes.
• Under EU AI Act Article 26 (binding Aug 2, 2026), the blast radius score is the operator-facing translation of human oversight, data minimization, and log retention obligations. It's a governance artifact, not just an engineering one.
• Blast radius grows silently as the source system grows. Re-score quarterly and on every material change.
• The day-one question: In the next hour, what is the worst this agent could do, and is that proportional to the value it delivers? If you can't answer with numbers, you don't know.