Cloud Security Services in 2026: The 7 Risks Assessments Keep Finding

2 days ago

19 min read

By Yonatan Hoorizadeh CISSP, CISM, CRISC, AAISM

Published By: Purple Shield Security

Published: September 15, 2026 | Last updated: September 15, 2026

The biggest cloud security risks in 2026 are compromised identities, unpatched third-party software, help desk vishing that steals SaaS session tokens, exposed AI workloads, poisoned software packages, internet-exposed services, and missing logs. Google Cloud found identity compromise underpinned 83% of the cloud incidents it observed. A cloud security assessment should test all seven, on every platform you run.

Cloud breaches in 2026 rarely start with a clever zero-day against Amazon, Microsoft, or Google. They start with a test credential sitting in a storage bucket, an executive who trusts a phone call from "IT," or a Python package that updated itself overnight. The major cloud platforms are holding up. The identities, configurations, and software that companies stack on top of those platforms are where attackers are winning.

This roundup pulls together the most useful cloud security research published this year, including Google Cloud's Cloud Threat Horizons Report H1 2026, Intruder's 2026 Cloud Security Index (built on data from 3,000 organizations), and incident analysis from the Sysdig Threat Research Team and Arctic Wolf. For each risk, the post covers what the data shows, why it matters to owners and executives, and what cloud security services and assessments should actually be checking.

What are the biggest cloud security risks in 2026?

Seven risk patterns dominate cloud incidents in 2026: weak identity controls, unpatched third-party applications, help desk vishing with session token theft, exposed AI workloads, software supply chain compromise, internet-exposed services with permissive firewalls, and missing logs combined with attacks on backups. Most organizations carry several of these at once, and attackers routinely chain two or three together in a single intrusion.

Risk	2026 evidence	Who feels it most
1. Weak identity and access controls	Identity compromise underpinned 83% of incidents (Google Cloud); weak IAM in 80% to 98% of accounts (Intruder)	Every organization, including large enterprises
2. Unpatched third-party software	44.5% of initial access in H2 2025, ahead of weak credentials at 27.2% (Google Cloud)	Firms running their own apps on cloud servers
3. Help desk vishing and SaaS token theft	PREY-0058 steals Microsoft 365, SharePoint, and Box data with no malware (Arctic Wolf)	Executives in healthcare, finance, real estate, professional services
4. Exposed AI workloads	AWS intrusion reached admin in about 8 minutes via AI training data buckets (Sysdig)	Companies running AI pilots on AWS, Azure, or Google Cloud
5. AI and software supply chain attacks	Poisoned LiteLLM releases harvested cloud keys; tied to CVE-2026-33634 (CISA KEV)	Any team building software or AI tools
6. Exposed services and permissive firewalls	Exposed services in 76% of AWS accounts; permissive firewalls in 83% (Intruder)	Multi-cloud and fast-growing environments
7. Missing logs and deleted backups	Missing logging in 80% to 98% of accounts (Intruder); ransomware gangs deleting snapshots (Google Cloud)	Regulated firms facing breach notification decisions

Why is identity the top cloud security risk in 2026?

Identity is the top cloud security risk because an attacker who signs in as a real user or service account bypasses nearly every other control. Google Cloud's Cloud Threat Horizons Report H1 2026 found identity compromise underpinned 83% of the cloud compromises its teams observed. Intruder's 2026 Cloud Security Index found weak identity and access management (IAM) controls in 80% to 98% of accounts on AWS, Azure, and Google Cloud.

The specific identity failures vary by platform. Intruder found that 83% of AWS accounts had IAM policies that allow privilege escalation, meaning a low-level identity can grant itself more power. On Azure, 55% of accounts had Microsoft Entra ID users without multi-factor authentication (MFA). That Entra ID gap matters well beyond Azure servers, because Entra ID also controls sign-in to Microsoft 365, many third-party SaaS apps, and some on-premises systems.

Google Cloud accounts showed their own pattern. Intruder found OS Login MFA missing in 77% of Google Cloud accounts, unused service accounts in 75%, and overly permissive service accounts in 53%. A service account is a non-human identity that software uses to talk to other software, and unused ones are easy for attackers to take over because nobody notices when they start doing something new.

Size does not fix identity. Intruder found weak IAM controls in 87% of small and midsize businesses, 95% of midmarket organizations, and 98% of large enterprises. For most other risk categories, larger organizations did better. Identity got worse with scale, because every new application, vendor integration, and automation adds identities that someone has to govern.

From a CISO's seat, the useful question is not "is MFA turned on?" Most leadership teams will hear "yes" and move on. The better question is "who owns each non-human identity, what can it do, and when was its key last rotated?" Service accounts, API keys, and automation roles often outnumber employees, and they rarely have a named owner or an offboarding process.

A cloud security assessment should inventory human and non-human identities, confirm MFA coverage for administrators and break-glass accounts, map privilege escalation paths, flag stale keys and unused service accounts, and review Conditional Access or equivalent sign-in policies on each platform.

Unpatched third-party software is now the top way into the cloud

Exploited third-party software has overtaken weak credentials as the leading way attackers break into cloud environments. Google Cloud's Threat Horizons Report H1 2026 found that third-party software accounted for 44.5% of initial access in the second half of 2025, compared with 27.2% for weak credentials. Google described this as the first time software exploitation took the top spot, and attackers are moving from disclosure to exploitation in days.

The shift was sudden. Infosecurity Magazine reported that third-party software was the entry point in just 2.9% of Google Cloud incidents in the first half of 2025. Over the same period, misconfiguration as an initial access method fell from 29.4% to 21%, according to Google Cloud. Attackers did not stop exploiting configuration mistakes. They simply found faster returns in unpatched applications.

Google Cloud was explicit that its own underlying infrastructure remained secure. The exploited weaknesses were in user-managed software and permissive firewall rules that customers configured themselves. In the React2Shell incident, Google Threat Intelligence Group (GTIG) observed attackers exploiting a popular third-party web framework within days of the vulnerability becoming public.

This is where the shared responsibility model (the split between what the cloud provider secures and what the customer secures) catches mid-market companies off guard. Microsoft, Amazon, and Google patch their platforms. They do not patch the web application, content management system, or open-source framework your team or contractor installed on a cloud server. Many owners assume "it's in the cloud, so the provider handles it." For anything you install, that assumption is wrong.

Here is the gap worth putting in front of a board. Intruder found that midmarket organizations take an average of 35 days to remediate cloud issues, compared with 8 to 16 days for smaller businesses and 10 days for large enterprises. Google Cloud's reporting shows attackers exploiting new flaws within roughly 72 hours. These are different datasets measuring different things, but the practical conclusion holds: a month-long fix cycle cannot keep up with a three-day exploitation window.

How are attackers stealing Microsoft 365 and SaaS data without malware?

Attackers are calling employees while posing as the IT help desk, steering them to fake sign-in pages, and capturing both the password and the MFA approval. The stolen session token then lets attackers sign in as the victim. Arctic Wolf tracks one active cluster, PREY-0058, that uses this method to steal data from Microsoft 365 and other SaaS services for extortion without installing any malware on endpoints.

According to The Hacker News, PREY-0058 mainly targets directors, vice presidents, and other executives. Its victims are spread across the U.S. in construction and engineering, healthcare and pharmaceuticals, real estate, finance, and professional services. The operation shares tradecraft with a data extortion group that Google-owned Mandiant tracks as UNC6671.

The attack chain is simple and effective. A caller impersonating IT directs the target to an authentication-themed web address built to look like it belongs to the victim's company. An adversary-in-the-middle (AitM) page, which relays the real Microsoft login while recording everything, captures credentials and MFA approvals. Attackers replay the stolen session tokens through residential proxy services located in the same geographic area as the victim, which makes the sign-in look routine.

Once inside, the attackers search SharePoint and Entra ID to learn what exists, then pull data in bulk from SharePoint, OneDrive, Exchange, and Box before sending extortion demands. Because no malware is deployed, endpoint detection and response (EDR) tools on laptops have nothing to catch. Google Cloud's H1 2026 report describes the same broader trend: attackers moving from email phishing to voice-based social engineering (vishing) and harvesting third-party SaaS tokens.

The business lesson is that "we have MFA" is no longer a complete answer. Push notifications and text-message codes can be relayed through an AitM page. Phishing-resistant MFA, such as FIDO2 security keys or passkeys bound to the real domain, does not relay. For law firms whose client matter files live in SharePoint, or healthcare organizations with patient data in OneDrive, this attack pattern should sit near the top of the risk register.

A cloud security assessment should review Conditional Access policies, phishing-resistant MFA coverage for executives and administrators, the help desk's identity verification procedure, SharePoint and OneDrive oversharing, and whether anyone is alerted when a session token is replayed from a new location or when a user downloads thousands of files in an hour. Arctic Wolf also recommends restricting how much data each user can reach in SharePoint and training help desk staff on vishing.

Why are AI workloads becoming a cloud security risk?

AI projects create new cloud storage, API keys, service accounts, and model access that often skip normal security review. In an AWS intrusion analyzed by the Sysdig Threat Research Team, an attacker used credentials found in public Amazon S3 buckets holding AI data, reached administrator access in about eight minutes, then abused Amazon Bedrock models and launched expensive GPU servers.

Sysdig observed the attack on November 28, 2025, and published its analysis in February 2026. The exposed buckets contained retrieval-augmented generation (RAG) data, which is the company-specific content an AI system searches to answer questions. The buckets were named using common AI tool naming conventions, and Sysdig noted the attackers actively searched for those names. The stolen credentials belonged to a user the victim had likely created to automate Bedrock tasks.

From there, the attacker injected code into an existing AWS Lambda function that had an administrative role attached, created new keys for an admin user, and moved across 19 distinct AWS identities. Sysdig's team was direct about the root cause: "Leaving access keys in public buckets is a huge mistake." Sysdig also found signs that the attacker used large language models to write code and make decisions, including hallucinated account IDs and a GitHub repository that does not exist.

The attacker then turned to LLMjacking, which is the theft of cloud AI model access so someone else pays for the usage. Before invoking models, the attacker checked whether Bedrock model invocation logging was turned on. It was not. The attacker also launched a GPU instance that Sysdig priced at $32.77 per hour, or roughly $23,600 per month if left running. For a CFO, that is the part of AI risk that shows up on an invoice before it shows up in a security report.

The practitioner take is that AI risk in the cloud is mostly ordinary cloud risk moving faster. AI pilots are often launched by a small team under deadline pressure, in an account that was meant to be a sandbox but gets connected to real company data. The keys, buckets, and permissions created for that pilot rarely go through the same review as a production system. Teams scaling AI across the business should pair the cloud assessment with an AI-specific review of models, data stores, and agent permissions.

AI and software supply chain attacks are harvesting cloud keys

Attackers are poisoning trusted open-source packages so they steal cloud credentials the moment a developer or build pipeline installs them. On March 24, 2026, two malicious versions of LiteLLM, a widely used open-source AI gateway, were published to the Python Package Index (PyPI). They stole cloud keys, SSH keys, and Kubernetes secrets from any environment that installed them, and the stolen data resurfaced publicly in August.

LiteLLM's maintainers said versions 1.82.7 and 1.82.8 were live for about 40 minutes before PyPI quarantined them, and they told users to treat any install that day up to 16:00 UTC as suspect. Sonatype noted that the package sees roughly three million downloads per day, which is why a short window still mattered. PyPI advised anyone who ran the affected versions to assume every credential available to that environment was exposed and to rotate it.

The LiteLLM compromise was one step in a larger campaign by a group tracked as TeamPCP, which first breached Aqua Security's Trivy vulnerability scanner in March 2026. According to CybelAngel, Aqua Security said the attacker kept access after an incomplete credential rotation. The campaign is tracked as CVE-2026-33634, which the Cybersecurity and Infrastructure Security Agency (CISA) added to its Known Exploited Vulnerabilities (KEV) catalog on March 26, 2026.

The fallout is still arriving. CybelAngel reported that a 153 GB dataset of exfiltrated credentials tied to the leak appeared in August 2026, mapped to more than 2,000 organizations worldwide. The FBI warned in a July 2 advisory, FLASH-20260702-01, that affiliated actors are likely to use credentials stolen in the TeamPCP campaign long after the initial compromise, as reported by The Hacker News.

Three lessons from this incident rarely make the headlines. First, the entry point was a security scanner, which means security tooling needs the same scrutiny as any other vendor. Second, an incomplete credential rotation turned a contained incident into a longer one, so "we rotated the keys" needs evidence. Third, a company does not need to use LiteLLM directly to be exposed. The package often arrives as an unpinned dependency inside AI agent frameworks, Model Context Protocol (MCP) servers, and other orchestration tools.

A cloud security assessment should examine where secrets live in build pipelines, whether dependencies are pinned to known-good versions, how broadly GitHub-to-cloud trust relationships are scoped, and whether long-lived keys can be replaced with short-lived roles. Google Cloud's H1 2026 report describes an intrusion in which attackers abused exactly that kind of GitHub-to-cloud trust relationship, then used an overly permissive cloud role to create administrative access.

Which cloud misconfigurations are most common on AWS, Azure, and Google Cloud?

The most common cloud misconfigurations differ sharply by provider. Intruder's 2026 Cloud Security Index found S3 buckets not enforcing HTTPS in 87% of AWS accounts, storage account key rotation disabled in 67% of Azure accounts, and OS Login MFA missing in 77% of Google Cloud accounts. A single generic checklist applied to all three platforms will miss the issues that matter most on each one.

Category (Intruder 2026)	AWS	Azure	Google Cloud
Exposed services	76%	64%	8%
Permissive firewalls	83%	45%	34%
Weak encryption	49%	35%	8%
Misconfigured services	68%	80%	37%
Weak IAM and missing logging	80% to 98% on every provider

AWS led in five of the six categories Intruder measured. Its most common issues after unenforced HTTPS on S3 were permissive ingress to sensitive ports (84%), overly permissive network access control lists (83%), and IAM policies that allow privilege escalation (83%). Intruder suggested that AWS offers the widest range of services, which creates the most configuration options and the most room for mistakes.

Azure's weak spot was storage. Beyond missing key rotation, 66% of Azure accounts still had storage account access keys enabled, and 61% allowed public network access to storage accounts. Intruder noted that where storage accounts are not hardened, several controls tend to be missing at once. Storage accounts frequently hold personally identifiable information, which makes this a direct privacy and breach-notification concern.

Google Cloud showed the lowest prevalence in five categories. Intruder attributed part of that to Google Cloud offering fewer services and part to its Shared Fate model, which ships more secure defaults for network exposure and encryption. Nearly every top Google Cloud issue in the index came down to identity and access management.

The wrong question for a leadership team is "which cloud provider is safest?" The right question is "does our team know how each platform we actually run tends to fail?" A company with Microsoft 365 on Entra ID, a line-of-business app on AWS, and an analytics project on Google Cloud has three different sets of failure modes. Cloud security services that only understand one platform will leave the other two under-examined.

Why do missing cloud logs and deleted backups turn incidents into crises?

Missing cloud logs mean an organization cannot prove what an attacker touched, which expands breach notification scope, legal cost, and friction with cyber insurers. Intruder found missing logging and alerting in 80% to 98% of cloud accounts. Google Cloud's H1 2026 report adds that nearly all major ransomware gangs now tamper with logs, snapshots, and other forensic evidence, and some destroy cloud resources to block recovery.

Google Cloud reported that threat actors continued destroying cloud resources before or during ransomware and extortion demands in the second half of 2025, likely to pressure victims who can no longer recover on their own. Google also cited security industry reporting that Storm-0501, a group targeting hybrid cloud environments, deleted Microsoft Azure data and backups while stealing data.

Logging gaps show up in real incidents. In the AWS intrusion Sysdig analyzed, the attacker specifically checked whether Amazon Bedrock model invocation logging was enabled before using the models. Attackers know which logs defenders forget to turn on, and they check first.

Here is why this lands on the CEO's desk. When breach counsel asks whether patient records or client files were accessed, cloud audit logs are how the question gets answered. Without those logs, counsel often has to assume the worst and treat every record in scope as potentially exposed. That turns a contained incident into a broad notification, and it weakens the organization's position with regulators and insurers.

A cloud security assessment should confirm that audit logging is enabled for cloud platforms and SaaS tenants, that log retention meets regulatory and investigative needs, and that logs are stored somewhere an attacker with admin access to production cannot delete them. It should also confirm that backups are immutable and that someone has actually restored a critical workload from them recently.

What does a cloud security assessment cover in 2026?

A 2026 cloud security assessment tests identities, SaaS tenants, AI workloads, build pipelines, network exposure, and logging and recovery across every cloud platform an organization uses, then identifies which weaknesses an attacker could realistically chain together. A cloud security posture management (CSPM) dashboard listing thousands of findings is a useful input. By itself, a dashboard is not an assessment, because it does not rank findings by business impact.

Assessment area	What gets tested	2026 risk it addresses
Identity and access	Human and non-human identities, MFA strength, privilege escalation paths, stale keys, sign-in policies	Risks 1 and 3
SaaS tenants	Microsoft 365, Google Workspace, and key SaaS apps: sharing settings, token and session controls, admin roles	Risk 3
Workload and patch exposure	Internet-facing apps and servers, patch cadence for user-managed software, firewall and security group rules	Risks 2 and 6
AI services and data	Bedrock, Azure OpenAI, Vertex AI usage; model access; RAG data stores; AI API key handling	Risk 4
Pipelines and supply chain	Secrets in CI/CD, dependency pinning, GitHub-to-cloud trust scope, vendor and integration access	Risk 5
Logging and recovery	Audit log coverage and retention, tamper-resistant log storage, immutable backups, restore testing	Risk 7
Governance and compliance mapping	Ownership, change control, and mapping to CIS Benchmarks, NIST CSF 2.0, HIPAA, FTC Safeguards Rule, or SOC 2	All seven

The deliverable matters as much as the testing. Executives should receive a short list of the issues most likely to cause a material incident, written in business terms, with an owner and a target date for each. Technical teams should receive the platform-specific detail needed to fix them. A retest after remediation confirms the fixes actually hold, which is the evidence auditors, insurers, and boards increasingly ask for.

Scope should follow the data, not the org chart. If client files live in SharePoint, patient scheduling runs on an AWS-hosted app, and the marketing team is piloting an AI assistant on Google Cloud, all three belong in scope. Leaving out the SaaS tenant or the AI pilot because "it's not really our cloud" recreates exactly the blind spots attackers exploited this year.

How do cloud security risks differ for healthcare, legal, and financial services?

The seven cloud risks apply to every industry, but regulated firms face higher stakes because a cloud incident can trigger mandatory notification, regulatory scrutiny, and client or patient loss. Healthcare organizations must account for electronic protected health information (ePHI) in the cloud, law firms must protect privileged client files, and financial firms must meet specific MFA and incident response requirements.

Healthcare organizations and HIPAA

The proposed overhaul of the HIPAA Security Rule is delayed. The U.S. Office of Management and Budget's Unified Agenda now lists July 2027 for final action, pushed back from an earlier May 2026 target, according to Fierce Healthcare and The HIPAA Journal. The proposal would make encryption and MFA mandatory rather than addressable, but it is not yet law.

The delay does not reduce today's obligations. Covered entities and business associates must still perform a HIPAA risk analysis that accounts for where ePHI actually lives. The decision rule is simple: if ePHI sits in Azure storage accounts, Microsoft 365, AWS, or a cloud-hosted EHR integration, the risk analysis should name those services specifically. With PREY-0058 already targeting healthcare and pharmaceutical executives, help desk vishing belongs in that analysis too.

Law firms and legal departments

Most law firms now keep client matter files in Microsoft 365, SharePoint, OneDrive, or Box, which are exactly the services PREY-0058 stripped for extortion. A single compromised partner account can expose privileged material across many clients at once. Firms should expect corporate clients to ask pointed questions about phishing-resistant MFA, data access restrictions, and audit logging in their security questionnaires.

Financial services firms

Financial firms carry explicit requirements. The FTC Safeguards Rule requires non-bank financial institutions to use MFA for anyone accessing customer information and to maintain a written risk assessment. The SEC's amended Regulation S-P requires covered broker-dealers, investment advisers, and funds to maintain an incident response program and notify affected customers, with compliance dates that arrived for smaller entities in June 2026. Cloud-hosted customer data falls squarely inside both.

General mid-market businesses

Mid-market companies face enterprise-level cloud complexity with smaller teams. Intruder's finding that midmarket organizations take 35 days on average to remediate cloud issues, longer than both smaller and larger organizations, reflects that squeeze. For these companies, the highest-value first step is usually identity and SaaS hardening, because those controls block the attack paths that require the least attacker effort.

What should owners and executives ask their IT team about cloud security?

Owners, CEOs, and CFOs do not need to read cloud configurations to hold their teams accountable. Seven plain questions reveal most of the 2026 cloud security risks covered above. If the answers come back vague, slow, or "we think so," that uncertainty is itself the finding.

How many non-human identities, such as service accounts and API keys, do we have, and who owns each one?
Do our executives and administrators use phishing-resistant MFA, or can their sign-ins be relayed through a fake login page?
What would our help desk do if a caller claiming to be an executive asked for an MFA reset?
Which AI services are running in our cloud accounts, and who approved the data they can reach?
How long does it take us to patch an internet-facing application after a critical vulnerability is announced?
If an attacker got admin access to production, could they delete our logs and backups?
When did we last restore a critical system from backup, and how long did it take?

When should a business hire a cloud security consultant?

A business should bring in a cloud security consultant when its cloud footprint has outgrown the security expertise on staff, or when a specific trigger makes an independent view urgent. Common triggers include running more than one cloud platform without dedicated cloud security staff, launching AI projects that touch company data, holding regulated data in the cloud, and facing a cyber insurance renewal or acquisition.

Several situations make the decision straightforward. Organizations whose last cloud review predates their AI rollout should reassess, because the environment has changed. Companies that installed affected packages during the TeamPCP campaign should get outside validation that credential rotation was complete, given how the Trivy incident unfolded. Regulated firms whose risk analysis does not name specific cloud and SaaS services have a documentation gap that an examiner or plaintiff's attorney can find.

Independence matters when choosing help. A cloud security consultant who also resells posture management tools has a built-in reason to recommend more tools. Purple Shield Security does not resell products or accept vendor referral fees, so its cloud security assessments end in a prioritized fix list rather than a purchase order. Whoever you choose, ask directly how the firm is paid and whether any recommended tool generates revenue for them.

What can a business do about cloud security in the next 30 days?

Most of the risk reduction available in 2026 comes from a short list of identity, logging, and exposure fixes that do not require new tools. The actions below map directly to the attack patterns documented this year and can be started within a month by an internal IT team or managed provider, with an assessment used to confirm the results.

Require phishing-resistant MFA (FIDO2 keys or passkeys) for administrators and executives first, then expand.
Write a help desk rule that MFA resets and password changes for executives require a callback to a number already on file.
Block public access to cloud storage at the account or subscription level on AWS and Azure, then document any approved exceptions.
Search code repositories, storage buckets, and build logs for long-lived access keys; rotate them and replace with short-lived roles where possible.
List every AI service and AI API key in use, and turn on model invocation logging for Amazon Bedrock or its equivalent on other platforms.
Confirm whether any environment installed LiteLLM 1.82.7 or 1.82.8, or affected Trivy components, and verify that every exposed credential was rotated.
Send cloud audit logs to a separate account or storage location that production administrators cannot delete.
Restore one critical workload from backup and record how long it took.

Frequently asked questions

What is the difference between cloud security services and a cloud security assessment?

A cloud security assessment is a point-in-time review that identifies weaknesses across identities, configurations, workloads, SaaS tenants, and logging, then prioritizes fixes. Cloud security services is the broader category, covering the assessment plus remediation guidance, architecture review, ongoing posture monitoring, and incident readiness. Most organizations start with an assessment to establish a baseline and decide which ongoing services they actually need.

How often should a mid-size company get a cloud security assessment?

A mid-size company should complete a full cloud security assessment at least once a year and again after any major change. Major changes include adopting a new cloud provider, launching AI workloads that use company data, completing an acquisition, or experiencing a security incident. Regulated firms should also align the timing with their required risk analysis or risk assessment so the two documents support each other.

Is Microsoft 365 included in a cloud security assessment?

Microsoft 365 should be included, because many of 2026's most damaging cloud attacks targeted SaaS tenants rather than servers. Arctic Wolf's PREY-0058 research shows attackers stealing data from SharePoint, OneDrive, and Exchange using stolen session tokens and no malware. An assessment that covers AWS or Azure infrastructure but skips the Microsoft 365 or Google Workspace tenant leaves one of the most active attack paths untested.

Does using AWS, Azure, or Google Cloud make our data secure by default?

No. Under the shared responsibility model, the provider secures the underlying platform, and the customer secures identities, configurations, data, and any software it installs. Google Cloud's H1 2026 report states its infrastructure remained secure while attackers exploited customer-managed software and firewall rules. Intruder's data shows customer-side weaknesses, such as weak IAM, in 80% to 98% of accounts on all three major providers.

Could we be affected by the LiteLLM compromise if we never used LiteLLM?

Yes, potentially. LiteLLM often arrives as an unpinned, indirect dependency inside AI agent frameworks, Model Context Protocol (MCP) servers, and orchestration tools, so developers may not know it is installed. Any environment that pulled versions 1.82.7 or 1.82.8 on March 24, 2026, should have rotated every credential it held. The FBI warned in July 2026 that stolen TeamPCP credentials are likely to be used long after the original theft.

The cloud platforms themselves are not what failed companies in 2026. Identities, SaaS settings, AI experiments, build pipelines, and missing logs are. If you want an independent view of how those seven risks show up across your AWS, Azure, Google Cloud, and Microsoft 365 environments, Purple Shield Security's cloud security services start with an assessment built around the attack patterns documented this year, delivered as a prioritized plan your team and your board can act on.

Explore Cloud Security Services