5 SSPM Coverage Gaps a SaaS Security Platform Leaves Open

5 SSPM Coverage Gaps a SaaS Security Platform Leaves Open

Your SSPM dashboard is green. Your OAuth grants are reviewed, your tenant configs are clean, and your AI agent inventory is current. Then a contractor uploads a customer list to WeTransfer from a personal browser profile, and none of it shows up anywhere. That's not a bug. That's one of five SSPM coverage gaps that come standard with a SaaS-layer view.

It's a description of where the product is looking, not a failure of it. A SaaS security platform watches the SaaS layer, and it usually watches it well. Data doesn't respect the boundary. Here are five paths it takes that a SaaS-layer view was never built to see.

When Obsidian Security is the right purchase

Start with the cases where you should write the check. If your third-party app estate is wide, Salesforce and ServiceNow and Snowflake and Databricks and Workday and a few dozen more, Obsidian connects to 200+ enterprise applications and sees inside them. Nobody covers that spread by hand.

Buy them when identity is the live threat. Obsidian publishes SaaS ITDR, account takeover prevention, access violations, and excessive privilege management, correlated in a Knowledge Graph that maps identity and activity across SaaS apps, browsers, and identity providers. If your last two incidents both started with a session token or an over-privileged admin, that's the surface you need, and it isn't one we compete in.

Buy them when you build with AI. Agent visibility, agent governance, agent runtime security, MCP security, and AI-SPM across Amazon Bedrock, Microsoft Foundry, Google Vertex AI, OpenAI, Copilot, and Salesforce Agentforce is a real surface, and their announced integration with Anthropic's Claude Compliance API extends it. A platform team spinning up agents with standing access to production data has a governance problem today, and Obsidian is built for it.

What they don't sell is a secure web gateway, an on-device proxy, or a URL filtering and anti-malware product. That's a deliberate scope, not an oversight. So everything below is a stack-design question. You're not looking for a product that failed. You're looking for the layer nobody bought.

1. The upload to a site that isn't an app

The scenario. A sales engineer needs to get a 400 MB customer data export to a partner. Email bounces it for size. So they open WeTransfer, drag the file in, type the partner's address, and hit send. Ninety seconds, problem solved, no policy consciously broken.

Why the SaaS-layer view misses it. WeTransfer isn't a connected application. There's no OAuth grant, no tenant, no API to poll, no audit log to ingest. The file never entered Microsoft 365 or Google Workspace, so no SaaS platform has a record of it. From the SaaS layer, this event does not exist. It isn't suppressed or deprioritized. There's nothing to suppress.

What covers it. Inspection on the path itself. dope.SWG runs the full gateway on the device, so SSL inspection and break/inspect happen locally rather than after a trip to somebody's data center. Dopamine DLP sits inside that on-device proxy and reads the contents of the upload while it's still moving, with an LLM doing the classification and no regex behind it. In Block mode, the upload doesn't complete. The engineer gets a Dopamine explanation in plain language telling them why, and the event forwards to your SIEM. Nobody had to predict WeTransfer in advance, which is the part that matters, because the next one won't be WeTransfer.

2. The file that leaks without ever moving

The scenario. A project manager flips a Drive folder to "anyone with the link" so a contractor can pull one document, then drops the link into a shared channel. Eight months later the contractor is long gone, the channel has forty people in it, and somebody has added a spreadsheet of patient records to the same folder. Nothing was ever uploaded. Nothing moved.

Why the SaaS-layer view misses it. Posture management asks configuration questions: is external sharing permitted, is this account over-privileged, did someone change a setting they shouldn't have. Here, nothing is misconfigured. Link sharing is a setting you deliberately allow, and the person who used it was entitled to. The missing piece isn't a permissions finding. It's knowledge of what sits inside the file at the end of that link.

What covers it. CASB Neural, which treats data at rest as a classification problem instead of a configuration one. It's LLM-powered DLP for Microsoft 365 and Google that scans OneDrive and Google Drive for publicly or externally shared files containing PII, PCI, PHI, or IP. No configuration is required to start it. It shows you what's exposed and exactly who has access, gives you one-click remediation to make a file private again, and monitors file-sharing changes continuously, so the next link doesn't sit unnoticed for eight months. Posture tells you the door is unlocked. This tells you what's in the room.

3. The file dragged into personal webmail

The scenario. Someone is leaving. Their last week is quiet, and one afternoon they open personal Gmail in a tab next to the corporate one, attach four files from their desktop, and send them home. Nothing about it looks unusual in a log. It's a browser tab and an attachment.

Why the SaaS-layer view misses it. This is the personal-tenant problem again, but with a sharper edge, because the destination provider is one you almost certainly do have connected. Your Google Workspace integration sees your tenant. It doesn't see a consumer Gmail account that happens to share a login page. The corporate audit log records nothing because the corporate account wasn't involved. The files came off local disk, not from Drive.

What covers it. The upload itself is the only reliable place to catch this, and the upload happens on the device. Dopamine DLP inspects it there, with per-policy DLP, exceptions for specific users or groups, and bypass lists including dope-managed bypasses so the false-positive tax stays low. Cloud Application Control handles the tenant side, keeping the personal Google login off the device entirely. The same pairing covers the personal ChatGPT paste: CAC turns away the consumer login, and Dopamine DLP reads the prompt on the approved path. Neither one requires you to know in advance which sites to worry about, which is the part that makes list-based approaches fail.

4. The malicious site with no SaaS in the story

The scenario. A finance clerk clicks a link in a convincing invoice email. The page is a credential harvester with a lookalike domain registered eleven hours ago. Or it's a legitimate site serving a malicious payload through a compromised ad network. Either way, the user never signs into a SaaS app.

Why the SaaS-layer view misses it. There's no application here at all. No OAuth, no tenant, no configuration to be posture-managed. A SaaS security platform might eventually detect the consequence, an account takeover attempt against your identity provider, for instance, and detecting that is genuinely valuable. But it detects the aftermath. The initial visit, the download, and the payload execution all happen on a path the SaaS layer has no window into.

What covers it. This is the oldest job in the stack and it still needs doing. dope.SWG handles URL filtering and anti-malware inline, on the device, before the page renders and before the file lands. Policy changes push in seconds rather than the 30 to 60 minute polling cycles legacy gateways run on, which matters when a domain goes bad in the middle of a workday. There's a fallback mode with cached policies so protection holds if connectivity drops, and SSL error notifications surface traffic broken by certificate pinning so admins can create bypasses in a few clicks.

5. The unmanaged browser and the device off the network

The scenario. A developer installs a second browser for a project and never enrolls it in anything. A regional manager works a week from a hotel, never touching the corporate network. A contractor is on a laptop your MDM has never seen. All three are working, and all three are outside whatever coverage assumptions your tooling makes.

Why the SaaS-layer view misses it. Browser telemetry is real and useful, and Obsidian names it as one of four data sources alongside third-party app and AI configs, user activity, and real-world threat signals. Telemetry is also bounded by definition: it reaches the browsers and devices it reaches. Network-anchored controls have the same property in a different shape, since they stop applying the moment the user leaves the network. Ask any vendor, including us, to show you where the edge of their coverage sits and how you would see it in the console.

What covers it. Move enforcement to the device and the network stops being the control point. dope.security runs a lightweight agent, dope.endpoint, that does SSL inspection and policy enforcement locally, with traffic flying direct to the internet instead of backhauling to a data center. It's Mac native plus Windows, under 100 MB RAM, and up to 4x faster than legacy proxy gateways. It works in China and other restricted geographies where backhauling gateways struggle. The hotel room, the airport, and the second browser nobody enrolled all get the same policy, because the policy lives where the traffic starts. The honest limit: a device with no agent still needs an access decision of its own. A Fortune 100 rollout moved at roughly 3,000 devices a week on that model.

Where each SSPM coverage gap actually closes

GapWhy the SaaS layer misses itWhat covers it
Upload to a non-app siteNo tenant, no API, no logdope.SWG plus Dopamine DLP on the upload
Over-shared file that never movesNothing is misconfiguredCASB Neural, content scan plus one-click fix
File into personal webmail or personal AIConsumer account, same providerDopamine DLP on the upload, CAC on the login
Malicious siteNo application involveddope.SWG URL filtering and anti-malware
Unmanaged browser or off-network deviceCoverage is bounded by inputOn-device enforcement via dope.endpoint

This is a stack question, not a scoreboard

The mistake isn't buying a SaaS security platform. It's assuming the purchase covered the whole path.

Data leaves through the gateway, the endpoint, the tenant login, and the AI prompt. dope.security covers all four in one console with one agent: dope.SWG, Dopamine DLP, CASB Neural, AI-Powered SSPM, and Cloud Application Control. That's the argument. Not that anyone else is doing their job badly, but that their job was never the whole path.

Close the gaps

Pick the scenario above that made you wince and ask who in your current stack owns it. If the answer is nobody, book a 20-minute demo or try dope.security free. We'll show you all five closing in the same console.

CASB
CASB
Shadow IT
Shadow IT
Data Loss Prevention
Data Loss Prevention
back to blog Home