• Cloud Security Newsletter
  • Posts
  • 🚨 Google Cloud Phishing Bypasses Email Security: Lessons from Anthropic's MCP Security Response

🚨 Google Cloud Phishing Bypasses Email Security: Lessons from Anthropic's MCP Security Response

This week's newsletter examines sophisticated attacks exploiting legitimate cloud services—from Google Cloud's email features to AI agent tooling—and explores how enterprises like Anthropic are building secure-by-design systems. We feature insights from Caleb Sima and Ashish Rajan on implementing defense-in-depth architectures that assume breach and verify continuously.

Author

Ashish Rajan
January 28, 2026

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter topic: AI Security 2026 Predictions: The "Zombie Tool" Crisis & The Rise of AI Platforms (continue reading) 

This image was generated by AI. It's still experimental, so it might not be a perfect match!

Incase, this is your 1st Cloud Security Newsletter! You are in good company!
You are reading this issue along with your friends and colleagues from companies like Netflix, Citi, JP Morgan, Linkedin, Reddit, Github, Gitlab, CapitalOne, Robinhood, HSBC, British Airways, Airbnb, Block, Booking Inc & more who subscribe to this newsletter, who like you want to learn what’s new with Cloud Security each week from their industry peers like many others who listen to Cloud Security Podcast & AI Security Podcast every week.

Welcome to this week’s Cloud Security Newsletter

The emergence of "living off the cloud" attacks where threat actors weaponize trusted platform features rather than compromising infrastructure signals a fundamental shift in cloud security. Traditional authentication-based trust models are failing as attackers abuse legitimate Google Cloud services to bypass email filters and leverage Azure Copy for undetectable data exfiltration.

This week, we're diving into architectural patterns that address this challenge with insights from Caleb Sima and Ashish Rajan, who share proven strategies for building resilient cloud security programs that maintain effectiveness even when attackers operate through trusted channels.[Listen to the episode]

đź“° TL;DR for Busy Readers

  • Google Cloud email abuse: Attackers sent 9,394 phishing emails through legitimate Google services, bypassing SPF/DKIM/DMARC—behavioral analytics now essential

  • AI tooling expands attack surface: Anthropic patched Git MCP server vulnerabilities showing agent connectors need privileged integration treatment

  • OVHcloud acquires Seald: Zero-knowledge E2EE pressures SaaS providers to adopt customer-controlled encryption architectures

  • GitLab 2FA bypass patched: Self-managed instances vulnerable to account takeover leading to CI/CD credential theft

  • Microsoft 365 outage became security event: When logging pipelines and identity flows fail, IR runbooks assuming SaaS availability collapse

đź“° THIS WEEK'S TOP 5 SECURITY HEADLINES

Each story includes why it matters and what to do next — no vendor fluff.

1. Phishing Campaign Exploits Google Cloud Automation to Bypass Email Security

Check Point researchers uncovered a sophisticated campaign where attackers abused Google Cloud Application Integration's "Send Email" feature to distribute 9,394 malicious emails to approximately 3,200 organizations. The emails originated from Google's authentic address ([email protected]), perfectly passing SPF, DKIM, and DMARC validation. The three-stage attack chain started with trusted storage.cloud.google.com links, moved through fake CAPTCHA validation on googleusercontent.com, and terminated at credential harvesting pages.

Why this matters: This represents a paradigm shift in email security. Traditional defenses fail completely because the email is legitimate from a technical standpoint—only the intent is malicious. Organizations with cloud-dependent architectures have inherently trusted Google infrastructure, creating exploitable blind spots. The campaign's targeting (48.6% US, heavy focus on manufacturing, technology, and financial services) suggests attackers specifically exploit enterprises' trust relationships with major cloud providers.

Action for defenders: Implement behavioral analytics that identify suspicious patterns regardless of sender authentication. Monitor for unexpected Application Integration notifications in environments not using this service, analyze multi-hop link redirection chains, and flag urgent credential requests even from authenticated cloud services. Update security awareness training to emphasize that @google.com emails can be malicious when features are abused.

2. GitLab patches a high-severity 2FA bypass affecting self-managed instances

What happened: GitLab fixed CVE-2026-0723, enabling 2FA bypass/account takeover in certain conditions; self-managed users were urged to upgrade (GitLab.com not impacted).

Why it matters (enterprise CloudSec):

  • GitLab is a supply chain and identity chokepoint. Account takeover can become: CI/CD secret theft → pipeline tampering → cloud key exfiltration.

  • Many orgs treat “developer systems” as separate from “cloud security” but this is exactly where cloud compromises start.
    Mitigation / next steps (30–60 mins):

  • Upgrade GitLab self-managed to patched versions; confirm coverage.

  • Rotate high-value CI/CD secrets, audit recent runner registrations, and review pipeline edits for anomalies.

    Sources: TechRadar

3. Microsoft 365 outage: resilience gaps become security gaps

What happened: A major service disruption on 22 Jan 2026 impacted Microsoft 365 services; Microsoft attributed it to service infrastructure not processing traffic as expected during remediation/maintenance.

Why it matters (enterprise CloudSec):

  • Outages create “security brownouts”: broken logging pipelines, delayed alerts, impaired incident comms, and even conditional access dependencies.

  • If your IR plan assumes M365 is always available, you risk losing coordination during a real incident.
    Mitigation / next steps (30–60 mins):

  • Add “SaaS outage mode” to IR: alternate comms channel, offline runbooks, and a plan for identity disruptions.

  • Test whether your SIEM/SOAR continues ingesting critical telemetry during provider degradation.

Sources: TechRadar

4. Anthropic patched flaws in its Git MCP server agentic tooling expands the attack surface

What happened: Reporting described vulnerabilities in Anthropic’s Git MCP server where chained configurations could enable file tampering or even code execution risks in some setups; patches were issued.

Why it matters (enterprise CloudSec):

  • MCP/agent tooling turns connectors into execution-adjacent infrastructure.

  • The risk is rarely “the model got hacked” and more “connectors + permissions + tool calls created a new path to repos/secrets/build systems.”
    Mitigation / next steps (30–60 mins):

  • Treat MCP servers like privileged integrations: least privilege tokens, egress controls, allowlisted repos, auditing.

  • Separate tool permissions: read-only vs write/execute by default; require explicit approvals for destructive actions.

Sources: TechRadar

5. OVHcloud Acquires Seald for Zero-Knowledge End-to-End Encryption

OVHcloud announced acquisition of French encryption company Seald to natively embed end-to-end encryption across OVHcloud services, where only end users can decrypt content. This represents a move toward confidential-by-default SaaS patterns protecting data from intermediaries, including cloud operators and administrators.

Why this matters: Customer-controlled cryptography fundamentally changes the threat model for sensitive workloads. When cloud providers can't access plaintext data, entire classes of insider threats, government access requests, and supply chain compromises become irrelevant. This acquisition pressures competing cloud and SaaS providers to offer similar capabilities or risk losing security-conscious enterprises.

Action for defenders: Identify workloads that should migrate from "encryption at rest" to true E2EE or client-side encryption—collaboration content, secrets repositories, regulated documents. Critically, validate how this impacts eDiscovery requirements, DLP effectiveness, key recovery procedures, and insider threat controls before broad adoption.

Source: OVHcloud

🎯 Cloud Security Topic of the Week:

Definitions and Core Concepts đź“š

Before diving into our insights, let's clarify some key terms:

  • Living Off the Cloud (LOTC): Attack technique where threat actors weaponize legitimate cloud platform features and services to conduct malicious activities, analogous to "Living Off the Land" tactics in traditional endpoint security. Examples include abusing Google Cloud Application Integration for phishing or using Azure Copy for data exfiltration.

  • Model Context Protocol (MCP): Framework enabling AI agents to interact with external systems through standardized connectors. MCP servers act as bridges between language models and tools like Git repositories, databases, or APIs, expanding AI capabilities while creating new integration security challenges.

  • Zero-Knowledge Encryption (E2EE): Cryptographic architecture where service providers cannot access plaintext data because encryption/decryption occurs exclusively on client devices using keys the provider never possesses. Differs from standard "encryption at rest" where cloud providers control encryption keys.

  • Behavioral Analytics: Security monitoring approach that establishes baselines of normal activity patterns and identifies deviations indicating potential threats, rather than relying solely on signature-based detection or known indicators of compromise.

  • SPF/DKIM/DMARC: Email authentication protocols (Sender Policy Framework, DomainKeys Identified Mail, Domain-based Message Authentication Reporting & Conformance) designed to verify sender legitimacy and prevent spoofing. These protocols fail when attackers abuse legitimate services rather than spoofing domains.

This week's issue is sponsored by Prowler 

The world’s most widely adopted open cloud security platform

Trusted by modern cloud security teams, Prowler detects vulnerabilities and misconfigurations, prioritizes risk, accelerates remediation, and delivers audit-ready compliance reports.

With 44M+ downloads, 12K+ GitHub stars, and 300+ contributors, Prowler is the open standard for cloud security.

Ask Lighthouse AI security questions just like a trusted colleague. Get actionable insights and remediation plans instantly. Secure your cloud programmatically with the Prowler MCP server.

💡Our Insights from this Practitioner 🔍

AI Security 2026 Predictions: The "Zombie Tool" Crisis & The Rise of AI Platforms(Full Episode here)

The Trust Inversion: When Authentication Becomes the Attack Vector

The Google Cloud phishing campaign and AI tooling vulnerabilities represent what Caleb Sima identifies as a fundamental inversion in cloud security assumptions. "We've spent decades building authentication and authorization systems that grant access based on identity verification," Sima explains. "But when attackers operate through legitimately authenticated services—whether that's Google Cloud Application Integration or Azure Copy—they inherit the trust we've built into our architectures."

This observation captures why traditional email security failed completely against the Google Cloud abuse. The emails passed every authentication check because they were authentic. SPF records validated correctly, DKIM signatures were genuine, and DMARC policies approved the messages—all technically correct because Google's infrastructure was being used as designed, just with malicious intent.

Ashish Rajan emphasizes the architectural implications: "The challenge for cloud security teams is that we've optimized our defenses around perimeter thinking—trusted versus untrusted, internal versus external. Cloud platforms dissolve these boundaries. When an attacker uses Azure Copy to exfiltrate data, they're not breaching a perimeter; they're using the exact same APIs your employees use for legitimate file synchronization."

Building Detection That Survives Trust Exploitation

The failure of authentication-based trust requires a fundamental shift in detection strategies. Sima advocates for what he terms "intent-level verification" rather than identity-level verification: "You can't ask 'is this sender authenticated?'—you have to ask 'does this authenticated action make business sense?' That requires understanding context, relationships, and patterns."

This approach directly addresses the Google Cloud phishing campaign's success. A behavioral analytics system wouldn't focus on whether the email came from @google.com—it would flag that an organization not using Google Cloud Application Integration suddenly received urgent credential requests through that service, or that a link chain traversed multiple Google domains (storage.cloud.google.com → googleusercontent.com) before landing on a credential harvesting page.

Rajan provides practical implementation guidance: "Start by inventorying which cloud services your organization legitimately uses and which features within those services are actually enabled. If you don't use Google Cloud Application Integration, any email from that service should be investigated. If you don't use Azure Copy for cross-region replication, large data movements through that tool deserve scrutiny regardless of who initiated them."

The Anthropic MCP vulnerabilities reinforce this principle. As AI agents gain deployment, Sima notes that "AI connectors are execution-adjacent infrastructure masquerading as data integrations. You need to treat them with the same security rigor as CI/CD pipelines or database connection pools—least privilege, segregated networks, comprehensive logging, and continuous verification of what they're accessing."

Architectural Patterns for Zero-Trust Cloud Operations

Both experts emphasize that addressing trust exploitation requires architectural decisions, not just operational adjustments. The OVHcloud acquisition of Seald exemplifies one pattern: moving toward cryptographic guarantees that remain valid even when cloud providers or attackers gain administrative access.

"Zero-knowledge encryption fundamentally changes your threat model," Sima explains. "When the cloud provider literally cannot decrypt your data, entire categories of risk—insider threats, government access requests, supply chain compromises—become architecturally impossible rather than operationally mitigated."

However, Rajan cautions about implementation complexity: "True E2EE creates operational trade-offs. You need to solve key management, ensure key recovery mechanisms exist for legitimate business needs, and recognize that security controls like DLP and eDiscovery that rely on inspecting plaintext content will need architectural redesign. Organizations implementing customer-controlled encryption need to think through these implications before deployment."

For organizations not ready for zero-knowledge architectures, both experts advocate defense-in-depth patterns that assume breach even of trusted services. Sima recommends: "Implement egress monitoring that tracks data movements regardless of tool legitimacy. Deploy network segmentation that limits blast radius even when credentials are compromised. Build incident response procedures that don't assume availability of cloud services you depend on."

The Microsoft 365 outage crystallizes this point. Rajan notes: "If your incident response runbooks assume M365 is available, you've created a single point of failure. When that platform goes down during an active incident, you lose logging, alerting, identity verification, and team communications simultaneously. Building resilience requires alternative channels and offline contingencies."

Operationalizing Security for AI Agent Deployments

The Anthropic Git MCP vulnerabilities reveal emerging challenges as AI agents gain broader deployment. Sima emphasizes treating these integrations with heightened scrutiny: "When you connect an AI agent to your Git repositories or cloud APIs, you're creating an execution path from natural language prompts to privileged operations. That pathway needs the same controls you'd apply to any other automation with similar privileges."

Practical implementation includes several critical patterns. First, enforce strict separation between read and write capabilities: "An AI agent analyzing code should have read-only repository access. An agent that creates pull requests needs write access, but that should be a separate, more restricted deployment with comprehensive audit logging."

Second, implement allowlisting at multiple levels. Rajan recommends: "Don't give an AI connector access to all repositories—explicitly define which repos it can access. Don't allow arbitrary tool invocations—define specific, approved actions. Each layer of restriction reduces the potential blast radius if the integration is compromised or behaves unexpectedly."

Third, deploy egress controls and network segmentation: "AI connectors should operate in isolated network segments with explicit egress rules. If your AI agent only needs to access internal Git repositories, it shouldn't have general internet access that could be exploited for data exfiltration."

Practical Response to Living Off the Cloud Threats

Both experts provide concrete guidance for organizations responding to the current threat landscape. For email security in light of the Google Cloud phishing campaign, Sima advocates immediate tactical adjustments: "Update security awareness training to explicitly address the fact that emails from @google.com, @microsoft.com, or other major providers can be malicious when features are abused. Employees need to verify through alternative channels before responding to urgent credential requests, regardless of sender authenticity."

Technically, implement advanced threat protection capable of analyzing entire link redirection chains rather than just first-hop URLs. "The Google Cloud campaign used multi-stage redirections specifically because traditional email security only examines initial links. You need systems that follow the complete chain and flag suspicious patterns like traversing multiple domains before reaching a credential input form."

For cloud data exfiltration risks, Rajan recommends: "Implement data classification and sensitivity-based monitoring. Large movements of sensitive data should trigger investigation regardless of the tool used. If someone uses Azure Copy to move 500GB of customer records to an external storage account, that deserves immediate scrutiny even if the operation was executed through legitimate APIs with valid credentials."

Organizations should also audit their cloud service usage comprehensively: "Many enterprises have cloud services and features enabled that nobody remembers authorizing. Conduct an inventory of what's actually in use, disable features you don't need, and implement monitoring for unexpected usage of services that shouldn't be active in your environment."

Building Resilience Against SaaS Concentration Risk

The Microsoft 365 outage highlights systematic risks from cloud service concentration. Sima advocates for explicit "SaaS outage mode" planning: "Your incident response procedures need to work when the services you depend on are unavailable. That means alternative communication channels, offline copies of runbooks, cached contact lists, and contingency plans for identity system failures."

Testing is critical: "Actually simulate a Microsoft 365 outage during a security exercise. Can your SIEM still ingest logs? Can your team coordinate response activities? Can you verify user identities when conditional access policies can't be evaluated? Most organizations discover significant gaps when they actually test these scenarios."

Rajan adds: "Consider geographic and provider diversity for critical security functions. If all your logging, alerting, identity, and communication runs through a single cloud provider, you've created systemic risk. Building resilience might mean deploying backup SIEM infrastructure on a different cloud platform or maintaining secondary communication channels that don't share dependencies with your primary systems."

Strategic Evolution: From Perimeter to Continuous Verification

Both experts see the current threat landscape as accelerating a necessary evolution in cloud security thinking. Sima articulates the strategic shift: "The perimeter model assumed that once you verified identity and granted access, you could trust subsequent actions. Cloud environments require continuous verification—every action needs to be evaluated for business legitimacy regardless of who's performing it."

This manifests in specific architectural decisions. Organizations should implement just-in-time access elevation rather than standing privileges, require business justification for sensitive operations even when performed by authorized users, and deploy comprehensive behavioral analytics that establish normal patterns and flag deviations.

Rajan emphasizes the cultural dimension: "Senior cloud security professionals need to advocate internally for realistic threat models. If your organization assumes that authentication from Google or Microsoft guarantees benign intent, you need to change that assumption at the leadership level. The Google Cloud phishing campaign proves that authenticated ≠ safe."

The path forward requires accepting architectural complexity in exchange for resilience. "Building secure cloud environments means layering controls that remain effective even when outer layers are bypassed," Sima concludes. "Defense in depth isn't just good practice—it's the only viable strategy when attackers operate through channels you've explicitly trusted."

Question for you? (Reply to this email)

🤔  How do you balance AI adoption speed with security controls are your developers choosing secure paths or working around them?

Next week, we'll explore another critical aspect of cloud security. Stay tuned!

📬 Want weekly expert takes on AI & Cloud Security? [Subscribe here]”

We would love to hear from you📢 for a feature or topic request or if you would like to sponsor an edition of Cloud Security Newsletter.

Thank you for continuing to subscribe and Welcome to the new members in tis newsletter communityđź’™

Peace!

Was this forwarded to you? You can Sign up here, to join our growing readership.

Want to sponsor the next newsletter edition! Lets make it happen

Have you joined our FREE Monthly Cloud Security Bootcamp yet?

checkout our sister podcast AI Security Podcast