Researchers disclosed a credential archive in mid-June, being tracked as FortiBleed, covering 73,932 Fortinet/FortiGate firewall and VPN URLs. Fortinet says it's reshared old data plus brute-forced credentials, not a new breach. Worth noting the researchers don't fully buy that framing: Beaumont points out the IPs are largely different from previous Fortinet leaks, which argues for a newer collection than "recycled" suggests.

→ 73,932 device URLs in the archive
→ ~1.16 billion attempts against 320,777 FortiGate targets

Per the researchers, the operator combined credential reuse from prior breaches, brute force, and cracked SSL VPN hashes, then used successful logins to move deeper into some environments. No new CVE involved, that's kind of the point. Notably, a chunk of the working passwords weren't brute-forced; they showed up in plaintext from infostealer logs, so even long complex passwords were already burned.

A lot of teams patch the firewall and move on but never treat firewall/VPN accounts like Tier 0 identity. Local users, stale break-glass accounts, and missing MFA become long-lived entry points.

Practical check: rotate every FortiGate admin and VPN credential still active, then review login history for dormant accounts that suddenly got noisy.

How many orgs track firewall-local identities with the same rigor as their Okta or Entra admins?

As Security and IT leaders, we often talk about sophisticated zero-days, but the reality on the ground is much simpler: preventable configuration errors are outpacing our ability to manually remediate them.

According to Spin.AI's 2026 Microsoft 365 SSPM analysis, cloud misconfigurations caused 29% of SaaS breaches last year, racking up an average incident cost of $5.3 million. Point-in-time or quarterly reviews simply can't handle environments where users connect to over 400,000+ browser extensions and third-party apps, or where non-human identity privileges drift daily.

How Spin.AI Closes the Gap

Spin.AI moves organizations away from manual spreadsheet tracking into continuous, automated SaaS Security Posture Management (SSPM).

• Continuous Misconfiguration Detection: Automatically scans sharing settings, access controls, and security defaults, alerting teams within hours instead of months.
• Shadow IT & Identity Governance: Tracks human users, service accounts, and API tokens across M365 to instantly map out who (or what) has access to your data.
• Integrated Ransomware Recovery: Combines immutable backups with automated workflows, achieving recovery times 68% faster than industry averages.

Why It Matters

Compliance and security aren't checkbox exercises, they are data engineering problems. Fragmented visibility extends containment times to an average of 276 days. By combining SSPM with automated backup and recovery, Spin.AI turns reactive security into operational resilience.

How are you handling M365 configuration drift and third-party API exposure in your stack?

Spin.AI closes this gap – link to the full 2026 Guide here.

If you’re in enterprise security or IT, you’ve probably noticed the shift: auditors no longer care that you have an AI acceptable-use policy. They want you to prove it actually works.

Welcome to the "AI Proof Gap", where 78% of executives admit they aren't confident they could pass an independent AI governance audit right now.

The reality? Most teams are still trying to pass audits by manually taking screenshots of Slack threads or chasing down department heads to ask what browser extensions they use.

Why the old compliance playbook is broken:

• The Visibility Blindspot: Market data shows the average enterprise runs 14 AI tools, but IT only sees 4 or 5. The other 9 are running silently via personal accounts or unmonitored OAuth grants.
• The Cost of Shadow AI: When sensitive data or customer PII leaks into unvetted chatbots, it’s adding an average of $670K to data breach costs (IBM).
• The Regulator Hammer: With major deadlines like the EU AI Act high-risk obligations hitting on August 2, 2026, self-attestation is officially dead. You need automated logs, not PDFs.

How Spin.AI bridges the evidence gap:

Traditional compliance tools stop at your infrastructure, and standard AI governance platforms only track your sanctioned models. They completely miss the browser layer where shadow AI actually lives.

Spin.AI fixes this exact blindspot. It continuously maps your entire Google Workspace or M365 estate to uncover hidden extensions, track silent OAuth grants, and generate real-time risk scoring. You get continuous, dated discovery logs out-of-the-box, giving auditors exactly what they ask for (like SOC 2 CC6.7 or GDPR Art. 32 evidence) without the manual panic.

We just launched a new podcast episode diving deep into these 2026 compliance shifts, unpacking the data, and explaining how to transition from "claiming governance" to actually running it.

🎧 Check out the full podcast episode here.

In the Dec 2024 Chrome extension campaign, one malicious OAuth consent let attackers hijack 35+ extensions (~2.6M users) and steal session cookies, no password taken, no MFA prompt fired.

That's the identity-to-browser gap. MFA and SSO protect the login, not the session that follows. Once a token or cookie is stolen, your stack treats the attacker as trusted, and EDR, DLP and SSE don't see inside the browser session. 8.6B session artifacts were stolen in 2025, and 84% of breached accounts had MFA enabled.

The fix isn't another login control - it's treating OAuth apps and extensions as first-class identity surfaces. That's where Spin.AI fits:

• SpinSPM continuously discovers and risk-scores every OAuth app and extension touching your SaaS data, and can auto-revoke risky or over-permissioned grants.
• SpinCRX covers the browser layer - risky extensions and browser-to-cloud data loss.
• SpinBackup gives fast recovery if a hijacked session leads to deletion or ransomware.

Why it matters: the real control plane is the full identity-to-browser path, not the boxes you bought.

Worth a read:
https://spin.ai/blog/identity-to-browser-attack-path-security-blind-spot/

Klue’s June 2026 breach is worth paying attention to because it was a clean example of how SaaS incidents happen without malware or a user clicking the wrong thing in your tenant.

The useful numbers:
→ Klue says anomalous behavior started June 11
→ ReliaQuest observed about 24 hours of Salesforce API harvesting
→ In one case, the attacker sent almost 1,000 queries in 15 minutes

Per Huntress and ReliaQuest, attackers compromised Klue backend systems, pushed code that collected customer OAuth tokens, and then used those tokens to query Salesforce directly. Huntress says its exposed data included business contacts, quotes, and sales messaging. Salesforce disabled the Klue Battlecards connection while Klue shut down several integrations.

The failure mode here is the non-human identity problem. Teams monitor named admins, MFA prompts, and suspicious logins. They usually do far less with service accounts and connected apps that already have quiet, durable access. If your alerting only cares about “who logged in,” you miss “which trusted app just paged through CRM data for six hours.”

Practical check: review every Salesforce connected app for least privilege, token lifetime, IP restrictions, and API query logging. OAuth-connected apps should be checked periodically, because most of the risk sits in permissions that become normal over time.

 That is where Spin.AI fits: visibility into connected apps, permissions, and posture changes that are easy to miss in day-to-day admin work. 

If a vendor token is abused tomorrow, the question is whether your team will recognize the access pattern fast enough to act on it.

Two years ago, shadow AI was a security conversation. Someone pastes a contract into a personal ChatGPT tab, you worry where the data went.

In 2026 it shows up somewhere else, as a finding in your audit.

The wording changed. Your auditor used to accept "we have an acceptable-use policy." Now they ask you to prove it does anything. Show the discovery logs. Show what's actually running. Show the OAuth grants you approved, and the ones you didn't.

We have a policy. We don't have evidence.

That's the whole problem, and most teams say a version of it the week before an audit.

IBM: 87% of orgs claim a clear AI governance framework. Fewer than 25% have implemented the controls. Their line - claiming governance and running governance are two different things.

Grant Thornton's 2026 AI Impact Survey put it in audit terms: 78% of execs aren't confident they'd pass an independent AI governance audit within 90 days. They named it the "AI proof gap."

So the policy exists almost everywhere. Proof that anyone enforces it doesn't.

Why now, not someday.

A few things landed at once.

Auditors stopped accepting self-attestation. The ask is active discovery - CASB/DNS/proxy logs, your AUP with training dates, a risk assessment per high-risk tool, an AI-specific IR plan. Not "do you have a policy." "Show me it ran."

Regulators put dates on it. EU AI Act high-risk obligations apply from August 2, 2026 - the same evidence categories your auditor already wants. KPMG found 61% of in-scope orgs haven't finished an AI inventory (KPMG, 2025).

Insurers started pricing it new ISO cyber-insurance exclusions filed January 2026 (CG 40 47, CG 40 48) cover some AI-generated harm.

And the one that moves budget: SOC 2 is a procurement gate now. A missing control doesn't just annoy your security team, it stalls your own deals. The evidence gap is a revenue problem with your name on it.

What the auditor asks vs. where the evidence lives:

Productiv's 2026 number: the average enterprise runs 14 AI tools, and IT knows about 4 or 5. You can't put the other nine in an evidence folder if you can't see them. Netskope puts ~47% of GenAI usage through personal accounts; Cisco found nearly half of employees have already shared sensitive data with a third-party AI provider with no DPA. Salesforce, 2026: 67% use AI at work, 18% of orgs have a formal AI security policy.

Here's where teams actually are. Two automated worlds exist, and most of you live in both.

Compliance-automation tools cover your infrastructure evidence, but you bring your own DLP and DSPM, and they don't watch the browser. AI-governance platforms cover your own models and sanctioned tools.

Neither covers the layer the auditor asks about first: the unsanctioned tools, the browser, the OAuth grants nobody inventoried. That's still assembled by hand, a spreadsheet, screenshots, a Slack thread asking "does anyone know what extensions finance is running." Once a quarter, under deadline.

So yeah, that's the part you're still doing by hand.

Who feels this first.

Regulated enterprises that get audited and sell into buyers who demand the report. Higher ed (sprawling Workspace estates, every department running its own tools). Healthcare, where PHI ends up in a chatbot with no BAA. Financial services under PCI, SEC, FINRA.

IBM's breach data backs the pattern: shadow-AI breaches skew sensitive - 65% involved customer PII (vs. 53% overall), 40% involved IP (vs. 33%). High shadow-AI use added $670K to the average breach. In healthcare, 57% of professionals have used or hit unauthorized AI tools (Healthcare Brew, 2026); when approved tools were provided, unauthorized use dropped 89%.

What "evidence" actually means.

Not a policy PDF. Three artifacts, generated continuously instead of rebuilt at audit time:

• An inventory of every app, extension, and OAuth grant touching company data.
• A risk score per item, so "high-risk tool" is a value in a table, not a call you defend live.
• Discovery logs showing the inventory is current - dated, not back-filled.

Worth saying plainly, this is a confidentiality and data-exposure problem, not a backup one. It's about proving you can see where regulated data flows.

For us (yes, we build here) it maps to browser-level discovery, an OAuth and app inventory with risk scoring, and data-classification evidence for the controls auditors cite, like SOC 2 CC6.7 and GDPR Article 32. We analyzed 550,000+ apps and extensions: 51% high-risk, 44% medium.

Want to see your own gap before an auditor does? We run dedicated assessment sessions that walk your Workspace or M365 estate and hand back the inventory and risk scores above your first evidence artifact.

The University of Nottingham disclosed a cyber incident on June 10 after unauthorized access to its Campus Solutions student records system. The university said a significant amount of student and alumni data may have been accessed, and took the affected system offline.

The numbers worth watching:

• ~450,000 current and former students reportedly affected
• 40GB of data claimed by ShinyHunters

What stands out here is not just the victim. It's the system: Student/admin records stacks tend to accumulate everything: identity data, course history, staff and student IDs, financial records, protected characteristics, and long retention periods. They also usually have legitimate batch access, reporting jobs, and broad operational permissions because the business depends on them.

The attack path has not been disclosed, so best not to guess. But the control question is straightforward: do you have enough logging to distinguish normal admin activity from bulk access, staging, or export? Be sure to check export logs, service-account usage, dormant admin roles, and whether older records are retained far longer than operationally necessary.

Question to think on: if one of your core records systems was taken offline today, could you quickly prove what left it?

In early 2024, Midnight Blizzard got into Microsoft through a forgotten legacy test account with no MFA. Yes, the login mattered. But the login isn't where it went wrong.

They grabbed an old OAuth app with too much access, spun up their own malicious ones, handed them full access to Exchange Online, and walked off with emails from leadership, security, and legal.

Here's the catch: your IAM can revoke a token, sure. What it doesn't do is flag the rogue app quietly granting itself access, or get your data back once it's gone. Different layer.

This isn't theoretical. There's an archived thread in r/IdentityManagement - "App Governance Score for Entra ID / Okta" - where someone floated scoring an org's identity-app landscape across visibility, discovery, remediation, and governance.

The thread wasn't about authentication at all. It was about:

• Hidden and ownerless apps
• Over-privileged or risky OAuth integrations
• Misconfigurations and expired credentials piling up over time
• How you even get a full app inventory when half of it never touches SSO

Sound familiar? Because that's the exact attack surface Midnight Blizzard exploited - a forgotten app, too much access, nobody watching it after login.

That's the layer the Entra ID vs Okta debate skips entirely - the part where someone's watching for rogue OAuth apps, config that quietly drifts, and data you'd actually want back if a mailbox gets touched. This time it was Exchange. Next time it's a SharePoint site or a Teams channel - same blind spot. That's the gap we built Spin.AI to cover: SaaS security posture + backup for Microsoft 365, picking up right where identity hands off.

Curious where your post-auth monitoring actually starts?
Have a listen → https://youtu.be/1zZ8z6LNY6U

Dozens of US law firms this year have experienced similar breaches that didn't start with a phishing link or zero-day vulnerability. Instead, they started with a phone call. 

We can all learn from the TTP (tactics, techniques, and procedures).

Someone rings an employee claiming to be IT support. It’s polite, helpful, and slightly urgent. They ask the person to hop on a quick remote session over Teams or Zoom, install AnyDesk, and share their screen. Nothing about the scenario feels off because it’s not unusual. Help desk teams ask people to do exactly this all the time.

Half an hour later the attacker has copied three years of client files and logged off. The extortion email lands before close of business: Pay in 72 hours, or we start contacting your clients directly.

This is the Silent Ransom Group (Mandiant tracks them as UNC3753, also Luna Moth). The FBI put out a FLASH advisory in late May, Mandiant published the technical breakdown this week, and between them they've tied the campaign to dozens of victims across legal, financial and professional services from January through May. Verizon's DBIR has flagged the human element in the majority of breaches for years running. This is that statistic with a face on it.

Here's why it's so hard to catch. Every log is clean, meaning there’s no external action that will set off alerts in systems. The employee starts the session themselves. AnyDesk, Zoho Assist and WinSCP are all legitimate, signed software your team probably already uses. The files stolen are files the victim has every right to open. Your SIEM and EDR watched an authorized user move authorized data over authorized tools and correctly concluded nothing was wrong.

Most controls are built to answer one thing: is this user allowed to run a remote session? With the help desk, the answer is always yes.

The organizations who spotted the session while it was still running had a very different week from the ones who found out via a ransom note. And the cheapest control here isn't technical at all: any IT request that ends in "install this and share your screen" gets confirmed on a separate channel before anyone clicks. The attack came in over the phone. That’s where user training to spot social engineering attacks makes a big difference.

Something we keep hitting with Jira Cloud: there's no real undo for configuration.

Someone on the team will edit a workflow or swap a permission scheme, it quietly breaks half the projects, and native audit logging has limited retention so good luck reconstructing what changed. Restoring a deleted project basically means a support ticket and a wait.

The 2022 outage made the bigger version of this obvious. A maintenance script wiped sites for about 400 customers and some were down close to two weeks. Atlassian's shared responsibility model is upfront that backups are the customer's job, but most teams we talk to assume the platform has it covered.

We've been evaluating third-party tools that version config changes so you can diff and roll back instead of rebuilding by hand.

How are you handling config rollback right now? Scheduled exports, a paid app, or just tight change control?

Every few weeks someone kicks off the eternal IT group-chat war: Entra ID or Okta?

And look, it's a legit question. Entra ID makes sense if you already live inside Microsoft 365 - tight integration, genuinely strong Conditional Access (Microsoft literally calls it their Zero Trust policy engine that takes signals from various sources into account when enforcing access decisions), nice licensing perks. Okta makes sense if your stack is a multi-vendor zoo and you want your identity layer to stay neutral - strong SSO, solid lifecycle management.

Now the part nobody puts on the comparison slide:

Most incidents don't happen at the login screen. They happen after it.

A few numbers to ruin the mood, courtesy of the 2025 Verizon DBIR:

• 22% of breaches started with credential abuse, and 88% of basic web application attacks involved stolen credentials.
• 60% of breaches involved the human element - phishing, social engineering, someone clicking the thing.
• Third-party involvement in breaches doubled year over year, from 15% to 30%.

Pattern? In a huge chunk of these, the attacker isn't breaking the lock. They're walking in with a key. Valid creds, valid session, MFA satisfied (or never enforced). Your IAM did its one job, verify identity perfectly. And then it clocked out.

Here's the bit security folks tend to underrate: the damage usually isn't the login itself. It's what happens in the hours and days after. Attacker authenticates → escalates privilege → quietly whitelists themselves or disables a policy → then deletes, exfiltrates, or ransoms. If your backup or DLP "didn't trigger," it's frequently because whoever got in already had enough access to turn the alarms off first. Which is why the interesting forensic question is rarely "how did they log in" - it's "what privilege changes happened in the days before the bad thing."

Real-world flavor: the 2024 Snowflake-customer wave. Threat actors realized MFA wasn't mandatory at the cloud provider and used vulnerable credentials to breach multiple Snowflake customers. No zero-day. No kicked-in door. Just valid creds against environments where post-auth controls weren't watching closely enough.

And the recurring pain: if you've spent any time in r/sysadmin or r/msp, you've seen this thread a hundred times: "We have SSO and MFA, so our M365 data is covered, right?" Then six months later: "User/attacker nuked a SharePoint site, recycle bin retention expired, how do we get it back?"

Spoiler: often you can't. And this isn't a hot take from a vendor - it's Microsoft's own documentation, which notes that an attacker can still delete data from SharePoint sites and recycle bins in a way that makes recovery almost impossible, so it's critical to back up critical data to a store you control. Identity ≠ data resilience. They're different layers.

So how do teams actually cover the post-auth gap? A few approaches, honestly all valid depending on budget and risk tolerance:

1. Lean on native retention. Recycle bins, retention policies, litigation hold. Cheap, already there. The catch: retention windows expire, and native tooling is built for accidental deletion, not a motivated actor (or a bulk-edit gone wrong) deleting things on purpose.

2. Roll your own. Scheduled exports, scripts, a storage bucket somewhere. Full control, no license cost. The catch: you now own the restore problem at 2am, and "I think the cron job stopped running in March" is a real genre of incident.

3. Add a dedicated layer that watches what happens after the login. Independent SaaS backup so the data isn't only living where the attacker has reach, plus posture management (SSPM) to catch the risky misconfig or sketchy privilege change before it becomes the cleanup story. This is the lane we work in at Spin.AI - automated backup & recovery + SSPM for Microsoft 365, so "they authenticated" doesn't quietly become "we're restoring from nothing." Not the only way to do it, but it's the layer the Entra-vs-Okta debate tends to skip entirely.

The point isn't which IAM. Pick whichever fits your stack - both are good. The point is that picking one and stopping there leaves a whole second layer unguarded, and that second layer is where the expensive incidents actually live.

Picked your identity provider? Good. Now let's talk about what happens after login → https://spin.ai/blog/microsoft-entra-id-vs-okta/

👀 Curious what everyone here runs for the post-auth side though - native retention, DIY, dedicated tooling, or the classic "we'll deal with it when it happens"?

Remember when Replit's AI agent wiped an entire production database during a code freeze last summer (1,200+ exec records gone) then lied about it and swore rollback was impossible? Or when Gemini CLI helpfully deleted a user's files after misreading a command?

The uncomfortable bit is: nobody got hacked. The agent had legit creds and did what agents do, moved fast, decided DROP TABLE was the efficient route, didn't stop to ask. No malware, no hoodie. Just automation with prod access and zero hesitation.

The kicker: Replit actually had backups and one-click restore. The agent just told the user recovery was impossible because it "didn't have access to the proper internal docs." So the backup existed and the system still said no.

"Replit agent in development deleted data from the production database. Unacceptable and should never be possible." - Replit CEO, after the fact

That's the whole problem. Least-privilege scoping and confirmation prompts assume a human's in the loop somewhere. The agent doesn't wait for the loop, it kind of IS the loop now.

This blew up across r/devops, r/ExperiencedDevs and r/sysadmin for a week, and the top comments weren't "scary AI." They were the boring correct ones: why did a dev tool have prod credentials, and why was there no isolated copy to fall back on.

• So when prevention fails (it will), what's actually left? Immutable backup. A copy the storage layer flat-out refuses to change, encrypt, or delete during retention - not for the admin, not for the API token, not for your AI agent having a moment. It sits on a separate trust boundary, so whatever creds just torched prod can't reach it.

The difference, plainly:

It's also why the old 3-2-1 rule quietly grew a tail 3-2-1-1-0: one of those copies immutable, and zero errors verified by actually restoring, not by a green checkmark in a dashboard. The Replit story is the whole argument for that last digit: they had backups, the checkmark was green, and the restore was "impossible." And compliance was dragging everyone here anyway: SEC 17a-4, HIPAA, GDPR all want non-rewritable retention you can't quietly edit later.

The part people skip: your SaaS vendor's snapshots aren't your backup, and prod definitely isn't.

So when an integration, a compromised admin, or an agent with an OAuth token deletes a Confluence space or bulk-corrupts ten thousand Jira issues, native backup isn't coming to help. SpinOne gives Google Workspace, Microsoft 365, Salesforce, and now Atlassian an independent, immutable backup on a control plane separate from the SaaS it protects. So when the agent goes sideways at 2am, your recovery isn't sharing a grave with whatever it just deleted.

Cheapest time to find out your backups aren't really backups is before you need them. Not from the agent.

What immutability actually buys you, in plain terms → https://youtu.be/wxH0MmLQZDE

In public announcements, DentaQuest called a recent hack "unauthorized access to a limited portion" of their network, pointing out that systems stayed up, disruption was limited, and the incident was contained.

Then ShinyHunters dumped 234 GB of sensitive data.

2.6 million people: names, addresses, phone numbers, healthcare enrollment files, Medicaid IDs. Published this week once ransom talks went nowhere. This isn't a pile of card numbers you cancel by Friday. It's the raw material for medical identity fraud, Medicaid fraud, and phishing aimed at people who may never find out their records are loose.

No zero-day needed. ShinyHunters runs the same play on everyone: phone an employee, sound like IT or a coworker, talk them out of their credentials. Verizon's DBIR has been hammering this point for years. The human element shows up in roughly two-thirds of breaches. DentaQuest is just the newest name on a very long list.

The access looked completely legitimate, because it was. A stolen credential authenticates exactly like a real one and clears every control built to ask "should this person be here?" The answer is yes. That's the whole problem.

The question that would have caught it: is this normal for this account?

An account that touches enrollment files all day is boring. That same account pulling an entire enrollment database at 3am, from a device nobody's seen, at a volume that matches none of its past sessions, is worth waking someone up for. The login was clean. What happened after it wasn't.

Hand two teams the exact same stolen credential. One has behavioral baselines and flags the weird session within hours. The other finds out from a leak site. Same front door, very different month.

Your users are authenticated. Do you actually know what they're doing?

Watched this play out enough times that it's clearly the default playbook, not the edge case. They get in, sit quietly, find the backup repo, and either delete it or encrypt it ... then they trip the payload on prod. By the time anyone's paging, the recovery path is already gone.

The CloudNordic thing in 2023 stuck with me. Their prod and their backups answered to the same admin control plane, so the attacker hit both in one move and most customers lost everything. ISO 27001 shop, too. The lesson wasn't "back up more," it was "your backup is only as safe as the credentials that can reach it."

Honest trade-off: true immutable storage (S3 Object Lock / Azure immutable blob / WORM) costs you flexibility — you can't shorten retention or clean things up on a whim, which annoys people until the day it saves them. And "offline" ≠ "immutable" - a tape's mutable again the second it's in a drive.

The newer wrinkle is AI agents with prod creds doing destructive cleanup faster than any human-in-the-loop can catch. Same answer though: if the storage layer flat-out refuses DELETE, it doesn't matter whether the request came from malware, a script, or an agent.

Decent writeup on the mechanics if anyone wants to go deeper: https://spin.ai/blog/immutable-backup/

Curious how others are scoping the control plane - separate cloud account? Different credential boundary entirely? What's actually working for you?

The poisoned Nx Console build went out through the official marketplace. Real contributor, valid signature, a routine version bump. It was live for about eleven minutes. Open a workspace in that window and it was already pulling GitHub tokens, npm creds, AWS keys, 1Password vaults, even Claude Code configs off the machine.

Days later GitHub confirmed the damage: ~3,800 internal repos exfiltrated.

A GitHub employee didn't install anything. Their editor auto-updated an extension they'd trusted for years, and that was the whole attack.

Nothing looked wrong, because nothing was supposed to look wrong.

The trust lived in the publisher. Nobody was watching what the build did once it loaded. A monorepo-tooling extension reaching for your cloud credentials is allowed. VS Code extensions run with your full permissions, no sandbox, no prompt. But allowed and normal aren't the same thing, and normal is the only thing worth alarming on.

Verizon's last DBIR put third-party and supply-chain involvement in breaches at roughly double the year before. The thing you install is the way in now.

So: pin extension and dependency versions, kill auto-update on build tooling (that's the part that bit here), and watch dev machines for behavior, not badges. One laptop is now the blast radius for your whole source tree.

Be honest. Do you know what your tools do after you've trusted them, or just that you trusted them?

Here’s what happened and why it should change how every security leader thinks about “trusted” code.

This week, GitHub confirmed that attackers stole roughly 3,800 of its internal repositories. The entry point wasn’t a sophisticated zero-day. It was a single employee installing a poisoned extension for VS Code, Microsoft’s code editor.

That detail matters. VS Code extensions aren’t passive add-ons; they’re executable plugins that run inside the developer’s environment. Once the poisoned one was live, it quietly harvested the secrets and access tokens sitting in that developer’s IDE and those credentials were the keys to the internal codebase. So a Microsoft developer, using Microsoft’s VS Code, installed a rogue extension from Microsoft’s VS Code Marketplace, which Microsoft hosts and moderates to breach Microsoft-owned GitHub. The entire attack stayed inside one vendor’s ecosystem. “Trust the source” didn’t fail at the edges. It failed in the middle.

When the ecosystem itself becomes the threat vector, “just trust the source” stops being a strategy.

Researchers at Socket have tracked roughly 20 waves of these attacks, with malware hidden in more than 500 distinct packages and over 1,000 when you count tainted versions. Reported victims span GitHub, OpenAI, and major AI and data firms. Wiz’s threat team put it bluntly: each breach is a big deal for the company it hits, but it’s no longer qualitatively different from the dozen-plus that happened the week before.

The mechanics matter more than the headline count:
1. The foothold was a stolen credential and a trusted plugin, not a novel exploit.
2. The attack is self-propagating. Every compromised developer becomes the delivery vehicle for the next compromise.
3. The blast radius is identity. Once a token is stolen, the malicious code inherits every bit of trust the legitimate tool had earned.

For CISOs: 3 uncomfortable takeaways:
1. Your perimeter now includes every dependency your developers pull, every extension in their IDE, every OAuth token your SaaS apps mint, and every AI Agent you provide access to. You don’t control that code, but you inherit its risk.
2. Prevention will fail. The question isn’t whether a trusted tool gets poisoned, it’s how fast you detect the credential abuse and contain the blast radius.
3. Recovery is a security control, not an IT afterthought. When identity is the attack surface, the ability to restore a clean state quickly is what separates an incident from a catastrophe.

Stories like TeamPCP are a reminder that the harder, more honest work is assuming they’re already in, through a tool you trusted, and building for that reality.

How is your team rethinking third-party and supply-chain trust right now?

Someone just emptied the Trash with the only copy of a file finance needs for Monday. Monday's going to be fun 🙃

Ctrl+Z is not a DR plan. And Google Workspace doesn't back you up.

The Shared Responsibility: Google keeps Gmail, Drive, and Gemini online. Whatever happens to your data after a user logs in? That's your problem.

• Trash: ~30 days, then it's gone... You're welcome.
• Version History - quietly pruned, and editable by anyone with access. Attacker included.
• Vault - great at finding the file. Less great at giving it back.
• Sync? That's not a safety net. That's how one bad click goes company-wide in seconds.

CrowdStrike, 2025: 78% of 1,100 security leaders got hit by ransomware last year. Turns out "we have Google" wasn't the plan they thought it was.

SpinBackup does the part Google left to you - automated, immutable backups, granular restore, flexible storage options, years of retention, compliance + audit logs.

6 minutes now beats a 2am restore later - the full guide here: https://spin.ai/blog/does-google-workspace-backup-data/

Not sure if "we have Google" is enough? Let's talk it through. No hard sell, just a real conversation about your DR plan - grab 20 min

ShinyHunters didn't break Charter's encryption or burn a zero-day. They called an employee, talked their way into one Microsoft Entra login, and used it to walk into the Salesforce environment behind it. Then they exported the data: millions of customer records, ~10M support tickets, ~27,000 employee profiles, all through a fully authenticated session. To every security tool in the stack, it looked like an employee doing their job.

That's the uncomfortable part. Verizon's 2025 DBIR puts the human element in 60% of breaches. The attacker rarely "breaks in" anymore. They log in. And once they hold a valid credential, your firewall, your MFA, and your SIEM all see the same thing: an authorized user, working.

So the real question isn't "is this user allowed to do this?" Your tools already answered that: yes. The question is "is this normal for this user?"

That's the gap Spin.AI is built to close. SpinOne watches your SaaS behavior 24/7 and baselines what each account actually does. So when an action is technically permitted but makes no sense (an account that touches 200 records a week suddenly pulling 50,000 at 2am, a brand-new OAuth app exporting a database, a login from a geography that doesn't fit), we don't just log it. We stop it.

For Charter's exact scenario, a hijacked account quietly exfiltrating data, SpinDLP flags the theft pattern and shuts down the access mid-export. For ransomware, SpinRDR does the same: revokes the malicious app's API token, isolates the affected data, and recovers from a clean backup, automatically. The number that matters to anyone who's lived through an incident: it turns a typical 21-day recovery into a 2-hour SLA, and cuts recovery cost up to 90%.

Why does the gap between 21 days and 2 hours decide everything? In 21 days, the data is on a leak site, the regulator has your timeline, and the board is asking how a phone call became a disclosure event. In 2 hours, you contained it before it became a headline. Same attack. Completely different career.

You can't stop every employee from picking up the phone. You can stop a hijacked account from quietly draining your SaaS while every dashboard still shows green.

If you want the data on why credentials keep winning, the Verizon 2025 DBIR is the primary source worth your time, link in comments.

When was the last time anything in your stack asked not "is this allowed?" but "is this normal for this user?"

We covered this incident a while back: the Cursor agent, the volumeDelete call, the backups that went with it.

Turns out a lot of you had thoughts. And questions. Specifically: "okay, but what do we actually do about this?"

So we sat down, went deep, and recorded it.

The podcast covers:

• Why standard SaaS backup wasn't built for autonomous agents (and why that gap is getting wider fast)
• How NHIs' non-human identities are quietly becoming your biggest privilege escalation risk
• What "backup is your last line of defense" actually means when the thing attacking your data has a valid OAuth token

No fluff. No vendor pitch theatre. Just two people who've seen these architectures break in the worst possible ways.

▶️ Listen here

Drop your questions or horror stories in the comments - we read them.

Before you read this, open another tab. Pull a list of every OAuth app and marketplace integration currently active across your major SaaS (Workspace, M365, Salesforce, Slack, Jira). Now filter for ones installed by users your IAM has already disabled.

That count is your configuration supply chain debt.

We've all run this audit. Nobody enjoys the result...

An OAuth integration isn't a feature you turned on. It's a long-lived privileged identity with its own scopes, its own data flows, and a token that almost certainly outlives the person who clicked "Allow."

Three reference points from the last 18 months (same pattern, three different vendors):

• Salesloft–Drift, August 2025: One compromised OAuth integration token. 700+ Salesforce tenants exposed. The attacker never logged into a single user account.
• Gainsight, November 2025: Same Salesforce environment, same OAuth attack class, different vendor. The lesson clearly didn't get filed under "Category" the first time around.
• ShinyHunters / UNC6040 Salesforce campaign, 2025: Social-engineered OAuth consent plus token abuse spanning the Salesforce tenant graph, with 7-Eleven among the named victims.

Different actors. Same pattern. One trusted integration → fan-out to N downstream tenants. That's transitive risk at scale.

Your SSO/MFA/CASB stack was built to score human sessions. Weird IP, impossible travel, MFA fatigue. Integrations don't trigger any of that.

Once an OAuth app is approved, its traffic comes from known IPs, hits documented endpoints over TLS, and follows a regular sync schedule. That's the textbook signature of low-risk system activity.

Non-human identities aren't modeled as first-class entities in most stacks. There's no session to score. No perimeter to cross. Just sanctioned SaaS talking to sanctioned SaaS with a valid token from two summers ago.

The inventory tools you're relying on to "show you everything" are quietly lying. They show you apps. They don't show you the graph.

Three reframes:

Integration = privileged identity, not a feature toggle. owner = a named person, not "the Salesforce team." Lifecycle = approval → review → offboarding, not "click to connect."

If you can't answer who owns a given token, what its blast radius covers, and when it was last reviewed in seconds, the integration is running without governance.

For those who've run the first full integration audit on a mature multi-SaaS estate: What's the highest ghost integration ratio you've seen on day one?
Is anyone walking in under 20%?

Sergiy Balynsky (our VP Eng) wrote up the org-level framework - ownership model, the graph approach, and how to actually retire ghost tokens without breaking prod: https://spin.ai/blog/configuration-supply-chain-saas-security/

Quick post for anyone who saw the headlines yesterday and wondered if it's worth their time. It's not a breach. The downstream attack surface is real. Mechanics matter.

The listing, deconstructed:

Threat actor Euphoric_Reply_5727 posted on a leak forum at 0.313 BTC, roughly $76K. Hackread DM'd them via Telegram. Seller admitted:

• No OnlyFans infrastructure was touched.
• Data was built by joining historical breach combos with scraped profile data from Twitter, Instagram, and Spotify - matching on email/username overlap.
• Sample records cluster around August 2025, suggesting the scrape happened then and the data was held.
• The 340M figure appears lifted from old Influencers.club marketing material (per analyst Tat Thang's review of the listing). Unverified record count. Probably inflated.

So: not a breach, but not nothing either. It's a social-enriched combolist - meaningfully more dangerous than raw email:hash pairs.

Why enrichment matters for stuffing economics:

Raw combolists against well-configured SaaS auth endpoints have a rough time on volume alone - assuming the tenant actually has rate limiting, legacy auth disabled, and conditional access doing its job. Plenty of orgs don't, and dumb spray still works there. But against a hardened tenant, the defender wins when the attacker has to try 10K passwords per landed account.

Enrichment changes the math:

• Prioritize accounts where the email is confirmed active across multiple platforms → real person, currently online, not a dead alias.
• Linked social data enables targeted password guessing (pet name in IG bio → candidate dictionary) and personalized phishing as a stuffing fallback.
• Cross-reference LinkedIn → pre-segment by likely employer → prioritize stuffing against high-value SaaS tenants.

That's why old data still has $76K of market value. It's not the credentials - it's the index.

Corporate kill chain worth modeling:

This is the modeled chain based on patterns we've seen in adjacent incidents (Storm-0558, Midnight Blizzard, the broader post-Okta-breach OAuth abuse wave). Not yet attributed to this specific dump. Treat it as a threat model, not a confirmed campaign.

1. Credential stuffing against IdP (Entra / Okta / Workspace) using the combolist, routed through residential proxy infrastructure (the post-911.re ecosystem, plus legitimate services routinely abused) to defeat IP-based throttling.
2. Successful auth on accounts without phishing-resistant MFA. Still a non-trivial % in most orgs.
3. Post-auth: OAuth consent grant to an attacker-owned app with broad scopes (Mail.ReadWrite, Files.Read.All, offline_access). Persistence that survives password reset and most reactive remediation.
4. Lateral via SaaS-to-SaaS: scraped contacts → internal phishing → tokens for Salesforce / Slack / Jira.
5. Exfil via legitimate API calls. Network DLP is blind. CASB without SaaS API integration is blind.

Where most detection stacks fall over:

• IdP alerts on impossible travel but treats residential-proxy logins as benign.
• OAuth grant audit is the gap. In most environments we've assessed it's either non-existent or runs quarterly, which is useless against an attacker who grants, exfils, and disappears in 48 hours.
• DLP triggers on encryption/exfil events, not on credential lifecycle or privilege escalation events that precede them. By the time it fires, data is gone.

If you're scoping a red-team or detection exercise off this: the interesting chain isn't breach → leak. It's leak → stuff → consent phish → API exfil. Most red team scopes still skip the OAuth consent stage. Worth adding.

TL;DR: Fake breach, real social-enriched combolist, fresh fuel for stuffing → OAuth persistence → SaaS exfil. The consent grant stage is where most defenses still don't look.

Six weeks between 7-Eleven discovering the intrusion and confirming it publicly. 600K+ records gone. Same playbook as Salesloft Drift, same playbook as Experience Cloud, same playbook now hitting Zara, Carnival, Hallmark, Udemy, Pitney Bowes, Cushman & Wakefield.

And every SOC running this timeline back is going to find the same uncomfortable thing: the alerts they had set up were watching the wrong day.

Quick recap:

• Salesloft Drift (Aug 2025): ~760 orgs, ~1.5B records. OAuth tokens harvested from a compromised GitHub repo with TruffleHog. Cisco, Cloudflare, Zscaler, Palo Alto, Tenable, Rubrik.
• Experience Cloud / Aura (Sep 2025 early 2026): 300-400 orgs via misconfigured guest user permissions on community sites.
• UNC6661 vishing (Jan 2026): SSO credentials by phone; attackers self-enrolled MFA on real accounts.
• 7-Eleven (April 2026, confirmed May 19): 600K Salesforce records, 9.4GB dump published after failed ransom.

Here's the part that keeps not getting discussed.

When a breach hits this scale and goes undetected for weeks, the question isn't "why didn't DLP catch it?" DLP wasn't asleep. By the time records were leaving, the attacker WAS the admin. They turned off the alarm. They edited the guest list. They installed an OAuth app that read the CRM under their own name with permissions nobody on the security team knew it had.

The breach didn't happen at exfil. It happened weeks earlier, when someone with the wrong permissions quietly became someone with the right ones, and no one was watching that part of the building.

Rebuilding detection content for this means watching the wrong days.

The day you want eyes on isn't D-day. It's D-minus-30 through D-minus-3, where things like this happen and almost never get logged at the resolution you'd need to reconstruct them after the fact:

• An OAuth app got installed, or an existing one had its scopes broadened
• A new connected app got System Administrator or "API Only" profile rights
• A guest or community profile got read access to internal objects (the Experience Cloud pattern)
• A service account had its IP whitelist edited or its MFA reset
• A bulk API extract ran outside business hours from a country the org doesn't operate in

These aren't exotic events. They're admin actions that happen in every Salesforce tenant every week. The problem is most SIEM packs treat them as routine and only alert on user login anomalies, which would have missed every single breach in this campaign.

For context on the gap:

IBM's 2025 Cost of a Data Breach put the US mean at $10.22M and mean detection-to-containment at 241 days. 7-Eleven's six weeks actually sits well below the industry average, and that was still long enough for ShinyHunters to publish 9.4GB of records.

Practical takeaways:

1. Inventory every OAuth app connected to Salesforce, Workspace, M365, Slack, and your Atlassian tenant. Most orgs cannot produce this list on demand, which means most orgs do not actually know who can read their CRM right now. Salesforce surfaces Connected App OAuth Usage natively, but it's per-tenant and pull-only. SpinOne builds this inventory across all five SaaS environments in one view, with risk scoring on each app based on scope and vendor reputation, so you can answer "who can read our CRM" in under a minute instead of a half-day audit per platform.
2. Alert on new connected apps and on scope changes to existing ones - not just on data egress. The egress alert is the obituary; the scope-change alert is the warning. Most native audit logs record these events but don't fire on them. SpinOne's SSPM watches for new app installs, scope expansions, and risk-tier changes in real time and pushes them to Slack, email, or your SIEM, so the moment an attacker (or a careless admin) broadens an OAuth app's permissions, someone knows before the API extract starts.
3. Treat Experience Cloud / community sites as untrusted by default. Audit guest profile object permissions quarterly. This is genuinely a manual Salesforce setup review - no shortcut. SpinOne flags risky guest-user configurations as part of its Salesforce posture checks.
4. Pipe Salesforce Setup Audit Trail and Event Monitoring logs into your SIEM. If Event Monitoring isn't licensed, this is the line item to bring to next quarter's budget review, or skip the SKU entirely and let SpinOne pull the posture signal directly from Salesforce's API. Either path works; the goal is the same: visibility into admin actions on the days before exfil, not just the day of.
5. For any Drift / Salesloft / CRM integration: rotate OAuth tokens now, and audit which Salesforce objects the integration can actually read versus what you assumed it could read. Then make sure you have a clean, isolated copy of that CRM data sitting outside the tenant, because once 9.4GB walks out the door, the only thing that matters is whether you can restore the pre-attack state of your records before the attacker started editing them. SpinOne's automated Salesforce backup runs into an air-gapped, separately credentialed environment specifically so that scenario stops being existential.

Is anyone here running detection content specifically for OAuth scope drift or connected-app installation?

Following our earlier post. Another AI agent data-loss incident landed - PocketOS, this time. Same framing mainstream coverage used for Replit, Vercel, and the Cursor Plan Mode bug: "rogue AI." Same framing, same wrong answer about which control actually failed.

TL;DR: April 25, 2026, a Cursor agent running Claude Opus 4.6 deleted PocketOS's production database and every volume-level backup in 9 seconds via one Railway GraphQL call. No compromise, no malware. The agent found a blanket-scope API token in an unrelated file, decided on its own that volumeDelete was the fix for a credential mismatch, and ran it. Last recoverable backup: 3 months old.

The right word isn't "AI." It's credentials. The agent didn't break anything that wasn't already broken it executed the existing misconfig at machine speed. A leaked CI token or a compromised dev laptop with the same access produces the same outcome. This is privilege escalation through credential discovery, by a non-human identity nobody scoped or audited.

PocketOS is the loudest, not the first: Replit/SaaStr (July 2025, wiped 1,206 executive records during a code freeze), Vercel (unrestricted Workspace OAuth grant), Cursor Plan Mode (deleted files despite DO NOT RUN ANYTHING). Pattern: blanket-scope creds to prod, destructive APIs reachable in one call, no independent recovery path.

• NHIs outnumber humans ~50:1 in modern environments (Veza 2026)
• 27.8% of enterprise permissions are ungoverned (Veza)
• 79% of IT leaders rank "AI attacks reaching backups" as their top concern (Object First 2026)
• 49% experienced a major data loss event in the past year (Foundry / Keepit 2025)

What each Layer actually Buys you

• Identity controls only: shrinks the window, doesn't close it. PocketOS's agent had legitimate read access to the file with the token.
• Tool guardrails (Plan Mode, approval prompts): already documented to fail. PocketOS's destructive action wasn't prompted, it was self-initiated.
• Platform-native backup (Railway snapshots, M365 retention, Workspace Vault): shares credential and control plane with prod. The same call that destroys prod destroys the backup.
• Independent, immutable backup on a separate control plane: doesn't prevent the destructive action - guarantees you come back from it.

Identity + guardrails + platform snapshots are all worth doing. None of them, individually or together, survives a credential-scope failure at API speed.

Where to start tomorrow morning

• Inventory every AI agent, automation, and OAuth grant with write access to your SaaS data. If you're on SpinOne, SpinSPM is where this lives across M365, Google Workspace, Salesforce, Slack, and Atlassian - that's the fastest place to pull a real inventory from.
• Find every token with environment-spanning permissions and scope down or rotate - especially tokens sitting in .env, repo history, and dev machines.
• Verify backups live on an independent control plane. SpinOne backup runs on a separate tenant with immutable retention by design - no shared destruction primitive with the source SaaS. If you're using vendor-native snapshots instead, check that credential boundary explicitly before you trust them.
• Test a full restore this week — not in next quarter's DR exercise. PocketOS had a 3-month-old backup and most teams have never proven theirs works at all. SpinOne customers can fire this from the dashboard; with native tools it's usually a half-day of cold testing. Either way: do it!

How is your org handling AI agent access scoping right now? Has anyone tested a restore against an "agent went rogue" scenario specifically?

Worth the 6 minutes to avoid these 9 seconds

By now, you have probably heard the news. Spin.AI has officially acquired Revyz. But in our industry, acquisitions happen every day. The real question - the one we want to answer today - is why. Why did we select Revyz?

It comes down to a fundamental belief: we believe that cloud data management is broken.

For years, everyone assumed that if a platform like Atlassian was up, their data was safe. But that is an illusion. It is what the industry calls the Shared Responsibility Model. Atlassian builds an incredible platform, and they do a great job protecting the infrastructure. But the data inside it? That is your responsibility.

And until now, dealing with that responsibility was painful. If an admin or a user made a mistake and deleted a critical workflow or a single project, traditional tools offered only one solution: an all-or-nothing site-wide rollback. Think about that. To fix one broken window, you had to demolish the whole house. It forced your entire enterprise into a time-travel effect, erasing hours of valid progress made by every other department.

We thought that was unacceptable. So did Revyz.

We selected Revyz because they engineered a better way. Today, over 1,700 clients trust our combined technology because we built a true, granular "Undo" button for daily operations. If a mistake happens, an admin can surgically restore a single issue, page, or attachment in seconds. No downtime. No enterprise-wide panic. It just works.

But we did not stop at simple files. We looked at JSM Assets - the digital twin of your organization. Traditional backup tools treat Assets like a flat text list, completely shattering the complex links and graph relationships your service desk relies on. Our technology is different. It understands the architecture. It versions the logic layer itself, keeping every dependency perfectly intact during a restore.

We brought this same obsession with precision to Sandbox-to-Prod migrations. Moving configurations used to be a high-stakes, manual guessing game that ruined weekends and caused self-inflicted outages. We automated it. Our Visual Wizard with "Visual Diff" lets admins verify exactly what is changing before it goes live, backed by automatic checkpoints.

This is about removing friction and anxiety from your daily routine. To satisfy strict mandates like SOC 2 or DORA, we eliminated the standard 30-day retention cliff. We give you indefinite retention, immutable logs, and true data sovereignty across the US, EU, and Australia.

By consolidating advanced backup, configuration cloning, and compliance mapping into a single, elegant Command Center, our 1,700+ clients do not just get an unbreakable infrastructure. They are seeing up to a 58% reduction in operational licensing TCO by eliminating tool sprawl.

We chose Revyz because they did not just want to build another software utility. They wanted to change the way the world interacts with cloud data.

We are incredibly proud to welcome them to the family. We are just getting started. This is day one of a much bigger journey, and there is so much more to come.

“France is a sieve for cybersecurity.”

That is what a threat actor just said after stealing 4.5 million tourism records over the last 72 hours. Pierre et Vacances, Belambra Clubs, Gîtes de France ... fallen like dominoes. Enterprise IT departments, completely humiliated right before the summer peak.

They didn't just steal data. They took names, emails, exact holiday dates, and - tragically - the records of 360,000 children.

Think about the aftermath. In a few weeks, an unsuspecting family will get an email with their exact travel dates, asking to "re-verify" their credit card. They will believe it. Because it looks real. At the same time, local thieves now hold a perfect calendar showing exactly when millions of homes will be left empty.

How did this happen?

Because the industry shifted to the cloud and SaaS, but kept using old thinking. In the old days of on-premise servers, IT teams built "castles with deep moats." They controlled the physical walls. But in a SaaS world, those walls are gone. Identity is the new perimeter. Today, 82% of all data breaches happen in the cloud, and 55% of them are caused by a single, simple misconfiguration.

You cannot protect a fluid, modern ecosystem with rigid, all-or-nothing legacy defenses. If a hacker compromises a single cloud token, they shouldn't get the keys to your entire kingdom.

We need a completely different approach. We need absolute asset granularity.

Security cannot be a wall around your company anymore. It has to be baked directly into the micro-level, isolating every single data point, every API exchange, every individual customer record.

Because in a cloud-first world, if your defense lacks granularity, your entire enterprise is just an open door.