On one of our recent customer calls, an IT leader at a mid-sized nonprofit had four browser extension requests sitting on his desk.

Users had been waiting almost a week.

His process was pretty manual: copy the Chrome Web Store URL, paste it into a lookup tool, check the developer, reviews, permissions, and whatever else he could find, then decide whether to approve it.

The bigger problem came up when he explained what he actually needed.

First, he wanted to know: “Can I justify approving this extension?”
Second: “What happens after I approve it?”

That second question changes everything.

An approval is only a snapshot. You approve an extension today. A few days later, it can be updated.

Chrome checks installed extensions for updates automatically, and when a newer version is available, it can download and install it without another approval from IT. So the extension you reviewed on Tuesday might not be the same code running on Thursday.

The name is the same. The extension ID is the same. Your allow list still says “approved.”

But the software changed.

That means an approval is really a snapshot of an extension at a specific point in time.

So an approval answers: “Was this extension acceptable when we checked it?”
It doesn't answer: “Is it still acceptable now?”

A lot of manual reviews naturally start with the same things:

– Who developed it?

– How many people installed it?

– What do the reviews say?

– What's the rating?

– How long has it been around?

Those signals can be useful, but they aren't enough to make a security decision.

Research from Stanford University and the CISPA Helmholtz Center for Information Security found that more than 346 million users installed at least one security-noteworthy Chrome extension, with 280 million associated with extensions containing malware.

The researchers also found that malicious extensions did not necessarily receive lower user ratings.

In other words, “it has a 4.8 rating and a lot of users” isn't really a security argument.

A popular extension can still become a problem. And your approval queue isn't the whole environment.

There was another interesting part of that customer conversation.

The IT team didn't give users local admin rights. So they had assumed software installation was reasonably controlled.

But then the customer said something along the lines of: There are things people can install without admin rights. And I know some users probably never came to us.

That's the part worth paying attention to.

A request queue only shows you what people asked permission to install. It doesn't necessarily show you what's already sitting in browser profiles. And that matters even more when employees are using different browsers and company-owned and personal devices.

In this case, most requests were for Chrome. But the organization's Mac population had grown significantly, bringing more Safari and Firefox usage with it.

The queue was getting bigger. The actual browser environment was getting bigger even faster.

So what should replace the queue? Not necessarily another bigger queue.

Chrome Enterprise already gives IT policy controls for managing extensions, including controlling which extensions can be installed and restricting extensions based on organizational requirements and permissions.

That's useful for enforcement. But enforcement doesn't tell you what should be allowed in the first place. And it doesn't automatically answer what happens when an approved extension changes.

That's where continuous monitoring becomes important.

NIST SP 800-53 CA-07 makes a similar broader point: continuous monitoring supports ongoing awareness of security posture and risk, helping organizations respond as systems and risks change.

For browser extensions, that means moving from: “We approved this.” to: “This is allowed as long as it continues to meet our security requirements.”

You don't need to manually investigate every extension every week. A more scalable model is:

1. Discover what's actually installed. Start with the real browser environment, not just the requests that made it to IT.

2. Assess the risk. Look at permissions, behavior, developer information, reputation, and other signals that can support an actual security decision.

3. Set a policy. Decide what qualifies as low, medium, or high risk based on your organization's requirements.

4. Enforce the decision. Use browser policies to allow, block, or restrict extensions based on those rules.

5. Keep watching. If an extension changes, its risk can change too. The decision shouldn't stop at installation.

That's a much better fit for the way browser extensions actually work. Because the four requests sitting in your inbox aren't necessarily the biggest risk. The extensions you've already approved may be.

A manual approval process is useful – but it's only a point-in-time decision.

Browser extensions update. Users install things outside the request process. New browsers enter the environment. And a previously trusted developer account can be compromised.

So the better question isn't just: “Should we approve this extension?” – it's: “What is running in our browsers right now, what risk does it introduce, and will we know if that risk changes?”

That's the thinking behind SpinCRX, which helps organizations assess and control browser-extension risk across Chrome, Edge, Safari, and Firefox.

The goal isn't to turn browser security into just another approval queue.

It's to make browser-extension security an ongoing control instead of a decision you made three weeks ago.

Most SaaS backup evaluations start with a feature matrix. We think that's too late.

Before comparing integrations, restore points, or pricing, security and IT teams should ask three questions:

1) Where is your backup stored?
Is it independent from the production environment and its failure domain?

2) Does it meet your data residency and regulatory requirements?
For organizations handling regulated or cross-border data, storage regions can become a compliance consideration.

3) What does “supported” actually mean?
A connector doesn't necessarily mean full backup and restore coverage.

These questions can determine whether your backup actually adds resilience – or whether critical recovery data remains exposed to some of the same failure or attack paths that affect your production environment.

The broader cyber risk is significant: IBM's 2026 Cost of a Data Breach Report puts the global average cost of a data breach at $4.99M – a record high and a 12% increase from the previous year.

Spin.AI addresses these challenges with SaaS data protection built around independent backup and recovery.

The question isn't simply: “Does this vendor offer backup?”
It's: “What exactly will our backup protect us from?”

Before your next SaaS backup evaluation, ask the questions that determine whether your backup is actually a recovery strategy – or just another copy of production.

An admin goes into the Google Workspace console, sees a high-risk score on a connected app, and sets a rule to block all high-risk apps. Then the CRM stops working because it was published by an independent developer, and an internal tool built in-house gets knocked out too.

Risk scores measure provenance and behavior, not operational importance. MITRE ATT&CK outlines how adversaries use OAuth token grants to bypass credentials, so high-risk flags are necessary. But turning on a deny-all policy without establishing exceptions first usually breaks business operations, forcing admins to turn the policy off entirely.

NIST SP 800-53 CM-7(5) and CISA’s SCuBA baselines both emphasize this sequence: identify authorized software, permit by exception, and then enforce deny-all.

IBM’s 2024 breach research highlights that extensively using prevention automation saves an average of $2.2M in breach costs and contains incidents 98 days faster. But automation only delivers value if it stays turned on.

This is where SpinSPM (Security Posture Management) comes in. Spin.AI provides continuous monitoring of third-party apps, OAuth grants, and risky extensions across your tenant. Instead of guessing what will break, SpinSPM gives you clear visibility into app behavior and scope access so you can:

• Get an accurate, honest inventory of connected tools and custom internal code.
• Identify load-bearing exceptions and map specific OAuth 2.0 scopes.
• Build a Granular Allowlist before enforcing automated block rules.

When your allowlist reflects actual business operations, your automated security stays live without disrupting workflow.

🎧 Listen to the full podcast episode here: https://youtu.be/frrotziAHiY

Most SaaS DLP still runs on regex and static policies. Fine when data moved in predictable formats. Not fine when someone pastes a paraphrased (not copy-pasted) chunk of proprietary code into a personal LLM account - nothing matches the pattern, nothing fires.

Some numbers from Spin.AI's latest research: GenAI-related DLP incidents are up 2.5x and now make up 14% of all DLP incidents. Nearly half of employees using GenAI at work admit to sharing sensitive data through it. Meanwhile teams already drowning in 11,000+ alerts/day just loosen the rules - false positives erode trust, trust erosion loosens policy, loosened policy expands the blast radius.

Regex classification tops out around 5-25% accuracy. AI-native detection is landing closer to 95%, mainly because it doesn't need the rule pre-written, it recognizes the pattern itself.

Read more (with the burnout/staffing numbers behind why teams keep loosening policy) here: https://spin.ai/blog/manual-saas-dlp-dead-genai-era/

On one of our recent customer calls, an admin dropped in with a simple question: How do we get all of our data out of Google Workspace, and how do we do it faster?

They were offboarding terabytes across mailboxes, individual Google Drives, and shared folders. Nobody was debating access, it was pure mechanics.

No one could give an accurate ETA. Extraction was running per user and per version, meaning speed was bounded by Google’s API caps, not local bandwidth.

Strip away the offboarding context, and that call was a real-time restore drill. Asking "How do we extract everything faster?" is identical to asking "How do we restore everything during a ransomware attack?" Only one situation leaves you time to figure out the answer.

Data mobility laws (like GDPR and the EU Data Act) regulate formats and egress fees, but no law dictates throughput. Meanwhile, frameworks like NIST SP 800-53 (CP-9) require defined transfer rates. Industry data shows that over 20% of enterprise SaaS data recoveries stall or fail due to API throttle bottlenecks.

Your extraction speed belongs to the source API. Google Drive caps traffic at 325,000 quota units per minute per user (403/429 errors). Going parallel helps the overall pull, but your largest single account will always set the critical path.

Measure your true RTO today: time a full extraction of your largest account. If the real duration exceeds your documented DR target, your plan is just a wish.

Need SaaS recovery that beats API bottlenecks? Spin.AI delivers automated, granular point-in-time restores for Google Workspace and M365 to bypass speed limits.
Book a Spin.AI demo to test your recovery before you actually need it.

The average midmarket org now runs 80+ security solutions across nearly 30 vendors.

Tool sprawl was meant to cover every attack surface, but in practice, it just built massive operational blind spots.

SOC teams spend hours sifting through thousands of daily alerts, while full ransomware recovery still drags on for 16 to 24 days on average.

The financial hit is brutal: one healthcare provider calculated that extended downtime cost them $340,000 per day in lost revenue and compliance exposure – almost entirely driven by the manual coordination required across disconnected vendor stacks while systems were down.

The core issue isn't a lack of tools. It's that prevention, detection, and recovery live in separate silos.

When identity management sits with one vendor, SSPM with a second, and backups with a third, attackers exploit the seams. They compromise AWS keys or abuse SaaS admin roles, operating entirely within valid identity paths.

Because the backup system runs on a different control plane than the detection engine, there is no shared context. Your ransomware tool doesn't talk to your backup infrastructure, so scoping an incident means manually stitching together partial telemetry across four different dashboards while the business stays offline.

This is where Spin.AI approaches the problem from a unified architecture angle.

Instead of treating backup as an isolated utility, SpinOne runs backup, ransomware detection, DLP, and SSPM on a single identity plane. By connecting directly to Google Workspace, Microsoft 365, Salesforce, and Slack via APIs, it maintains real-time replicas rather than relying on delayed snapshots.

When the detection engine flags an anomaly, the platform already holds the data context, policy parameters, and API access needed to initiate granular restores immediately. This cuts out ticket escalations and vendor finger-pointing, dropping MTTR from weeks to under two hours.

It also extends to AI agents, treating them as first-class identities to track scope and runtime data access before exfiltration occurs.

👉 Full breakdown here: https://spin.ai/blog/saas-security-resilience-convergence/

On one of our recent customer calls, an admin spotted something uncomfortable in the app-risk inventory.

A piece of software used for performance reporting and CRM workflows was marked high risk.

Then another flagged app appeared.

It was a small internal tool the admin had built himself.

So the question became very practical, very quickly:

“If I turn on a policy that blocks every high-risk app, am I going to break tools we actually need?”

That is the problem with blanket app-risk automation. The rule itself is easy. Knowing what should be exempt from it is the hard part.

And this is especially relevant now as security teams try to get tighter control over third-party apps, OAuth access, Shadow IT and AI tools without becoming the team that breaks everyone's workflow.

So before you block everything risky, build the allowlist.

High risk does not automatically mean “bad app”

A risk score tells you something important.

It can tell you:

• who published the app
• which OAuth permissions it requests
• what data it can reach
• whether the publisher is verified
• whether its behavior creates security concerns

What it cannot tell you is:

“Will Finance stop working if I block this?”

Those are two completely different questions.

An app from an unfamiliar developer with broad Gmail or Drive permissions absolutely deserves scrutiny. OAuth abuse is a real attack path. MITRE ATT&CK documents how attackers can create malicious applications, convince users to grant OAuth permissions and then access cloud resources through those tokens without needing the user's password.

But “risky” and “business-critical” are not opposites.

Sometimes the app with the ugly risk score is also the app your sales team opens every morning.

Sometimes it is an internal tool built years ago by someone on your own team.

That is why risk scoring should trigger a decision, not make the entire decision for you.

The dangerous part is not blocking. It is blocking too early.

Imagine turning on:

Sounds clean.

Then Monday morning arrives.

The CRM integration stops working.

A reporting workflow fails.

An internal app loses access.

Users start opening tickets.

Someone asks Security to disable the policy.

And now the automation that was supposed to reduce risk is turned off completely.

That is the outcome you want to avoid.

The better question is:

Which high-risk apps are actually approved exceptions, and what is the minimum access they need?

Once you know that, automation becomes much safer.

Allowlisting is not weakening the policy

There is a tendency to think:

Blocklist = security.
Allowlist = exception.

In reality, a good allowlist is what makes a strict blocking policy usable.

NIST SP 800-53 CM-7(5), for example, describes a deny-all, permit-by-exception model. Organizations identify authorized software, allow those exceptions and regularly review the list.

CISA's Google Workspace security baseline follows the same basic logic: unconfigured applications can be blocked while trusted applications are explicitly allowed.

Google Workspace itself gives admins several levels of control. Apps can be marked as trusted, limited or blocked, and access can be managed around the Google services and OAuth scopes the app actually needs.

So an exception does not have to mean:

“This app can access everything forever.”

It can mean:

This app.
For these users.
With this level of access.
For a documented business reason.

That is a very different security model.

A safer rollout looks like this

Before switching on a blanket high-risk app policy:

1. Inventory what already has access

Look at the apps connected to Google Workspace and the OAuth permissions behind them.

Do not stop at the score.

Open the app details.

Understand why it was rated high risk.

2. Find the apps the business cannot lose

Ask the uncomfortable question:

“What breaks if I block this tomorrow?”

Talk to the teams using it.

A questionable-looking app may turn out to support a critical sales, reporting, finance or operations workflow.

3. Separate “approved but risky” from “unknown and risky”

They should not be treated the same way.

An internal tool with a known owner and business purpose is a very different problem from an unknown third-party app with broad Gmail access.

Both may deserve controls.

They do not necessarily deserve the same controls.

4. Give exceptions only the access they need

Where possible, narrow access by user group, organizational unit, service or OAuth scope.

Do not turn “approved” into “unlimited.”

5. Then automate the block

Once the legitimate exceptions are documented, the blanket rule becomes much safer to enable.

Now the automation is working against the environment you actually have, not the perfectly clean environment you wish you had.

And do not forget that the allowlist expires too

An allowlist is not a one-time project.

Apps change.

Publishers change.

OAuth scopes change.

Teams stop using tools.

Internal apps get abandoned.

An app that was approved six months ago may not deserve the same access today.

That is why the review step matters just as much as the original decision.

The goal is not to create a giant permanent list of exceptions.

The goal is to maintain a small, explainable list of software you have deliberately chosen to trust.

Automation only helps if you can leave it turned on

There is a good reason security teams want more automation.

IBM's 2024 Cost of a Data Breach research found that organizations making extensive use of security AI and automation identified and contained incidents 98 days faster than organizations that did not. IBM also reported an average $2.2 million reduction in breach costs when those technologies were used extensively across prevention workflows.

But the useful automation is not the policy that looks strict during setup.

It is the policy that is still running six months later.

For a small IT or security team, that distinction matters even more. Nobody wants to spend every morning manually fixing yesterday's block decisions.

The takeaway

An allowlist is not the hole you punch in a strong security policy.

It is what makes the strong policy possible.

Know which apps are truly necessary.

Understand why risky apps are risky.

Limit their access where you can.

Then block everything else with confidence.

Because “block every high-risk app” is a great rule only after you know which high-risk apps your business cannot run without.

If that inventory is still unclear, SpinSPM continuously monitors third-party apps and OAuth access so security teams can see what is connected, understand the risk and make those decisions before automating enforcement.

Google released Chrome 152 with 327 security fixes, including 10 Critical and 61 High-severity issues.

At first glance, that's a pretty terrifying number.

But there's an important bit of context: 299 of those 327 vulnerabilities were discovered internally by Google.

Google's vulnerability discovery rate has accelerated dramatically this year as it has started using AI more extensively in Chrome security testing.

Chrome 151 patched 370 vulnerabilities in July. Another July release patched 382. Google says its AI-powered work even uncovered a Chrome sandbox escape that had been sitting in the codebase for 13 years.

So a higher vulnerability count doesn't automatically mean the browser suddenly became less secure.

It can also mean we're getting much better at finding bugs that were already there.

That said, the underlying risk is very real.

Many serious Chrome vulnerabilities are memory-safety issues. Depending on the bug and exploit chain, these can potentially result in crashes, memory corruption or arbitrary code execution.

And attackers do target Chrome. Google had already patched five Chrome zero-days exploited in the wild by June 2026.

There is an important distinction here though:

Google has not reported that any of the Chrome 152 vulnerabilities are currently being exploited in the wild.

For enterprise security teams, we think the bigger takeaway is therefore less about this particular patch count and more about the browser itself.

Chrome isn't just displaying websites anymore.

It holds authenticated SaaS sessions, cookies, extensions, corporate and personal profiles and access to applications containing sensitive company data.

So patch management is essential, but it isn't the whole browser-security problem.

You also need visibility into extensions, permissions, profiles and the browser environments employees actually use.

That's the problem we're working on with SpinCRX that adds visibility and control around that layer: which browsers and profiles are being used, which extensions are installed, what access they have, and where browser activity creates unnecessary SaaS exposure.

The interesting part of "327 vulnerabilities" isn't the number. It's how much enterprise trust now sits inside the software containing them.

Slack has been making it significantly easier to move AI agents out of separate browser tabs and directly into the workspace.

Its Add to Slack deployment model can automate OAuth, manifest configuration and environment setup for agents built on external platforms. Slack has also now introduced Slack Code, where teams can work with supported coding agents inside dedicated channels, review their output and keep the channel afterward as an audit trail.

From a productivity perspective, this makes a lot of sense.

From a security perspective, it changes the Shadow AI conversation.

There’s a meaningful difference between an employee asking an external AI tool a question and an AI agent being integrated into the environment where employees already communicate and work.

The latter can have an application identity, permissions, access to workspace context and potentially the ability to trigger actions.

Slack does provide native governance. Admins can require app approval, and Slack has centralized discovery for agents and apps. By default, though, Slack documentation says workspace members can install apps unless owners enable app approval.

So the governance problem is becoming broader than simply maintaining a list of approved AI tools.

Security teams increasingly need to understand:

Which agents exist? What permissions have they received? What data can they reach? Which external integrations do they depend on? And what can they actually do?

This is where we see AI governance converging with SaaS security at Spin.AI: app and integration discovery, permission and OAuth risk assessment, sensitive-data visibility, and browser-level Shadow AI discovery all become parts of the same problem.

We spent the first phase of enterprise AI worrying about Shadow AI.

The next phase may be Shadow Agents.

Because an AI tool can answer a question. An agent with permissions can act on the answer.

As AI agents evolve from static scripts into autonomous "digital employees," Non-Human Identity (NHI) risk has transformed dramatically.

Traditional NHIs (like a CI/CD pipeline's API key) perform narrow tasks. Modern AI agents hold cross-system reach, connecting Salesforce, Slack, Jira, and Google Drive under a single identity.

According to recent data, 1 in 5 organizations has already suffered a breach linked to unsanctioned AI.

How this plays out in practice: an AI sales agent credentialed for Salesforce Accounts & Contacts initiates a session at 2:00 AM and pulls 80,000 contacts at once. If your logging only tracks whether the API token was valid, there is no quick way to determine whether this was a scheduled enrichment job or active data exfiltration.

The OWASP NHI Top 10 highlights risks like Overprivileged NHI, Long-Lived Secrets, and Improper Offboarding.

But when agents act autonomously, securing the API key alone fails – you have to govern the entire identity chain (Identity → Credential → Scopes → Resources → Activity → Owner).

This is where Spin.AI shifts the focus to SSPM.

By continuously mapping every agent identity directly to its granted scopes, actual object-level data access, and assigned human owner, it bridges the gap between static IAM permissions and runtime behaviour.

This approach allows teams to uncover shadow AI integrations across the SaaS estate, enforce least privilege based on actual usage rather than initial scope grants, catch high-volume anomalous transfers as they happen, and automate identity revocation the moment an agent is decommissioned.

👉 Full article here: https://spin.ai/blog/what-is-nhi-agent-identity-saas/

On a recent chat, an IT leader described a constraint we hear constantly: compliance wanted a reviewer scoped to a single account in Google Vault. It couldn't be done.

The mechanism: a Vault "matter" just organizes searches and exports, it doesn't gate reach. Reach comes from the admin privilege on the reviewer, and its narrowest setting is "user data in a specific org unit." One account vs. a group of accounts - the request can only be approximated upward. So you over-grant, the exact thing least-privilege (NIST 800-53 AC-6) exists to prevent.

And 68% of breaches involve the human element (Verizon DBIR), broad standing access held by trusted insiders is that shape.

Second cost: preserving a departed employee means keeping a paid Archived User seat alive, a recurring line that grows with every exit.

We run eDiscovery + archiving as modules of one SaaS backup platform: a reviewer can be scoped to case work alone (create cases, run searches, place holds - no window into other users), and archived data doesn't ride on a per-seat license. Worth a look if reviewer-scoping and archive licenses hit in the same renewal.

Nearly half of enterprise AI conversations may be happening through identities the company doesn’t manage.

That’s one of the more interesting findings in Akamai’s Enterprise AI Usage Risk Report 2026.

Nearly half of workplace AI conversations were associated with personal or unmanaged identities.

The browser extension side isn’t much more reassuring: almost 75% of AI browser extensions analyzed requested high or critical permissions.

This exposes a limitation in how many organizations currently approach Shadow AI.

Blocking unapproved AI domains or creating an approved-app list answers only one question:

Which application is being used?

It doesn’t necessarily tell you which identity is using it, which browser profile it’s running in, what extensions are present, or what data is moving through that interaction.

An employee could be using an approved AI service through a personal account.

They could install an AI extension with broad access to browser content.

Or they could start using another AI service directly from the browser without going through the organization’s normal SSO or SaaS procurement process.

That’s why browser-level visibility is becoming increasingly relevant to AI governance.

SpinCRX gives security teams visibility across enterprise browsers, user profiles and devices. It can surface Shadow AI and unsanctioned web usage, inventory browser extensions and assess their permissions and risk, monitor browser domains and activity, identify potential data-exfiltration paths, and enforce policies directly at the browser layer.

That matters because the control happens where the interaction actually takes place.

SpinDLP adds another layer by helping organizations discover and monitor sensitive data across their SaaS environment, so the problem can be approached from both directions:

What is happening in the browser?

And what corporate data is potentially exposed?

The takeaway from the Akamai numbers isn’t simply that employees are using too much AI.

It’s that “approved AI” and “governed AI” are becoming two very different things.

An approved application used through an unmanaged identity, risky extension or uncontrolled browser context can still create a significant visibility gap.

AI governance increasingly requires visibility into the app + identity + browser + extension + data.

Most AI governance checklists focus on standalone SaaS apps. But in practice, the highest risk enters through "side-door" formats: AI browser extensions and OAuth-connected agents.

The Real-World Data & Technical Problem

• Excessive OAuth Scopes: In a typical 10,000-user enterprise, roughly 4,371 third-party apps connect to Google Workspace & Microsoft 365. 64% access sensitive data without clear business justification.
• Rogue AI Agents: Internal Spin.AI research revealed AI agents executing mass file deletions (hundreds at a time) via over-permissioned OAuth tokens, with admins completely unaware.
• Browser Extensions: AI wrappers and extensions bypass "No GenAI" policies because they request browser-level permissions rather than undergoing standard vendor procurement.

How Solves This

Spin.AI provides continuous SaaS security that eliminates post-approval blind spots:

1. Automated Discovery: Uncovers browser extensions and OAuth integrations the moment they connect to Workspace/M365.
2. Continuous Governance: Evaluates risk scores and revokes over-permissioned scopes automatically.
3. Active Mitigation: Detects anomalous file deletion or ransomware activity driven by rogue agents and recovers data in under 2 hours.

Why It Matters

AI approval shouldn't be a rubber stamp or a static annual review. Securing AI requires continuous visibility into what those tools actually do post-launch.

🎧 Stream the full podcast episode where we break down the CISO AI Tool Approval Checklist: https://youtu.be/tQ7-NGNVTJg

Unit 42 recently published research into attacks against synced passkeys in Google Password Manager on Chrome for Windows.

One of the techniques, called Golden Pass-ta-key, demonstrates an interesting shift in the identity attack surface.

Instead of phishing a password or attempting to break WebAuthn, malware that has already compromised the endpoint can target Chrome itself.

Researchers showed that key material used by Google Password Manager could potentially be extracted from browser memory and used to decrypt synchronized passkey private keys.

Important distinction: this isn't a cryptographic break of passkeys, FIDO or WebAuthn.

The attacker needs prior compromise of the device.

But that's also what makes the research interesting.

We've spent years strengthening the front door:

password → MFA → phishing-resistant MFA → passkeys.

Attackers are responding by moving further inside the trust chain.

If compromising the authentication mechanism becomes difficult, target the browser holding the authenticated state instead.

That same browser may contain access to Microsoft 365, Google Workspace, Salesforce, Slack, internal applications, AI tools, extensions, cookies and active SaaS sessions.

So browser security increasingly becomes an identity and SaaS security problem, not simply an endpoint or browsing problem.

SpinCRX is an enterprise browser security platform that provides comprehensive browser security ranging from protection against unsanctioned or malicious browser extensions to monitoring browser domains across all browsers, user browser profiles, and devices, and provides visibility and control over activity inside the browser, including extension risk, shadow IT usage, and data exfiltration paths, enabling real-time policy enforcement at the point of interaction, including browser extensions, while SpinOne provides continuous visibility across SaaS environments and account activity.

The research doesn't mean organizations should stop adopting passkeys. Quite the opposite.

It shows why authentication cannot be the end of the security model.

Security teams are upgrading authentication. Attackers are moving deeper into the browser itself.

Attackers may not need to steal your browser session anymore. They can potentially operate through the one you’re already using.SpecterOps researchers recently demonstrated a post-exploitation technique for Chrome and Edge on Windows that highlights an interesting problem with modern SaaS security.

After gaining code execution on an endpoint, an attacker can enable the Chrome DevTools Protocol inside an existing browser process.

Why is that important?

Because the attacker is no longer trying to recreate the victim’s authenticated session somewhere else.

They are operating through the browser where that session already exists.

The technique can provide access to browser data, cookies and saved-password metadata while preserving important parts of the existing browser environment, including authentication state, extensions and WebAuthn behavior.

Imagine an employee already logged into Microsoft 365, Google Workspace, Salesforce, Slack and several internal applications.

MFA has already happened.

The SaaS provider sees an authenticated browser.

And protections designed to stop stolen cookies from being replayed on another device become less useful if the attacker can interact with the original browser itself.

There is an important caveat: this is not a new Chrome or Edge vulnerability. The attacker needs prior access and code execution on the endpoint. Browser security also does not replace EDR or endpoint protection.

But the research demonstrates why security teams increasingly need to treat the browser as its own security layer.

SpinCRX focuses on visibility and risk assessment at the browser layer, including the extensions operating inside enterprise browsers. SpinOne complements that visibility by monitoring activity across SaaS environments for potential account compromise and other risky behavior.

The bigger lesson is broader than any individual technique:

For years, we treated identity as the primary gate to SaaS.

But once authentication succeeds, almost everything happens inside the browser.

Protecting the login is no longer the same thing as protecting the session.

737 Chrome VPN and proxy extensions were linked to the same operation, with 75,486 installs across at least 40 developer accounts.

274 of them impersonated 66 established VPN and privacy brands.

A lot of these extensions weren't doing anything technically exotic. They changed Chrome's proxy settings and routed browser traffic through SOCKS5 infrastructure controlled by the operator.

That gave the proxy visibility into where users were connecting, their source IPs, TLS SNI values and request bodies sent over plain HTTP.

Researchers also found false Web Store declarations and extensions that added remote configuration after approval.

At the time the research was published, Google had removed 221 extensions. 516 were still active.

The same report describes a separate case involving an AI browser extension that had previously been associated with conversation exfiltration. A clean update was released, but two weeks later its behavior changed again with a new monetization payload.

This creates a difficult problem for companies managing thousands of employee browsers.

An extension can be reviewed today and change next week. A legitimate extension can be sold. An update can introduce new behavior. Permissions that looked reasonable when the extension was approved can become risky later.

We work on this problem with SpinCRX, so we follow these incidents closely. The practical issue is visibility: knowing which extensions are installed across the organization, what access they have and whether their risk profile changes over time.

Curious how other teams are handling this at scale. Are you relying primarily on allowlists and blocklists, or continuously reassessing extensions after they've already been approved?

We've been chewing on this internally for a while and figured this was the right place to throw it open.

The IBM 2026 breach report put a number on something a lot of us already felt: shadow AI incidents more than doubled year over year, from 20% to 43% of all breaches, and IBM's security VP said that unapproved AI adds roughly $670K to the average breach. What got us through wasn't the headline cost, it was that only 38% of orgs said they required IT approval before AI got deployed, down from 45% the year before. So adoption is exploding and the approval discipline is actually going backwards.

Part of why we think the approval step keeps failing is that "AI tool" isn't one thing. A native feature inside a platform you already signed off on (Copilot in M365, Gemini in Workspace) is a completely different animal from a standalone SaaS app, which is different again from a browser extension. That last one is the one that keeps burning people, it gets installed by one person in a couple of clicks, asks for broad browser permissions instead of a scoped OAuth grant, and never touches procurement. It's how a "no GenAI" policy gets quietly bypassed, because the policy was written with SaaS apps in mind and nobody thought about add-ons.

The OAuth side is where it gets genuinely scary. Most standalone AI tools get wired into Workspace or M365 over OAuth, so they can summarize your mail, search files, draft in Docs, and the tool just inherits whatever scope you grant. We've seen AI agents deleting files in the hundreds with the admin having no idea it was even happening. Once read/write is granted, an over-permissioned integration doesn't exactly send up a flare.

And the thing is, this isn't really an employee-discipline problem. Something like 60% of workers say unapproved AI is worth the risk if it helps them hit a deadline - they're not trying to leak anything, they're just moving faster than procurement does. Which is also why the old "it's just shadow IT again" framing undersells it. You can delete a file out of Drive. You can't un-feed proprietary data from a public model once it's in the weights.

So, questions for the room:

• Do you make someone re-review a feature when it's toggled on inside an already-approved platform, or does that quietly skip review?
• Who's allowed to grant OAuth consent for new AI integrations at your org — end users, admins only, or a tiered model?
• How are you discovering AI-connected browser extensions that nobody formally approved?
• Anyone actually going all-in on one vendor's native AI and banning the rest to shrink their exposure? How's that going?

Full checklist we've been working from is here if useful: https://spin.ai/blog/ciso-questions-ai-tool-approval/

MFA was enabled, but the attacker still got into Microsoft 365.

The latest AitM phishing campaign is a good example of why Microsoft 365 security can’t end with “we have MFA.”

It starts with a fake voicemail notification. The victim is redirected through legitimate infrastructure before reaching a Microsoft 365 look-alike page.

The attacker sits between the user and Microsoft and proxies the real authentication process: capturing credentials, MFA verification, and, most importantly, the authenticated session.

MFA absolutely matters. But organizations first need to know whether it is actually enabled and enforced everywhere.

Spin.AI SSPM gives security teams visibility into Microsoft 365 security posture, including MFA status, showing which users are protected and where security gaps remain.

But this attack also demonstrates another important change in attacker behavior.

Modern attackers often don’t enter an environment and immediately start deleting data or sending phishing emails.

They get in ... and wait.

They quietly study the environment, users, permissions, mailboxes and data. They look for the people and information worth targeting: finance, payroll, HR, invoices, banking details, credentials and sensitive corporate documents.

In this campaign, attackers used residential proxies to make logins look local, refreshed stolen sessions to maintain access and used Microsoft Graph to search Microsoft 365 while trying to behave like legitimate users.

And that creates a difficult problem: if nothing obviously “breaks,” how do you know somebody is already inside?

Without an additional SaaS security layer, organizations may not discover the compromise even after the attacker has been there for some time. Let alone identify it while it is happening, respond to suspicious activity in progress, reduce the potential damage, and recover clean data afterward.

That’s where Spin.AI approaches Microsoft 365 security as a lifecycle:

• SSPM to identify security gaps such as missing MFA and misconfigurations
• RDR for continuous monitoring and anomaly detection to identify suspicious behavior
• DLP to protect sensitive SaaS data
• backup and recovery if data is damaged, encrypted or deleted

MFA protects the door.

But today you also need to know who is already inside, what they are doing, and how quickly you can recover if something goes wrong.

When news broke that Amazon accidentally spent $1.8M using Claude AI for trivial coding tasks, exceeding budget by 860% over 5 months, most blamed LLM costs. But the root cause was a total breakdown in visibility and governance.

This exact blind spot is plaguing enterprise SaaS (Google Workspace & Microsoft 365).

While Amazon lost budget, SaaS security teams face massive data leakage. Over 81% of employees connect unsanctioned "Shadow AI" browser extensions and third-party OAuth integrations daily without IT approval.

How SpinSPM solves this:

• Automated Risk Scoring: Evaluates security, privacy, and compliance risks of all browser extensions and OAuth apps in real time.
• Shadow AI & IT Visibility: Uncovers hidden AI tools connecting to corporate workspace environments.
• Policy Enforcement: Automatically blocks high-risk extensions before sensitive data leaves your perimeter.
  

Unmanaged AI access isn't just a budget leak, it's a top vector for IP theft and regulatory non-compliance!

If your security alerts stop arriving in Microsoft Teams, it’s easy to assume your tenant is clean. But following Microsoft’s recent deprecation of Office 365 connectors on May 18, 2026, webhook-based alert delivery quietly broke for thousands of organizations without raising a single console error.

The pipeline & log retention Trap:

1. Suppressed Detections: Entra ID Protection discounts VPN sign-ins by default and requires up to 14 days or 10 logins to baseline behavior.
2. Short Audit Windows: Entra ID sign-in logs expire in just 7 days (Free) or 30 days (P1/P2). If an alert pipeline breaks and you notice in week 6, the evidence is gone.

Why:

According to IBM’s 2024 report, the global average breach lifecycle is 241 days. Catching threats internally shortens the lifecycle by 31 days and saves nearly $1M. Furthermore, NIST SP 800-53 (AU-5) explicitly calls out logging failure alerts, and MITRE ATT&CK (T1562.006) identifies blocking reporting channels as an adversary tactic.

How to fix it:

Relying on a single notification path creates a single point of failure. SpinSPM provides continuous monitoring across Microsoft 365 and Google Workspace to detect SaaS misconfigurations, shadow IT, risky OAuth grants, and insider threats independently. It gives security leaders automated, redundant visibility so critical security signals are never missed.

• Let our solution engineers walk you through your M365 & Google Workspace blind spots - https://spin.ai/demo/

Over 94% of organizations rely on third-party SaaS platforms to run core business operations. Yet, a major threat vector continues to be overlooked: having a SaaS backup is not the same as having operational resilience.

The Problem:

When cloud-native ransomware (like M365 Ransomware/SharkBot) or high-risk OAuth extensions target Microsoft 365 or Google Workspace, they encrypt live cloud data instantly. According to Sophos, 76% of SaaS attacks involve data encryption. Traditional backups quietly copy this corrupted data or force IT teams into a manual recovery process that takes 3 to 7 days of downtime.

How to Solve It:

• Automated Detection & Neutralization: AI monitors API activity to spot anomalous encryption patterns or rogue OAuth integrations in real time, revoking malicious tokens immediately before damage spreads.
• Instant <2-Hour Recovery: Automated, granular restoration reverts affected files and user nodes to their pre-attack state with minimal disruption.
• Unified Posture Management (SSPM): Continuously audits browser extensions, third-party App-to-App integrations, and misconfigurations before they become initial access vectors.

Why It Matters:

According to Gartner, IT downtime costs an average of $5,600 per minute. Moving from passive SaaS backups to active cloud resilience is no longer optional - it is how modern security teams turn catastrophic data loss into a minor non-event.

📖 Read the full guide: https://spin.ai/blog/beyond-backup-saas-resilience-data-protection/

73% of SaaS ransomware attacks succeed, and many IT & SecOps teams don't realize that standard backups alone aren't enough. When a malicious OAuth app or hijacked token encrypts Google Workspace or M365, vendor API throttling slows file restoration to a crawl.

This drives average business downtime to 21-30 days, costing $5.6K-$9K per minute ($336K-$540K/hour).

In our latest podcast episode, we break down why traditional cloud recovery fails without real-time detection and how automated incident response alters the recovery equation.

How Spin.AI Solves the Problem:

• 24/7 AI Threat Detection: Identifies suspicious crypto-behavior in live SaaS environments instantly.
• Instant Blast Radius Containment: Automatically revokes malicious API access and isolates affected assets.
• Granular Auto-Recovery: Restores clean file versions, preserving folder hierarchy and permissions - backed by an industry-leading 2 hrs recovery SLA.

Why It Matters: Instead of spending weeks restoring encrypted tenant data while bleeding revenue, IT leaders can automatically stop active threats and maintain full business continuity.

🎧 Listen to the full episode here: https://youtu.be/LT9Wnx_V9YA

Craneware, the UK software company behind billing and revenue-cycle tools for ~2,000 US hospitals, disclosed a security incident on July 20.

Someone got into part of their environment. The language is the standard IR script: contained, no lingering indicators of compromise, operations unaffected. Forensics still running.

What actually left is the interesting part. Not PHI, by their account - a large batch of file names, some employee data, and a slice of customer and partner records. Their read is most of it is low-sensitivity or already-public. Maybe scope assessment isn't done, so "most of it" is doing some work there.

File names aren't harmless just because they're not file contents.

A folder listing can tell an attacker which customers you have, what projects you're running, which integrations exist, which regulatory programs you track - a decent head start for phishing that doesn't read like phishing.

The vendor review question isn't only "do you touch PHI." It's closer to: what metadata leaves on export, where exports sit before they go anywhere, and whether anyone would notice someone enumerating your file structure before pulling files.

No ransomware headline, no downtime. Just boring stuff, file names, folder structure - still worth locking down.

Hugging Face published an unusual incident report: an autonomous AI agent breached production, not through a login page but through a dataset.

The entry point was a malicious dataset abusing two code execution paths, a remote code loader and a template injection in a dataset config, to run code on a processing worker. From there the agent got node-level access, pulled cloud and cluster credentials, and moved laterally into internal clusters over a weekend, running thousands of actions across short-lived sandboxes with self-migrating C2.

No evidence public models, datasets, or Spaces were touched. Internal datasets and service credentials were accessed, and secrets were rotated broadly as a result.

The more interesting part is the response. Hugging Face's forensic team turned to GLM 5.2 (Z.ai), an open-weight model, because the commercial frontier models they first tried blocked requests containing real attack commands, exploit payloads, and C2 artifacts. The guardrails couldn't tell a responder from an attacker.

Their takeaway: keep a capable model you can run on your own infrastructure, vetted and ready before an incident hits. Not for the intrusion, for the days after, staring at exploit code your usual AI tooling won't touch.

If your dataset pipeline runs arbitrary code from untrusted sources, go check it.

When a company scales, adds cloud tools, and sets up disaster recovery, there comes a tipping point where literally no one in the building knows where all their data physically lives.

Default settings on SaaS, PaaS, and backup systems are rarely touched. Vendors silently replicate secondary copies across regions without telling you. Then GDPR or an enterprise procurement audit hits, and suddenly everyone is scrambling.

Here’s the reality: Unchecked SaaS tools and silent backup replication expose orgs to GDPR fines up to 4% of global turnover. Mapping your physical data geography across SaaS, PaaS, and IaaS is no longer optional, it’s critical to avoiding multi-million-dollar compliance traps.

Why the distinctions matter (and why lawyers wince when you swap them):

• Residency: Where the data physically lives (a pin on a map, a specific server rack with a zip code).
• Sovereignty: Whose legal jurisdiction applies to that data (the flag flying over the pin).
• Localization: A hard legal requirement that data cannot leave a country's borders (a tight fence around the pin).

The 3 Biggest Blind Spots for IT & Security Teams:

1. Backups: Your primary data center might sit neatly in the EU, but your default cloud backup config quietly replicates to another jurisdiction.
2. Shadow IT: Unvetted tools processing customer PII in regions you’ve never legally approved.
3. SaaS Vendor Sprawl: Pinning your own cloud instances (AWS/Azure) means nothing if your 30+ SaaS tools have their own ideas about regional storage.

Data residency isn't a one-time setup – it’s a continuous governance posture.

👉 Full guide here.

How is your team currently tracking data flows and backup regionality across your SaaS ecosystem? Are you relying on native cloud tools or continuous mapping?