We've written before about shrinking the blast radius of a social engineering attack — the idea that you may not be able to stop an attacker from tricking one of your agents, but you can absolutely limit what they walk away with once they're in.
The ServiceNow incident disclosed in June 2026 is a reminder that the agent isn't the only thing that can fail. Sometimes a security vulnerability or insecure configuration in the platform itself is the breach.
What Happened
In early June 2026, ServiceNow disclosed a security incident in which unauthenticated users could, in certain circumstances, gain greater access to ServiceNow instances than intended. ServiceNow applied a security update to hosted customer instances on June 5, 2026, and confirmed that for a subset of customers it observed evidence of successful queries of instance tables.
According to public reporting, the root cause wasn't an exotic zero-day or a stolen password. It was a configuration problem: a ServiceNow API endpoint (/api/now/related_list_edit/create) was reportedly set with authentication disabled by default, meaning requests could reach data without the authentication controls administrators would expect for an API handling business records. There are also reports that the underlying issue was known internally since April before it was prioritized, and ServiceNow has since attributed at least some of the observed activity to security researchers rather than malicious actors.
The attribution debate is almost beside the point. Whether the traffic came from criminals or curious researchers, the architectural fact is the same: for a window of time, sensitive data sitting inside ServiceNow instance tables was reachable by someone who never authenticated. No phishing email. No social engineering. No compromised employee. Just a misconfigured endpoint and a query.
This Is a Different Kind of Failure
Most of the recent breach stories start with a human being getting tricked. An attacker socially engineers their way into an agent's account, inherits that agent's access, and pulls down whatever sensitive data has been quietly accumulating in tickets and case records.
The ServiceNow incident skips the human entirely. The platform you trusted to hold your data became the weak link on its own. And that raises an uncomfortable question that no amount of security awareness training will answer:
If the platform itself is queried directly, what does an attacker actually get?
Think about what's sitting in your support and ITSM records right now. HAR files uploaded by customers for debugging — which routinely contain session tokens, cookies, and authorization headers. API keys pasted into a comment. Debug logs. PII. Health data. Government IDs. Screenshots full of account details. This data accumulates for months or years, and most organizations have no idea how much of it is one misconfigured endpoint away from exposure.
That's your blast radius — and a platform-level flaw is the scenario where it matters most, because every traditional control that depends on identity (least privilege, MFA, agent permissions) is bypassed when the access never required a login in the first place.
How SendSafely Contains a Platform-Level Breach
This is exactly the failure mode SendSafely is built to help reduce the blast radius. The core principle: a breach of the platform should not equal a breach of your most sensitive customer data. Two capabilities do the heavy lifting here, and they're effective precisely because they don't rely on the platform's own access controls holding up.
1. The sensitive data is end-to-end encrypted. SendSafely encrypts files end-to-end on the sender's device before they ever leave it. No one in the middle — not the support platform, not your vendor's broader ecosystem, not SendSafely itself — can read the contents.
2. The sensitive information was never in the platform to begin with. All data protected by SendSafely is not stored within the targeted platform. The encrypted packages are stored either by SendSafely, or by the customer themselves in their own AWS S3 cloud storage. An endpoint that queries ServiceNow — or Zendesk, or Salesforce — instance tables comes up empty, because the sensitive data your customers shared was never stored there. You can't exfiltrate what isn't present.
Layered on top of those two, the rest of the SendSafely model keeps the blast radius small no matter how the failure starts:
- Automated data expiry and deletion you control. Data that doesn't exist can't be queried, leaked, or held for ransom. Expiration policies stop sensitive files from sitting in your environment indefinitely the way they did at the companies that ended up in the headlines.
- Just-in-time, file-level access. Agents get access to a file when a case is assigned and lose it when the case closes or is reassigned. Always-on, all-agent access is the thing that turns one compromise into a full-scale breach.
- IP restrictions. Even valid, stolen credentials or session tokens are useless from outside your approved network — so a token lifted off a compromised machine can't be replayed from attacker infrastructure.
- Keeping sensitive data out of AI. As support platforms lean harder on AI agents, SendSafely's HALO product keeps the encrypted file exchange out of the AI layer entirely, so a manipulated or prompt-injected agent can't expose what it was never permitted to touch.
The Same Lesson Applies Far Beyond ServiceNow
We're using ServiceNow as the example because it's recent and well-documented, but nothing about this is specific to one vendor. Zendesk, Salesforce, Jira, Freshdesk, Intercom — every platform that centralizes business data is, eventually, going to have a bad day. A misconfigured endpoint, a flawed release, a vulnerable integration, a credential-stuffing campaign. The list of ways a platform can fail only grows.
The question worth asking isn't "is my SaaS vendor secure?" It's "when my SaaS vendor has an incident, does my most sensitive customer data go with it?"
With SendSafely, the answer is no. The sensitive files aren't in the platform, and even if they were, they're encrypted with keys the platform never holds. A flaw in the platform stays a flaw in the platform — not a disclosure of your customers' HAR files, IDs, and health data.
The Bottom Line
The ServiceNow incident wasn't caused by a sophisticated, unstoppable adversary. It was a configuration setting that left an endpoint open, and data that happened to be sitting right behind it. The organizations most exposed are the ones treating their support and ITSM platforms as the safe, permanent home for sensitive files.
For any team running Zendesk, Salesforce, Jira, Freshdesk, ServiceNow, or Intercom workflows that touch sensitive data, SendSafely is the architecture that ensures a breach of the platform isn't a breach of your data.
SendSafely Halo: The Trust Layer Between Your Data and Your AI Stack
Want to see how SendSafely contains the blast radius of an attack on your ServiceNow environment? Contact us at sales@sendsafely.com or schedule a live demo.
