Key Points
- Some SSPM/DSPM tools operate with “god-mode” access to your cloud and data.
- Over-permissioned tools can silently duplicate secrets to vendor infrastructure.
- A hijacked token or vendor breach can expose your entire SaaS estate.
- Logs show one DSPM crawler accessed 20,000+ secrets/day while security teams were none the wiser.
- Learn how to mitigate these risks and monitor your security tools’ behavior.
The Hidden Danger of Over-Permissioned Posture Tools
By the time the alarms go off, it’s often too late. A trusted third-party security tool, one that promised to protect your cloud and SaaS environments, has been operating with unchecked ‘god-mode’ privileges. These tools, usually classified as SaaS Security Posture Management (SSPM) or Data Security Posture Management (DSPM), have been granted near-unrestricted access to your data, configurations, and secrets. In theory, that access helps find vulnerabilities before the bad guys do. In practice, it can become the ultimate insider threat. This dramatic opening isn’t fiction. It’s drawn from real incidents that have kept CISOs awake at night.
What are SSPM and DSPM? Two Critical Tools with Hidden Risks
Think of SSPM as the overachiever in your security stack. It plugs into all your SaaS applications and flags what’s misconfigured, overexposed, or noncompliant. It combs through Google Workspace, Microsoft 365, Salesforce, and Slack—the usual suspects—looking for “uh-oh” moments, like open sharing links, inactive MFA, or overly generous permissions.
Then there’s DSPM, the deep diver. It scans your data lakes, cloud buckets, Snowflakes, BigQuerys, and everything in between to find where your sensitive data is hiding and who’s poking at it. Secrets, API keys, PII, customer records: if it looks sensitive, DSPM wants to classify it, map it, and track how it moves.
On paper? A dream. One dashboard to rule them all.
Trusted but Risky: The Friendly Guardian with a Skeleton Key (and a Grin)
Picture this: you bring in a shiny new SSPM or DSPM platform to “guard” your SaaS apps and data stores. To do its job, you hand it a skeleton key that includes API tokens and integration credentials with broad scopes, sometimes with all-access read rights across multiple systems. Password vaults, cloud storage buckets, internal wikis, even your password manager: nothing is off limits. The vendor calls it “holistic visibility.” Security engineers might joke it’s like inviting a vampire into your house (with your full permission). And they’d be right.
The humor fades when you realize this friendly guardian now has a copy of every secret it was supposed to protect.
In one recent case, Mitiga investigated an over-permissive DSPM integration that inadvertently pulled sensitive secrets from an internal vault and a corporate password manager, duplicating the organization’s crown jewels into the vendor’s cloud database. All of this happened silently, under the radar of SecOps. After all, the tool’s activity was legitimate by design, quietly indexing and replicating sensitive data without tripping a single alarm.
God-Mode in Plain Sight: Why Over-Permission Goes Unseen
These security posture tools often operate with “god-mode” access. It’s the kind of deep, API-level control that would even make an admin blush. They can read configurations, pull data for indexing, and move across systems using service accounts that don’t trigger MFA or user notifications.
Even well-meaning vendors sometimes request overly broad OAuth scopes “just to be safe,” granting far more privilege than necessary. The result in an all-seeing, all-knowing process running quietly in the background. It looks so normal, your SOC analysts likely never give it a second glance.
There’s a dark irony here. The very tool you brought in to reduce risk could also be the perfect low-and-slow data siphon. While it reports on misconfigurations and exposures, it might also be stockpiling sensitive data in a location you don’t control. It’s the classic fox-guarding-the-henhouse scenario, except this fox was handed a map, a badge, and the keys to every coop.
When “Trust” Becomes a Single Point of Failure
All this godlike access turns one integration into a single, terrifying point of failure. If a SSPM or DSPM token leaks, or the vendor itself gets compromised, an attacker instantly inherits deep, privileged access to your environment.
This isn’t theoretical. Industry history is replete with warnings. Mitiga has seen attackers use stolen OAuth tokens from one breached vendor to pivot into another company’s SaaS environment, stealing source code and internal documents in the process.
Consider the cautionary tale of the Snowflake data breach. With one set of credentials, cybercriminals accessed hundreds of organizations’ databases and exfiltrated millions of records. What started as a stolen token avalanche turned into one of the biggest data heists of 2024: up to 165 companies had their Snowflake-hosted data dumped and sold on dark web forums.
The lesson’s clear: when a trusted conduit goes rogue, the fallout doesn’t stay contained. It’s like handing over the keys to multiple kingdoms and watching them all fall overnight.
Worse, a compromise at the SSPM or DSPM vendor itself could act like a supply chain atomic bomb. These tools sit deep inside customer environments, often with admin privileges. A vendor-side breach lets attackers quietly ride that trust into every client network.
It’s the ultimate stealth infiltration. The attack comes through the very security tool that organizations rely on, bypassing a lot of traditional defenses because it originates from a known-good service. Security teams are increasingly wary of this god-mode double-edged sword, especially after witnessing real-world fallout from third-party breaches.
Real-World Incident: When SSPM becomes a data broker
One real incident Mitiga handled recently drove this risk home. A mid-size tech firm had deployed a SaaS posture management solution to audit its cloud services. Everything looked fine. That is, until a routine review uncovered an unusual amount of data in places it didn’t belong.
The SSPM tool, thanks to an overbroad integration scope, had been pulling data from a secure database and a secrets vault, then storing those records on the vendor’s servers for “analysis.”
If you’re the SecOps team, here’s what that means:
- Your security tool has essentially become a shadow data broker.
- It quietly copied sensitive customer information and credentials outside your control.
- The integration wasn’t just checking configurations. It was exporting full records.
There was no attacker involved, but the stage was set for disaster. One leaked token. One compromised vendor account. And that cache of internal secrets would have been open season for any hacker savvy enough to find it.
This wasn’t an outlier. The scenario followed the pattern of other high-profile incidents. The Snowflake attack mentioned earlier proved how fast a single compromised integration or account can escalate into a multi-organization catastrophe. If a malicious actor had similarly piggybacked on our client’s SSPM tool, it might have taken weeks (or worse) to detect. Many Snowflake victims didn’t realize their data was siphoned away until it appeared on dark web markets. (Read our coverage and support for this attack for a tactical guide to threat hunting in Snowflake environments.)
Illusion of Safety: When security tools create new risks
It’s a paradox security teams have to wrestle with: the tools you deploy to safeguard data can introduce new attack paths. Over-permissive posture management tools create a false sense of safety. You think your SaaS sprawl and data stores are under control, while an unseen risk is growing in that comfort’s shadow.
The intent of SSPM and DSPM is solid: spot misconfigurations, flag overexposed data, and enforce best practices. But when a tool operates with near-omniscience, it’s fair to ask: Who watches the watchers?
If the answer is “no one, really,” every extra permission becomes a potential time bomb.
Modern enterprises have started to catch on. Sharp CISOs ask questions about least privilege and demand to know exactly what data is stored or indexed off-premises. Some forward-leaning teams add detective controls to monitor their own security tools, essentially putting a baby monitor on the watchdog.
That’s good practice, but it’s still not common. Too many organizations still blissfully assume that a security tool is inherently safe because it’s labeled “security.” That assumption is exactly what attackers would love to exploit.
Lessons from a Real-World Event: Detecting Overreach with Logs and IOAs
Let’s bring it all together. In a recent investigation, Mitiga tracked how an over-permissive DSPM token was hijacked to siphon source code from several SaaS tenants. The raw log API calls revealed exactly how it happened and the exact indicators that went unnoticed in real time.
What started as 500 “server-fetch” events per day escalated to more than 20,000. The crawler had mapped every vault, and accessed every secret, much to the shock of the security team. And no one flagged it. Because everything looked like normal tool activity.
from pyspark.sql.functions import col, count
result_df = (
df
.filter(
((col('event_name') == "server-fetch") | (col('event_name') == "reveal")) &
((col('user_name') == 'SSPM_USER') | (col('user_name') == 'DSPM_USER'))
)
.groupBy('date')
.agg(count('*').alias('trigger_count'))
.orderBy('date')
)
display(result_df)A code snippet to count download events grouped by date using PySpark, with Pandas used to generate a visualization of the trend.
The logs told the story. A massive spike in fetch activity. A service account repeatedly pulling secrets. All hidden inside the assumed-safe behavior of a posture management tool.
IOA - Technical Details
To detect a malicious behavior regarding an IOA, you first need to understand what a standard “itemusage” log looks like in a SaaS platform:
{
"uuid": "56YE2TAB2VFYRLNSHKPW5NVT5E",
"timestamp": "2025-06-11T16:32:50-03:00",
"used_version": 0,
"vault_uuid": "VZSYVT2LGHTBWBFGUJAIZVRABM",
"item_uuid": "SDGD3I4AJYO6RMHAD8DYVNFIDZ",
"user": {
"uuid": "4HCGRGYCTRQFBMTREGTABYDU2V",
"name": "USER USERI",
"email": "USER_EMAIL@COMPANYNAME.com"
},
"client": {
"app_name": "APPNAME",
"app_version": "20127",
"platform_name": "Chrome",
"platform_version": "93.0.4577.62",
"os_name": "MacOSX",
"os_version": "10.15.6",
"ip": "13.227.95.22"
},
"action": "reveal"
}The vault_uuid alone doesn’t have any significance for us. But when you see repeated “reveal” or “server-fetch” actions on a high amount of different (unique item_uuid) items in a short period, that’s a red flag.
While aggregating these logs, you can start to see patterns in client behavior. The logs capture key attributes: what action was taken, the performing users, when the actions occurred, and from which device.
To detect abnormal activity, you need to group the logs by user, device, and time window. From there, look for anomalies and malicious behaviors when looking at all actions that took place in a given time window. A high number of item accesses in a short period may be a strong indicator of misuse.
The type of correlation is essential. On their own, these actions can look legitimate. Only when viewed together do anomalies and malicious behaviors start to emerge.
Modeling Suspicious Vault Access With Pseudo-Code
The following pseudo-code models how to identify suspicious access by grouping log events.
In using this pseudo-code function, we aggregate actions on unique items – aggregating with a set collection based on an item_uuid – and then filter according to a minimum count defined as a “suspicious” amount of password reveals.
This approach surfaces what might be considered overreach by trusted tools or accounts that otherwise appear legitimate. We asses the severity according to the number of passwords revealed or fetched. It’s an effective method to detect low-and-slow scraping that doesn’t trigger traditional alerts.
POC Simulation: Enhancing Threat Detection
To validate this detection logic, the Mitiga team simulated an event of revealing all the keys from a vault after getting regular user credentials.
Using the simulation, we scaled a crawler to fetch and reveal simultaneously hundreds to thousands of items.
This simulation enabled us to test and sharpen the accuracy of our threat detection regarding suspicious behavior of accounts (and service accounts) in our clients’ environments.
Mitigation Checklist: Lock down Over-Permissive Tools
If you’re using SSPM or DSPM platforms, or evaluating one, these controls can reduce the risk of overreach:
- Grant per-app, per-tenant scopes
Avoid global read permissions. For example, in Microsoft 365, use Sites.Selected and list only the two SharePoint sites that hold SaaS configuration exports, instead of the default Sites.Read.All. In Google Workspace, limit drive.metadata.readonly to the Security-Audit OU, not the full domain. - Block write/admin APIs
Many posture tools ask for write access to enable auto-remediation. Unless explicitly required, deny *.write, Admin.*, s3:PutObject, graph.microsoft.com/…/update, and equivalent permissions. The tool can still report misconfigurations without being able to change anything. - Monitor for scope drift and credential spread
Set alerts if the vendor OAuth app suddenly gains new scopes, appears in a new workspace, or its call volume jumps. Treat scope inflation like privilege escalation. - Time-box discovery runs
Use expiring tokens with scheduled scans (e.g., 02:00–04:00) and hand the connector a token that lives only for that window. Outside those two hours, the credential is invalid, so a stolen key is worthless. - Don’t assume trust equals safety
Just because a tool is labeled “security” doesn’t make it safe. Audit it like any third-party integration with elevated access.
The Time to Audit Your Posture Tools
Security tools should reduce risk, not create new ones. As posture management platforms become more deeply embedded across SaaS and cloud environments, the blast radius of a single misstep grows. Over-permissioned integrations, silent data replication, and unmonitored API activity are all avoidable risks. But only if teams stop assuming trust is a control. The best time to audit your posture tools was yesterday. The second-best time is now.
Want to know if your security tools are over-permissive?
Mitiga can help. Contact us now.
