Hello from the Cloud-verse!

This week’s Cloud Security Newsletter topic: When AI Plays Both Sides: Rethinking SOC Architecture in the Era of 29-Minute Breakouts (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 security landscape shifted this week not because of a single breach, but because of three signals that point to a structural change in cyber defense.

First, CrowdStrike’s 2026 Global Threat Report revealed that the average adversary breakout time is now 29 minutes, with the fastest intrusion completing lateral movement in 27 seconds.

Second, IBM’s X-Force Index shows vulnerability exploitation overtaking phishing as the #1 initial access vector, driven by automated vulnerability discovery and AI-assisted attacks.

Third, Google and Mandiant disrupted a PRC-linked campaign that hid command-and-control traffic inside Google Sheets API calls, bypassing traditional allowlists.

Together, these developments point to a clear conclusion:

Defensive response timelines are now measured in minutes, not hours.

To understand what this means for enterprise SOC architecture, this week’s featured expert Edward Wu, Founder of DropZone AI, explains why the future SOC model is increasingly becoming:

“Humans set strategy. AI executes.”  [Listen to the episode]

⚡ TL;DR for Busy Readers

• Attackers now break out in 29 minutes.
  If your MTTD + MTTR exceeds this, lateral movement is statistically likely.

• PRC-linked attackers used Google Sheets as covert C2.
  ➡️ Audit Google API usage and service account behavior now.

• Microsoft launched native CIEM across AWS, GCP, and Azure.
  ➡️ Expect a surge of overprivileged identity findings after enabling.

• Vulnerability exploitation is now the #1 attack vector (IBM).
  ➡️ Prioritize unauthenticated CVE patching and AI-generated code scanning.

• AI SOC analysts can now perform tier-1 investigations autonomously.
  ➡️ Start documenting environment context and response authorization policies.

📰 THIS WEEK'S TOP 4 SECURITY HEADLINES

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

1. CrowdStrike 2026 Global Threat Report: AI Compresses Adversary Breakout Time to 29 Minutes

WHAT HAPPENED

CrowdStrike's 2026 Global Threat Report documents a 65% increase in attack speed year-over-year. The average eCrime breakout time is now 29 minutes; the fastest observed breakout: 27 seconds; in one intrusion, exfiltration began within four minutes of initial access. AI is operating as both accelerant and new attack surface: adversaries exploited legitimate GenAI tools at 90+ organizations via malicious prompt injection; exploited vulnerabilities in AI development platforms for persistence and ransomware staging; and published malicious AI servers impersonating trusted services. Russia-nexus FANCY BEAR deployed LLM-enabled malware (LAMEHUG) for automated recon; DPRK-nexus FAMOUS CHOLLIMA scaled insider operations via AI-generated personas. 82% of 2025 detections were malware-free.

WHY IT MATTERS

The 29-minute figure is not a metric to track it's a hard architectural constraint. If your MTTD + MTTR combined exceeds 29 minutes, lateral movement is statistically likely before containment begins. In cloud environments, where identity federation and service account trust chains enable rapid cross-account traversal, this window compresses further.

The GenAI prompt injection finding is the most operationally novel data point in the report. Adversaries are no longer exploiting software they are socially engineering software, tricking AI-enabled applications into misusing their own service credentials. This is insider threat detection applied to non-human identities.

🎯 Action: 

• Validate EDR/XDR detection coverage for malware-free intrusion patterns; establish DLP and governance controls for enterprise GenAI tool usage;

• Pressure-test detection gaps in AI development platform access (MLflow, SageMaker, Vertex AI);

• Benchmark MTTD + MTTR against the 29-minute breakout threshold.

👉 Read the CrowdStrike Threat Report →

👉🏾 Read the 2026 Browser Attack Techniques Report →

Sources: CrowdStrike Press Release | CrowdStrike Blog

2. Microsoft Embeds Native CIEM Across Azure, AWS, and GCP in Defender for Cloud

WHAT HAPPENED

Cloud Infrastructure Entitlement Management (CIEM) is now a native capability in Microsoft Defender for Cloud across all three major cloud platforms. Key changes: inactive identity detection now evaluates unused role assignments (not sign-in activity); the inactivity lookback window extends to 90 days (up from 45); CIEM onboarding no longer requires elevated high-risk permissions; and GCP Cloud Logging ingestion is available in preview. This update follows Microsoft's announced retirement of Entra Permissions Management Defender CSPM is now the defined migration destination.

WHY IT MATTERS

This is a meaningful consolidation with real procurement implications. Enterprises running Entra Permissions Management as a standalone CIEM tool now have a clear migration path. More consequentially, the shift from sign-in-based to role-assignment-based inactivity detection will surface a materially larger set of overprivileged identities especially service principals and managed identities in AWS and GCP that authenticate via service accounts rather than interactive login.

Expect an initial wave of new CIEM findings post-migration. The right move is to build a remediation workflow and establish a baseline before enabling at scale not to be caught flat-footed by hundreds of new recommendations on day one.

🎯 Action: 

• Plan CIEM migration from Entra Permissions Management before the retirement deadline;

• pre-build remediation workflows for the likely surge in overprivileged identity findings;

• pay particular attention to non-human identities (service principals, managed identities) that don't generate sign-in events.

Sources: Microsoft Learn Release Notes | Microsoft Tech Community | Microsoft Learn CIEM Overview

3. Google and Mandiant Disrupt PRC Espionage Campaign Abusing Google Sheets as Covert C2

WHAT HAPPENED

Google Threat Intelligence Group (GTIG), Mandiant, and partners took action to disrupt a global espionage campaign targeting telecommunications and government organizations across four continents. The threat actor UNC2814, a suspected PRC-nexus group tracked since 2017 achieved confirmed intrusions across 53 victims in 42 countries. Central to the campaign was the GRIDTIDE backdoor: a C-based malware that abuses the Google Sheets API as a communication channel to disguise C2 traffic. Google terminated all attacker-controlled Cloud Projects and released indicators of compromise.

WHY IT MATTERS

This campaign is a direct operational threat to any enterprise running Google Workspace or permitting Google APIs through their perimeter which is nearly every large organization. GRIDTIDE hides malicious traffic within legitimate cloud API requests, requiring no exploit and leaving no conventional network indicator: the backdoor is just another HTTPS call to googleapis.com.

Post-intrusion, the group moved laterally via SSH, escalated privileges, and deployed SoftEther VPN Bridge for persistent encrypted egress infrastructure metadata suggests active use since July 2018. Google expects UNC2814 to work to re-establish its footprint: this campaign is disrupted, not finished.

🎯 Action: 

• Audit Google Service Account creation and API access patterns in GCP/GWS;

• Deploy Google-provided search queries to scan for GRIDTIDE IOCs;

• build SIEM/NDR rules to flag anomalous Sheets API call volumes from non-browser user agents;

• treat SoftEther VPN traffic as a high-fidelity indicator.

Sources: Google Cloud Blog / GTIG | The Hacker News | Cybersecurity Dive | The Register | Infosecurity Magazine

4. IBM X-Force 2026: Vulnerability Exploitation Overtakes Phishing as #1 Attack Vector

WHAT HAPPENED

IBM's 2026 X-Force Threat Intelligence Index reports that vulnerability exploitation became the leading cause of attacks in 2025, accounting for 40% of incidents. A 44% increase in public-facing application attacks was driven by missing authentication controls and AI-enabled vulnerability discovery. Large supply chain and third-party compromises nearly quadrupled since 2020. X-Force tracked nearly 40,000 vulnerabilities in the year 56% of disclosed flaws required no authentication to exploit. AI-assisted coding tools are compounding the exposure, with unvetted generated code feeding insecure pipelines. Infostealer malware drove the exposure of 300,000+ ChatGPT credentials on dark web marketplaces, signaling that AI platforms now carry credential risk on par with core enterprise SaaS.

WHY IT MATTERS

The displacement of phishing by vulnerability exploitation as the leading initial access vector is a structural signal that should directly influence defensive investment allocation. The 56% of vulnerabilities requiring no authentication is particularly alarming in cloud-native environments, where public-facing APIs, serverless functions, and container ingress points routinely bypass traditional perimeter controls.

The 4x supply chain increase since 2020 is a direct indictment of CI/CD pipeline security maturity industry-wide. For teams embracing AI-assisted development, the risk compounds: AI-generated code is entering pipelines faster than security reviews can keep pace, and attackers know it.

🎯 Action: 

• Prioritize unauthenticated CVE remediation in patch queues;

• extend SAST/SCA coverage into AI-generated code outputs;

• audit third-party SaaS integration trust chains;

• apply credential hygiene controls to enterprise AI platform accounts (ChatGPT Enterprise, Copilot, Claude) as you would to identity providers.

Sources: IBM Newsroom | IBM X-Force Report | Industrial Cyber

🎯 Cloud Security Topic of the Week:

When AI Plays Both Sides:
Rethinking SOC Architecture in the Era of 29-Minute Breakouts

There is a quiet but consequential arms race underway inside enterprise security operations, and it's not playing out in the way most security leaders initially anticipated. The fear was that AI would produce dramatically more sophisticated attacks autonomous, multi-stage campaigns executing end-to-end. The reality, as Drop Zone AI's Edward Wu explains, is more operationally challenging in a different way: AI has fundamentally changed the economics and speed of attack preparation and initial access, even before it automates full campaigns end-to-end.

This week's CrowdStrike report puts a precise figure on what that means for defenders: 29 minutes from initial access to lateral movement, with a fastest-ever 27-second observed breakout. The question for every cloud security leader is not whether their SIEM caught the alert, it's whether their entire detection and response pipeline, from signal to containment action, can complete within that window.

For cloud environments specifically, the challenge is amplified. Identity federation, service account trust chains, and cross-account IAM relationships mean that a single compromised credential can traverse from one AWS account to an entire organization's environment far faster than a traditional on-prem lateral movement scenario. The GRIDTIDE campaign disclosed this week is a concrete illustration: no exploit, no conventional indicator, just legitimate API calls that an overwhelmed tier-1 analyst reviewing a queue of 300 alerts would have no reasonable way to flag in time.

Edward Wu's framing of the solution is worth sitting with: not "AI replaces humans in the SOC," but "humans set strategy, AI executes." The three components of human strategy he identifies: scope of work, scope of authorization, and business context are exactly the kinds of decisions that cannot be automated, and exactly what most security teams are still trying to find time to make amid a flood of alerts. That is the real asymmetry to close.

Featured Experts This Week 🎤

• Edward Wu- Founder & CEO | Dropzone AI

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

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

• AI SOC Analyst An AI agent category designed to autonomously investigate security alerts at tier-1 analyst quality or above. Tools in this category (such as Drop Zone AI) analyze alert data, correlate with environmental context, and produce investigation outputs without requiring a human analyst to review each alert from scratch.

• Prompt Injection An attack technique targeting AI-enabled applications whereby malicious input is crafted to override or manipulate the application's intended behavior. In an enterprise security context, this translates to a service account being "social engineered" tricked into performing actions outside its intended scope, generating behavioral anomalies detectable by SOC tooling.

This week's issue is sponsored by Push Security

Learn how browser-based attacks have evolved — get the 2026 report

Most breaches today start with an attacker targeting cloud and SaaS apps directly over the internet. In most cases, there’s no malware or exploits. Attackers are abusing legitimate functionality, dumping sensitive data, and holding companies to ransom. This is now the standard playbook. 

The common thread? It's all happening in the browser. 

Get the latest report from Push Security to understand how browser-based attacks work, and where they’ve been used in the wild, breaking down AitM attacks, ClickFix, malicious extensions, OAuth consent attacks, and more. 

💡Our Insights from this Practitioner 🔍

Keeping up with the 29min Attacker Window as SOC (Full Episode here)

The Analytics Gap Is Not a Headcount Problem It's an Architecture Problem

Edward Wu has spent more than a decade at the intersection of alert generation and alert investigation. Eight years at Actual Hub Networks building NDR detection systems gave him an unusually clear view of a dynamic that most security teams experience as a chronic background stressor: the volume of alerts is structurally outpacing the capacity to process them. What's changed and why he founded Drop Zone AI is that AI agents have reached the point where they can close that gap operationally, not just theoretically.

"We believe that humans alone are insufficient to close this asymmetric capacity gap. Silicon and electricity can perform a lot of analysis for pennies on the dollar and can really help plug this ever-expanding analytical gap between the analytics required to sufficiently protect the organization and the limited capacity constrained by headcount, budget, and staffing." Edward Wu

This isn't a vendor pitch, it's a structural observation that the CrowdStrike and IBM data this week substantiates. Alert volumes are growing 30% year-over-year, attack surfaces are expanding as cloud-native infrastructure proliferates, and the window between initial access and lateral movement has collapsed to 29 minutes. The math has changed. A human-only tier-1 process simply cannot operate at the required speed and scale.

What AI Can Actually Do Today And What It Can't

Wu is careful to distinguish between the current reality of AI-assisted attacks and the inevitable future. Today, attackers are using LLMs for the early stages of campaigns, highly personalized spear-phishing at scale, automated reconnaissance, and AI-assisted vulnerability discovery and exploit generation in the AppSec domain. Full end-to-end autonomous attack campaigns of 10 to 15 steps? Not yet. But trending there quickly.

"We have not seen AI agents end-to-end performing a 10-step or 15-step attack campaign but we have absolutely seen a lot of cases of AI-generated, very personalized spear-phishing emails, and AI utilization in the early reconnaissance phase. And the world is trending toward autonomous end-to-end campaigns." Edward Wu

On the defense side, the picture is more mature. Wu reports that Drop Zone's AI SOC analyst is delivering investigation quality at or above a typical tier-1 human analyst, autonomously and at scale, across 300+ customer environments. The company has processed the equivalent of 160 years of human alert investigations through software alone. Hallucination concerns, once a legitimate objection, have proven to be largely an artifact of poor context management rather than fundamental model limitations.

The MSSP Model Is Transforming Whether MSSPs Know It Or Not

One of the most practically useful threads in Wu's conversation concerns managed security service providers. The traditional MSSP model allocating fractional analyst time across dozens of clients has a structural flaw that Wu names directly: customizability. An analyst covering 50 clients cannot internalize what constitutes normal behavior in each environment. Clients consistently cite this as their primary complaint.

What Wu observes at the leading edge of the MSSP market is a shift from 100% human-delivered service models to 80–90% AI-delivered outcomes, with human analysts focused on the final 10%. This is not cost-cutting, it's the only viable model at the speed and accuracy levels the threat landscape now demands. Simultaneously, some enterprises that previously outsourced tier-1 triage to MSSPs are bringing that function in-house, replacing the MSSP relationship with AI tooling for staff augmentation.

The 'Human Strategy, AI Execution' Model

Wu's clearest articulation of how this architecture works in practice centers on three components of human responsibility that AI cannot substitute for:

• Scope of work: Humans must define what the AI investigates, what alert types matter, and what threat hunts are in scope for the organization's risk profile.

• Scope of authorization: Humans must determine what actions the AI can take autonomously containing a host, disabling a user account, escalating an alert and under what conditions. This is a governance and liability question, not just a technical one.

• Business context: No AI system can read minds. The organization's operational knowledge which service account behaviours are normal, which integrations are expected, which IP ranges belong to trusted partners must be materialized in an accessible format.

"Making your context knowledge accessible to that system whether it's an AI agent like Drop Zone, or a human coworker is vitally important. We've seen cases where using AI to generate a structured onboarding survey, then having practitioners fill it out, can bootstrap an AI agent's understanding of your environment very quickly." Edward Wu

This framing has direct implications for how cloud security teams should approach AI adoption in their SOC. The work of writing down your environmental context: what's normal, what matters, what the AI is authorized to do is not overhead. It is the core governance activity that makes the entire model functional. It also doubles as institutional knowledge documentation that survives analyst turnover.

Prompt Injection as a SOC Detection Problem

Wu's perspective on prompt injection offers a useful reframe for security teams trying to operationalize this emerging risk. Prompt injection, he argues, is not a new detection category requiring a new toolset. It is insider threat detection applied to non-human identities.

When a malicious prompt tricks a GenAI application into misusing its service credential to read 50GB of data from an internal repository, that activity shows up as an anomalous behavioural alert the same kind a behavioural analytics engine would generate for a compromised human account. The investigation question is identical. The difference is that cloud security teams may not have yet baselined their AI application service accounts with the same rigor they apply to privileged human identities.

This is an under appreciated gap. As enterprises deploy AI assistants, code generation tools, and agent workflows, each operates with a service credential. Until those identities are baselined, monitored, and governed with the same discipline applied to human privileged access, they represent an uninvestigated attack surface.

RELATED RESOURCES 🎧

• Drop Zone AI

• CISA AI Security Guidance for Critical Infrastructure

• NIST AI Risk Management Framework

• MITRE ATLAS Adversarial Threat Landscape for AI Systems

Cloud Security Podcast

• Cloud Security Podcast Episode with Edward Wu

Question for you? (Reply to this email)

🤔 If your SOC deployed an AI investigation agent tomorrow, what is the first action you would allow it to take autonomously?

• Disable user account
• Isolate host
• Block token/session
• None — humans only

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!

Shilpi Bhattacharjee

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

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter topic: The AI Security Blueprint: A Maturity-Staged Framework for Enterprise AI Governance (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

If this week had a single unifying signal it was this: the AI systems your organisation is deploying faster than ever are becoming the attack surface. From a weaponised npm package silently installing an autonomous AI agent on developer machines, to a Russian nation-state actor using legitimate SaaS webhooks to exfiltrate data without touching a single CVE, to ransomware operators now confirmed exploiting a CVSS 9.9 pre-auth RCE in one of the enterprise's most privileged remote access tools   the threat actors are not waiting for your AI governance programme to catch up.

This week's guest, Shannon Murphy, Senior Researcher and AI Security Strategist at TrendAI, has spent the last five years working directly with CISOs, CTOs, and cloud security architects on exactly this problem. In a wide-ranging conversation with Cloud Security Podcast host Ashish Rajan, Shannon lays out a clear-eyed AI security blueprint   grounded not in theory but in the patterns she observes across enterprise field engagements   covering data governance, agent identity, shift-left for AI, and how to build a cross-functional governance committee that actually holds.

We also cover the Cisco State of AI Security 2026 report revealing that 71% of enterprises are deploying agentic AI they cannot secure, and Microsoft's new Security Dashboard for AI now in public preview. The news this week is not background noise, it is a live demonstration of every risk Shannon describes.[Listen to the episode]

🎯 Two Actions to Take This Week

👉 Patch or isolate BeyondTrust immediately
👉 Audit every AI agent in CI/CD and restrict token scope

The AI readiness gap is no longer theoretical.
It’s operational risk.

📰 TL;DR for Busy Readers

• BeyondTrust CVE-2026-1731 (CVSS 9.9) is confirmed
  Patch to RS 25.3.2 / PRA 25.1.1 immediately or isolate from internet exposure.

• Cline npm supply chain attack

  • Prompt injection used to steal publish credentials.
    → Enforce 48-hour npm version hold.
    → Audit AI agent permissions in CI/CD.

• Cisco's 2026 AI Security report:

  • 83% deploying agentic AI. Only 29% ready.
    → Treat the readiness gap as a funded backlog item.

• Microsoft's Security Dashboard for AI (public preview) 

  • First Unified AI asset inventory across Defender, Entra, Purview.
    → Enable this week and export your first AI asset register.

📰 THIS WEEK'S TOP 4 SECURITY HEADLINES

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

1. BeyondTrust CVE-2026-1731 (CVSS 9.9)

What Happened: What began as a critical disclosure on February 6 escalated this week into confirmed ransomware exploitation across multiple sectors. BeyondTrust's own telemetry indicates active exploitation started January 31 a full week before public disclosure   making CVE-2026-1731 a zero-day in retrospect. The flaw is an OS command injection vulnerability in the thin-scc-wrapper component of BeyondTrust Remote Support (RS) and Privileged Remote Access (PRA), exposed via WebSocket and exploitable without authentication. A public PoC dropped February 10; GreyNoise observed mass scanning within 24 hours. CISA added it to the KEV catalog on February 13 with a 72-hour remediation mandate for federal agencies and updated the KEV entry on February 19 to activate the ransomware exploitation flag.

Palo Alto Networks Unit 42 confirmed active exploitation this week across finance, legal, healthcare, higher education, and retail in the US, France, Germany, Australia, and Canada. Observed post-exploitation activity includes VShell and SparkRAT deployment, web shell installation, PostgreSQL database exfiltration, and lateral movement.

Why it matters to you: BeyondTrust RS and PRA are privileged access tools by design they carry SYSTEM-level authority over every managed endpoint. An unauthenticated RCE on these appliances is effectively a master key to your entire managed estate. With 11,000+ internet-exposed instances confirmed and ransomware actors now actively pre-positioning, treat this as an active incident response situation, not a patch management queue item.

👉 Download Unit 42 IOCs and validate exposure this week.

Sources: BleepingComputer · SecurityWeek · SC Media

2. Cline CLI npm Supply Chain Attack Prompt Injection Weaponised to Steal Publish Credentials and Deploy OpenClaw

What happened: On February 17, a threat actor used a stolen npm publish token to release cline@2.3.0   a poisoned update to Cline CLI, a popular AI-powered coding assistant with approximately 90,000 weekly npm downloads. A single postinstall script silently ran npm install -g openclaw@latest on any machine installing the package. The malicious version was live for approximately eight hours. StepSecurity estimated roughly 4,000 downloads of the compromised version.

What makes this attack structurally significant is the initial access vector: security researcher Adnan Khan had disclosed on February 9 that Cline's Claude-powered GitHub issue-triage workflow was vulnerable to prompt injection. A crafted GitHub issue could cause the AI agent to execute a malicious payload, poison the GitHub Actions cache, and pivot to steal the npm publish token. Cline patched the triage workflow within 30 minutes   but rotated the wrong token. Eight days later, the still-valid token was used to publish the malicious package. The payload, OpenClaw, is a legitimate open-source AI agent with broad system access (full disk, terminal, persistent WebSocket daemon) and a known critical CVE (CVE-2026-25253, CVSS 8.8) in versions prior to 2026.1.29 allowing unauthenticated operator access.

Why it matters to you: This attack introduces a materially new threat model: prompt injection against AI agents in CI/CD pipelines as an initial access technique for credential theft. The entry point was not a phishing email or a code vulnerability, it was a GitHub issue. Any organisation using LLM-powered bots to automate repository triage, PR review, or release workflows with access to production secrets is now a viable target for this attack pattern. This connects directly to Shannon Murphy's warning that agentic AI is creating new blind spots that existing DLP and AppSec tooling cannot cover.

👉 If your AI agent can push code, it must be governed like a privileged identity.

Sources: The Hacker News · Dark Reading · Snyk Deep-Dive · StepSecurity Detection Report

3. Cisco "State of AI Security 2026"- 71% of Enterprises Are Deploying Agentic AI They Cannot Secure

What happened: Cisco's AI Threat Intelligence & Security Research team released its flagship annual report on February 19, with Help Net Security publishing a practitioner-focused analysis on February 23. The report documents three compounding risks: rapid agentic AI deployment outpacing security readiness; a fragile AI supply chain with documented tool poisoning and MCP ecosystem vulnerabilities; and adversarial techniques   particularly prompt injection and jailbreaks   maturing from research concepts into documented real-world exploits. Key statistic: 83% of surveyed organisations plan to deploy agentic AI into business functions; only 29% feel ready to secure those deployments.

Documented incidents include a GitHub MCP server compromise in which a malicious issue injected hidden instructions that hijacked an agent and exfiltrated private repository data. The report also covers a fake npm package mimicking an email integration that silently forwarded outbound messages to attacker infrastructure   a pattern strikingly consistent with the Cline incident reported in the same week. Cisco's researchers demonstrated that open-weight models remain susceptible to multi-turn jailbreaks at significantly higher success rates than single-turn attacks.

Why it matters to you: The report crystallises what security leaders are observing operationally: AI agents are being granted authority to execute tasks, query databases, modify code, and interact with external services   often without the controls that would be non-negotiable for a human performing the same actions. The agent-to-agent trust problem is particularly acute. For cloud security teams, the MCP attack surface deserves immediate attention; Cisco has released open-source scanners for MCP, A2A, and agentic skill files as companion tooling. The 71% readiness gap is not a statistic to present to leadership   it is a project backlog. This data is the empirical foundation for every strategic recommendation Shannon Murphy makes in this week's feature.

👉 Use this data in your next board update and tie it to funded remediation.

Sources: Cisco AI Security Blog (Primary) · Help Net Security · Cisco Report

4. Microsoft Launches Security Dashboard for AI in Public Preview - Unified CISO Visibility Across the Enterprise AI Estate

What happened: Microsoft released the Security Dashboard for AI into public preview on February 16, available across enterprise tenants with eligible Defender, Entra, and Purview subscriptions at no additional cost. Accessible at ai. security. microsoft. com, the dashboard aggregates real-time risk signals from all three platforms into a single governance interface designed for CISOs and AI risk leaders. Core capabilities include: a comprehensive AI asset inventory spanning Microsoft 365 Copilot agents, Copilot Studio agents, Azure AI Foundry deployments, MCP servers, and third-party AI applications including OpenAI, Google Gemini, and ChatGPT tenant integrations; an AI risk scorecard with posture drift tracking; correlated risk views linking Purview data sensitivity signals with Entra identity context and Defender threat alerts; and delegated remediation actions. Security Copilot is embedded for natural-language investigation.

Why it matters to you: This announcement directly addresses the shadow AI problem Shannon Murphy identifies as the critical first milestone in any AI security programme: you cannot govern what you cannot see. The dashboard's AI inventory discovery function is the operationalisation of that principle   and for organisations already invested in the Microsoft security stack, it is immediately actionable. The dashboard also directly addresses the data leakage risk Cisco independently flags in this week's AI Security report: oversharing detection in Purview integration targets agents with overly broad data permissions, one of the most prevalent enterprise AI exposure patterns observed in 2025. For organisations not on the Microsoft stack, this announcement raises the competitive bar for what a mature CNAPP or CSPM vendor must now offer in AI security posture management.

Enable it. Export inventory. Start governance.

Sources: Microsoft TechCommunity (Primary) · Help Net Security · Microsoft Learn Docs

🎯 Cloud Security Topic of the Week:

The AI Security Blueprint: A Maturity-Staged Framework for Enterprise AI Governance

One of the clearest themes emerging from Shannon Murphy's conversation is that most organisations are attempting to govern AI deployments using frameworks and tool stacks designed for a deterministic, pre-AI world   and that gap is not theoretical. It is showing up in the Cisco report's 71% readiness gap, in the Cline supply chain attack, and in the data leakage scenarios Shannon describes from real enterprise field engagements.

The AI security blueprint she outlines is structured around three maturity stages   adopter, builder, and scaler   each with distinct risk profiles and corresponding security requirements. What makes this framework practically valuable is that Shannon explicitly states the underlying philosophy remains consistent across all three stages: discover, assess, prioritise, mitigate. The level of security capability scales with the attack surface; the methodology does not change.

Stage-1 - Adopter: Organisations in productivity-gain mode face their highest risk from data governance failures and over-permissioned AI access.

Primary Risk: Shadow AI & Data Exposure
Objective: Real-time AI asset visibility

Deliverable:
Continuously updated AI inventory not a spreadsheet.

Stage-2 - Builder: Development teams building internal AI tools or going to market with AI-powered products face all of the adopter risks plus the application security and supply chain risks illustrated by the Cline attack this week.

Primary Risk: Supply chain & application security
Add:

• AI-specific vulnerability scanning

• Container security

• Runtime monitoring

• Agent identity governance

Shift-left is necessary.
Runtime monitoring is mandatory.

Stage-3-  Scaler: Organisations investing in AI factories and enterprise-wide automation are operating in what Shannon describes as an inferencing security paradigm: continuous monitoring of live AI systems for behavioural drift, adversarial manipulation, and agent-to-agent trust failures.

Primary Risk: Inferencing Security & Agent-to-Agent Trust
Objective:Treat agents as identities:

• Scoped permissions

• Short-lived credentials

• Access governance

• Continuous behavioural monitoring

DSPM becomes foundational here.

Featured Experts This Week 🎤

• Shannon Murphy- Senior Researcher & AI Security Strategist | TrendAI

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

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

• Agentic AI
  Autonomous systems executing multi-step tasks via tool calls.

• Prompt Injection
  Malicious instructions embedded in data processed by AI agents.

• Model Context Protocol (MCP)
  Standard defining how agents discover and call tools.

This week's issue is sponsored by AI Security Podcast

💡Our Insights from this Practitioner 🔍

How to Build an AI Security Program from Scratch. (Full Episode here)

1. Why 95% of AI Projects Fail   and What Security Owns in the Answer

Shannon opens with a striking data point from an MIT study that circulated widely in the security community: 95% of AI projects are failing. Her diagnosis is direct:

"Any security leader who attempts to drive an AI governance strategy in a silo will fail. 95% of AI projects are failing because we're not having all the stakeholders at the table."   Shannon Murphy, TrendAI

The failure pattern she describes is recognisable to anyone who has watched a well-intentioned AI governance initiative stall: business units move fast under top-down pressure to adopt AI, security is brought in late or not at all, and the resulting programme has policy gaps that surface as incidents. The structural fix she advocates is a cross-functional governance committee   legal, compliance, engineering, and security   with board-level sponsorship that distributes risk ownership rather than concentrating it in the security team alone.

For cloud security leaders, this is both a risk management and a career positioning insight. Shannon notes that AI is creating the conditions for security to have a genuine seat at strategic decision-making tables for the first time   because business leaders now understand they have knowledge gaps that require security intelligence to navigate. The opportunity to shift from reactive incident responder to proactive governance partner is real, but it requires showing up with scenario-based risk framing ("here is what a data exfiltration incident looks like in our AI environment and here is what it costs") rather than technical jargon.

2. Your Existing Stack Has a Blind Spot the Size of Your AI Deployment

One of the most practically important points Shannon makes concerns the false sense of coverage that a mature security stack can create when AI enters the picture:

"AI is embedded in every single SaaS application and every single tool that your team is using. You need to know what people are using, you need to know what content is going into that experience and what content is going out."   Shannon Murphy, TrendAI

She illustrates the blind spot with a deceptively simple example: an employee asks their corporate AI copilot for a colleague's salary. Traditional DLP, tuned to flag sensitive data leaving via email or file transfer, has no visibility into this interaction. The data exposure happens entirely within what the organisation considers a sanctioned, secured application   and no alert is generated. Scale this to thousands of employees across dozens of AI-enabled SaaS tools, and the aggregate data risk is substantial.

Her prescription is not to abandon the existing stack but to recognise it as table stakes that now requires an AI-specific visibility layer on top. The key principle: context is everything. Risk that exists in isolation   an AI query here, a model access there   becomes actionable and prioritisable only when it can be seen in relation to the identity making the request, the data being accessed, and the threat signals already in your environment. This is precisely what Microsoft's Security Dashboard for AI announced this week attempts to operationalise.

3. The Three-Milestone AI Security Roadmap

Shannon provides the clearest practical roadmap in the conversation for how a security leader should sequence their AI security programme. It maps directly to the three building blocks her blueprint prioritises:

Milestone 1   Real-Time AI Asset Visibility: "Shadow AI is absolutely massive and you need to be able to wrap your arms around it." This is the non-negotiable foundation. Shannon is explicit that a static inventory is insufficient: "What we have today in place is not what we have tomorrow   literally tomorrow." The first deliverable is a continuously updated, real-time inventory of every AI application, agent, model, and integration in your environment. Tools exist today to make this tractable   the question is whether the programme has been prioritised.

Milestone 2   Identity and Access Governance for AI: Once you have inventory, the next question is access. Who   and what   gets access to which data and tools? Shannon's recommendation to treat agents as identities is strategically important: "Maybe we wanna start treating them a little bit like identities. Taking an identity risk management approach to those agents." The tooling for identity governance is mature; applying it systematically to AI agents requires discipline and the right agent inventory to work from.

Milestone 3   Data Governance and Provenance: Shannon identifies this as "your biggest project" and the one most security teams are furthest behind on. DSPM   understanding where your data lives, who has access to it in AI contexts, and what happens to it during model fine-tuning or inference   is the pillar she describes as "the central bingo card conversation in every CISO engagement over the last two years." For organisations fine-tuning open-weight models on proprietary data, this is particularly acute: the data used for fine-tuning must be governed with the same rigour as production data.

4. Shift Left for AI - More Critical Than Ever, and More Incomplete

Ashish Rajan asks Shannon directly whether shift-left DevSecOps is still relevant in an AI-first world. Her answer is nuanced and worth the full framing:

"Shift left is more needed than ever before. But it is what is going to keep you out of trouble from a quality perspective   and when we layer in things like an AI scanner for vulnerability, that's what's going to keep you out of trouble even when we're live in runtime."   Shannon Murphy, TrendAI

The key addition she makes is that shift-left for AI does not end at the pipeline gate. Unlike traditional deterministic software, AI applications continue to change after deployment through model drift, fine-tuning updates, and the inherent non-determinism of LLM outputs. This means that runtime monitoring   for hallucination, for adversarial prompt injection, for novel zero-day vulnerabilities in live inference stacks   is a distinct and mandatory complement to pre-deployment scanning. The Cline attack this week is a live demonstration: a supply chain compromise in the pre-deployment phase that delivered a runtime-persistent agent with ongoing system access. Both vectors required coverage; neither alone was sufficient.

5. The Model Card as Enterprise Trust Infrastructure

Shannon surfaces an emerging practice that deserves broader adoption among organisations building AI-powered products: the model card used as customer-facing transparency documentation.

"Some organizations are doing something really great using a model card that I call a license to thrive   where they show here are the models we use, here are the safety precautions we take, this is how we use a Zero Trust approach to protect your data." She expects standardisation of this practice to accelerate through 2026 as regulated industries (healthcare, financial services) begin demanding it from AI-powered vendors as a due diligence requirement.

For security leaders at organisations building or evaluating AI-powered products, the model card framework serves a dual purpose: externally, it builds customer trust without disclosing IP; internally, it creates the documentation discipline that forces clarity about which models are in production, what data they have been trained on, and what controls are in place. That internal clarity is also the foundation of a defensible DSPM programme.

RELATED RESOURCES 🎧

• NIST AI Risk Management Framework (AI RMF)

• OWASP Top 10 for LLM Applications

• MITRE ATLAS   Adversarial Threat Landscape for AI Systems

• TrendAI Security Blueprint Whitepaper   Framework for adopters, builders, and scalers

Cloud Security Podcast

• Cloud Security Podcast Episode with Shannon Murphy

Related Podcast Episodes 🎧

Question for you? (Reply to this email)

🤔 If your AI agent can read GitHub issues and push production code… Does it have more access than your junior engineer?

Because in many enterprises — it does.

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!

Shilpi Bhattacharjee

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

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter topic: The Shared Responsibility Gap in AI Workloads: Why Cloud Security Assumptions Break at the LLM Layer (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

We are at an inflection point. The same attack vectors that have haunted cloud security teams for a decade  misconfiguration, credential exposure, shadow usage, and blurry shared responsibility  are now being applied with surgical precision to AI workloads. This week's news cycle makes that unmistakably clear: from the first confirmed infostealer theft of an AI agent's cryptographic keys to Microsoft's Copilot silently bypassing DLP controls on confidential email for weeks.

To help make sense of what this means for practitioners building and securing AI systems on cloud infrastructure, this edition features Toni de la Fuente, founder and CEO of Prowler  one of the most widely deployed open-source cloud security platforms in the industry, with a decade of checks built around real-world misconfiguration patterns. In conversation with Cloud Security Podcast host Ashish Rajan, Toni delivers a grounded, practitioner-first framework for understanding where cloud security ends and AI security begins  and why that distinction matters more than ever. [Listen to the episode]

📰 TL;DR for Busy Readers

• AI agents are credential stores: Infostealers now exfiltrate gateway tokens, cryptographic keys, and behavioral memory from tools like OpenClaw treat agent configs like privileged secrets.

• Agentic Endpoint Security is now a category: Palo Alto's ~$400M acquisition of Koi signals every SOC must now inventory AI agents running on endpoints as privileged processes.

• Copilot can silently nullify your DLP: M365 Copilot bypassed sensitivity labels on Sent Items and Drafts for weeks to audit your Purview logs for Jan 21–early Feb now.

• The shared responsibility gap has expanded: Bedrock, Vertex, and Azure AI services inherit cloud's responsibility ambiguity and add new layers  infra, LLM configuration, and shadow AI all need explicit ownership.

📰 THIS WEEK'S TOP 5 SECURITY HEADLINES

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

1. Infostealers Begin Targeting AI Agents: First Confirmed Theft of OpenClaw Credentials and Cryptographic Keys

Hudson Rock disclosed on February 13 that a Vidar-variant infostealer successfully exfiltrated an OpenClaw AI agent's entire configuration environment  including its gateway authentication token, public and private cryptographic keys, and soul.md behavioral memory files. The malware didn't need a purpose-built AI module: it used a broad file-grabbing routine targeting extensions like .openclaw. OpenClaw has over 200,000 GitHub stars and is increasingly integrated into professional and enterprise workflows.

Why it matters to you: This isn't a one-off curiosity  it's a proof-of-concept that the infostealer ecosystem will follow the value. Just as they built dedicated modules for Chrome credentials and Telegram sessions, dedicated AI agent parsers are coming. The stolen gateway token in this case could allow an attacker to remotely impersonate the victim's client in authenticated API requests. CISOs should act now: inventory agentic AI tool usage enterprise-wide, enforce encrypted storage of all agent configuration files and tokens, restrict port exposure for locally-running agents, and ensure DLP tooling covers .openclaw, .json, and similar agent file paths.

Sources: The Hacker News | BleepingComputer | Infosecurity Magazine

2. Palo Alto Networks to Acquire Koi Security: 'Agentic Endpoint' Emerges as a Formal Security Category (~$400M)

Palo Alto Networks announced a definitive agreement to acquire Koi Security  a one-year-old Israeli startup already protecting 500,000 endpoints  on February 17, 2026. Koi's platform gives enterprises visibility and control over AI agents, browser extensions, IDE plugins, MCP servers, and model artifacts that carry deep permissions but bypass traditional endpoint controls. Koi's capabilities will be folded into Prisma AIRS and Cortex XDR post-close.

Why it matters to you: This acquisition formally names a new product category and confirms what security architects have been quietly worried about: your endpoint perimeter now includes AI agents. Palo Alto's own announcement cited 135,000 exposed OpenClaw instances and 800+ malicious skills in its marketplace discovered within days of launch  alongside documentation of the first malicious MCP server in the wild. For defenders: treat AI agents running on your estate (browser copilots, desktop assistants, IDE plugins, local LLM tools) as privileged processes requiring the same conditional access and least-privilege controls you apply to cloud admin sessions.

Sources: Palo Alto Networks Press Release | Help Net Security | Security Boulevard

3. Proofpoint Acquires Acuvity: Email Giant Bets on AI Governance and MCP Server Visibility

Proofpoint announced on February 12 the acquisition of Acuvity, whose platform provides unified visibility and enforcement across AI usage  from endpoints and browsers to MCP servers, locally installed tools like OpenClaw and Ollama, and AI-powered workflows embedded in Microsoft 365 and other enterprise SaaS. Financial terms were not disclosed.

Why it matters to you: Email and collaboration platforms are where AI copilots acquire their richest enterprise context  contracts, calendar data, internal policy docs, financial records. That makes M365, Teams, and SharePoint the highest-value data path for AI-driven exfiltration and shadow AI risk. Proofpoint is positioning Acuvity as the control plane that spans human email behavior, sensitive data governance, and AI agent activity in a single policy layer. Alongside the Palo Alto/Koi deal, the market signal is loud: AI governance is an active buying priority now, not a 2027 roadmap item. Defenders should immediately define an AI usage policy covering approved models, permitted data classifications, required logging of prompts and responses, and guardrails around all SaaS connectors your agents are authorized to touch.

Sources: Proofpoint Press Release | CyberScoop | Help Net Security

4. Microsoft 365 Copilot Bug Bypassed DLP Controls, Summarizing Confidential Emails for Weeks (CW1226324)

Microsoft confirmed that a bug tracked as CW1226324 caused M365 Copilot to summarize confidential emails from users' Sent Items and Drafts folders from January 21 through early February  bypassing sensitivity labels explicitly configured to restrict automated tool access. The root cause was a code issue in the Copilot work tab that incorrectly picked up labeled items in those folders. Items in other folders were not affected. A server-side fix began rolling out in early February; no final remediation timeline has been provided and the number of impacted tenants has not been disclosed.

Why it matters to you: This is a governance stress test for every organization running Copilot. Server-side AI processing can nullify tenant controls without any action from administrators or end users  and Sent Items and Drafts routinely hold content subject to attorney-client privilege, regulatory protections, and contractual confidentiality. Immediate actions: verify your tenant received the CW1226324 remediation; review Purview Copilot activity logs for January 21 through early February; use Restricted Content Discovery to harden SharePoint exclusions; and temporarily restrict Copilot Chat for high-risk user groups (legal, HR, executive, finance) until you can validate DLP is functioning as expected. Strategically, this incident demands that AI feature releases be added to your change management process with a mandatory DLP regression test before rollout.

Sources: BleepingComputer | TechCrunch | The Register | Office 365 IT Pros

🎯 Cloud Security Topic of the Week:

The Shared Responsibility Gap in AI Workloads: Why Cloud Security Assumptions Break at the LLM Layer

If you spent the last decade internalizing AWS's shared responsibility model, your data, your configuration, your IAM; their hypervisor, and their physical infrastructure, prepare to rethink those clean lines. Managed AI services like Amazon Bedrock, Google Vertex AI, and Azure AI introduce layered dependencies (and layered ambiguity) that make the cloud SRM look elegantly simple by comparison.

The central question practitioners must now answer isn't just "what does the vendor secure?"  it's "which of the five or six parties in my AI stack has responsibility for what, and does any of them actually know?" As Toni de la Fuente explains in this week's conversation, this isn't a theoretical gap. It's the exact same disorientation cloud teams experienced in the early days of RDS and Lambda  amplified across LLMs, agent runtimes, MCP servers, and the prompt-to-response pipeline that now touches your most sensitive enterprise data.

Featured Experts This Week 🎤

• Toni de la Fuente- CEO, Prowler Security

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

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

• MCP (Model Context Protocol) An open protocol that allows AI agents and language models to connect to external tools and data sources  databases, APIs, file systems  in a standardized way. MCP enables agents to "do things" beyond generating text: query live data, execute functions, and interact with enterprise systems. Because MCP servers often carry broad permissions, an insecure MCP implementation (e.g., one that speaks directly to a production database without RBAC) represents a significant attack surface.

• Agentic Endpoint Security A new security category, formalized this week by Palo Alto's Koi acquisition, focused on providing visibility and control over AI agents and related software (browser extensions, IDE plugins, MCP servers, local LLM tools) running on endpoints. These processes operate with high privileges and deep data access but bypass traditional endpoint security controls designed for human-interactive applications.

• Shadow AI Unauthorized or unmonitored use of AI tools within an organization  employees using consumer ChatGPT, DeepSeek, or other models to process enterprise data without IT or security awareness. Shadow AI creates data governance and regulatory exposure, particularly when users upload contracts, PII, or confidential internal documents to models that may use that data for training.

• Promptfoo An open-source LLM assessment framework that supports red-teaming, vulnerability scanning, and OWASP/ATLAS threat mapping for language models. Prowler has integrated Promptfoo to allow security teams to assess LLMs as part of their existing cloud security scanning workflows.

• DLP (Data Loss Prevention) Security controls that detect and prevent unauthorized transmission or exposure of sensitive data. In M365, DLP relies on sensitivity labels to restrict automated tool access to protected content. This week's Copilot incident exposed a critical assumption gap: that server-side AI pipelines respect tenant-configured DLP policies  they may not.

This week's issue is sponsored by Push Security

Stop browser-based attacks with Push Security

Major breaches are increasingly originating in the browser, where traditional security controls can’t detect them. This is a conscious shift, with both criminal and nation-state actors adopting browser-native TTPs into their standard toolkit.

Push Security brings real-time detection and response into every browser — where today’s work and attacks actually happen. Push gives security teams visibility into modern threats, proactive control over user risk, and powerful telemetry to detect, investigate, and stop attacks fast.

Frictionless deployment. Instant protection.

Check out Push Security now.

💡Our Insights from this Practitioner 🔍

The Shared Responsibility Gap in AI Workloads: Why Cloud Security Assumptions Break at the LLM Layer (Full Episode here)

1. Cloud Security and AI Security Are Overlapping, Not Identical  and That Distinction Has Real Architectural Consequences

One of the most clarifying frameworks Toni offers is a simple structural decomposition: AI systems have two security domains, and they require different thinking. The first is the infrastructure of AI  GPUs, storage, the cloud services (S3, SageMaker, Bedrock, Vertex) that host the data pipelines and model training workloads. This domain largely inherits cloud security controls, and practitioners with cloud backgrounds are well-equipped to address it. The second is the AI itself  the model configuration, the guardrails, the prompt injection controls, the behavioral parameters that determine what the model can do, what it knows, and what it will refuse.

"The same way that we distinguish between cloud infrastructure and application infrastructure, we can distinguish between AI infrastructure or AI configuration itself."  Toni 

The practical implication for security architects: when reviewing a new AI workload for production readiness, you need two distinct checklists. One that treats it like a cloud workload (IAM, network exposure, encryption, logging) and one that treats it like a model deployment (guardrail configuration, prompt injection testing, data classification of training inputs, model access control).

2. The Shared Responsibility Model Has Been Extended  and the Boundaries Are Murkier Than Ever

Toni draws a direct parallel between the confusion early cloud adopters felt about services like RDS and what practitioners are now experiencing with Bedrock and similar managed AI services. The difference is that AI services add multiple new configuration surfaces  guardrails, model access policies, prompt filtering  that vendors are still publishing documentation for as they go.

"If a company like AWS launches AI service like Bedrock, you could expect that it's following all the best practices. But what about your side or what about your expectations? I mean, that is very blurry. Sometimes it's not even clear for anybody  not for the customer, not for integrators, and of course not for the CSP."  - Toni

Ashish adds a critical structural observation: "I used to be the first party with just me and things I manage on my virtual machine. Then I had a third party with me and Amazon managing my workload. Now I have a fourth party, fifth party as well  because now my Bedrock is the access to my Claude or OpenAI."

This isn't an abstraction. Each party in that chain carries its own configuration surface, its own security posture, and its own data handling behaviors. Security teams that have mapped shared responsibility for IaaS are now working with dependency chains where the blast radius of a misconfiguration is significantly harder to contain.

Practical guidance: Map your AI stack completely. For every AI service in your environment, document which configuration options belong to your responsibility, which are vendor-managed, and which are simply undisclosed. Build your security controls around the API endpoints you can see and modify  that is your accountability boundary.

3. MCP Security: The New Frontier Where Most AI Applications Are Getting It Wrong

One of the most operationally actionable insights in this conversation comes from Toni's direct experience building Prowler's own MCP implementation. The team observed a consistent pattern across community-built AI architectures: MCP servers deployed with direct database access, no RBAC enforcement, and no authentication layer beneath the tool interface. This is the AI equivalent of exposing an admin console directly to the internet without a jump server.

"We have seen many how insecure the default configuration or default AI architecture with MCP can be. Never compute an MCP talking to a database directly. Put your MCP on top of your RBAC, and the RBAC is below the API."  Toni de la Fuente

The architectural pattern Prowler enforces in its own implementation: MCP → RBAC → API → Database. Each layer has a defined access control boundary. The MCP server has no direct datastore access; it operates within permissions granted through the RBAC layer. This pattern translates directly to any enterprise building production agentic applications.

For teams currently evaluating or deploying AI agents connected to internal systems: treat every MCP endpoint as a privileged interface. Apply the same conditional access controls you'd require for a cloud admin session  MFA, session logging, least-privilege permission scoping, and regular access reviews.

4. AI Doesn't Know Everything  and Assuming It Does Is a Security Risk

Toni describes an illuminating experiment the Prowler team ran with Claude Code: they asked it to identify any S3 buckets open to the public internet using only AWS credentials, a check Toni himself wrote nearly ten years ago as one of Prowler's first detections. Claude Code worked through several incorrect approaches before eventually identifying Prowler as the appropriate tool for the task.

"We think that AI is going to know everything magically. This is not magic. You have to measure between AI-created detections or using AI to take advantage of rule-based detections. At the end of the day, that is what we truly believe is needed  AI around everything, but sometimes you have to tell the AI: no, this is the A, B, C that you have to take into account." 

The security implication extends well beyond tooling: AI-driven detection systems deployed as autonomous agents carry real risk if their limitations aren't acknowledged and guarded against. The failure mode isn't dramatic  it's subtle. An agent that confidently executes the wrong check or scans the wrong region doesn't trigger an alert; it just leaves a gap. The corrective is to use AI to augment and accelerate rule-based detection engines  not replace them.

5. The SDLC Has Changed  and Security Teams Need to Catch Up

Perhaps the most strategically significant observation in this conversation is about how AI is changing who can deploy cloud infrastructure. Tools like Claude Code and Lovable enable developers with limited infrastructure experience to provision cloud resources, generate Terraform, configure databases, and deploy to production  all through conversational prompts.

Toni frames this directly: "When you create a new application with Claude Code, it's going to generate the Terraform code, ask you for credentials in AWS, and then you deploy something there  with your storage, database, everything. Now what?"

The 'now what' is exactly the security gap. Applications are being generated and deployed faster than security review processes can follow. The answer is continuous scanning across both the infrastructure-as-code layer and the running cloud environment  and AI-powered tooling is now fast enough to make this feasible at developer velocity. The security team's role is to ensure those scans are running, that findings are routed back into the development pipeline, and that AI-generated infrastructure doesn't escape into production carrying the same misconfigurations that have been exploitable for years.

6. Three Security Controls Every AI-on-Cloud Workload Needs Before Production

When pressed by Ashish for a concise framework for practitioners moving AI-on-cloud workloads to production, Toni offered three pillars:

• Secure the infrastructure: Treat the cloud workload running the AI application with the same rigor as any production cloud environment  IAM least privilege, network segmentation, encryption at rest and in transit, runtime monitoring. This is table stakes, and AI doesn't change it.

• Secure the LLM: Know where your model lives. Is it a shared multi-tenant service? Does the vendor use your prompts and data to improve the model? Assess your LLM configuration using tools like Promptfoo and map findings to the OWASP Top 10 for LLMs and MITRE ATLAS.

• Know who has access: Shadow AI is not a theoretical problem, it's happening across your organization today. Establish an AI usage policy, enforce it through technical controls (DLP, web filtering, identity governance), and build visibility into which AI tools are accessing which enterprise data through which connectors.

This framework maps cleanly onto this week's news. The Microsoft Copilot DLP failure is a pillar two and three failure. The OpenClaw infostealer theft is a pillar of three failure  credentials for an AI agent treated like user data instead of privileged secrets. The Koi acquisition is the market responding to the pillar one gap on the endpoint.

RELATED RESOURCES 🎧

• CISA Known Exploited Vulnerabilities Catalog - Authoritative source for actively exploited CVEs requiring remediation

• Anthropic's Model Context Protocol Documentation - Technical specifications and security considerations for MCP

• Cloud Security Alliance: AI Security Guidance - Enterprise frameworks for AI governance

Cloud Security Podcast

• Cloud Security Podcast Episode with Toni De la Fuente

Related Podcast Episodes 🎧

Question for you? (Reply to this email)

🤔 Are you currently:

A) Blocking AI tools
B) Allowing everytrhing
C) Trying to build decision-point governance

Reply and tell me where you are.

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!

Shilpi Bhattacharjee

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

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter topic: The Developer-First AI Governance Dilemma: Building Security Controls That Don't Get Routed Around (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

As ransomware operators actively exploit critical vulnerabilities in email infrastructure and cloud-native threats evolve into self-propagating worms across multi-cloud environments, security teams face a fundamental question: how do we govern rapidly evolving attack surfaces while maintaining the agility that development teams demand?

This week, we examine three critical security stories from the SmarterMail CVE-2026-24423 ransomware campaign to the TeamPCP botnet's multi-cloud rampage and cloud platform abuse for phishing infrastructure. More importantly, we dive deep into a conversation with Bryan Woolgar-O'Neil, CTO and Co-Founder of Harmonic Security, who shares hard-won lessons on implementing AI security governance that developers don't route around. [Listen to the episode]

🚨 This Week’s Mental Security Check

• 🔥 Ransomware actively exploiting email RCE

• ☁️ 60,000+ servers wormed across AWS, Azure & GCP

• 🎣 Phishing kits hosted on trusted cloud domains

• 🤖 Developers running local MCP servers with production access

Two questions to ask:

1️⃣ Are your Docker/Kubernetes endpoints exposed?
2️⃣ Do you actually know where AI is touching production data?

📰 TL;DR for Busy Readers

• Patch SmarterMail CVE-2026-24423 immediately

• Audit exposed Docker APIs & Kubernetes control planes

• Assume phishing infrastructure now lives on trusted cloud domains

• 70%+ of AI usage in most orgs is invisible

• Coaching-based AI governance beats blanket blocking

📰 THIS WEEK'S TOP 5 SECURITY HEADLINES

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

1. ☁️ TeamPCP Botnet - The First Real Multi- Cloud-Native Worm Worm Compromises 60,000+ Servers Across AWS, Azure, and GCP

What Happened
Security researchers at Flare published findings on February 9 detailing TeamPCP, a sophisticated cloud-native worm that has successfully compromised over 60,000 servers across all three major cloud platforms AWS, Azure, and Google Cloud Platform. The malware operates through automated exploitation of exposed Docker APIs, misconfigured Kubernetes clusters, and the React2Shell vulnerability, spreading laterally within and across cloud environments. Once established, TeamPCP deploys cryptocurrency miners and functions as command-and-control infrastructure for ransomware operations. The attack chain demonstrates cloud-specific tradecraft, including abuse of cloud metadata services, IAM credential harvesting, and multi-cloud persistence mechanisms.

Why It Matters
TeamPCP represents the maturation of cloud-native attack techniques into wormable, self-propagating threats that treat multi-cloud infrastructure as a unified attack surface. This isn't an opportunistic cryptominer it's a platform for ransomware C2 infrastructure that happens to self-fund through mining while establishing persistent access across your cloud estate.

The multi-cloud dimension is particularly concerning. Organizations that assume cloud security posture management tools provide adequate protection should revisit their assumptions TeamPCP demonstrates how attackers move fluidly between AWS, Azure, and GCP, exploiting the seams between different security tooling and visibility gaps. Your cloud security architecture needs unified detection, shared threat intelligence, and consistent security policies across all cloud platforms.

Immediate actions:

• Scan for exposed Docker APIs

• Audit internet-facing Docker and Kubernetes endpoints

• review IAM policies for least privilege violations,

• Review Kubernetes API server exposure

• Enable VPC Flow Logs across environments

• Monitor metadata service access attempts

• Threat hunting should focus on abnormal CPU/GPU usage

• outbound C2 patterns

• credential access attempts against metadata services.

Sources: Flare Research | Dark Reading | The Hacker News

2. 🎣 Threat Actors Weaponize Azure, Firebase, and AWS for AiTM Phishing Infrastructure

What Happened
Research published by ANY.RUN on February 4 reveals an escalating trend of threat actors abusing legitimate cloud platforms specifically Microsoft Azure, Google Firebase, and AWS to host adversary-in-the-middle (AiTM) phishing kits. These campaigns leverage the trusted domain reputation and SSL certificates of major cloud providers to bypass traditional email security filters and URL reputation systems. The researchers identified widespread deployment of sophisticated phishing frameworks like Tycoon2FA, which specifically targets enterprise users with MFA-enabled accounts by intercepting authentication tokens in real-time. The abuse extends across Azure Static Web Apps, Firebase Hosting, and AWS Amplify.

Why It Matters
When attackers host phishing infrastructure on azure.com, firebaseapp.com, or amazonaws.com subdomains, traditional blocklist-based defenses fail catastrophically. These platforms provide attackers with legitimate SSL certificates, resilient hosting infrastructure, and the same high-availability guarantees your organization relies on for production workloads.

For cloud security leaders, this demands a strategic shift in defensive architecture. Email security posture must evolve beyond domain reputation to incorporate behavioral analysis, real-time link inspection, and user authentication patterns. Cloud platform governance needs to include monitoring for abuse of your own organization's cloud subscriptions if attackers can stand up phishing sites on Microsoft and Google infrastructure, nothing prevents them from doing so within your Azure tenant or GCP project if credentials are compromised.

The AiTM dimension targeting MFA is particularly critical. Organizations that have implemented MFA as a primary security control need to recognize that session token theft bypasses this protection entirely. This reinforces the need for phishing-resistant authentication (FIDO2/WebAuthn), conditional access policies based on device posture and network location, and session lifetime controls that limit token validity windows.

Sources: Cyberpress | GBHackers on Security | ANY.RUN Research

3. AWS IAM Identity Center adds IPv6 (dual-stack endpoints)

What Happened:
AWS announced IPv6 support for IAM Identity Center via new dual-stack endpoints, allowing access over IPv4, IPv6, or dual-stack clients while keeping existing IPv4 endpoints intact. The dual-stack capability applies across access portals, managed applications, and Identity Center flows so authentication can route through IPv6 where available. AWS positioned this as a compatibility and modernization upgrade for orgs operating IPv6 networks and hybrid environments.

Why It Matters (for cloud security leaders)

• Identity is your control plane’s front door. Introducing IPv6 paths changes the network perimeter assumptions some enterprises still rely on (firewall rules, proxies, allowlists, egress controls), especially where teams accidentally only modeled IPv4 flows.

• Policy drift risk: If your controls (WAF/proxy, egress filtering, DLP, CASB, SIEM parsing) are IPv4-centric, you can end up with “shadow paths” where identity traffic bypasses expected inspection. This is an availability and security issue: broken routing can cause auth failures; uninspected routing can reduce visibility.

• Validate that IPv6 is permitted/inspected across enterprise networks where Identity Center traffic originates (office, ZTNA, VDI, managed endpoints).

• Update firewall/proxy rules and allowlists for the dual-stack domains, and verify your monitoring tooling correctly logs IPv6 addresses (normalization, correlation, geo, alert rules).

• Run a short change-control test: confirm sign-in flows, SSO to managed apps, and break-glass access still work under dual-stack conditions.

Source: AWS

4. 🚨 SmarterMail CVE-2026-24423: Unauthenticated RCE Under Active Ransomware Exploitation

What Happened
CISA added CVE-2026-24423 to its Known Exploited Vulnerabilities catalog on February 5, 2026, following confirmation that ransomware operators are actively exploiting a critical unauthenticated remote code execution vulnerability in SmarterTools' SmarterMail email server platform. The vulnerability carries a CVSS score of 9.3 and affects versions prior to the emergency patch released in late January. In a striking validation of the threat, SmarterTools itself disclosed on February 9 that it had been breached through this same vulnerability, with attackers gaining access to internal systems. The platform serves over 15 million users globally across enterprise and service provider deployments.

Why It Matters
This incident represents a perfect storm of risk for cloud and hybrid email infrastructure. The vulnerability requires no authentication and enables full system compromise, making it trivially exploitable at scale. Ransomware groups are already operationalizing exploits in the wild; this isn't theoretical. The vendor breach demonstrates that even security-aware organizations struggle with emergency patching timelines, highlighting the window of exposure all SmarterMail operators face.

For cloud security teams, this demands immediate action: inventory verification to identify any SmarterMail instances in on-premises, private cloud, or hybrid deployments; network segmentation review to ensure email infrastructure isn't directly internet-accessible without compensating controls; and incident response preparation given the ransomware context. If you're running SmarterMail, assume a breach until patching is verified.

The CISA KEV listing triggers compliance obligations for federal agencies (21-day patching deadline) but should be treated as a forcing function for private sector cloud environments as well. This reinforces the security maturity gap between legacy on-premises solutions and cloud-native alternatives with automated security updates and vendor-managed infrastructure.

Sources: CISA KEV Catalog | Help Net Security | BleepingComputer | SecurityWeek

5. WinRAR CVE-2025-8088: “patched, still exploited” across state + cybercrime actors

What Happened
Google reported widespread exploitation of CVE-2025-8088 (patched July 2025) using Windows Alternate Data Streams (ADS) to drop attacker-controlled files into execution/persistence locations (e.g., Startup paths). Despite being an “n-day,” it remains high-impact because patch adoption is uneven.

Why It Matters

• Endpoint compromise is still the fastest route to cloud session theft and control-plane abuse.

• This is a governance lesson as much as a vulnerability story: unmanaged “non-core” tools (archivers, plugins) become reliable attacker entry points.

• Action: force-update WinRAR fleet-wide; detect suspicious archive extraction to autorun locations; tighten conditional access and privilege to reduce downstream cloud blast 

Sources: Google Cloud Threat Intelligence Group

🎯 Cloud Security Topic of the Week:

The Developer-First AI Governance Dilemma

As AI tools become embedded in developer workflows from Claude Code to GitHub Copilot to custom MCP servers security teams face a familiar challenge with unfamiliar characteristics: how do you govern a technology that's being adopted bottom-up by individual contributors, evolves weekly, and produces non-deterministic outputs?

This week's conversation with Bryan Woolgar-O'Neil reveals why traditional security approaches fail in AI adoption and what actually works when developers are your primary threat vector not because they're malicious, but because they're solving business problems faster than your security policies can keep up.

Featured Experts This Week 🎤

• Bryan Woolgar-O'Neil- CTO & Co-Founder, Harmonic Security

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

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

• MCP (Model Context Protocol): A standardization framework released by Anthropic that provides a uniform interface for AI models to interact with various APIs and data sources. Think of it as a plug-and-play system that allows AI agents to connect to GitHub, databases, Jira, or custom internal tools without developers needing to write custom API integrations for each service. Critically, MCP servers can run locally on developer workstations or be hosted centrally, with approximately 70% currently running locally.

• Shadow AI: Unauthorized or unmonitored AI tool usage within an organization, similar to shadow IT but with higher velocity and risk. This includes personal accounts on ChatGPT, Claude, or Gemini being used for work tasks, unapproved MCP servers accessing production data, or AI coding assistants with unrestricted access to internal repositories.

• Agent/Agentic Flows: AI systems that can perform multi-step tasks autonomously, making decisions and calling tools or APIs without human intervention at each step. In enterprise contexts, this might mean an AI agent that reads logs, performs root cause analysis, writes code, tests it, and deploys what previously took human developers 3-5 days, now happening in 20 minutes.

• Small Language Models (SLMs): Specialized, lightweight AI models trained for specific tasks or domains rather than general-purpose use. Unlike large language models (LLMs) that try to handle everything, SLMs can be optimized for faster inference (sub-200ms response times), deployed locally, and fine-tuned for particular use cases like detecting sensitive data patterns or understanding security policy intent.

This week's issue is sponsored by Push Security

Stop browser-based attacks with Push Security

Major breaches are increasingly originating in the browser, where traditional security controls can’t detect them. This is a conscious shift, with both criminal and nation-state actors adopting browser-native TTPs into their standard toolkit.

Push Security brings real-time detection and response into every browser — where today’s work and attacks actually happen. Push gives security teams visibility into modern threats, proactive control over user risk, and powerful telemetry to detect, investigate, and stop attacks fast.

Frictionless deployment. Instant protection.

Check out Push Security now.

💡Our Insights from this Practitioner 🔍

Is Developer Friendly AI Security Possible with MCP & Shadow AI (Full Episode here)

The False Sense of AI Security Control

Most organizations believe they have AI usage under control because they've purchased enterprise licenses for ChatGPT, Claude, or Copilot. Bryan Woolgar-O'Neil destroys this illusion quickly: "Even though they can tell that there's a certain amount of traffic going to this website, it is like, what? What does that actually mean to an organization? And I think a lot of them don't know."

The fundamental problem isn't that organizations lack AI tools it's that they lack visibility into what employees are actually doing with them. Traditional security telemetry from firewalls or CASB tools can tell you that users visited claude.ai, but they can't tell you whether those users were:

• Experimenting with prompt engineering for personal learning

• Processing production customer data to generate support responses

• Using personal Gmail accounts instead of enterprise licenses

• Building MCP servers that connect AI directly to internal databases

This visibility gap creates what Bryan calls "shadow AI" and unlike shadow IT, the blast radius is fundamentally different. "The power that AI can bring to a business... you're doing the same jobs, but the AI's doing it a lot faster, a lot more," he explains. When an engineer can reduce a 3-5 day bug fix process to 20 minutes using Claude Code with MCP access to logs, repositories, and deployment systems, you're not just dealing with unauthorized software you're dealing with unauthorized automation of privileged operations.

The enterprise impact? Organizations that think they're "AI-ready" because they bought licenses are discovering that:

1. Developers bypass enterprise tools when personal accounts are faster or more capable

2. Data exfiltration happens at AI velocity, not human cut-and-paste speeds

3. Personal accounts create data portability risks when employees leave, they take all their prompts and organizational knowledge with them

For security leaders, this means your first priority isn't building AI security policies, it's understanding where AI is actually being used and for what purposes. As Bryan puts it: "Getting that initial visibility. So understand where usage is, and not just at the 'you are using these sites', but with the right level of context and intent."

Why Traditional Security Controls Fail for AI

Traditional approach:

Define policy → Block → Create ticket → Add friction

Developers route around it.

AI evolves weekly.
Outputs are non-deterministic.
Adoption is bottom-up.

You can’t gate this the way you gated cloud migration.

The Shift: Coaching Over Blocking

So what actually works? Harmonic Security's approach, which Bryan's team uses internally before deploying to customers, centers on "coaching in real time rather than blocking everything."

Here's how this manifests in practice:

Scenario: An AI agent is running a 12-minute automated workflow to fix a bug. It needs to pull logs from production, perform root cause analysis, write code, and deploy. At the 10-minute mark, it attempts to send production customer data to a public LLM for analysis.

Traditional Blocking Approach: The security tool kills the entire workflow, the engineer sees "Access Denied," their 10 minutes of progress is lost, and they're furious.

Coaching Approach: The security tool intercepts the data transfer and provides context to the AI agent itself: "This data contains PII and cannot be sent to public LLMs per company policy. Here's what you should do instead: [alternatives]." The AI reads this coaching, adjusts its approach, and completes the task without exposing data.

The key insight is that most AI models will read coaching information and work out a new plan to complete the task without data exposure. You're not blocking the developer's work you're teaching the AI to work within security boundaries.

Bryan extends this to human users as well: "On the browser, we think of the end user similarly... you're trying to coach the end users, the actual employees, to say, well, you're trying to do this, but you're sending this type of data that the organization doesn't want to go into this type of destination."

For example, if an employee tries to paste sensitive data into a free version of a tool when the company has an enterprise license, the coaching system redirects them: "We have an enterprise version of this tool that's approved for this data type use that instead." Or if they're using a public LLM like DeepSeek for data that shouldn't leave the organization: "This model trains on your input data and is hosted in a jurisdiction we don't allow for this data classification. Try [approved alternative]."

The coaching approach works because it assumes positive intent and provides just-in-time education rather than frustration. As Bryan says: "It's almost like a focus on coaching at the point of time of data loss or other types of events that you wanna step in, in the middle of."

The MCP Security Challenge: Local Servers and Data Access

Model Context Protocol (MCP) represents one of the most significant changes in how developers interact with AI, and one of the hardest to secure. Bryan breaks down why:

"Roughly like 70% of MCP servers are local servers. So like... servers that run locally rather than things you connect to."

Why does this matter for security? Three reasons:

1. Developers can build MCP servers in 3-4 hours without needing infrastructure approval

2. Local MCP servers inherit the developer's access rights if the engineer can access production databases from their laptop, so can their MCP-enabled AI

3. No network visibility unlike hosted services that security can monitor via CASB or proxies, local MCP servers operate entirely on the endpoint

This creates a governance nightmare. As Bryan describes from customer conversations: "People were probably seeing it in a similar way to things like third party libraries you might add into code repository. So we wanna have some way of reviewing and risk assessing those and then putting some controls around what is available to be used or not."

The specific risks organizations worry about:

• Cross-system data flows: An MCP server could "plug into a data store, pull data from that and then push it to the web. And an engineer could have done that previously, but they probably wouldn't 'cause they've got an in-built knowledge of what is acceptable, whereas the AI doesn't have that knowledge."

• Destructive actions: AI agents with MCP access to Jira, GitHub, or cloud platforms could create projects, repositories, or infrastructure without human oversight

• Production data access: In permissive organizations where developers have production database access for troubleshooting, MCP servers can now query production data automatically

Bryan's team runs MCP gateway internally: "We've been running it harmonics. So we had our MCP gateway like three or four months before we kind of put it on for customers where we were kind of trying different things out, seeing where we wanted to add in additional controls."

The result? They can allow developers to experiment with MCP locally while maintaining governance: "We don't really want AI to be creating new Jira projects. We don't want it to be creating git repositories because we are not trying to build like a 'go and build my whole website from scratch' prototype thing. It's more like we want you to do this feature, so we want you to exist within our own architecture."

The AI Governance Maturity Model

For CISOs trying to figure out where to start, Bryan offers a practical maturity framework that organizations can progress through:

Level 1 – Basic Logs
You see AI domains being accessed.

Level 2 – Usage Visibility
You understand use cases + intent.

Level 3 – Access Controls
You enforce approved tools and block destructive MCP actions.

Level 4 – Intent-Based Coaching
You intervene intelligently without breaking productivity.

Most organizations are stuck at Level 1.

They think they’re at Level 3.

Developer-First Reality: New Organizational Structures for AI

Perhaps most interesting is how AI adoption is changing organizational structures themselves. Bryan observes: "There's a whole bunch of new job titles and they're not all the same yet."

What he's seeing in the wild:

• Head of AI Development - Brought into engineering organizations specifically to manage AI tool adoption, typically from engineering and data backgrounds rather than security

• Evolution of AI Committees - What started as cross-functional committees (CIO, CISO, Legal, Compliance, Privacy) are becoming permanent AI departments with dedicated staff

• Department-Level AI Specialists - Individual departments hiring AI-focused roles to drive adoption in their specific contexts

This creates interesting dynamics for security teams. As Bryan notes: "Most organizations have a AI committee now... but that committee model's evolved into like we have a department now and it's a small department around AI."

For CISOs, this means AI governance isn't purely a security problem it requires partnership with these new organizational structures. The security team that tries to unilaterally define AI policy will find themselves routed around by departments that have their own AI leadership.

One customer example particularly stands out: their company objective is to "10x every employee via AI." When AI adoption is a board-level business priority at that scale, security teams can't be seen as obstacles they need to enable that 10x productivity while managing risk.

The Future: Small Language Models and Specialized AI

Looking ahead, Bryan sees a shift from general-purpose LLMs toward specialized Small Language Models (SLMs) optimized for specific business functions:

"Organizations will end up having [specialized models] around their different job functions... what will win out is someone will develop their own small language models or constrained models that are great at sales, and they'll be way better than something like OpenAI will be because they're being trained for that specific purpose."

Why does this matter for security? Because each specialized model represents a new attack surface to govern. Harmonic uses SLMs internally because they need sub-200ms response times for real-time coaching something general-purpose LLMs can't deliver consistently.

"We need to get response back within like 200 milliseconds. And we wanna look at intent. So we need to have a model that can understand the context and semantics of what's going in there. And we also want the model to explain to the end user what was wrong."

Building SLMs requires actual ML engineering teams data collection, labeling, feature engineering, training, testing, deployment, and management. "I don't think organizations will build them out of the box," Bryan predicts. Instead, vendors will provide specialized models for different domains: sales AI, coding AI, customer support AI, security AI.

For security teams, this means the "approve these three AI tools" approach won't scale. You'll need frameworks that can govern hundreds of specialized models, each with different capabilities and risk profiles.

Practical Takeaways for Cloud Security Leaders

From Bryan's experience building AI security at Harmonic and deploying it to enterprise customers, here are the actionable lessons:

• Start with visibility, not policy

• Assume developers are already using AI

• Focus on specific pinch points (data exfiltration, destructive ops)

• Design for coaching, not blocking

• Treat MCP servers like third-party libraries

• Expect AI capability to evolve weekly

• Partner with emerging AI leadership roles

• Accept that productivity objectives will win — enable safely

RELATED RESOURCES 🎧

• CISA Known Exploited Vulnerabilities Catalog - Authoritative source for actively exploited CVEs requiring remediation

• Anthropic's Model Context Protocol Documentation - Technical specifications and security considerations for MCP

• Cloud Security Alliance: AI Security Guidance - Enterprise frameworks for AI governance

Cloud Security Podcast

• Cloud Security Podcast – Full Episode with Bryan Woolgar-O’Neil

Related Podcast Episodes 🎧

Is Developer Friendly AI Security Possible with MCP & Shadow AI

Question for you? (Reply to this email)

🤔 Are you currently:

A) Blocking AI tools
B) Allowing everything
C) Trying to build decision-point governance

Reply and tell me where you are.

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!

Shilpi Bhattacharjee

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

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter topic: From Vulnerability Chaos to Exposure Clarity: How Enterprises Are Winning the Risk Reduction Game (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 security industry is quietly abandoning vulnerability management — and Palo Alto’s $3.35B observability acquisition makes that impossible to ignore.

In cloud-native environments, patch lists and CVSS scores no longer reflect real business risk. Exposure now spans infrastructure, identity, APIs, SaaS, containers, and increasingly, autonomous AI systems. Recent acquisitions by Palo Alto and Varonis signal a structural shift: from counting vulnerabilities to orchestrating risk reduction across business services.

This week, we're examining this evolution through two lenses: major vendor consolidation moves that signal where the market is heading (Palo Alto's $3.35B Chronosphere acquisition and Varonis' $125M AllTrue.ai purchase), and practical guidance from Brad Hibbert, a 20-year security veteran who has watched vulnerability management mature from simple patch lists to enterprise-wide exposure orchestration.

Brad brings a unique perspective, having worked across vulnerability management, privileged access management, and third-party risk before landing at exposure management. His insights reveal why the industry is shifting from reporting vulnerabilities to orchestrating remediation, and how organizations can make this transition without losing the domain knowledge they've built over years. [Listen to the episode]

📰 TL;DR for Busy Readers

• Palo Alto's $3.35B bet on observability: Unifying security + observability signals shift to AI-driven, autonomous remediation at scale

• Varonis acquires AI TRiSM: Data security vendors now own AI agent governance expect policy enforcement over prompts, connectors, and sensitive data access

• Exposure management is the new standard: Moving beyond risk-based vulnerability management to business service-aligned risk reduction

• Trust before automation: AI-powered remediation only works when built on normalized data and explainable models

• Start small, prove impact: Pick critical services, demonstrate risk reduction, then scale don't boil the ocean

• “Exposure management isn’t about more data. It’s about deciding what actually matters and mobilizing teams to fix it.” — Brad Hibbert, COO & CSO, Brinqa

📰 THIS WEEK'S TOP 5 SECURITY HEADLINES

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

1. 📈 Palo Alto Networks Completes $3.35B Chronosphere Acquisition

What Happened: Palo Alto Networks finalized its acquisition of Chronosphere, a cloud-native observability platform and 2025 Gartner Magic Quadrant leader, in a $3.35 billion deal originally announced in November 2025. Chronosphere's telemetry pipeline reduces data volumes by approximately 30% and requires 20x less infrastructure than legacy observability tools. The company plans to integrate Chronosphere with its Cortex AgentiX platform, enabling AI agents to automatically detect and remediate security and IT issues across applications, infrastructure, and AI systems.

Why This Matters: This acquisition represents Palo Alto's strategic response to the "data tax" problem plaguing modern security operations. For cloud security teams managing massive telemetry volumes across containers, microservices, and distributed systems, the integration of observability and security signals a fundamental shift from reactive detection to proactive, AI-driven remediation.

Consider the implications for your security architecture:

1. Platform consolidation pressures: Organizations will face strategic decisions about continuing standalone observability tools (Datadog, New Relic, Dynatrace) versus adopting Palo Alto's unified platform. This creates both opportunity (simplified vendor management) and risk (increased vendor lock-in).

2. Cost optimization at scale: The 30% data reduction capability directly addresses escalating SIEM/SOAR data ingestion costs a pain point for every enterprise dealing with petabytes of telemetry. Security teams should evaluate how this affects their data pipeline strategies and storage costs.

3. Autonomous incident response: The Cortex AgentiX integration promises to reduce MTTR through autonomous remediation. However, as Brad Hibbert notes in our feature interview, "You want it to speed the right things up. So you want to make sure that your AI is based on a sound data foundation."

4. Vendor concentration dynamics: Combined with Palo Alto's pending $25B CyberArk acquisition, this positions them as a dominant force in platform-based security. CISOs should assess dependency risks and negotiate accordingly.

Source: Palo Alto Networks Press Release, PR Newswire

2. 🤖 Varonis Acquires AllTrue.ai for $125M: AI TRiSM Meets Data Security

What Happened: On February 3, 2026, Varonis Systems announced its acquisition of AllTrue.ai, an AI Trust, Risk, and Security Management (AI TRiSM) platform, for $125 million in an all-cash deal. AllTrue.ai provides real-time visibility and governance for AI systems across enterprises, enabling organizations to inventory AI systems, understand their intent and connections, control AI behavior in real-time, and prove accountability for governance and compliance. The acquisition addresses the challenge of autonomous AI systems (models, copilots, and agents) operating at machine speed without clear visibility or guardrails.

Why This Matters: This acquisition positions Varonis at the forefront of an emerging security category: securing AI agents and autonomous systems that act on enterprise data. As organizations deploy GenAI tools, chatbots, and AI agents at scale, these systems move beyond passive data analysis to making autonomous decisions and taking actions creating a fundamentally new risk profile.

For cloud security practitioners, this signals several critical trends:

1. AI security evolution: The focus is shifting beyond prompt injection and model attacks to include governance, behavior monitoring, and accountability for AI actions. This aligns with Brad Hibbert's observation that "teams are drowning in data" and need better ways to "make connections that as a human is difficult to make."

2. Data security vendors as AI gatekeepers: Companies with visibility into data access patterns are positioning themselves as the logical owners of AI security. Expect AI governance controls (model risk monitoring, exposure controls, usage policies) to converge with data security posture (SaaS + cloud data stores).

3. Least-privilege extends to AI: Traditional identity and access management principles must now apply to AI systems, not just users. Organizations should start mapping where LLM/agent workflows touch cloud data (S3, Azure Blob, Google Drive, SaaS apps) and decide whether AI controls belong in DSPM/CASB, IAM, or a dedicated AI security layer.

4. Compliance and auditability: As AI systems make autonomous decisions affecting business operations, proving compliance becomes critical. Organizations need audit trails for AI decisions, especially where AI touches regulated data.

Action for defenders: Prioritize establishing inventories of AI systems and their data access, implementing real-time monitoring for AI agent behavior, defining policies for acceptable AI actions, and ensuring audit trails for AI decisions.

Sources: Varonis Press Release, Varonis Q4 2025 Earnings, Wall Street Journal

3. 💰 Thoma Bravo Explores Sale of Imprivata (Up to ~$7B Valuation)

What Happened: Reuters reports that private equity firm Thoma Bravo is exploring a sale of healthcare identity vendor Imprivata, potentially valuing it at up to $7 billion. Imprivata sits at the intersection of healthcare identity, privileged workflows, and regulated access, often integrated into hybrid cloud and SaaS environments.

Why This Matters: A transaction of this scale signals continued consolidation in the IAM space, particularly around specialized identity solutions for regulated industries. For enterprises relying on Imprivata or similar "workflow IAM" solutions, this potential ownership change could impact product roadmaps, pricing models, and integration strategies with major identity platforms like Microsoft Entra ID, Okta, and PAM solutions.

This relates directly to the exposure management theme: as identity becomes increasingly central to security architecture, organizations need to understand their dependencies on identity vendors and ensure they have contingency plans. As Brad Hibbert emphasizes, "It's not just about the server, it's about the services...those services could be spread across multiple processing units and storage units."

Action for defenders: If you rely on Imprivata or similar solutions, confirm exportability of identity and audit data, validate integration roadmaps with major identity providers, and build vendor-change risk into your 2026 identity program planning.

Source: Reuters

4. ☁️ Cloud Provider Security Updates Worth Acting On

What Happened: Several notable security feature updates were announced across major cloud providers this week:

• AWS CloudFront: Added mTLS to origins, enabling true end-to-end client authentication patterns beyond viewer-to-edge

• AWS EC2/VPC: Introduced "Related resources" view for security groups to reduce misconfiguration risk during rule changes

• Microsoft Defender for Cloud: Highlighted Microsoft Security Private Link (public preview) to keep Defender traffic on private connectivity

• Google Cloud (Apigee): Shipped Advanced API Security updates supporting richer condition logic in security actions

Why This Matters: These are "quiet" changes that materially improve control-plane security (private telemetry paths), edge-to-origin trust, and safe change management for network controls. In the context of exposure management, these updates represent the kind of incremental security improvements that reduce attack surface without requiring major architectural changes.

Brad Hibbert's perspective is relevant here: exposure management is about "not just about the exposures, but exposures that could impact your business. Are those exposures in your environment? Are they reachable? Are they exploitable? If they are exploited, what's the blast radius?" These cloud provider updates help reduce both reachability and exploitability.

Actions for defenders:

• If you operate CloudFront with sensitive origins, evaluate mTLS-to-origin as a hardening lever for internal services and partner integrations

• In Azure, assess Private Link options for security tooling connectivity patterns to reduce exposure and simplify egress controls

• Review Google Cloud Apigee updates if you're managing API security at scale

Sources: AWS What's New, AWS Blog, Microsoft TechCommunity, Google Cloud Release Notes

5. 🤖 Agentic AI Security: Exposed Control Panels + Prompt Injection = One-Click RCE

What Happened: Axios reported security concerns around an open-source autonomous agent (Moltbot), including exposed/misconfigured control panels and susceptibility to prompt injection. Separately, a high-severity OpenClaw flaw was disclosed enabling one-click RCE via a malicious link (now patched). Security researcher Bruce Schneier also highlighted "indirect prompt injection" as a growing attack class.

Why This Matters: Agents frequently run with broad API keys, SaaS tokens, and cloud credentials. Prompt injection turns "content" (emails, tickets, docs, web pages) into a command channel that can exfiltrate secrets or trigger destructive actions. This is the next wave of supply chain attacks, but at the workflow layer attackers target what the agent reads and what tools it can use.

This connects directly to our main theme: as organizations adopt AI-powered automation in their security operations (including exposure management and remediation), they must understand the security implications. Brad Hibbert cautions: "You have to trust the opinions that these AI models are producing...automation works well for known patterns...but if it's risky change, if it's something where it could have an impact on a critical service...you may not automate it 100%. You still might want a human in the loop."

Actions for defenders:

• Enforce tool-scoped permissions with least-privilege API keys for all AI agents

• Isolate agent execution environments from production systems

• Require human approval gates for high-risk actions (data export, IAM changes, code deployments)

• Add monitoring for agent-initiated abnormal access patterns (bulk reads, new destinations, unusual OAuth scopes)

Sources: Axios, The Hacker News, Schneier on Security, Tenable

🎯 Cloud Security Topic of the Week:

From Vulnerability Chaos to Exposure Clarity: How Enterprises Are Winning the Risk Reduction Game

The security industry has a dirty secret: most organizations are drowning in vulnerability data but starving for actionable insights. According to Brad Hibbert, who has spent 20 years watching vulnerability management evolve from quarterly server scans to AI-powered exposure orchestration, the fundamental problem isn't finding vulnerabilities, it's deciding what to do about them.

"It really wasn't about the tools," Hibbert explains. "It was really about decision clarity and kind of moving beyond the tools."

This week, we're exploring why leading enterprises are moving from risk-based vulnerability management to exposure management, and what this means for cloud security teams trying to protect increasingly complex environments spanning infrastructure, applications, containers, identities, and AI systems.

Featured Experts This Week 🎤

• Brad Hibbert - COO & Chief Strategy Officer, Brinqa

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

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

• Risk-Based Vulnerability Management (RBVM): An approach that prioritizes vulnerabilities based on context like asset criticality, threat intelligence, and CVSS scores. Typically operates within individual tools and teams, providing prioritized lists of exposures but remaining siloed by domain (infrastructure, applications, cloud, etc.).

• Exposure Management: A holistic, enterprise-wide approach that sits above individual security tools to normalize, correlate, and prioritize risks across all domains. Focuses on business outcomes (risk reduction to critical services) rather than metrics (number of vulnerabilities closed). Emphasizes decision orchestration and remediation coordination across teams.

• Business Services vs. Assets: In exposure management, the unit of analysis shifts from individual assets (servers, containers, VMs) to business services (customer-facing applications, internal workflows, revenue-generating systems). A single business service may span multiple assets, and a single asset may support multiple services.

• Remediation Owner vs. Risk Owner: Risk owners (typically service owners or business unit leaders) decide what risk to accept or remediate based on business impact. Remediation owners (infrastructure, cloud, AppSec teams) perform the actual fixes. This separation is critical for effective exposure management.

• Decision Orchestration vs. Data Orchestration: Data orchestration normalizes and aggregates vulnerability data from multiple sources. Decision orchestration provides opinionated recommendations on what to fix based on business context, reachability, exploitability, and blast radius enabling faster, more confident action.

• Explainable AI in Security: AI models that provide clear reasoning for their recommendations, allowing security teams to understand why a particular vulnerability or exposure is prioritized. Critical for building trust in AI-driven security decisions.

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.

See Prowler In Action

💡Our Insights from this Practitioner 🔍

From Vulnerability Chaos to Exposure Clarity: How Enterprises Are Winning the Risk Reduction Game (Full Episode here)

The Evolution: From Patch Lists to Business Impact

Twenty years ago, vulnerability management was straightforward. Organizations scanned servers quarterly, generated reports sorted by CVSS score, and worked down the critical/high list until the next audit cycle. "We were dealing with large customers...it was all about the servers and patching servers", Hibbert recalls. "They might have done a scan once a quarter to meet their compliance requirement. Then they moved it to monthly".

But the cloud changed everything.

"Today, assets are a lot more dynamic and interconnected than they were in the past", Hibbert explains. "It's not just about a server, it's about the business services that server is supporting. A server could be supporting multiple services. Those services could be spread across multiple processing units and storage units and those sorts of things".

This interconnectedness creates a fundamental challenge: traditional vulnerability management approaches, even risk-based ones, remain siloed within individual teams and tools. Infrastructure teams manage server vulnerabilities. AppSec teams manage code vulnerabilities. Cloud teams manage container and configuration issues. Each has their own priorities, their own dashboards, their own understanding of "critical".

"The team's really drowning in data", Hibbert observes. "It's not, you don't have a telemetry, it's how do you kind of work through that data? I come to you as a remediation owner, so you crack open a spreadsheet and start arguing that your data's different from my data. Right? That happens a lot".

The Exposure Management Difference: Context Over Volume

The shift to exposure management represents a fundamental change in how organizations think about security risk. Instead of optimizing for vulnerability closure rates or compliance metrics, exposure management focuses on a more strategic question: What exposures could actually impact the business, and how do we coordinate their removal across teams?

Hibbert breaks this down into several key questions that exposure management must answer:

1. Do I have this exposure in my environment? (Discovery still important but no longer sufficient)

2. Is it reachable in my environment? (Network context, segmentation, access controls)

3. Is it exploitable? (Threat intelligence, exploit availability, attack complexity)

4. What's the blast radius if exploited? (Connected services, data access, lateral movement paths)

5. Which business services does this affect? (Service mapping, criticality assessment)

6. Who owns the risk and who fixes it? (Service owners vs. remediation teams)

"It's a shift from reporting to remediation", Hibbert emphasizes. "Exposure management is all about getting that prioritization done at a finer level, but then mobilizing and orchestrating the remediation that needs to happen to remove that risk from the environment across the different teams".

This distinction is critical. Risk-based vulnerability management gives you better prioritized lists. Exposure management gives you coordinated action.

The Ownership Problem: Service Owners vs. Remediation Teams

One of the most persistent challenges in vulnerability management has always been ownership. Who's responsible for fixing what? In traditional environments, the answer was simple: if it's on your server, it's your problem. But modern architectures don't work that way.

"The server team's not gonna know which one of these services is most important to the business", Hibbert points out. "It would be the service owners that understand, am I willing to accept this risk?"

He provides a concrete example: "If a server has multiple applications or is supporting multiple services, one might be a service that's providing a service to your internal employees. It might also be providing support for a service that's providing a service to your customers. The server team's not gonna know which one of these services is most important to the business".

This leads to a crucial distinction in exposure management: risk owners versus remediation owners.

Risk owners (typically service owners or business unit leaders) understand business impact and make decisions about risk acceptance or mitigation priority. They can answer: "Is this service revenue-generating? Is it customer-facing? What's the SLA? What's the business impact if it goes down?"

Remediation owners (infrastructure, cloud, AppSec teams) have the technical expertise and access to implement fixes. They can answer: "How do we patch this? What's the change control process? What's the testing requirement? What's the rollback plan?"

"I own the risk as the service owner", Hibbert explains. "But when exposures happen that could impact my service, I have to mobilize those remediation teams to go fix it. Those teams could be, if it's in the code, could be the code team. If it's in the cloud, it could be the cloud team. If it's on the server, it could be a server team".

This separation enables more effective decision-making because business context and technical execution are properly aligned.

The AI Opportunity (and Its Limits)

Given the massive volumes of security data organizations must process vulnerabilities, configurations, threat intelligence, asset context, network topology, identity permissions AI seems like an obvious solution. And Hibbert agrees, with important caveats.

"AI is certainly a great way to help you kind of do that", he says. "It can help you make the connections that as a human are difficult to make. So if you start to look at attacker behavior, attack techniques, the way that these exploits are being leveraged, what mitigating controls you have in place...there's just a number of different data elements that could be tied together. And the use of AI certainly helps you make those connections very quickly".

But here's the critical insight: AI is only as good as the data foundation it's built on.

"You have to trust the opinions that these AI models are producing", Hibbert warns. "And so, for me, you know, I always tell people AI's great. Automation's always great. It can speed things up. You want it to speed the right things up. So you want to make sure that your AI is based on a sound data foundation".

This means:

1. Normalize data from all sources: Multiple scanners, multiple CMDBs, multiple threat feeds must speak a common language

2. Establish shared risk models: Teams must agree on how risk is calculated and prioritized before AI starts making recommendations

3. Ensure explainability: AI must show its work why is this vulnerability prioritized? What factors contributed to the score?

4. Build trust gradually: "If you don't believe in the data, if you're suspect over the opinions coming out of the AI, then you're not gonna take action based on those outputs"

Regarding the holy grail of automated remediation, Hibbert is pragmatic: "Automation works well for known patterns. Like if it's a simple fix or configuration change or something you've done in the past where the AI can look back and see previous behavior and say, 'Hey, I have a 90% confidence that this is the right thing to do.'"

But for high-impact changes? "If it's a risky change, if it's something where it could have an impact on a critical service...or it could have significant damage in some way, then you may not automate it 100%. You still might want a human in the loop where you automate everything, but a human has to click the button".

This aligns perfectly with the emerging threats we're seeing around AI agents and prompt injection attacks. As AI systems gain more autonomy in security operations, the blast radius of a compromised or misdirected AI agent increases dramatically. The guardrails matter.

Compliance vs. Impact: A Critical Distinction

One of the most persistent challenges in vulnerability management is the compliance-driven approach many organizations are forced to adopt. PCI DSS requires critical vulnerabilities to be remediated within 30 days. Other frameworks have similar requirements. But Hibbert argues these metrics miss the point.

"Compliance in many cases just proves activity", he observes. "Hey, I closed my critical vulnerability in 21 days, but it's not tied to the actual risk".

The problem is that compliance frameworks tend to lag behind the reality of modern threat landscapes. They focus on metrics that are easy to measure (number of vulnerabilities, time to patch, coverage percentages) rather than outcomes that actually matter (risk reduction to business-critical services, prevention of real-world attacks).

"Compliance proves activity", Hibbert says. "Exposure management proves impact risk reduction in the environment. So you tie it back to, again, I removed this much risk from this particular business service as opposed to like, 'Hey, I cleared off my critical vulnerabilities off my servers.'"

This doesn't mean ignoring compliance requirements. It means understanding that compliance is a floor, not a ceiling. Organizations that only optimize for compliance metrics are playing a dangerous game: they're measuring activity while adversaries are measuring opportunity.

The Maturity Path: How to Start Without Boiling the Ocean

For organizations looking to evolve from risk-based vulnerability management to exposure management, Hibbert's advice is consistent: start small, prove value, then scale.

"Don't try to boil the ocean", he cautions. "Pick an area of the business that you want to evolve beyond risk-based vulnerability management to an area where risks are visible, where they're painful in the organization today. So that could be on a certain set of services. Maybe it's one service or two services that you want to focus on getting that next level of prescription. Maybe it's your external attack surface...whatever the area is within your organization, focus on that first".

The key is demonstrating actual risk reduction to business services, not just improved metrics: "Show that you have success. We have many customers of ours who have dozens of different applications that they've kind of brought into the program, but they started with two. And then kind of once they showed some value and showed how they're making better decisions that better aligned to the business itself, then they expanded".

He recommends several prerequisites before beginning an exposure management initiative:

1. Executive commitment: "There has to be executive commitment at the top layer that exposure management is a discipline that an organization wants to embrace".

2. Shared understanding of risk: "You have to have that shared understanding of risk across the different teams...in many cases, I would say there needs to be a shared incentive program. So they're all working towards the same goal across the different teams".

3. Dedicated resources: "Most of the programs that we've seen...just to drive the accountability and the movement across the different teams and coordinate the activities across the teams, it does require some resourcing and some investment".

4. Start with friendlies: Begin with teams that understand the limitations of current approaches and are motivated to try something new. Success with early adopters builds momentum.

5. Accommodate existing workflows: "You don't wanna force them to some sort of corporate way of doing things. We've got customers who use 20 different flavors of Jira, and we can accommodate that. We're not asking them all to change the way they develop code, but we're showing them where in their code that they should fix exposures by using a broader, more business-aligned prioritization model".

The Data Consistency Challenge

One recurring theme in Hibbert's experience is the "competing spreadsheets" problem. Different teams use different tools, which produce different data, which leads to endless debates about whose numbers are correct.

"What you don't wanna do in an exposure management program is I come up with this great list of things I need to get done, but then I come to you as the remediation owner and I say, 'Hey, can you go fix this?' And you crack open a spreadsheet and start arguing that your data's different from my data. Right? That happens a lot".

The solution isn't to force everyone onto the same tooling that's neither practical nor desirable, as different teams need different capabilities. Instead, exposure management platforms sit above the tools, normalizing and correlating data to create a single source of truth for prioritization decisions.

"Having that shared understanding of risk and how you're gonna calculate risk is critical", Hibbert explains. "And then having explainability on why...you feel that your data has given you the best decisioning capability that you can, is pretty important".

This normalization layer also helps address another common challenge: legacy systems and technical debt. "You're never gonna start with perfect data, perfect systems", Hibbert acknowledges. "But pick an area of the business that you want to focus on...and then focus on the decisions. Don't focus on the scope of the program".

RELATED RESOURCES 🎧

• AI TRiSM Overview by Gartner - Understanding the AI Trust, Risk, and Security Management category

• AWS Security Best Practices - Official AWS security guidance

• Microsoft Cloud Security Benchmark - Azure security baseline recommendations

• Google Cloud Security Foundations Guide - GCP security architecture patterns

• Brinqa Exposure Management Platform - Enterprise-grade exposure management and decision orchestration

Cloud Security Podcast

• Cloud Security Podcast – Full Episode with Brad Hibbert

Related Podcast Episodes 🎧

Vulnerability Management vs. Exposure Management

Question for you? (Reply to this email)

🤔   Is your team still fighting spreadsheet wars over vulnerability priorities which service owner will you pilot exposure management with first?

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!

Shilpi Bhattacharjee

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

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 (noreply-application-integration@google.com), 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.

Source: Check Point Research

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:

Featured Experts This Week 🎤

• Caleb Sima- WhiteRabbit.vc | Co-Host AI Security Podcast

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

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.

See Prowler In Action

💡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."

RELATED RESOURCES

• Check Point Research Blog - Original research on cloud service abuse and emerging threat vectors

• Morphisec Labs - Analysis of ransomware evolution and cloud-based attack techniques

• Anthropic Security Advisories - Insights on securing AI agent deployments

• NIST Zero Trust Architecture (SP 800-207) - Framework for implementing continuous verification

• Cloud Security Alliance - Cloud Controls Matrix - Comprehensive cloud security control framework

• OWASP AI Security and Privacy Guide - Security patterns for AI integrations

• MITRE ATT&CK for Cloud - Cloud-specific adversary tactics and techniques

• ScoutSuite - Multi-cloud security auditing tool for configuration assessment

• Prowler - Open-source cloud security assessment tool

Related Podcast Episodes 🎧

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!

Shilpi Bhattacharjee

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

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter topic: Engineering-Led Detection Programs in the AI Era (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

As enterprises scale AI across security and engineering workflows, a hard truth is emerging: LLMs fundamentally cannot distinguish instructions from data.
This week’s Cloud Security Newsletter connects the dots between prompt injection vulnerabilities across Google Gemini, Microsoft Copilot, and GitHub Copilot, CI/CD trust boundary failures in AWS CodeBuild, and what detection programs must look like in an AI-first threat landscape.

🎙️ This week’s practitioner deep dive features Antoinette Stevens, Principal Security Engineer at Ramp, sharing how engineering-led detection programs scale with AI without outsourcing judgment to models.[Listen to the episode]

📰 TL;DR for Busy Readers

• Prompt injection is now OWASP LLM01 — models cannot reliably separate instructions from data

• CI/CD pipelines are auth surfaces: AWS CodeBuild regex flaw shows how supply-chain attacks scale

• Semantic attacks beat string-based defenses (Gemini + Calendar invites)

• Microsoft Copilot “Reprompt” enabled silent, persistent data exfiltration

• Engineering-led detection treats alerts as production code, not rules

• AI SOC agents help at L1 — but hallucinate without human validation

📰 THIS WEEK'S TOP 5 SECURITY HEADLINES

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

1. "CodeBreach" Vulnerability in AWS CodeBuild Exposed Supply-Chain Risk

Wiz Research disclosed a critical vulnerability pattern in AWS CodeBuild's GitHub integration where improperly anchored regex checks could enable attackers to impersonate authorized maintainers and trigger privileged build workflows. The flaw, dubbed "CodeBreach," demonstrates how authorization weaknesses in CI/CD pipelines can escalate into software supply-chain compromise events. AWS remediated the issue within approximately 48 hours and confirmed no customer environments were impacted.

Why This Matters: This vulnerability exemplifies a classic CI/CD trust boundary failure where seemingly minor authorization logic can become a blast radius multiplier. For cloud security teams, every build trigger represents a production authentication surface—particularly those that can mint credentials, publish artifacts, or merge to protected repositories. As Antoinette Stevens noted in our conversation, detection engineering must extend beyond traditional security boundaries to include developer workflows and automation systems.

Recommended Actions: Audit all CodeBuild and GitHub integration patterns for regex anchoring and identity mapping issues. Implement manual approval gates for privileged PR-comment workflows. Restrict build roles to least-privilege, short-lived credentials. Deploy detections for anomalous trigger identities and unusual PR-comment patterns.

Source: IT Pro

2. Prompt Injection Officially Named Top AI Threat - OWASP LLM01 for 2026

Multiple January 2026 research publications and incidents confirmed prompt injection as the primary attack vector against AI systems, with OWASP formally designating it as LLM01 in their updated Top 10 for LLM Applications. A comprehensive academic review analyzed 45 sources documenting real-world attacks including GitHub Copilot's CVE-2025-53773 (CVSS 9.6 remote code execution), ChatGPT's Windows license key exposure, and research demonstrating that just five carefully crafted documents can manipulate AI responses 90% of the time through RAG poisoning. IEEE Security & Privacy 2026 research revealed that 8 of 17 third-party chatbot plugins fail to enforce conversation history integrity, enabling client-side message manipulation.

Why This Matters: This represents a fundamental architectural vulnerability in LLM systems with no complete technical solution models cannot reliably distinguish instructions from data. For cloud security teams deploying AI-powered tools including code assistants, chatbots, and automation agents, prompt injection creates risks across the entire attack chain: data exfiltration, credential theft, unauthorized actions, and supply-chain compromise. The OWASP update added new categories for System Prompt Leakage and Vector/Embedding Weaknesses, reflecting the maturation of attack techniques. Organizations must implement defense-in-depth strategies including input sanitization, output validation, privilege minimization for AI agents, sandboxing for tool execution, monitoring for anomalous behavior, and strict separation between trusted system prompts and untrusted user or external content. Reports from Palo Alto Network’s Unit 42 were referred for this news coverage.

Sources: MDPI Research, OWASP, Palo Alto Unit 42

3. Microsoft Copilot "Reprompt" Vulnerability Enabled Silent Data Exfiltration

Varonis Threat Labs disclosed a critical vulnerability in Microsoft Copilot Personal that enabled attackers to silently exfiltrate sensitive user data through a single malicious link click. The "Reprompt" attack exploited the 'q' URL parameter to inject hidden prompts, enabling continuous data extraction even after the Copilot session closed—all without requiring plugins, direct user interaction with Copilot, or additional authentication. Microsoft patched the flaw on January 13, 2026, following responsible disclosure in August 2025. The vulnerability bypassed built-in safety controls through parameter injection, double-request techniques, and chain-requests that maintained persistence.

Why This Matters: Reprompt demonstrates the fundamental security challenge in LLM-based assistants: the inability to reliably distinguish between trusted instructions and untrusted data. For enterprise cloud security teams, AI assistants integrated into workflows create new attack surfaces for credential theft and data exfiltration. Notably, Microsoft 365 Copilot enterprise customers were not affected, highlighting the critical importance of enterprise-grade security controls around AI deployments. Organizations deploying AI assistants must implement input sanitization, session integrity checks, and continuous monitoring—treating LLM interfaces as untrusted user input vectors equivalent to traditional web applications.

Sources: The Hacker News, Varonis, SecurityWeek

4. Google Gemini Calendar Integration Exploited for Semantic Attacks

Miggo Security reported a prompt injection and authorization bypass vulnerability where malicious payloads embedded in Google Calendar invites could be interpreted by Gemini-integrated workflows, exposing private meeting data and enabling creation of deceptive events. Google confirmed and mitigated the issue following responsible disclosure.

Why This Matters: This vulnerability represents the clearest manifestation of the cloud productivity-to-AI agent risk pattern: trusted business objects like calendar invites, documents, and tickets become instruction channels for AI systems. Traditional security controls looking for malicious strings cannot defend against semantic attacks. Defense requires tool-permission governance, data provenance tracking, and runtime policy enforcement to prevent models from exfiltrating sensitive context into attacker-visible fields.

Recommended Actions: For enterprise AI assistants and agents, restrict tool scopes particularly for write actions and cross-tenant sharing. Implement allowlists for sensitive actions including create, share, and export operations. Deploy monitoring for unusual automated edits and creates in Calendar and Drive. Treat AI integrations as new privileged applications requiring threat modeling, comprehensive logging, and incident response playbooks.

Source: Miggo Security

5. AWS Publishes Updated SOC Reports: 185 Services Now In Scope

AWS announced availability of Fall 2025 SOC 1/2/3 reports with 185 services now in scope, providing customer assurance, control mapping capabilities, and audit readiness support.

Why This Matters: SOC scope expansions reduce control gaps for regulated cloud programs and can accelerate onboarding of additional managed services—provided teams update their control mappings accordingly. This is particularly relevant for organizations standardizing evidence collection across multi-region, multi-account environments.

Recommended Actions: Refresh GRC evidence packages. Validate which newly in-scope services your organization relies on. Align internal control narratives to the updated SOC boundary. Leverage this expansion to simplify vendor questionnaires and reduce bespoke audit work.

Source: AWS Security Blog

🎯 Cloud Security Topic of the Week:

Engineering-Led Detection Programs in the AI Era

As AI systems integrate deeper into enterprise security operations, the traditional approach to detection engineering faces fundamental challenges.

This week's topic explores how engineering principles testing suites, validation frameworks, and architectural thinking—are becoming essential for building detection programs that scale effectively while maintaining accuracy and business context.

We examine the reality of AI-augmented security operations, the critical distinction between AI as a force multiplier versus a replacement for human expertise, and practical strategies for maturing detection capabilities in 2026's threat landscape.

Featured Experts This Week 🎤

• Antoinette Stevens –  Principal Security Engineer at Ramp

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

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

• Prompt Injection: A vulnerability class where attackers manipulate AI system behavior by embedding malicious instructions within user inputs or external data sources. Unlike traditional injection attacks, prompt injection exploits the fundamental architectural limitation that LLMs cannot reliably distinguish between trusted system instructions and untrusted user data.

• Detection as Code: An engineering approach to detection engineering where detection rules are managed as source-controlled code with testing suites, validation frameworks, and automated deployment pipelines. This methodology brings software engineering disciplines to security operations.

• RAG Poisoning: An attack technique targeting Retrieval-Augmented Generation systems where attackers inject malicious content into knowledge bases or vector databases that AI systems query to enhance their responses. Research demonstrates that as few as five carefully crafted documents can manipulate AI responses 90% of the time.

• Model Evaluation (Evals): A framework for measuring AI model accuracy and reliability by testing outputs against known-good examples or validation criteria. In security contexts, evals measure how accurately AI agents perform investigations, triage alerts, and make security decisions.

• Model Memory: The capability of AI systems to retain and reference previous interactions within a session or across sessions. Modern AI assistants use conversation history to inform future responses, which is critical for maintaining investigation context but also creates new attack surfaces for memory poisoning.

• CI/CD Trust Boundary: The authentication and authorization perimeter around continuous integration and deployment systems. Failures in these boundaries can enable supply-chain attacks where unauthorized actors trigger privileged automation, mint credentials, or publish malicious artifacts.

• Alert Bloom: A condition where detection rules generate excessive false positives, overwhelming security teams and reducing the signal-to-noise ratio. Engineering-led detection programs treat alert bloom as a code quality issue requiring systematic refactoring.

This week's issue is sponsored by Push Security 

Want to learn how to respond to modern attacks that don’t touch the endpoint? 

Modern attacks have evolved — most breaches today don’t start with malware or vulnerability exploitation. Instead, attackers are targeting business applications directly over the internet. 

This means that the way security teams need to detect and respond has changed too. 

Register for the latest webinar from Push Security on February 11 for an interactive, “choose-your-own-adventure” experience walking through modern IR scenarios, where your inputs will determine the course of our investigations. 

Register Now

💡Our Insights from this Practitioner 🔍

The Engineering Foundation: Why Testing and Validation Matter More Than Ever (Full Episode here)

One of the most striking insights from Antoinette Stevens centers on what distinguishes engineering-led detection programs from traditional security operations approaches. The difference isn't merely technical—it's philosophical. Engineering-trained practitioners bring disciplines that seem obvious until you realize they're not universally practiced: testing, validation, reliability, and observability.

"I think there are certain things that you learn when you've been trained to do engineering work, especially around testing and validation and reliability and observability," Stevens explained. "Some of those things that some people might take for granted—it feels obvious until you realize you haven't been doing it."

This engineering mindset fundamentally changes how detection programs scale. Traditional approaches often treat detection rules as one-off implementations: identify a threat, write a rule, deploy it, and move on. Engineering-led programs instead view detection rules as production software requiring lifecycle management. Stevens described this evolution: "We've seen a rise in detection as code becoming more popular. That's an engineering-led approach where you are source controlling something, you might make a test suite to make sure it works. You have validations, you do various things before you move things to production."

The practical implications are substantial. At Ramp, Stevens built validation directly into the detection pipeline. Her detection engineer created GitHub-based rule validation, while their detection platform provides built-in testing frameworks where mock logs validate that alerts fire as expected. This isn't theoretical testing—it's automated validation that runs before any detection rule reaches production.

Practical Application: For security leaders building or maturing detection programs, the first step is treating detection rules as production code. This means implementing source control for all rules, creating testing frameworks that validate detection logic against both historical and synthetic data, building automated validation into your deployment pipeline, and establishing observability for detection effectiveness including false positive rates and coverage gaps.

The Build vs. Buy Calculation Changes with Engineering Capability

The traditional security vendor landscape assumes teams lack engineering capability. Stevens challenges this assumption, arguing that engineering-led teams should fundamentally reconsider their approach to tooling procurement. "If you have engineers on your team—people who can build software—your approach to buying tooling changes such that my approach is now: can I build it myself? And if so, is the cost of me building it myself more or less than the cost of buying it?"

This isn't about blanket build-versus-buy recommendations. Stevens applies a nuanced framework considering maintenance burden, support requirements, and long-term sustainability. "There are platforms that help you with log ingestion—I'm not paying for that. I could write a script and then never touch it again." But for more complex capabilities like AI agent evaluation frameworks, "I don't want to run that myself. I want to stay away from building an entire product internally that won't outlast my tenure."

The decision matrix centers on complexity and required ongoing investment. Simple, stable functionality that rarely requires updates becomes a build candidate. Complex systems requiring continuous tuning, evaluation frameworks, and vendor support become buy candidates. This is particularly relevant for AI-powered security tools where evaluation infrastructure, model rotation capabilities, and observability platforms represent significant ongoing engineering investments.

Practical Application: When evaluating security tools, assess your team's engineering capability honestly. For teams with strong engineering skills, conduct build-versus-buy analyses for each major capability area. Calculate total cost of ownership including development time, maintenance burden, and opportunity cost of not focusing on core security problems. Reserve building for stable, low-maintenance capabilities where vendor solutions add limited value. Buy complex platforms requiring continuous evaluation, model management, or specialized expertise your team lacks.

AI as Force Multiplier: The Reality Check on AI SOCs

The promise of fully autonomous AI security operations centers has captured significant vendor marketing attention. Stevens provides a grounded reality check based on actual implementation experience. At Ramp, AI handles first-level triage, conducting initial investigations before human analysts review and make final decisions. But Stevens is emphatic about the limitations: "I do not trust it to close out alerts. I have watched ChatGPT just lie to me continuously. I am definitely not fully on board with just letting it close out things."

The challenges are fundamental, not merely teething problems with immature technology. Stevens identified several critical issues. First, AI agents make logical inferences that may be incorrect: "If you're not clear with it in how an investigation should be run, it tends to try to fill in the gaps for you. It likes to make a lot of logical summarizations where it says 'and this happened because of X' and 'the result of this is that'... I don't need you to guess at why someone did something. I just need the facts of the situation."

Second, AI agents lack business context that's obvious to human analysts. Stevens cited an example where their AI flagged a subnet opened to the internet as legitimate because "this action was taken by an engineer, and so it is legitimate." The agent missed the critical point: "It doesn't matter if it's legitimate. We should always know and want to do something if a resource is open to the internet."

Third, model variability poses operational risks. "A new version of GPT could come out and be completely wrong," Stevens noted, highlighting that AI SOC implementations must account for model regression risks. This requires robust evaluation frameworks to catch degradation in investigation quality across model updates.

Despite these limitations, AI has delivered measurable value. "AI should be a force multiplier, but it should not be your brain," Stevens emphasized. For her team, AI has been "helpful with noise reduction" and "helpful with tuning." The key is appropriate human oversight: "I still have a base philosophy that if an alert is not useful, it should not fire," meaning even AI-triaged alerts require human validation to ensure quality.

Practical Application: When implementing AI for security operations, deploy it for L1 triage with mandatory human review before any automated response actions. Implement evaluation frameworks to continuously measure investigation accuracy and catch model regression. Develop clear investigation procedures that constrain AI to factual reporting rather than inferential reasoning. Maintain business context through well-defined prompts and investigation playbooks. Track false positive rates separately for AI-triaged versus human-triaged alerts to measure actual effectiveness. Plan for model variability by designing systems that can gracefully handle model updates or degradation.

The Prerequisites: Why AI Doesn't Replace Fundamentals

Perhaps Stevens' most important insight concerns who can effectively leverage AI for detection engineering. The answer challenges popular narratives about AI democratizing technical capabilities. "If you don't know how to write code, AI won't help you get anywhere faster because it's going to write slop and then things will break and you won't know how to fix it," Stevens stated bluntly.

This isn't gatekeeping—it's recognition that AI amplifies existing capabilities rather than creating them. Stevens explained: "For people who already know how to build software, I think it accelerates. But for almost anyone else, it likely slows you down." The reasoning is straightforward: without understanding code architecture, developers cannot evaluate whether AI-generated code is over-engineered, missing critical functionality, or introducing vulnerabilities.

The security implications are particularly concerning. "If you don't understand how architecture works or the basics of writing code, then if your AI generates code that is over-engineered or missing something, especially if you're prompting it and you don't know how... you end up with a product that down the line isn't sustainable. At best isn't sustainable, at worst is vulnerable to something."

This extends to understanding both security and cloud domains. Using AWS as an example, Stevens noted: "You already have AWS experience, you have generic cloud computing understanding. You could easily walk into an Azure environment and go, show me the equivalent of object storage. I'm looking for this specific type of thing. What's possible here?" But that contextual knowledge is prerequisite—without it, you cannot effectively prompt AI or evaluate its responses.

Practical Application: When building detection engineering teams, prioritize fundamental skills: coding ability, cloud architecture understanding, and security domain expertise. AI training should be additive, not foundational. For existing team members adopting AI tools, invest in prompt engineering training that emphasizes contextual expertise—teaching people to validate AI outputs rather than blindly trust them. For detection programs considering AI augmentation, ensure team members can review and modify AI-generated code, understand the architecture of systems being monitored, and possess security domain knowledge to catch hallucinations or incorrect inferences.

Multi-Agent Architectures: The Future of AI Security Operations

As detection programs mature their AI implementations, architectural sophistication increases. Stevens discussed exploring multi-agent architectures where specialized agents handle specific tasks with an orchestrator coordinating overall investigation workflow. "Individual agents do very specific things and there's an orchestrator agent pulling data from each of them," she explained.

This approach addresses a fundamental limitation of general-purpose AI agents: they perform better with narrow, well-defined responsibilities. "They do really well when they do a very specific job," Stevens noted. She referenced vendor implementations with specialized agents for legal analysis, penetration testing, and validation that collaborate to reach consensus before taking actions.

The multi-agent pattern also improves accuracy through specialization and cross-validation. Rather than a single agent making investigation decisions, specialized agents provide domain-specific analysis that an orchestrator synthesizes. This architectural approach mirrors how security operations centers organize human analysts by specialty areas, suggesting it may represent a sustainable pattern for AI-augmented security operations.

Practical Application: For organizations with mature AI implementations, consider transitioning from monolithic AI agents to multi-agent architectures. Design specialized agents for distinct investigation tasks such as log analysis, threat intelligence lookup, compliance checking, and business context validation. Implement orchestrator patterns that coordinate specialized agents and synthesize their outputs. Develop evaluation frameworks that measure both individual agent accuracy and overall investigation quality. Start with lower-risk investigation areas before expanding to critical alerts.

Career Implications: The Shift in Entry-Level Security Positions

Stevens raised a sobering reality about AI's impact on security career paths. "I am really nervous for the entry-level positions in security," she admitted. "A lot of the entry-level work that we would hire people for can be done now with AI." This isn't a distant future concern—it's happening now.

The implications extend beyond technical skills. Stevens offered crucial advice for early-career professionals: "If you're early on in your career, your job is to be a personality hire. That is your goal. If you don't do anything, you contribute almost no value at that stage. Your job is to be a good person and to learn as much as you can."

This represents a fundamental shift in what organizations value in junior security professionals. Technical tasks that previously provided entry points into security careers are increasingly automated. What remains irreplaceable are interpersonal skills, adaptability, composure under pressure, and the ability to collaborate effectively—the very skills that enable someone to be, as Stevens put it, "cool as a cucumber" during incidents when everyone else is panicking.

For those entering security now, Stevens recommended targeting larger, established enterprises rather than startups. "Finding an older, larger company is going to be your best bet," she advised, noting that these organizations are slower to adopt AI and still maintain traditional career progression paths. "The realistic possibilities of getting a job at a smaller startup without some sort of deeply technical skill to go with it is very slim."

Practical Application: For hiring managers, recalibrate entry-level requirements to emphasize interpersonal effectiveness, learning agility, and composure under pressure alongside technical fundamentals. For early-career professionals, focus on developing differentiated skills that AI cannot replicate: incident response composure, cross-functional collaboration, business context understanding, and technical communication. Target internships and entry-level positions at larger enterprises with established security programs. Build foundational technical skills—particularly coding ability—that enable effective AI utilization rather than replacement by AI.

The Emerging Threat Landscape: Back to Basics

Despite AI's prominence, Stevens emphasized that effective security in 2026 still requires fundamentals. "A lot of this is just getting the basics right," she stressed. Her specific recommendations reflect current threat patterns: "If you don't have a good endpoint detection program, you should probably consider getting one now, considering all the NPM packages that are getting compromised and the move to targeting engineering and developer machines."

Shadow IT management has become increasingly critical as threat actors exploit AI hype. "Getting a Shadow IT program going, if you don't have one, is a good move. We've seen a lot of malware be propagated through tooling claiming to be AI or like different AI software," Stevens noted.

This advice grounds AI security concerns in actionable defensive measures. While prompt injection and AI agent vulnerabilities represent real threats, they layer atop traditional attack vectors that remain highly effective. The solution isn't choosing between AI-focused or traditional defenses—it's ensuring foundational controls are robust before adding AI-specific protections.

Practical Application: Audit your endpoint detection coverage, particularly for developer and engineering workstations that are increasingly targeted through compromised development tools and packages. Implement or strengthen Shadow IT programs with specific focus on unapproved AI tools that may introduce data exfiltration or prompt injection risks. Review software supply chain security including NPM, PyPI, and other package repositories your developers rely on. Establish baseline security controls before investing heavily in AI-specific security tools. Remember that threat actors are also learning AI—they're not yet expert adversaries, providing a window to strengthen fundamentals.

RELATED RESOURCES 🎧

• OWASP Top 10 for LLM Applications 2025 — Comprehensive guide to AI security risks including prompt injection, supply-chain vulnerabilities, and system prompt leakage

• Detection Engineering Maturity Matrix — Framework for assessing and improving detection program maturity with focus on engineering practices

• AWS CodeBuild Security Best Practices — Official guidance on securing CI/CD pipelines including least-privilege build roles and trigger authentication

• MITRE ATT&CK for ICS: AI/ML Attack Techniques — Taxonomy of adversarial techniques targeting AI systems including data poisoning and model evasion

• Detection as Code: A Practical Guide — Open-source resources for implementing source-controlled, tested, and validated detection rules

• Prompt Injection Defenses: A Comprehensive Guide — Simon Willison's authoritative resource on understanding and mitigating prompt injection attacks

• Cloud Security Alliance: AI Security Guidance — Industry consortium guidance on securing AI deployments in cloud environments

Cloud Security Podcast

• Cloud Security Podcast – Full Episode with Antoinette Stevens

Related Podcast Episodes 🎧

Why AI Can't Replace Detection Engineers: Build vs. Buy & The Future of SOC

Question for you? (Reply to this email)

🤔 Is your detection program treating AI as a force multiplier or a replacement — and what’s the first capability you’d automate with human oversight still in the loop?

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!

Shilpi Bhattacharjee

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

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter topic: AI Vulnerability Management: Why You Can't Patch a Neural Network (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

As we enter the first full week of 2026, a troubling pattern is emerging: sophisticated threat actors are exploiting critical infrastructure vulnerabilities months, even years before public disclosure, while enterprises struggle to secure increasingly dynamic, AI-driven assets.

This week, Sapna Paul, Senior Manager of Vulnerability Management at Dayforce, joins us to explain why traditional scan-and-patch workflows are breaking down — and how AI is forcing a fundamental rethink of what “vulnerability management” actually means.[Listen to the episode]

📰 TL;DR for Busy Readers

• Chinese threat actors exploited VMware ESXi zero-days for 12+ months before disclosure, targeting 30,000+ exposed instances

• HPE OneView vulnerability (CVSS 10.0) actively exploited, CISA sets January 28 remediation deadline for infrastructure management platforms

• CrowdStrike acquires SGNL for $740M, signaling major consolidation in identity security and zero-trust markets

• AI vulnerability management requires new approach: observe, detect anomalies, retrain models—not just scan and patch

• FBI warns North Korean Kimsuky APT using QR code phishing to bypass email security and harvest credentials via mobile devices

📰 THIS WEEK'S TOP 5 SECURITY HEADLINES

1. Chinese Hackers Exploit VMware ESXi Zero-Days a Year Before Disclosure

Security researchers at Huntress uncovered a VM escape toolkit (“MAESTRO”) used by Chinese threat actors to exploit three VMware ESXi zero-days:

• CVE-2025-22224

• CVE-2025-22225

• CVE-2025-22226

Active since: Feb 2024
Disclosed: March 2025
Exposed instances: 30,000+

Why This Matters

Why Security Leaders & Teams Should Care

• Hypervisors remain silent, high-impact targets

• Signature-based scanning failed for a full year

• VM escape = total trust boundary collapse

Action

• Patch ESXi immediately

• Enable hypervisor-level monitoring

• Reduce ESXi internet exposure

• Segment management planes

Virtualization platforms remain high-value APT targets.

Sources: Huntress Research, Broadcom Security Advisory, SecurityWeek

2. HPE OneView Zero-Day Exploited in the Wild (CVE-2025-37164)

A maximum-severity vulnerability in HPE OneView was added to CISA’s KEV list.

Remediation deadline: January 28, 2026

Why This Matters
Infrastructure control planes are becoming single points of enterprise failure.

Action

• Patch immediately

• Restrict OneView network access

• Monitor admin activity and command execution

Infrastructure management platforms are becoming single points of failure.

Sources: CISA KEV Catalog, ITPro

3. CrowdStrike Acquires SGNL for $740M

CrowdStrike announced its acquisition of SGNL, expanding into AI-powered continuous authorization.

Why This Matters

Traditional IAM struggles with:

• Static access policies

• Multi-cloud fragmentation

• Limited entitlement visibility

This acquisition reinforces trends toward:

• Continuous authorization

• Zero-trust architectures

• Real-time access decisions

Sources: CNBC, CrowdStrike Announcement

4. FBI Warns: Kimsuky Using QR-Code Phishing (“Quishing”)

The FBI warns that North Korean APT Kimsuky is embedding malicious QR codes in emails to harvest credentials via mobile devices.

Why This Matters

Key risks include:

• Mobile devices bypassing enterprise security

• QR codes evading email inspection

• Session token theft bypassing MFA

Recommended Actions

• Deploy Mobile Threat Defense (MTD)

• Treat mobile as lower-trust endpoints

• Educate users on QR phishing

• Monitor mobile authentication anomalies

Sources: FBI Flash Alert, Tech Radar

5. Insider Threat: Cybersecurity Professionals in BlackCat Ransomware

Two U.S. cybersecurity professionals pleaded guilty to acting as BlackCat/ALPHV ransomware affiliates, earning $1.27M.

Why This Matters

Key Takeaway:

• Insider threats now include highly skilled defenders

• Zero-trust must apply to privileged users

• Vendor security assurance needs deeper scrutiny

Sources: U.S. Department of Justice, SecurityWeek

AWS Previews Security Agent

AWS announced the preview of Security Agent, an AI-powered penetration testing and security review platform that provides context-aware application security testing from design through deployment. The tool represents AWS's investment in AI-driven security automation, addressing the growing gap between application release velocity and security testing cadence.

Why This Matters

Traditional application security testing struggles to keep pace with modern CI/CD pipelines where organizations deploy code hundreds of times per day. AWS Security Agent attempts to solve this by:

• Context-aware security testing

• CI/CD-integrated AppSec

• Developer-focused remediation

Organizations should validate AI findings and maintain human oversight.

Sources: AWS Security Blog

🎯 Cloud Security Topic of the Week:

AI Assets and the Evolution of Vulnerability Management

Traditional vulnerability management has operated on a simple premise: find the flaw, patch it, verify the fix. But what happens when the asset itself is a learning system that can develop flaws organically over time? As AI models become core enterprise assets powering everything from fraud detection to customer service security teams face a fundamental challenge: you can't patch a neural network the way you patch Windows Server.

This week, we explore how vulnerability management is evolving to address AI assets, based on insights from Sapna Paul's work at Dayforce. The implications extend beyond AI-specific risks to fundamentally reshape how we think about asset management, risk quantification, and security operations in dynamic environments.

Featured Experts This Week 🎤

• Sapna Paul – Senior Manager, Vulnerability Management, Dayforce

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

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

• AI Model Vulnerability: A flaw or weakness in an artificial intelligence model that can be exploited to manipulate outcomes, exfiltrate training data, or cause the model to behave incorrectly. Unlike traditional software vulnerabilities, AI model vulnerabilities often stem from traning data poisoning, adversarial inputs, or emergent behaviors that weren't present during development.

• Neural Network: The underlying architecture of most modern AI systems, consisting of layers of interconnected nodes (neurons) that process information and learn patterns from data. In vulnerability management contexts, the neural network itself becomes the asset requiring protection, rather than just the application hosting it.

• Model Retraining: The process of updating an AI model by feeding it new or corrected training data to modify its behavior. This is the AI equivalent of patching, but unlike applying a security patch, retraining can take weeks of compute time and requires extensive validation to ensure the model maintains accuracy while addressing the vulnerability.

• Data Poisoning: An attack technique where adversaries inject malicious data into an AI model's training dataset, causing it to learn incorrect patterns or behaviors. This is particularly insidious because the vulnerability becomes embedded in the model's fundamental understanding, not just in its code.

• Behavioral Monitoring (AI Context): Continuous observation of AI model outputs and decision-making patterns to detect anomalies that might indicate vulnerability exploitation, data drift, or emergent problematic behaviors. This replaces traditional point-in-time vulnerability scanning for AI assets.

• NIST AI Risk Management Framework (AI RMF): A voluntary framework providing guidance for managing risks associated with artificial intelligence systems. It covers governance, trust, and responsible AI principles, serving as a de facto standard for U.S. organizations building or deploying AI systems.

This week's issue is sponsored by Push Security 

Want to learn how to respond to modern attacks that don’t touch the endpoint? 

Modern attacks have evolved — most breaches today don’t start with malware or vulnerability exploitation. Instead, attackers are targeting business applications directly over the internet. 

This means that the way security teams need to detect and respond has changed too. 

Register for the latest webinar from Push Security on February 11 for an interactive, “choose-your-own-adventure” experience walking through modern IR scenarios, where your inputs will determine the course of our investigations. 

Register Now

💡Our Insights from this Practitioner 🔍

AI Vulnerability Management: Why You Can't Patch a Neural Network (Full Episode here)

The Three Layers of AI Vulnerability Management

Sapna Paul fundamentally reframes vulnerability management for AI assets around three critical layers that security teams must address simultaneously:

Layer 1: Production Model Security
The first layer focuses on how adversaries can impact models actively serving users. "Have to keep analyzing the production models that are running, that are solving a use case," Sapna explains. "How an adversarial can impact the working of that model through red teaming and security testing of these models is so important."

This isn't traditional penetration testing it requires specialized techniques like:

• Adversarial example generation to test model robustness

• Prompt injection testing for language models

• Boundary testing to identify model hallucination thresholds

• Performance degradation analysis under attack conditions

For enterprise security teams, this means dedicating resources to ongoing model security assessment, not just pre-deployment validation. As Sapna notes, vulnerabilities in AI systems "can make AI become rogue" if left unaddressed.

Layer 2: Data Security and Integrity
The second layer addresses the training pipeline, the most critical attack surface for AI systems. "The vulnerabilities that can make their way into the model is through data, the training that is happening on the left side," Sapna emphasizes. "Poisoning, the biasness that an AI can learn is in the left side. So it's so important to understand what data is going in and the controls that need to be put around that data layer."

This requires security teams to:

• Implement access controls on training datasets with full audit logging

• Validate data integrity and provenance before training

• Monitor for bias indicators in training data

• Test models for signs of data poisoning (unusual decision boundaries, performance degradation on specific inputs)

The complexity here is that data poisoning attacks can be subtle. An attacker doesn't need to corrupt the entire dataset; carefully crafted examples injected into training data can cause specific failure modes that only activate under certain conditions.

Layer 3: Behavioral Ethics and Compliance
The third layer addresses what Sapna calls the "technically correct but ethically wrong" problem. "A model is giving you an outcome which is technically correct but ethically wrong if compliance is not there, AI can become rogue."

This layer requires entirely new evaluation frameworks:

• Ethical review of model outputs across diverse scenarios

• Demographic fairness testing to identify discriminatory patterns

• Regulatory compliance validation (EU AI Act, state-level AI regulations)

• Alignment testing to ensure model behavior matches organizational values

Consider a fraud detection model that accurately identifies fraud but disproportionately flags transactions from specific demographic groups. The model is technically working it's catching fraud but its operation violates fairness principles and potentially regulatory requirements.

"You have to make business understand what risk AI is bringing to your business," Sapna notes. "If you cannot tie back to the business or whatever your company's goals are, it's just not a useful risk register."

Shifting from Patching to Retraining: A Fundamental Workflow Change

Traditional vulnerability management follows a predictable cycle: discover vulnerability → apply patch → verify fix → move to next vulnerability. This workflow assumes the asset is static between updates.

AI assets break this model completely. "What would you do if an AI model has learned something wrong? There's no patch," Sapna explains. "There's no Patch Tuesdays. You can't just go there and patch the vulnerabilities. You have to take a step back, detect what it's doing, what weaknesses and flaws the model has, and then retrain."

The retraining process introduces complexity that traditional patch management never encountered:

Compute Resource Requirements: Model retraining can consume weeks of GPU time and cost tens of thousands of dollars for large models. This makes the "just patch everything" approach financially impractical.

Validation Cycles: After retraining, teams must validate that:

• The vulnerability has been addressed

• The model maintains its original accuracy and performance

• No new failure modes have been introduced

• Regulatory compliance is maintained

Deployment Risk: Deploying a retrained model carries risk that doesn't exist with traditional patches. A misconfigured model update could cause widespread service degradation or incorrect business decisions.

"It takes so many cycles of compute and weeks of testing and revalidation and redeployment," Sapna notes. "If I just put it in one line: you don't scan and patch anymore. You observe, you detect anomalies, and you retrain the model."

Asset Management Meets AI: When Assets Learn and Evolve

Perhaps the most fundamental shift Sapna describes is reconceptualizing what constitutes an "asset" in vulnerability management. "The asset is a neural network. The asset is a model, right? It's an AI, artificial intelligence. We have not done or assessed that sort of asset before in a typical traditional vulnerability management or cybersecurity space."

This creates several challenges for traditional asset management systems:

Dynamic Asset Behavior: Traditional assets have predictable behavior. A web server processes HTTP requests the same way today as it did yesterday. AI models evolve their behavior based on input patterns and can develop emergent properties that weren't present during testing.

Parameter Space Complexity: "There are billions of parameters, billions of different things you have to think about when you are doing vulnerability management in this space," Sapna explains. Traditional configuration management might track hundreds or thousands of settings; AI models have billions of weights and connections that collectively determine behavior.

Lack of Determinism: Unlike traditional software where the same input reliably produces the same output, AI models incorporate randomness and can produce different results for identical inputs. This makes vulnerability reproduction and testing significantly more complex.

For security teams, this means rethinking asset inventory practices:

• Document not just the model, but its training data lineage, hyperparameters, and validation metrics

• Track model versions with the same rigor as critical infrastructure

• Maintain test datasets that can verify model behavior over time

• Establish baselines for "normal" model behavior to detect drift or compromise

Speaking the Language of Data Teams: Bridging the Security-AI Gap

One of Sapna's most valuable insights addresses the communication gap between security and AI development teams. "You have to talk in the language that data people understand. If you go and say your model has this security vulnerability, they'll be like, 'What? No.' But if you go and say your model is going to be 30% less effective because an adversarial can do something to it and change its scores, now you can sit with that person and make them understand."

This reframing is critical because:

Different Risk Perspectives: Security teams think in terms of vulnerabilities and exploits. Data science teams think in terms of model accuracy, precision, and recall. The same issue must be translated across these mental models.

Business Impact Translation: Instead of technical security jargon, frame AI vulnerabilities in terms of:

• Model performance degradation under attack

• Business revenue impact from compromised models

• Regulatory penalties from biased or non-compliant model behavior

• Reputational damage from AI failures

Upskilling Requirements: "For that, we need to upskill as well. Security compliance people need to upskill their AI concepts, knowledge, subject matter... so you can talk in their language," Sapna emphasizes.

Organizations should invest in:

• AI fundamentals training for security teams

• Security awareness training for data science teams

• Cross-functional working groups that bring both disciplines together

• Shared metrics that matter to both security and AI teams

Governance Over Perfection: The Pragmatic Path Forward

Sapna offers a refreshingly pragmatic perspective on AI security: "You can't really have a perfect system. An ML model cannot just explain how it is reaching that particular outcome. So you won't have perfect explainability, but what you can have is good governance of AI systems."

This governance-first approach recognizes that:

Explainability Has Limits: Many of the most powerful AI models (deep neural networks, ensemble methods) are inherently difficult to fully explain. Demanding complete explainability would prevent deployment of valuable AI systems.

Governance Provides Guardrails: Instead of trying to make AI perfect, focus on:

• Version control for models (like Git for code)

• Audit trails of data access and model training

• Security gates in ML pipelines

• Continuous monitoring of production models

• Incident response procedures for AI failures

"If governed properly and audited properly, these can become big enablers for people who are trying to get AI models out the door," Sapna notes.

Using AI to Manage AI Vulnerabilities: The Meta-Solution

Perhaps most intriguingly, Sapna describes how AI itself can help manage the vulnerability burden that AI creates. "Use AI in your workflow if you have not done that. Start thinking and start planning for it... You can use AI to lessen and lessen the burden of vulnerabilities on our stakeholders."

Practical applications include:

Intelligent Prioritization: AI can analyze vulnerability data alongside threat intelligence, asset criticality, and exploitability to surface the most critical risks. "It needs a lot of planning. You can't just use public models and start giving vulnerability data to it... In a more contained environment, how can you take the model, feed the data it needs to, and then see what outcomes you can get from the model to help prioritize even farther than you are prioritizing today."

Operational Efficiency: "Your analyst hours can be saved if you just give them the magic of AI," Sapna explains. Instead of spending time on coordination and manual data collection, analysts can focus on vulnerability research and quality assessment. "All those traditional workflows can just die. The data would be on the plate for you to investigate and quality assess."

Persona-Based Assistants: Sapna describes implementing AI bots tailored to specific user roles: "Think about the personas that you deal with in your day-to-day life. Put yourself in those shoes. Write a prompt that if I am a system engineer and I need to patch through these servers in this weekend cycle, what should I focus on?"

The key is providing these AI assistants with appropriate context:

• Current vulnerability data and compensating controls

• Asset criticality and business impact

• Patch schedules and maintenance windows

• Historical patching success rates

The Build vs. Buy Decision for AI Security Tools

Organizations face the critical decision of whether to build custom AI security capabilities or purchase commercial tools. Sapna's guidance emphasizes starting with available resources:

Cloud Provider Platforms: "Every company is using a cloud provider... Every cloud provider has an AI platform. You have access to their own platform. You can just go to your cloud service provider platform, start using AWS Bedrock, Azure OpenAI Foundry... start writing prompts of what would help me in my job."

Vendor Tool AI Features: "Plug AI into your existing workflow systems like ServiceNow or Jira they have their own AIs as well. Each tool has their own AI, and these companies are doing a great job in giving that functionality to users."

Gradual Adoption: "Start with one video and just make a note that you have to see one video every week on AI," Sapna advises. "Start with a basic prompt first. This will improve over time. Once you put it in their hands, your users, you will be amazed to see how they can build such great prompts."

The message: don't let perfect be the enemy of good. Start experimenting with AI tools using low-stakes use cases, learn from the results, and gradually expand to more critical applications.

Compliance and Innovation: Complementary, Not Contradictory

Sapna challenges the common perception that compliance and security slow innovation, particularly with AI. "Compliance and innovation go hand in hand. They complement each other. Compliance allows you to put guardrails in your AI. If compliance is not there, if risk and assessment is not there, AI can become rogue."

The key is framing security as an enabler:

Guardrails Enable Speed: By establishing clear security boundaries, organizations can move faster with AI deployments because they've pre-approved certain architectures and controls. Teams don't need to reinvent security for each new AI project.

Shift-Left Principle: "You have to shift left. You can't think compliance or security is an afterthought. From the moment you have started your pipeline, from the moment the data comes into your organization, it has to be within certain guardrails."

Practical implementation:

• Access controls on training data with full audit trails

• Version control from day one of model development

• Integrity testing and bias detection in data pipelines

• Security gates at each stage of the ML pipeline

"That mindset needs to be there to see them as enablers, not blockers," Sapna emphasizes. "And I think that is also relevant to other innovations, not just AI."

Future Skills: What Vulnerability Management Teams Need

Looking ahead, Sapna outlines the evolving skill requirements for vulnerability management professionals: "You just have to have …to learn AI…”

RELATED RESOURCES 🎧

Cloud Security Podcast

• Cloud Security Podcast – Full Episode with Sapna Paul

Related Podcast Episodes 🎧

AI Vulnerability Management: Why You Can't Patch a Neural Network

Question for you? (Reply to this email)

 🤖 Should AI agents be treated as “identities” with least privilege and audit trails or as tools your org implicitly trusts?

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!

Shilpi Bhattacharjee

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

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter topic: Your Backup Strategy Is Incomplete Without Identity Recovery (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

This week brings sobering reminders that cyber resilience isn't just about having backups it's about having the ability to recover when everything you trust becomes compromised. From a CVSS 10.0 React vulnerability under active nation-state exploitation to AI coding assistants becoming supply chain attack vectors, the attack surface continues expanding in ways traditional disaster recovery plans never anticipated.

In this edition, we explore why identity systems have become "ground zero" for cyber resilience with Matt Castriotta, Field CTO for Cloud at Rubrik. Matt brings seven years of shepherding cloud security at Rubrik and over two decades in data management, offering hard-won insights on why having backups doesn't mean you can recover, and why your Active Directory might be your most critical unprotected asset. [Listen to the episode]

📰 TL;DR for Busy Readers

• 💻 IDEsaster: 24 CVEs across Cursor, Windsurf, GitHub Copilot, Zed, Roo Code, and Junie - 100% of tested AI IDEs vulnerable to prompt injection, enabling RCE and data exfiltration from developer machines

• 🔐 Identity is ground zero: Forest-level Active Directory recovery must be part of every cyber resilience plan

• 🤖 AI supply chain attacks: PromptPwnd + IDEsaster show AI coding assistants acting as high-privilege non-human identities

• 💰 ServiceNow-Armis ($7B): Consolidation signals asset visibility and CMDB accuracy are now resilience prerequisites.

📰 THIS WEEK'S TOP 3 SECURITY HEADLINES

1. IDEsaster: 30+ Vulnerabilities in AI IDEs

A comprehensive security analysis has uncovered 24 CVE-assigned vulnerabilities across popular AI-enhanced IDEs including Cursor, Windsurf, GitHub Copilot, Zed, Roo Code, and Junie. The research found that 100% of tested AI IDEs are vulnerable to prompt injection attacks that, when combined with legacy IDE features, enable remote code execution and data exfiltration. The vulnerabilities affect developer workstations directly, potentially compromising source code and credentials stored in local development environments.

Why This Matters: Developer workstations have become high-value targets, and AI IDE vulnerabilities provide attackers with direct access to intellectual property and credentials. This complements the PromptPwnd findings and underscores a broader theme: AI integration is outpacing security controls. For security leaders, this means extending zero-trust principles to developer tools and ensuring that credential management doesn't rely on the security of local development environments. Recovery plans must account for scenarios where developer machines and associated credentials are compromised.

Sources: Independent Security Researcher MaccariTA, The Hacker News

2. ServiceNow in Talks to Acquire Armis for $7 Billion

ServiceNow is negotiating to acquire cyber asset management platform Armis for approximately $7 billion, marking what would be the company's largest M&A deal to date. Armis specializes in providing visibility into operational technology (OT), Internet of Things (IoT), and unmanaged assets critical blind spots for enterprise security teams.

Why This Matters: This acquisition signals major consolidation in the enterprise asset management space and highlights the convergence of CMDB (Configuration Management Database) capabilities with cybersecurity. For cloud security leaders, this underscores the growing importance of comprehensive asset inventory something Matt Castriotta emphasizes as foundational to cyber resilience: "You'd be amazed at how many customers I talk to that don't have a CMDB and are not inventorying exactly what they have. Shadow IT is still a thing." The deal also reflects increasing focus on critical infrastructure protection, particularly OT/IoT environments that traditional security tools struggle to cover.

Source: Industrial Cyber

3. PromptPwnd: AI Coding Assistant Supply Chain Attacks

Security researchers have disclosed a new vulnerability class affecting AI coding assistants in CI/CD pipelines, dubbed "PromptPwnd." The attack vector uses prompt injection in GitHub Actions and GitLab CI/CD workflows to exploit AI agents like Gemini CLI, Claude Code, and OpenAI Codex. Successful exploitation enables secret exfiltration, remote code execution, and GitHub token theft. At least five Fortune 500 companies have been confirmed as impacted. Google patched Gemini CLI within four days of disclosure.

Why This Matters: This represents an entirely new attack surface that traditional security controls weren't designed to address. As organizations rush to adopt AI coding assistants for productivity gains, they're introducing non-human identities with broad access to code repositories and secrets. Castriotta's warning about AI agents resonates here: "If we're gonna use AI to increase productivity, we're gonna need to remove the human in the loop... You need the ability to understand what that agent did, and if that agent did something erroneous, you need the ability to be able to rewind that back." Organizations need visibility into AI agent activity and the capability to recover from erroneous or malicious actions.

Sources: Aikido Security, SecurityWeek, The Hacker News

🎯 Cloud Security Topic of the Week:

Identity as Ground Zero: Why Your Backup Strategy is Incomplete Without Identity Recovery

The conversation around cyber resilience has evolved beyond "do you have backups?" to a more critical question: Can you actually recover when your identity systems are compromised? Most organizations treat identity as a security control to protect, but few treat it as a data source that requires the same backup and recovery rigor as their databases and applications.

This oversight creates a dangerous gap. As Matt Castriotta explains: "If identity's down, everything's down. You have no ability to access anything. Your identity system is ground zero. It's the perimeter".

Featured Experts This Week 🎤

• Matt Castriotta, Field CTO for Cloud, Rubrik

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

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

• Cyber Resilience vs. Disaster Recovery: Cyber resilience is the ability to recover when data and identity systems are inherently mistrusted due to attacker compromise. Disaster recovery assumes data and identity remain in a "trusted zone" and focuses on business continuity during outages.

• Operational Recovery: Restoration from accidental changes or errors where systems remain in a trusted state requires rewinding to a known good point in time.

• Forest-Level Recovery: In Active Directory environments, the process of recovering an entire domain forest structure, typically required when attackers have compromised the root domain or made extensive changes to the directory structure.

• Minimum Viable Company (MVC): The critical subset of systems and data required to maintain essential business operations during a major cyber incident the foundation of effective cyber recovery planning.

• Survivable Backups: Backup copies that are immutable, air-gapped, or otherwise protected from tampering by attackers who have gained privileged access to production environments.

This week's issue is sponsored by AI Security Podcast 

In-depth practitioner discussions on Enterprise AI risk, governance, and security with guests including AI Bug Bounty Hunters, CISOs from Foundational Models & more.

💡Our Insights from this Practitioner 🔍

Why Backups Aren't Enough & Identity Recovery is Key against Ransomware (Full Episode here)

The Fatal Flaw in Modern Backup Strategies

When organizations say "we have backups", they're often conflating business continuity with cyber resilience. This distinction matters enormously when an attacker is inside your environment.

Matt Castriotta draws a stark line: "Having backup doesn't mean anything. Do you have the ability to recover? That's the key. You always have to think about it as: I don't have a backup, I have an insurance policy. I have a recovery plan. I have the ability to get my business back".

The challenge with traditional disaster recovery is that it assumes your data and identity remain trusted. But modern attackers operate as authenticated users within your environment. Once they're in, everything becomes suspect. Castriotta explains: "Once the cyber attacker gets into the environment, most likely by acting as an authorized and authenticated user on your network, at that point your data and your identity are inherently mistrusted. Now I have to figure out what did they impact and how do I get back to a good clean point".

This is why cloud-native continuity features like S3 versioning and cross-region replication create false confidence. Castriotta cautions: "Just because you replicate your data, if your data's impacted in your primary region, the replication is replicating that impact to the secondary region. Your secondary regions are now impacted too".

Practical Application: Audit your current backup strategy by asking three questions:

1. Can you identify which backup copy is "clean" if your production systems are compromised?

2. Do your backups exist outside the administrative domain of your production environment?

3. Have you tested recovery scenarios where both production data AND identity systems are assumed compromised?

If you answered "no" to any of these, you have continuity but not resilience.

Identity: The New Perimeter That No One Is Backing Up

The most striking insight from Castriotta's experience is how few organizations treat identity as a recoverable data source. "A lot of times conversations around cybersecurity resilience are framed around backup recovery, but not really around identity", he notes.

This oversight is particularly dangerous because identity systems enable everything else. As Castriotta puts it: "Identity is the new perimeter. If identity's down, everything's down. You have no ability to access anything. Your identity system is ground zero".

Attackers understand this better than defenders. They infiltrate environments through compromised identities, escalate privileges through misconfigured IAM roles, and move laterally across accounts and regions. The identity layer is both their entry point and their highway through your environment.

Yet when organizations plan cyber recovery, identity is often an afterthought. Castriotta observes: "There are businesses that were built solely on just protecting identity systems Active Directory backup solutions. So yes, absolutely, your identity system needs protection not only from an operational error... but also from the fact that an attacker could make many modifications to your identity system to facilitate their lateral movement".

Practical Application: Evaluate your identity recovery posture:

For On-Premises Environments:

• Do you have the ability to perform forest-level Active Directory recovery?

• Can you recover domain controllers to known-good states within your RTO?

• Are your AD backups stored outside the domain they're backing up?

For Cloud Environments:

• Are you backing up IAM policies, roles, and trust relationships?

• Can you detect and revert unauthorized privilege escalations?

• Do you have offline copies of service principal credentials?

For Hybrid Environments:

• Can you recover Entra ID (Azure AD) configurations independently of on-premises AD?

• Are conditional access policies backed up and version-controlled?

• Can you rebuild federation trusts if both sides are compromised?

Castriotta emphasizes that identity recovery must come first: "Your identity system is ground zero. You need the ability to bring that back first before you bring back anything else".

The Assumed Breach Mindset: Gaming Out Total Compromise

Organizations that succeed in cyber resilience share a common trait: they've adopted an "assumed breach" mindset and actually practiced large-scale recovery.

Castriotta explains the difference: "The organizations that really succeed are the ones that have already gone beyond [perimeter security]. They've adopted this assumed breach mindset and they've gamed out the process of what a large-scale cyber recovery would look like".

This isn't a theoretical exercise. "When I say game it out, I mean they've done tabletop exercises with their security organization, with security teams that they partner with. IT and security are in lockstep with each other, and security has a vested interest in recovery—which security doesn't always have a vested interest in recovery in organizations".

The concept of "Minimum Viable Company" becomes critical here. Organizations need to identify: "What comprises my minimum viable company and what would it take for me to bring that back if assuming everything was impacted."

This requires brutal honesty about dependencies. Castriotta notes the first step: "The ability to know the assets that you have and the RTO expectations for each of the applications you're running in your environment. You'd be amazed at how many customers I talk to that don't have a CMDB and are not inventorying exactly what they have. Shadow IT is still a thing. Untracked buckets are still a thing".

Practical Application: Conduct a Minimum Viable Company exercise:

1. Define Core Business Functions: What are the 3-5 capabilities required to keep your business operating at minimal viability? (For many organizations: customer-facing services, payment processing, internal communications, identity/access systems)
   

2. Map Technical Dependencies: For each core function, document:
   

   • Primary applications and their data sources

   • Identity/authentication requirements

   • Network/connectivity dependencies

   • Third-party service dependencies

   • Regulatory/compliance considerations

Establish Recovery Priorities: Assign tiers to applications:

1. Tier 0: Identity systems and core infrastructure

2. Tier 1: Revenue-generating applications (bring back within hours)

3. Tier 2: Business-critical applications (bring back within days)

4. Tier 3-4: Important but non-critical applications

1. Test the Recovery Runbook: Execute tabletop exercises where IT and security jointly practice recovery scenarios. Key question: "If we assume our production environment and identity systems are fully compromised, how do we rebuild from backups while ensuring we're not restoring malicious changes?"
   

2. Organizations that skip this planning discover painful truths during actual incidents—when time pressure and stress make clear thinking nearly impossible. 

The AI Agent Challenge: Recovery in the Age of Autonomous Actions

The emergence of AI agents introduces a new dimension to cyber resilience that traditional backup strategies never contemplated. As Castriotta observes: "AI has really opened people's eyes to the fact that the data is the gold. That is your crown jewels. And then access to it and how you facilitate that access."

The challenge intensifies when AI agents act autonomously. "We're gonna need to remove the human in the loop. The human in the loop right now is what's getting in the way", Castriotta explains. "When that does decrease and there's less humans in the loop, you need the ability to understand what that agent did, and if that agent did something erroneous, you need the ability to be able to rewind that back".

This creates unprecedented visibility and recovery requirements. Unlike human operators whose actions can be logged and audited through established patterns, AI agents may make thousands of decisions per hour across multiple systems. The PromptPwnd and IDEsaster vulnerabilities this week demonstrate how AI agents can be manipulated to exfiltrate secrets and execute code essentially becoming insider threats that operate at machine speed.

Castriotta emphasizes that organizations are creating "overly permissive non-human identities... because AI needs access to all the data". These privileged service accounts become attractive targets and potential blast radius amplifiers.

Practical Application: Implement AI agent oversight and recovery capabilities:

Visibility and Auditability:

• Deploy comprehensive logging for all AI agent actions, not just successful operations

• Track which data sources agents access and what changes they make

• Monitor for unusual patterns in agent behavior (e.g., accessing data outside normal scope)

• Maintain chain-of-custody logs showing which prompts led to which actions

Access Controls:

• Apply least-privilege principles to AI agent service accounts

• Use time-limited credentials where possible (rotate frequently)

• Implement approval workflows for high-risk agent operations

• Segment agent access by function don't give one agent access to everything

Recovery Mechanisms:

• Ensure you can identify "pre-agent" backup snapshots for critical systems

• Test recovery scenarios where you need to revert agent-made changes

• Document the process for disabling compromised agents and revoking their access

• Maintain offline copies of configurations that agents might modify

Rubrik's upcoming Agent Cloud platform addresses this gap by providing visibility into agent operations and the ability to rewind changes recognizing that AI agents represent both productivity opportunities and new threat vectors that require specific resilience strategies.

Multi-Cloud Recovery: Beyond Checkbox Compliance

The DORA regulations in the European Union are forcing financial services organizations to confront multi-cloud recovery realities. But as Castriotta notes, many are approaching this as compliance theater rather than genuine resilience.

"Right now what I'm seeing is that a lot of folks are treating DORA as sort of a checkbox. I'm just gonna make sure that I copy my backups to Azure. I'm not gonna make sure they're in a format that Azure can even understand, nor am I even gonna ever test a recovery back into something in Azure".

This approach fails on multiple levels. First, egress costs make cross-cloud data movement expensive at scale. Second, and more critically, AWS and Azure are fundamentally different: "VMs that are spun up in AWS look nothing like VMs spun up in Azure. How do you do that conversion and do it on the fly in a way where I can build my application on the other side cleanly?"

The recent AWS outages underscore why this matters. When the East-1 region went down, it took Amazon an entire day to restore capacity. As Castriotta points out: "Even the hyperscalers struggle with the complexity of what they've built. If even the hyperscalers struggle with that, our customers are struggling with the complexity of what they've built too. They need a recovery plan that can get them back quickly."

Practical Application: Build genuine multi-cloud resilience:

Assessment Phase:

1. Identify applications where multi-cloud recovery provides genuine value (typically: tier-0/tier-1 applications, regulatory requirements, geopolitical risk concerns)

2. Calculate the total cost of true multi-cloud recovery (egress, storage, conversion tools, testing)

3. Determine if the investment justifies the risk mitigation

Implementation Phase:

1. Test recovery to alternate clouds quarterly, not just backing up to them

2. Maintain runbooks for the conversion process (don't assume hyperscaler migration tools will work during an incident)

3. Pre-position networking, identity, and security configurations in the alternate cloud

4. Ensure your team has actual hands-on experience with both platforms

Reality Check: For most organizations, multi-cloud recovery for all workloads isn't economically viable. Focus on:

• Critical applications that justify the investment

• Data archives that can be stored cost-effectively across clouds

• Disaster recovery scenarios where you accept longer RTOs for alternate-cloud recovery

The key insight: multi-cloud backup is easy; multi-cloud recovery is hard. Don't confuse the two.

RELATED RESOURCES 🎧

Cyber Resilience and Identity Protection:

• NIST Cybersecurity Framework 2.0 - Recover Function - Updated framework with enhanced recovery guidance

• Microsoft Active Directory Forest Recovery Guide - Technical runbooks for AD recovery

• CISA Cyber Resilience Guide - Guidance for critical infrastructure

Incident Response and Recovery:

• SANS Incident Handler's Handbook - Practical incident response guidance

• AWS Disaster Recovery Whitepaper - Cloud-specific DR strategies

• Rubrik Cyber Recovery Guide - Practical framework for cyber resilience

Cloud Security Podcast

• Cloud Security Podcast – Full Episode with Matthew

• For deeper discussion on failed data lakes, AI in detection engineering, and where SIEM still fits.

Related Podcast Episodes 🎧

How to secure your AI Agents: A CISOs Journey

Question for you? (Reply to this email)

 🤖 Should companies work on a AI Backup Plan?

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!

Shilpi Bhattacharjee

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

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter Topic we cover - How to secure your AI Agents: A CISOs Journey (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

As enterprises race to integrate AI agents into production environments, we're witnessing a collision of traditional application security challenges with entirely new threat vectors. This week brings critical lessons from the frontlines: a React vulnerability exploited within hours of disclosure, infrastructure providers scrambling to protect customers, and practical guidance from organizations that have successfully navigated the transition from API-driven platforms to AI-first architectures.

I'm joined this week by Yash Kosaraju, Chief Security Officer at Sendbird, who brings a unique perspective on securing AI agents at scale. Sendbird transformed from a mature chat API platform into an AI agent company practically overnight a microcosm of the transformation many enterprises are experiencing right now. Yash shares candid insights on building security programs that balance innovation velocity with enterprise-grade protection, from embedding security engineers in AI development teams to redefining what constitutes a "security incident" when AI agents make suboptimal decisions. [Listen to the episode]

📰 TL;DR for Busy Readers

• React2Shell (CVE-2025-55182): Critical 10.0 CVSS RCE in React Server Components exploited by Chinese APT groups within hours so patch immediately

• Zero Trust ≠ Multi-Layered Trust: Yash explains why “controls fail” must be your foundational assumption.

• AI Incidents ≠ Breaches: Wrong answers, poor decisions, and unexpected agent actions need new IR playbooks.

• LLM Contracts Matter: Scrutinize training exclusions, data deletion clauses, and derivative model usage.

• Culture > Tools: Security embedded in AI teams reduces Shadow AI and accelerates safe experimentation.

📰 THIS WEEK'S TOP 3 SECURITY HEADLINES

1. React2Shell: Critical Unauthenticated RCE Demands Immediate Action

A perfect 10.0 CVSS RCE in React Server Components is now under active exploitation by Earth Lamia and Jackpot Panda. Added to CISA KEV within 48 hours.

Action: Patch immediately. Inventory where React Server Components appear across your cloud estate.

Why it matters: Time-to-exploit is compressing. Automated detection + patch orchestration must be in place before disclosure hits.

Source: NVD, AWS Security Blog

2. Cloudflare Outage Tied to React2Shell Emergency Response

A 25-minute Cloudflare outage occurred during emergency firewall rule deployment.

Why it matters: Even security fixes can cause availability impact.

Action: Ask vendors for emergency mitigation SLAs and rollback procedures.

Source: The Cloudflare Blog, Reuters

3. Saviynt Raises $700M, Signaling Identity Consolidation Trend

Identity is the new perimeter, and boards are funding accordingly.

Action: Reevaluate identity governance maturity and JIT access controls.

Source: Wall Street Journal

🎯 Cloud Security Topic of the Week:

Building Multi-Layered Trust for AI Agents (with Sendbird
CISO - Yash Kosaraju)

The transition from traditional applications to AI-powered systems isn't just a technology shift it's a fundamental reimagining of security architecture, incident response, and organizational culture. This week's conversation with Yash Kosaraju reveals how Sendbird navigated this transformation while maintaining enterprise-grade security for customers deploying AI agents that take autonomous actions in production environments.

Featured Experts This Week 🎤

• Yashvier Kosaraju, Chief Security Officer at Sendbird

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

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

• AI Agent: An autonomous system that uses large language models (LLMs) to understand context, make decisions, and execute actions without constant human oversight. Unlike traditional chatbots that respond to queries, AI agents can modify backend systems, process transactions, and orchestrate complex workflows.

• Multi-Layered Security/Trust: A defense-in-depth approach assuming that individual security controls will eventually fail. Rather than relying on a single "zero trust" perimeter, organizations implement overlapping controls across device trust, identity verification, network access, application authorization, and data protection.

• RAG (Retrieval-Augmented Generation): A technique where AI models query external knowledge bases before generating responses, improving accuracy and reducing hallucinations by grounding outputs in verified information.

• Context Injection/Prompt Injection: Attack techniques where adversaries manipulate AI system inputs to override security constraints, extract sensitive data, or cause unintended actions. Similar to SQL injection but exploiting LLM processing logic rather than database queries.

This week's issue is sponsored by Drata

Security teams shouldn’t be buried in manual evidence collection. 

Drata automates compliance end-to-end while providing unified visibility across cloud workloads, identities, and configurations. 

Teams use Drata to cut audit prep from weeks to hours, accelerate security reviews, and reinforce DevSecOps pipelines with real-time controls monitoring. 

If you're scaling cloud infrastructure and need a smarter path to continuous compliance, Drata is built for you.

Book Demo with Drata

💡Our Insights from this Practitioner 🔍

How to secure your AI Agents: A CISOs Journey (Full Episode here)

The Reality Check: AI Security Isn't Just Application Security 2.0

When Sendbird pivoted from a mature chat API platform to an AI agent company, the security team faced a challenge that extends far beyond securing APIs and databases. "You go from fine, we are building an application, go test for OWASP Top 10, go test for XSS, SQL injection," Yash explains. "That changes to a lot of different things. The attack paths are different. The types of security issues are different. The data security models are different."

This transformation mirrors what many enterprises are experiencing as they integrate AI capabilities. The comfortable world of known vulnerabilities and established testing frameworks gives way to questions about LLM hallucinations, context injection attacks, and data leakage through training corpora. Traditional AppSec engineers suddenly find themselves securing systems they don't fully understand a humbling experience that Yash addresses directly with his team.

The Hidden Stress on Security Teams: One of the most candid moments in our conversation came when Yash shared how a senior engineer approached him: "We are building this new AI stuff. We have to review and secure it. I don't know if I can do a good enough job with this." This vulnerability reflects a broader industry challenge that isn't discussed enough the expectation that experienced security professionals should instantly become AI security experts simply because AI is built on software.

Yash's response reveals his leadership philosophy: "Let's acknowledge it's new technology. We will make mistakes. It's okay to do that. We'll eventually catch up to it. A staff AppSec or principal engineer is not automatically a staff AI security engineer." This psychological safety creates space for teams to learn, experiment, and build expertise without the paralysis that comes from fear of failure.

Multi-Layered Trust: Beyond Zero Trust Marketing

When I asked Yash about his approach to zero trust, his response cut through the industry hype: "A true multi-layered approach doesn't use flashy marketing terms and call it zero trust. It's plain multi-layers of security."

The distinction matters. Zero trust has become such an overloaded term that it risks meaning nothing a checkbox on a compliance form rather than a meaningful security architecture. Yash's multi-layered trust framework at Sendbird is more pragmatic: assume every control will eventually fail, and design your architecture accordingly.

The Login Flow That Actually Works: Yash walks through Sendbird's employee authentication flow as a concrete example. When an engineer attempts to access GitHub, the system verifies:

1. The request originates from a company-issued device

2. The Chrome browser is enrolled in Google Enterprise

3. Okta performs device health checks via CrowdStrike integration

4. Multi-factor authentication using FIDO2/WebAuthn (YubiKey, fingerprint, or Okta Verify)

5. Password verification for users accessing sensitive systems in certain jurisdictions

"There are four or five layers that happen in the background that you as a user wouldn't even realize," Yash notes. This seamless security creates minimal friction while maintaining defense in depth if one control fails, four others remain.

For cloud security architects, this approach offers a template for designing authentication flows that don't rely on a single trust decision. The key insight is that AWS IAM, GitHub Enterprise, and Azure Active Directory aren't "secure by default" they're powerful platforms with security features that must be deliberately configured and layered.

The Data Question That Changes Everything

The most significant blind spot Yash identified in early AI adoption wasn't technical, it was contractual. "The major blind spot was the notion of 'yes, we're using GitHub Copilot. It's an enterprise tool backed by Microsoft, so it's secure. It's okay to use,'" he explains. "But as you look at it, the different terms of service for a beta model that Copilot has released versus a GA model it's important that you look at those, look at the nuances."

This observation should alarm enterprise security leaders. Many organizations are deploying "enterprise AI" tools without understanding fundamental questions:

• Is the vendor using customer data to train their base LLM?

• What contracts exist between your AI vendor and their LLM provider?

• How is customer data handled during the training lifecycle?

• What happens to your data when you terminate the contract?

The 360 Lifecycle of AI Data: Yash emphasizes that data governance in AI systems requires thinking through the complete lifecycle: "If and when I decide to terminate my contract, how do you delete my data? If it has been used in some LLM training context, even if that's just for my account or app that you use for training how does that work?"

These questions extend beyond traditional data processing agreements. LLM training creates derivative works that may contain fragments of your data in model weights. Simple deletion of source data may not remove its influence from the model. Enterprises need contractual guarantees about data isolation, training exclusions, and verifiable deletion requirements that many "enterprise" AI offerings don't yet provide.

Redefining Incidents When AI Makes Mistakes

Perhaps the most thought-provoking insight from our conversation concerns incident response. "The definition of what is an incident is also changing," Yash observes. "When an AI agent gives a wrong answer or a suboptimal answer, how do you classify that? It is an incident of some sort. It's not a breach. This is new."

Consider the implications: An AI customer service agent grants an unauthorized refund. A coding copilot introduces a subtle vulnerability that passes code review. An AI-powered analytics tool misinterprets data and influences a business decision. None of these are traditional security incidents, yet all represent failures with real impact.

The IR Team's New Challenge: Yash describes the complexity facing incident responders: "You add this other element where a call is going into a customer's environment, and then the origination of the incident either could be in our environment or somewhere in a customer's environment with a dotted line between the two. Figuring out how that works when you're in the middle of an incident, these unknowns, even though they may be small, cause big roadblocks."

Traditional incident response playbooks assume clear boundaries: our network, our applications, our data. AI agents that take actions across organizational boundaries blur these lines. When a Sendbird AI agent makes an API call to a customer's backend system and something goes wrong, who owns the investigation? Who has access to the necessary logs? What SLAs apply?

Sendbird's approach involves close collaboration between their incident response team and product teams to build new detection capabilities and response procedures. They're defining metrics for "AI incidents" that sit somewhere between operational errors and security breaches a new category that the industry hasn't yet standardized.

The Enterprise AI Toolkit Strategy

Rather than trying to prevent AI adoption through restrictions, Sendbird provides employees with enterprise-grade AI tools: Google Gemini, ChatGPT Teams (not Enterprise. Yash is deliberate about cost-benefit tradeoffs), Claude, Cursor, and GitHub Copilot. This strategy acknowledges that employees will use AI regardless of policy the question is whether they'll use sanctioned, contractually protected tools or shadow IT solutions.

"If you don't enable them by providing AI tools, they are going to find tools either pay out of pocket or use free versions to get the job done," Yash notes. The alternative to approved tools isn't no AI usage; it's unmonitored AI usage with unknown data handling practices.

The Communication Layer: Providing tools isn't enough. Sendbird accompanies their AI toolkit with clear communication about what's approved, what's blocked, and why. "We send out communications like 'here's why we are blocking it. Here's a reminder, these are the approved AI tools. If you want to try something out, be careful. Do not put real enterprise data.'"

This approach balances enablement with responsibility. Employees understand they can experiment with new AI tools, but they're expected to make risk-conscious decisions about data handling. When organizations treat employees as partners in security rather than potential threats, they typically get better outcomes than pure lockdown approaches.

Trust OS: Making AI Agent Actions Observable

Sendbird's Trust OS represents their answer to a fundamental challenge: how do you give customers confidence in AI agents that take autonomous actions? The platform provides observability into agent decisions, human oversight capabilities, and automated testing frameworks that let customers verify agent behavior before granting expanded permissions.

"It's assuring our customers of 'yes, there's an unknown AI that's performing actions, but here are all the ways you have oversight'" Yash explains. Customers can see conversations, review actions taken, configure permitted operations, and build test cases that alert when agent behavior changes.

This architecture acknowledges that trust in AI systems comes from transparency and control, not from claims about model accuracy. Enterprises deploying AI agents need to know: What is this agent doing? Can I review its decisions? Can I limit its capabilities? What happens when it makes a mistake?

The Testing Paradigm: One of Trust OS's key features is enabling customers to build automated test cases for agent behavior. If an agent should never discuss certain topics, never access particular data types, or always escalate specific request categories, customers can codify these rules and receive alerts when they're violated. This shifts AI governance from reactive incident response to proactive behavior monitoring.

The Skills Gap Nobody Talks About

Throughout our conversation, Yash returned to a theme that deserves more attention: the stress on security professionals expected to secure AI systems without adequate preparation. "A staff engineer, staff AppSec or principal engineer is not automatically a staff AI security engineer," he emphasizes. "It does put a decent amount of stress on AppSec engineers where companies are moving really fast on AI and they're expected to help secure them."

This gap extends beyond technical skills. Understanding LLM behavior, prompt injection attacks, and RAG implementations requires different mental models than traditional application security. The attack surface isn't just code anymore it's the interaction between code, models, prompts, context windows, and external data sources.

Yash's Advice to Overwhelmed Security Teams: "Let's acknowledge it's new technology. We will make mistakes. It's okay to do that. We'll eventually catch up to it. When SQL injections and XSS came out in the very early days, those were big deals and nobody knew exactly how they worked. Today we are much ahead of that game. We will eventually get to something similar on the AI front."

This perspective offers psychological relief to security teams feeling overwhelmed. The goal isn't perfect security from day one it's building capabilities iteratively while maintaining awareness of risks. Organizations that give security teams space to learn, experiment, and occasionally fail will develop more robust AI security programs than those that demand immediate expertise.

Learning AI with AI

One of the most practical insights Yash shared was almost throwaway: "You can use AI to learn AI." When new concepts emerge RAG, context windows, fine-tuning, mixture of experts security professionals don't need to wait for training courses or documentation. They can ask Claude, ChatGPT, or Gemini to explain concepts, provide examples, and answer follow-up questions.

Yash takes this further: "There's this Gemini app where you could have conversations with it. So I go on walks and I'm like, 'explain this to me.' It's a conversation with AI on anything and everything, and that could be how AI works."

For busy security leaders trying to stay current, this approach is remarkably efficient. Rather than blocking out hours to read documentation, you can integrate learning into your daily routine through conversational AI interfaces. The key is approaching these tools as learning aids rather than definitive sources verify important details, but use AI to accelerate your baseline understanding.

RELATED RESOURCES

AI Security & LLM Guidance

• OWASP Top 10 for LLM Applications - Comprehensive framework for AI application security

• NIST AI Risk Management Framework - Federal guidance on managing AI risks

• Anthropic: Claude's Constitutional AI - Understanding AI safety through design

Multi-Layered Security Architecture

• Google BeyondCorp: A New Approach to Enterprise Security - Foundational zero trust architecture principles

• AWS Security Best Practices for IAM - Multi-layered access control implementation

Incident Response for Modern Environments:

• SANS Cloud Incident Response Framework - Adapting IR for cloud and AI systems

• Atlassian Incident Management Handbook - Modern incident response processes

Cloud Security Podcast

• Cloud Security Podcast – Full Episode with Yashvier

• For deeper discussion on failed data lakes, AI in detection engineering, and where SIEM still fits.

Related Podcast Episodes 🎧

How to secure your AI Agents: A CISOs Journey

Question for you? (Reply to this email)

 🤖 Is there an AI Incident that is not a breach?

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!

Shilpi Bhattacharjee

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

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter Topic we cover - From SIEM to Data Lake: Why Security Teams Are Making the Shift (And What It Actually Takes) (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

As identity security takes center stage with ServiceNow's billion-dollar acquisition of Veza and AI security vulnerabilities proliferate across enterprise environments, security teams face a critical inflection point: how do we scale visibility without breaking the bank?

This week, we're joined by Cliff Crosford, co-founder of Scanner.dev and veteran of multiple security startups including an acquisition into Cisco. Cliff shares hard-won lessons from building security data lakes at massive scale including what works, what fails spectacularly, and why most teams underestimate the engineering lift required to make data lakes actually usable for security operations. [Listen to the episode]

📰 TL;DR for Busy Readers

• ServiceNow's $1B* Veza acquisition signals identity + ITSM consolidation- Identity is consolidating fast with ServiceNow’s Veza move, it is a clear play to own “who has access to what” across cloud and SaaS; revisit your IAM/CIEM roadmap now.

• Claude AI "Skills" plugins shown deploying ransomware  AI plug-ins are the new PowerShell – Claude Skills and shadow AI in the browser demand Tier 0 governance and an allowlist model, not “free install for everyone.” treat AI tools as Tier 0 code execution environments.

• Oracle EBS zero-day hits 100+ orgs including Penn & Phoenix Universities confirm patch status and SSO integration points immediately

• AWS and Google Announce Joint Multi-cloud Networking Service- Multicloud networking is getting easier and riskier. AWS + Google’s joint fabric is great for latency and terrible for flat, poorly governed architectures.

• Data lakes promise SIEM cost savings but require serious engineering budget for schema maintenance, not just storage

• AI can accelerate detection tuning 80% but humans remain essential implement human-in-the-loop review for all AI-generated detections

📰 THIS WEEK'S TOP 5 SECURITY HEADLINES

1. ServiceNow Moves to Acquire Veza in ~$1B Identity Security Deal

What Happened

ServiceNow announced a definitive agreement to acquire identity security company Veza in a deal reportedly valued at around $1 billion, according to SecurityWeek's M&A tracker. Veza specializes in authorization and access intelligence across modern infrastructure and SaaS, mapping "who has access to what" across cloud providers, data platforms, and business applications.

Why It Matters

Identity is the new control plane in cloud-native environments. Veza's entitlement graph across AWS, Azure, GCP, SaaS, and data stores represents exactly the visibility layer many organizations are attempting to build themselves. This acquisition signals further consolidation of identity, ITSM, and security operations into single platforms a trend that creates both opportunities and risks.

As Cliff Crosford notes from his experience building security infrastructure at scale: "Log volumes just get massive and then it becomes impossible to keep all of the logs that you want in your SIEM. Traditional SIEMs were wonderful in the era when you had maybe individual gigabytes or tens of gigabytes of logs per day." ServiceNow's move to acquire Veza positions them to become the central control plane not just for workflow, but for identity telemetry at enterprise scale.

For large enterprises, the strategic implications are significant: tighter vendor integration enables faster response automation, but it also creates a higher blast radius when identity metadata and agentic controls live inside a single vendor platform. Organizations already using ServiceNow for ITSM should immediately map where identity artifacts flow today and prepare for integration changes.

Actionable Steps:

• Inventory your current IAM/CIEM/DSPM/IGA stack and note overlaps with Veza's capabilities

• If you're a ServiceNow customer, ask reps about roadmap timelines, data residency, and API access

• Track this as a signal that "identity + operations + security" convergence is accelerating

• Update procurement risk registers to evaluate lock-in and data residency implications

Source: SecurityWeek M&A Tracker

2. Oracle E-Business Suite Zero-Day Campaign Widens – Penn & Phoenix Universities Confirm Breaches

What Happened

The University of Pennsylvania and University of Phoenix disclosed they're victims of the ongoing Oracle E-Business Suite (EBS) hacking campaign, which has already impacted more than 100 organizations. Attackers compromised EBS instances used for supplier payments, general ledger, and other core business processes, exposing PII, dates of birth, Social Security numbers, and banking details. The campaign is linked to Cl0p ransomware activity, with FIN11 suspected behind the intrusion chain, and appears to leverage unknown zero-day vulnerabilities in Oracle EBS that remain publicly undisclosed.

Why It Matters

ERP systems like Oracle EBS sit at the heart of finance, procurement, payroll, and student information and are increasingly hosted in cloud and hybrid environments. A compromise here is not just a "data breach"; it's a business operations incident that can halt core business functions.

The campaign highlights the opacity of third-party risk when organizations consume Oracle as a managed service or via integrators. Limited visibility into vendor-hosted ERP can leave security teams blindsided when zero-days are exploited at scale. Once attackers gain access to EBS, they're adjacently close to SSO integrations, data lakes, and downstream SaaS applications that consume ERP data multiplying the blast radius if identities or integration credentials are reused.

Actionable Steps:

• Immediately confirm whether you run Oracle EBS (on-prem or hosted) or if vendors do on your behalf

• Demand clear answers on patch level and mitigations applied against the EBS campaign

• Review how ERP authentication integrates with IdP, VPNs, and cloud platforms

• Add ERP systems to attack surface management and tabletop exercises

• Prepare procedures to isolate ERP environments and rotate integration credentials quickly

Source: SecurityWeek Oracle EBS Campaign Coverage

3. Claude "Skills" Plug-ins Shown Able to Deploy Ransomware

What Happened

A Cato Networks researcher demonstrated that an Anthropic Claude "Skill" a plug-in used by Claude Code to automate tasks can be modified to deploy MedusaLocker ransomware without being flagged by the model. By inserting a seemingly benign function into Anthropic's open-source "GIF Creator" Skill that downloads and executes external code, the researcher showed that Claude reviews only the visible Skill code, not remote payloads fetched at runtime. Anyone can download, tweak, and re-upload Skills in similar fashion, and Anthropic's current stance is that users are responsible for trusting Skills.

In parallel, security researchers are warning about "shadow AI in the browser" unmanaged AI extensions and agentic browsers that can read data across SaaS tabs and silently exfiltrate it, often outside CASB/DLP visibility.

Why It Matters

AI tools are becoming the new "PowerShell" of enterprise environments. Skills, plug-ins, and AI-controlled agents are code execution environments with access to source code, secrets, and internal SaaS not harmless productivity helpers. The Claude demonstration shows how little effort is required to turn them into delivery vectors for ransomware and other malware.

Traditional code review, software composition analysis, and CASB controls often ignore AI plug-in ecosystems and browser agents, even though they can read session cookies, internal dashboards, and cloud consoles in the browser context. Auto-updating Skills and extensions create an AI supply chain where a poisoned update or compromised extension publisher can instantly impact thousands of developers and analysts.

This connects directly to Cliff's point about data engineering complexity: "Every log source is quite a bit of work, and you will be on this endless journey of maintaining a data lake forever." Just as security teams must continuously maintain log pipelines, they now must maintain AI agent governance treating these tools as critical infrastructure requiring the same rigor as production code.

Actionable Steps:

• Treat AI plugins/Skills/Agents as Tier 0 code requiring allowlisting and code review

• Require provenance checks for internal or forked Skills, just like internal libraries

• Update acceptable use and AI policies to cover approved tools and prohibited data types

• Implement restrictions on installing AI extensions/agentic browsers on corporate endpoints

• Ask EDR and browser security vendors how they detect AI-driven automation and token exfiltration

Sources: Axios Claude Ransomware PoC, The Hacker News Shadow AI Analysis

4. AWS and Google Announce Joint Multicloud Networking Service

What Happened

AWS and Google Cloud jointly launched a new multicloud networking service combining AWS Interconnect–multicloud with Google Cloud's Cross-Cloud Interconnect, allowing customers to establish private, high-speed links between AWS and GCP environments in minutes instead of weeks. The providers also introduced an open specification for network interoperability, with Salesforce named as a day-one user.

Why It Matters

Multicloud private connectivity is becoming dramatically easier great for latency and reliability, but it also increases the need for tight segmentation, routing governance, and inspection between clouds. Many enterprises currently rely on DIY IPsec or third-party SD-WAN for multicloud connections. This offering will tempt teams to move to provider-managed connectivity, which can be beneficial but security controls must move with you (firewalls, IDS/IPS, service mesh, policy as code).

Once AWS and GCP are connected via one high-speed "trusted" fabric, misconfigurations in one cloud (e.g., flat VPCs, overly broad peering) can more easily propagate risk to the other. As organizations build cross-cloud data lakes and security operations, this interconnect becomes a critical attack surface requiring dedicated monitoring and segmentation.

Actionable Steps:

• Request a threat model of current and planned multicloud connectivity from your cloud networking team

• Define security guardrails: mandatory use of segmented VRFs/VPCs/projects and clear patterns for east-west inspection

• Update cloud architecture standards to ensure cross-cloud links are visible to SecOps

• Integrate new cross-cloud resources into logging, NDR, and incident response workflows

• Review network segmentation and egress policies to ensure flow logs cover cross-cloud transport

Sources: Reuters AWS-Google Collaboration, ITPro Coverage

🎯 Cloud Security Topic of the Week:

From SIEM to Data Lake: Why Security Teams Are Making the Shift (And What It Actually Takes)

The traditional SIEM model is breaking under the weight of modern log volumes. This week's conversation with Cliff Crosford reveals a painful truth that many security leaders are discovering: when your log volume reaches multiple terabytes per day, the economics of traditional SIEMs become untenable, forcing impossible choices about which logs to drop and which blind spots to accept.

Featured Experts This Week 🎤

• Cliff Crosford   Co-founder, Scanner.dev

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

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

• Data Lake vs. Traditional SIEM: A data lake is an architectural approach that stores massive volumes of raw data in object storage (like S3) at significantly lower cost than traditional SIEMs. Unlike SIEMs that require structured ingestion and charge by volume, data lakes can store petabytes of logs indefinitely. However, they require significant data engineering to make logs searchable and useful.

• OCSF (Open Cybersecurity Schema Framework): A vendor-agnostic schema that provides a common structure for security log data across different sources. While useful for standardization, it requires significant transformation work to fit diverse log sources into its strict schema requirements.

• Schema Normalization: The process of transforming logs from different sources into a consistent structure with standardized field names. This enables correlation across log sources but requires ongoing maintenance as applications evolve and schemas change.

• Security Data Lake
  A log and event repository built on cloud object storage (e.g., S3, GCS, ADLS) plus engines like Presto/Trino, Spark, or specialized lake query engines. Optimized for cheap, long-term storage and large-scale analytics not for the interactive alerting workflows SIEMs excel at.

• Traditional SIEM
  Platforms like Splunk, Elastic, QRadar, etc. Great for parsing, normalizing, and searching logs up to a point. Licensing is usually volume-based, which becomes prohibitive beyond hundreds of GB/day, pushing teams to sample or drop logs.

• Normalization vs “Messy Data”
  Normalization = forcing all logs into a consistent schema. In practice, custom apps and constantly changing sources make perfect normalization a full-time job. Cliff argues for “best-effort normalization” + tools that can search nested JSON and free text without requiring strict tables.

• Detection Engineering
  The practice of designing, tuning, and maintaining detection rules and pipelines. In a data lake world, this includes SQL rules, full-text searches, anomaly jobs, and AI-assisted investigations, all closely tied to schema evolution and data quality.

This week's issue is sponsored by Drata

Security teams shouldn’t be buried in manual evidence collection. 

Drata automates compliance end-to-end while providing unified visibility across cloud workloads, identities, and configurations. 

Teams use Drata to cut audit prep from weeks to hours, accelerate security reviews, and reinforce DevSecOps pipelines with real-time controls monitoring. 

If you're scaling cloud infrastructure and need a smarter path to continuous compliance, Drata is built for you.

Book Demo with Drata

💡Our Insights from this Practitioner 🔍

SIEM vs. Data Lake: Why We Ditched Traditional Logging? (Full Episode here)

The Economic Reality Forcing Change

Cliff's experience building security infrastructure at a prior startup (later acquired by Cisco) illustrates the breaking point many organizations face. "To increase our license, it would've been more expensive than the entire budget for the engineering team," Cliff explains. When faced with exploding log volumes at his previous company, his team redirected 90% of log data to S3 buckets a seemingly logical cost-saving measure.

But the reality proved more complex. "It became a bit of a black hole where like you couldn't really search through very much data once the data set became large. Querying that data lake at S3 became more and more painful over time."

At modern scale, volume-based SIEM licensing becomes economically impossible. Data lakes promise cheaper, near-infinite retention for multi-TB/day security data and the ability to keep all security-relevant logs instead of sampling or dropping them. They also provide a better substrate for AI-driven detection and investigation. But today, they come with hard trade-offs around engineering effort, usability, and search performance.

The Hidden Cost of "Cheap" Storage

What looked like a financial win turned into an operational nightmare. The logs existed, but they were essentially unusable for actual security investigations. This experience highlights a fundamental misunderstanding about data lakes: cheap storage is only valuable if you can actually query the data when you need it. For security teams, that means during active incidents when every minute counts.

When Cliff's team tried to use Athena for queries, they hit the wall that many organizations eventually face: "The queries would take three hours to run and might cost a few hundred dollars." This isn't a configuration problem it's an architectural reality of how SQL-based data lake engines work.

The Engineering Reality Most Teams Underestimate

The fundamental issue? "Every log source is quite a bit of work, and you will be on this endless journey of maintaining a data lake forever," Cliff warns. Security teams often think of data lake migration as a one-time project, but his experience reveals it as an ongoing engineering commitment. Each new log source requires custom work to fetch, transform, and fit into your schema. And when applications update and schemas change which happens constantly your detection rules break.

One particularly painful reality: "Basically every week, at least one of them was misbehaving because the schema changed a little bit. New fields showed up that were important or got renamed and then suddenly it stopped getting inserted." For a team managing 40-50 log sources, this becomes a weekly firefighting exercise.

Why Traditional Data Lake Tools Fail Security Teams

The challenge goes deeper than engineering effort. Most data lake tools were designed for business analytics structured, columnar data that fits neatly into SQL tables. Security logs are fundamentally different. As Cliff explains: "For a lot of security logs they can be a lot messier. They can be like deeply nested JSON or lots of text like PowerShell command line text and so on. That's where SQL engines that are the typical data lake engines really break down."

This mismatch creates a paradox: you move to a data lake for visibility and cost savings, but then you can't effectively search the very data you're storing. Traditional full-text search capabilities that security teams rely on in Splunk or Elastic simply don't exist in most SQL-based data lake platforms like Athena, Presto, or Trino

The Hard Choices: What Gets Sacrificed?

When SIEM costs become prohibitive, security teams face brutal triage decisions. Cliff describes a common pattern: "They'll use Cribl to delete fields from logs, filter them down, sample them down try to just keep the log volume down to avoid spending too much on ingestion volume."

But here's the critical difference between SRE and security use cases: "For observability use cases, getting sampled data is all right, but for security teams, it can be pretty terrifying to be like, well, I'm only keeping like 20% of my log data. The threat actor activity and maybe the IOCs that I care about, like malicious IP addresses, are invisible to me."

Sampling works for understanding system health. It's catastrophic for security, where a single malicious event can represent a critical breach. The threat actor doesn't show up in every log entry just the ones you chose to drop.

Amazon Security Lake: Promise vs. Reality

Many teams look to AWS Security Lake as a turnkey solution, but Cliff's analysis reveals important limitations. While it's "a really good first step" with built-in support for many log sources and automatic OCSF (Open Cybersecurity Schema Framework) transformation, two major challenges remain:

First, the custom log problem: "For custom log sources or log sources that aren't in their list of supported log sources, you're gonna have to do the work to get it to fit into this very strict schema, and that can be a massive amount of work." Given that most enterprises run hundreds of custom applications, this isn't an edge case it's the majority use case.

Second, the search performance issue: "If you have things like command line text from EDR logs like PowerShell commands, you're trying to do substring search and really understand messier log data that is unfortunately still quite slow in the data lake." The platform is optimized for columnar, SQL-friendly data, not the messy reality of security logs.

The AI-Assisted Future (With Important Caveats)

Cliff sees AI as a genuine accelerator for data lake workflows, but with critical human-in-the-loop requirements. "AI can really help you figure out how to normalize your data if you really need to fit it into a SQL schema. It will get you like 80% of the way there. It can be kind of there's still like a bit more, it'll hallucinate a little bit."

For detection engineering, AI becomes particularly powerful: "Because it kind of knows everything that's out there, it can be a really great brainstorming partner." But Cliff is clear about boundaries: "My opinion for now is that it's not yet ready to be fully trusted with important investigations and response. It is good at getting started, but I think humans are still very much needed."

The most promising pattern he's seeing? Automated detection tuning: "An alert goes off, an agent takes a first cut at the investigation, then will make a recommendation for what the detection rule should probably be like. Maybe this is too noisy and we should tune it. Then it will go open up a pull request in GitHub, and then the team can just review it, accept it, and then the detection rule is now tuned better."

This closes the loop on detection engineering without requiring manual Jira tickets and waiting for vacation schedules. But notice the pattern: AI proposes, humans approve. The expertise remains human; the acceleration comes from AI.

Strategic Recommendations for 2026 Planning

For CISOs evaluating the SIEM vs. data lake decision in 2026 planning, Cliff offers pragmatic guidance: "I don't think it's quite time to totally replace your SIEM with a data lake. One pattern that tends to work well is to say, 'cool, all my logs used to fit in my SIEM a few years ago. Now it's like 10% of them. Let me keep those 10% going to my SIEM... and then nine terabytes a day of logs instead of dropping them entirely let's make the first step which is just store them in S3 for compliance purposes.'"

This hybrid approach acknowledges reality: traditional SIEMs still provide better usability for hot-path investigations, while data lakes solve the retention and cost problem for the long tail of logs you can't afford to keep in your SIEM.

The decision of whether to build or buy depends on your team composition: "If you have a really strong data engineering team, whether in the security side or the rest of your organization already doing a lot of data engineering with data lakes for other purposes like business analytics or observability, then yeah, you can share that work with them. That can be a fun project. It is a forever project though."

But for teams without deep data engineering resources: "If you don't have that data engineering talent and resources, you'll probably need to buy something." Be honest about your team's capabilities before committing to a multi-year engineering project.

The Schema Evolution Problem Nobody Talks About

Perhaps the most underestimated challenge Cliff identifies is schema evolution. "Tools in the future need to embrace the fact that logs are going to be messy. We as humans can kind of see these schema changes, be like, 'eh, I get it. I get what this new field means.'"

This human ability to adapt to changing schemas to understand that a renamed field still represents the same data is something current data lake tools completely lack. When an application updates and changes field names, your carefully constructed SQL queries break, your detections fail, and you lose visibility until someone manually fixes the schema mapping.

The future Cliff envisions: "Messiness will be embraced more" tools that can handle schema drift without requiring constant manual intervention. Until then, budget for weekly schema maintenance as part of your data lake TCO.

RELATED RESOURCES

OCSF & Schema Standards

• Open Cybersecurity Schema Framework (OCSF) - Vendor-agnostic schema for security logs

• AWS Security Lake Documentation - Managed data lake for security data

AI-Assisted Security Operations

• Model Context Protocol (MCP) - Connect AI assistants to external data sources

• Cursor - AI-powered code editor for automation scripts

• GitHub Copilot for Security - AI assistance for security workflows

Cloud Security Podcast

• Cloud Security Podcast – Full Episode with Cliff

• For deeper discussion on failed data lakes, AI in detection engineering, and where SIEM still fits.

Related Podcast Episodes 🎧

SIEM vs. Data Lake: Why We Ditched Traditional Logging?

Question for you? (Reply to this email)

 🤖 Would you be Team SIEM or Team Security Data Lake?

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!

Shilpi Bhattacharjee

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

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter Topic we cover - Can You Trust an AI SOC in a Regulated Environment? (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 convergence of sophisticated supply chain attacks and AI-driven security operations creates both unprecedented risk and opportunity for enterprise defenders. This week, we examine the Sha1-Hulud 2.0 worm that compromised 25,000+ GitHub repositories while exploring how organizations are successfully deploying AI Security Operations Centers (AI SOCs) in highly regulated environments.

This week is all about trust:

• Trust in your supply chain: Sha1-Hulud 2.0 tearing through npm and 25K+ GitHub repos. 

• Trust in your telemetry: Fluent Bit RCE and log tampering across 15B+ deployments.

• Trust in your identity tier: Oracle Identity Manager pre-auth RCE exploited since August.

• Trust in your SOC: as AI agents move from toy demos to front-line investigations in regulated environments.

Our featured expert this week is Grant Oviatt, Head of Security Operations at Prophet Security and former SOC leader at Mandiant and Red Canary. Grant brings over 15 years of experience in security operations and shares his journey, who went from an AI skeptic to running an AI SOC handling 12K+ investigations in 2 weeks with 99.3% agreement with humans and ~4-minute investigation times.

Together, they explore a question many of you are wrestling with right now: Can you put an AI SOC in front of regulated workloads and sleep at night? [Listen to the episode]

📰 TL;DR for Busy Readers

• Sha1-Hulud 2.0 worm compromised 600+ npm packages with persistent GitHub Actions backdoors rotate all CI/CD credentials immediately

• Fluent Bit vulnerabilities (8+ years old) threaten 15B+ cloud deployments attackers can manipulate logs while executing code

• AI SOC maturity ( with Grant Oviatt) now enables 4-minute investigations with 99.3% accuracy in regulated environments through explainability and traceability

• Data sovereignty controls allow regulated customers to host AI SOC data planes in their own cloud with single-tenant architecture

• Oracle Identity Manager zero-day exploited since August IAM compromises provide "keys to the kingdom" across hybrid environments

📰 THIS WEEK'S TOP 5 SECURITY HEADLINES

1.  Sha1-Hulud 2.0: Self-Replicating npm Worm Compromises 25,000+ Repositories

Between November 21-23, a second wave of the Sha1-Hulud supply chain attack compromised over 600 npm packages, including popular tools from Zapier, PostHog, ENS Domains, and Postman. The malware has infected 25,000+ GitHub repositories across approximately 500 users, with cross-victim credential exfiltration actively occurring. This evolved variant now installs self-hosted GitHub Actions runners on infected systems, providing persistent backdoor access that survives reboots, while harvesting credentials from AWS, GCP, and Azure environments across 17 AWS regions.

Why This Matters to Cloud Security Leaders:

This represents a fundamental escalation in software supply chain attacks, directly threatening enterprise CI/CD pipelines and cloud infrastructure. This worm isn’t “just another” npm typo-squatting event. It directly targets:

• CI/CD runners – Execution happens in preinstall, i.e., before dependencies resolve, when your build agents and secrets are fully exposed.

• Cloud control planes – It reaches into AWS/GCP/Azure creds across 17 AWS regions and exfiltrates them to attacker-controlled repos.

• GitHub Actions fleet – The worm installs self-hosted runners as durable, authenticated control channels into your infra.

If your org consumes affected packages some present in ~27% of code/cloud environments in sampled scans you may have both a supply-chain compromise and a cloud persistence problem.

Immediate Actions: 
Start by scanning all endpoints for affected packages, rotate ALL credentials (npm tokens, GitHub PATs, SSH keys, AWS/GCP/Azure credentials), 

CI/CD lockdown

• Disable or tightly restrict preinstall/postinstall lifecycle scripts in build environments.

• Treat build agents like production workloads: restrictive egress, zero trust to GitHub, npm, etc.

Incident playbook

• Cross-check all repos for "Sha1-Hulud: The Second Coming" and suspicious self-hosted runners (e.g., SHA1HULUD).

• Rotate everything: npm tokens, GitHub PATs, SSH keys, cloud credentials used on any affected machine.

AI SOC tie-in

• This is exactly the sort of large-scale, high-noise event where AI SOC triage can shine auto-enriching build logs, access logs, and GitHub audit trails to spot cross-tenant token reuse that humans would burn out on.

Read More: Wiz Research | Mend.io Analysis | Snyk Advisory | The Hacker News

2. Critical Fluent Bit Vulnerabilities Expose 15+ Billion Cloud Deployments

Oligo Security disclosed five critical vulnerabilities in Fluent Bit, the open-source logging agent deployed over 15 billion times across AWS, Google Cloud, Azure, and Kubernetes environments. The most severe flaw, CVE-2025-12972, is a path-traversal vulnerability that has existed for over 8 years, allowing attackers to write or overwrite arbitrary files for remote code execution. Additional vulnerabilities enable authentication bypass, log tampering, tag spoofing, and stack buffer overflow attacks.

Why This Matters to Cloud Security Leaders:

Fluent Bit sits at the heart of cloud observability infrastructure, processing logs, metrics, and traces before they reach SIEM platforms and detection systems. The tool is embedded in Kubernetes clusters, AI labs, banks, and all major cloud providers, making these vulnerabilities a systemic risk to cloud ecosystems.

Fluent Bit sits between your workloads and your SIEM/XDR. If it’s compromised, an attacker can:

• Hijack the node (DaemonSet → host-level RCE → cluster pivot).

• Silence or rewrite incriminating logs to defeat detection.

• Inject fake telemetry to mislead incident responders and AI-driven analytics.

That last bullet is especially relevant if you’re experimenting with LLM-based detection. If your logging substrate can be coerced into lying, AI just makes you confidently wrong, faster.

The attack surface is particularly concerning for enterprise defenders: attackers could execute malicious code through Fluent Bit while dictating which events are recorded, erasing or rewriting incriminating entries to hide their tracks, injecting fake telemetry, and injecting plausible fake events to mislead responders. Because Fluent Bit is commonly deployed as a Kubernetes DaemonSet, a single compromised log agent can cascade into full node and cluster takeover. This directly connects to Grant Oviatt's discussion on traceability: if your logging infrastructure can be manipulated, the entire chain of evidence for AI SOC investigations becomes unreliable.

The disclosure process itself revealed systemic issues: Despite multiple responsible disclosure attempts through official channels, it took over a week and the involvement of AWS before the vulnerabilities received sustained attention.

Immediate Actions:

Patch or replace immediately

• Upgrade all agents to v4.1.1 or v4.0.12; use AWS Inspector / Security Hub / Systems Manager to locate vulnerable nodes at scale.

Harden the log plane

• Lock Fluent Bit configs as read-only where possible.

• Use static tags + fixed paths to reduce spoofing.

• Limit network access for Fluent Bit outputs to known log backends only.

Monitor for integrity issues

• Add controls to detect tag spoofing, missing logs, or anomalous routing changes from Fluent Bit pods.

Read More: Oligo Security Report | CSO Online | The Hacker News

3. Oracle Identity Manager Zero-Day Exploited in the Wild Since August

CISA added CVE-2025-61757 to its Known Exploited Vulnerabilities catalog on November 21, a critical pre-authentication remote code execution flaw (CVSS 9.8) in Oracle Identity Manager. Searchlight Cyber researchers discovered active exploitation dating back to at least August 2025, possibly as a zero-day before Oracle's October 2025 patch. The vulnerability affects Oracle Identity Manager versions 11.1.2.3 and 12.2.1.3, allowing unauthenticated attackers to compromise systems over the network without user interaction.

Why This Matters to Cloud Security Leaders:

Oracle Identity Manager is a critical component of enterprise IAM infrastructure, deployed across government agencies and large enterprises. The pre-authentication nature of this vulnerability means attackers can compromise systems without any credentials, making it a prime target for initial access. Given the centralized nature of IAM systems, a compromise here could provide attackers with "keys to the kingdom" across cloud and on-premises environments.

The extended exploitation timeline is particularly concerning: evidence suggests the vulnerability may have been exploited as a zero-day before Oracle's October patch, giving attackers months of undetected access. CISA's inclusion in the KEV catalog indicates active targeting of federal systems, with federal agencies required to patch by December 12, 2025.

OIM is core IAM infrastructure key points:

• Pre-auth RCE on OIM is effectively a full identity tier compromise.

• Given the months-long exploitation window, assume adversaries have used it as an initial access + persistence vector.

• CISA has mandated US federal agencies patch by 12 Dec 2025, signaling active exploitation at scale.

Immediate Actions: Apply Oracle's October 2025 Critical Patch Update immediately, conduct forensic review of Oracle Identity Manager logs dating back to August 2025, look for suspicious authentication patterns or privilege escalations, and review all identity provisioning activities during the exploitation window.

Key points:
Patch OIM with Oracle’s October 2025 CPU as an emergency change.

Assume breach since Aug 2025:

• Review OIM logs for anomalous authentications, provisioning events, and privilege escalations.

• Treat OIM as a suspected initial access vector in any ongoing IR investigations.

Read More: BleepingComputer | SecurityWeek | The Hacker News

4. CrowdStrike Terminates Insider Sharing Data with Hacker Group

CrowdStrike terminated an employee on November 21 for sharing internal screenshots with the hacker group "Scattered Lapsus$ Hunters" on Discord. The terminated employee had access to CrowdStrike's Slack and Confluence systems but did not have access to production systems or customer data. CrowdStrike emphasized that no systems were breached and the incident involved an authorized employee sharing limited internal screenshots.

Why This Matters to Cloud Security Leaders:

This incident highlights the persistent insider threat risk facing cybersecurity vendors and cloud service providers. While CrowdStrike successfully detected and responded to the threat, the incident demonstrates how social engineering can target even security-conscious organizations. The hacker group attempted to use the screenshots as proof of a broader compromise, amplifying the incident through social media, a tactic that's increasingly common and can cause reputational damage disproportionate to actual risk.

For enterprise security leaders, this serves as a reminder that insider threats don't always involve malicious intent from the outset. Employees can be manipulated into sharing information that seems innocuous but provides attackers with reconnaissance value. The targeting of CrowdStrike, months after the company's July 2025 global IT outage, suggests adversaries are opportunistically targeting organizations during periods of heightened scrutiny.

Key Takeaways: Implement robust insider threat programs with behavioral analytics, educate employees on social engineering tactics targeting internal communications, restrict access to internal collaboration tools based on need-to-know principles, monitor for unauthorized data exfiltration from collaboration platforms, and have crisis communication plans for insider threat incidents.

Key Points

• Expand insider threat monitoring to include collaboration platforms and screenshot-heavy workflows.

• Train staff that “just screenshots” can still be sensitive.

• Ensure crisis comms plans explicitly cover insider-driven “near miss” incidents.

Read More: TechCrunch | BleepingComputer

5. SEC Drops SolarWinds Case After Years of Legal Battle

The SEC voluntarily dismissed its securities fraud lawsuit against SolarWinds and CISO Timothy Brown on November 20, ending a case filed in October 2023 over alleged misrepresentations about cybersecurity practices before the 2020 supply chain breach. The dismissal came after a federal judge ruled in July 2025 that most of the SEC's claims could not proceed, narrowing the case significantly.

Why This Matters to Cloud Security Leaders:

The SEC's decision to abandon the SolarWinds case represents a significant shift in regulatory enforcement around cybersecurity disclosures. While this may bring relief to many companies and CISOs concerned about the chilling effect on proactive security work, organizations must still proceed carefully when making public statements about their security programs.

In the wake of cyber incidents, federal, state, and international regulators may scrutinize cybersecurity disclosures as evidence of negligence. This includes the SEC's 2023 requirements for companies to disclose material cyber risks and incidents to investors. Effective governance around drafting and vetting cybersecurity statements and disclosures remains critical for public companies.

Strategic Implications: Review public-facing security statements for accuracy and consistency with actual practices, ensure board-level oversight of cybersecurity risk disclosures, maintain detailed documentation of security investments and improvements, and prepare for continued regulatory scrutiny even with shifting enforcement priorities.

Key Points

• The dismissal is widely seen as a setback to the SEC’s attempt to pursue personal liability for CISOs around security disclosures.

• But it should not be read as a retreat from cyber disclosure expectations if anything, it will refocus regulators on cases with clearer evidence trails.

• For cloud-heavy enterprises, this reinforces the need for defensible, documented risk narratives around supply chain, cloud concentration, and AI usage not marketing-driven security postures.

Read More: Inside Privacy | The Hacker News | Cybersecurity Dive

🎯 Cloud Security Topic of the Week:

Can You Trust an AI SOC in a Regulated Environment?

This week’s theme: if you want AI-assisted SOC in a regulated org, you have to design for trust first, not bolt it on later.

The 3 trust pillars for regulated AI SOCs

1. Explainability – Every conclusion must read like a senior analyst’s notes, not an opaque score.

2. Traceability – Line-by-line evidence of every query, API call, and log used in the investigation.

3. Sovereignty – A data plane that can live in the customer’s cloud, with single-tenant isolation and BYO-model gateways.

Our takeaway
If you can’t:

• Explain why an alert was closed,

• Show every step the AI took, and

• Prove where the data lived and who controlled it,

   …you don’t have a regulated-ready AI SOC yet. You have an experiment. [Listen to the full Episode: Grant Oviatt on building a regulated-ready AI SOC]

Featured Experts This Week 🎤

• Grant Oviatt - Head of Security Operations, Prophet Security

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

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

• AI SOC (AI Security Operations Center): A security operations center that leverages artificial intelligence agents to perform triage, investigation, and response activities traditionally handled by human security analysts. Modern AI SOCs use large language models and specialized agents to query security tools, analyze logs, and make investigative decisions with human oversight.

• Explainability: In the context of AI SOC operations, explainability refers to the ability to understand and articulate how an AI agent reached a specific decision. This includes visibility into the reasoning process, the data considered, and the logic applied similar to how a human analyst would explain their investigative conclusions.

• Traceability: The ability to track the complete lineage of data and decisions from raw inputs through transformation and analysis to final outputs. In AI SOC environments, this means documenting every query issued, every API call made, every log examined, and every decision point in an investigation

• Single-Tenant AI SOC Architecture: A deployment model where each customer's data, processing, and AI models operate in complete isolation from other customers. This ensures no cross-contamination of data and allows customers to maintain complete control over their security evidence and analysis.

• Data Plane: The component of a system that handles the actual processing

  and storage of customer data, as distinct from the control plane that manages configuration and orchestration. In AI SOC contexts, customers in regulated industries often require the data plane to reside within their own cloud environment for sovereignty and compliance.

• Model Gateway (BYO model): An org-controlled proxy in front of LLMs that enforces which models can see what data (e.g., no PHI to public models), logs every prompt/response, and allows AI SOC traffic to flow through the same AI governance stack as your product workloads.

This week's issue is sponsored by Brinqa

What If You Could See Risk Differently?

On Nov 19, Brinqa experts will show how a shift in perspective, adding context, can change everything about how you prioritize risk. Fast-paced, real, and surprisingly fun.

📤 Register here

💡Our Insights from this Practitioner 🔍

How to Build Trust in an AI SOC for Regulated Environments (Full Episode here)

The Evolution from AI Skeptic to AI SOC Advocate

Grant Oviatt's journey from AI skeptic to building enterprise-scale AI SOC solutions mirrors the transformation happening across the security operations industry. "If I think of 15 years ago with AI, anything AI detection in it scared me to death and I was very skeptical," Grant explains. "I knew it was gonna be the highest false positive in the entire company."

What changed? Grant's perspective shifted when he began experimenting with breaking down security investigations into composable pieces that AI agents could tackle with high consistency. "When it was great, it was great," he notes. "It started becoming more of a consistency problem of how can you chunk up this problem of doing a security investigation that security operators think of into small bite-sized pieces that agents can tackle really well instead of trying to eat the elephant."

This architectural approach decomposing complex security investigations into discrete agent tasks has proven successful at Prophet Security, where they've achieved remarkable results: "Our average time to complete an investigation is right around four minutes" compared to traditional SOC teams that "won't even start to look at an alert in four minutes, much less complete the investigation in that time."

The consistency problem that Grant identified is critical for regulated environments. In a recent customer engagement, Prophet Security processed 12,000 investigations over two weeks and "had 99.3% agreement between their security operations team and Prophet during that 12,000 investigation stint. We were significantly faster with it. It was 11x the difference in the meantime to investigate."

The Twin Pillars: Explainability and Traceability

For organizations in regulated industries healthcare, financial services, government trust in AI SOC capabilities rests on two fundamental requirements that Grant identifies: explainability and traceability.

Explainability addresses whether the AI's decision-making process is reasonable and understandable. "Given this particular situation, is it reasonable to make the decision here," Grant explains. "In an explainable way, is the analysis understandable and reasonable for a security practitioner?" This mirrors how human analysts would be evaluated not just on their conclusions, but on whether their reasoning makes sense given the evidence available.

Traceability focuses on the data lineage throughout an investigation. "What queries are the AI SOC issuing API requests issuing across different technologies? What queries is it issuing across your SIEM? What are the requests that it's making? What are the responses that it's returning?" Grant details. "Really tracing the inputs and the data transformation that's happening."

The difference from traditional SOC operations is striking. Where human analysts might copy-paste a few relevant log entries into their investigation notes, AI SOC platforms capture everything: "The average investigation is 40 to 50 queries across six different tools in a customer's environment. Instead of just having best effort copying and pasting of logs from a traceability perspective, you have a line by line detail of everything that was gathered, all the evidence that was gathered, and all the decision making that happened along the way."

Grant emphasizes that regulators are demanding a "10x magnification" in explainability and transparency for AI SOC compared to human-driven operations, "just given the skepticism with AI and the work product." This heightened standard actually benefits customers even those not in regulated industries by providing unprecedented visibility into security investigations.

Design move: Reject any AI SOC or MCP setup where you can’t see the raw queries, tool calls, and evidence chain for each decision. If you can’t audit it, you can’t defend it to a regulator.

Architecture for Data Sovereignty and Compliance

One of the most critical architectural decisions for AI SOC in regulated environments involves data management. Grant outlines Prophet Security's approach: "We're not a SIEM so we don't require you to stream all of your data to Prophet to make decisions. We make point in time queries across your different security tools to make decisions much like a person would."

This architecture dramatically reduces data exposure. "The subset of data that we're processing is much, much, much smaller and much more focused, which gets us out of a lot of problems from a data management perspective," Grant explains. Customers also maintain granular control: "Customers have total control of what they want to send to us and the capabilities that Prophet can issue."

For healthcare organizations dealing with HIPAA compliance, this flexibility is essential. Grant shares an example: "We have a healthcare regulated customer that said, 'Hey, my HIPAA data, I'm just not even gonna put that in the purview of Prophet to look at.' And we're gonna start without going down that path and we can explore it later."

Beyond selective data exposure, Prophet Security offers a "bring your own cloud" model where "the data plane of our environment can live defensively within the organization's perimeter. This has been really meaningful for financial organizations for us. There's defensibility that they own all of the evidence and data. They can remove our access at any time or blow away the data plane and all of that raw evidence is gone."

This architectural approach addresses a fundamental concern in regulated industries: who controls the security evidence, and can that access be revoked immediately if needed?

Single-Tenant Architecture and the Training Data Question

One of the most common concerns Grant encounters is whether customer data is being used to train AI models. His answer is unequivocal: "Our architecture's entirely single tenant. There's no cross contamination and you can think of it like onboarding a new security staff member to the team, like it's a new analyst. All the learning that happens within your tenant stays in your tenant."

Prophet Security enforces this "to a contractual level that your data is never used for training in improving the model outside of it improves the product for you, but there's no model training on the raw data." This single-tenant approach is "another huge component that's meaningful for regulated environments."

Grant also addresses the emerging trend of model portability: "Model portability is something that we've invested in as well, where regulated industries may have their own model gateway, where there's specific models that they are comfortable with and others that they're not." This allows organizations to "manage the traceability of the inputs going to the model, they're paying the outbound costs and able to manage that through their own AI governance process."

Design move: Treat “no cross-tenant training on my data” as a non-negotiable contractual requirement for regulated workloads.

AI SOC vs. MDR: Replacement or Complement?

For organizations already invested in Managed Detection and Response services, Grant sees AI SOC as both a potential replacement and a complementary solution, depending on the use case.

"We have many customers that are moving from MDR to AI SOC as their holistic approach for doing investigations," Grant notes. The speed advantage is compelling: traditional MDR teams "won't even start to look at an alert in four minutes, much less complete the investigation in that time. So there's just sort of a response velocity that can't be contended with."

However, some organizations take a hybrid approach. "We have a few customers that coexist and have both," Grant explains. "AI SOCs aren't scared by custom detections or things that your team has generated. That's often 20 to 30% of the burden of a security operations team, where they have specific applications or custom detections that their security engineering team has developed that their MDR can't reasonably look at."

The scalability difference is fundamental: MDR providers serve hundreds or thousands of customers and "focused on the base case that's consistent across all of those customers." Custom detections don't scale for human-driven MDR, but "on an AI SOC level, you know, one that's deployed for your environment specifically, it scales perfectly well."

Grant sees customers using this division of labor: "My MDR contract is going for another two years or three years, but I still have all these custom detections that are a problem for me. I would love to put AI SOC on that and then visit if this is a replacement or expand my budget spend to bring Prophet in in a broader way when that renewal is over."

The Reality of Building Your Own AI SOC

For organizations considering building AI SOC capabilities internally, Grant offers a realistic assessment: "It's a really hard problem. I think it's a fun thing to experiment with. I think there's a lot you can do on your own to build sort of enrichment and build context, but trusting decision making and that consistency with AI agents, very hard to do in an internal organization."

Grant has encountered creative attempts where teams "built a workflow that's in their store or something else where they go grab data and then they make an LLM call and then they send the data back and they make another LLM call. And it's very strict logic to try to make a single investigation work." The problem? "Now I've gotta do it for the other 500 detections in my environment. And I was like, that sounds like a chore. That doesn't sound like an answer to your problem. You're just focusing your energy in a different place."

The operational challenges extend beyond initial implementation. "Model providers change their models, and so without writing a lot of code, you might see a 3% improvement somewhere else, or a 0.5% degradation in consistency or quality of analysis," Grant explains. "We have an entire machine learning team that is looking at all the different model providers out there. You have a whole operational team that's kind of wrangling the weather, so to speak."

Grant's recommendation: "Play around with it, get an understanding of how prompts work and how models work. But when you're looking to scale this and trust this and not worry about security problems, I would work, try out some AI SOCs and see how it compares to what you build."

The Model Context Protocol Caution

For security leaders evaluating AI SOC technologies, Grant issues a specific warning about the Model Context Protocol (MCP): "MCP adds a whole other layer where there are MCP servers where you want to make it very easy to grab this information from your environment. But when you talk about regulated environments specifically, transparency is lost."

The problem is fundamental: "When I ask an MCP agent a question, it'll give me an answer, but it won't give me the query that it ran to generate the answer. And so there's a mismatch in auditability from our perspective to make this clear to you, a human, as to what happened, and that break in the chain is just one too many black boxes in the cycle."

Prophet Security made a conscious decision to "build our own collection agents for that transparency piece" rather than rely on MCP. Grant is "hopeful that MCP agents can expand to be more scrutinous on the auditability side and have some sort of REST API response that was queried on their end and tracked along with the results and send this entire package over to maintain that evidence chain of custody."

For organizations considering building their own AI SOC: "MCP is the fastest way to do it in a lot of cases, but who knows what's happening on a bunch of different levels at that point."

Red Lines: What AI Shouldn't Automate (Yet)

When it comes to automated remediation, Grant advocates for constrained creativity: "Agents are very creative, maybe a nicer way of saying probabilistic. If you were to give an AI agent, 'Hey, go and remediate this file on a system,' there's several different ways that it could go and do that."

His approach: "I am a big believer today in strict coupling of, instead of AI having creativity on the query part, there's a specific API that an agent is allowed to access. It performs one function, and this is the capability that the agent has in your environment."

Grant recommends treating remediation actions "more as a traditional integration in that sense, where AI SOC is managing the reasoning of when this is appropriate. But the action is a single call or a series of calls that are more deterministic."

The risk assessment is straightforward: "If agents are inspired and agentically performing remediative actions in your environment rather than coming up with the playbook of things that you should do and aligning those to REST API calls, that gets a little scary in redlining it in my opinion."

For organizations comfortable with MDR-driven remediation, the risk profile is actually lower with AI SOC: "If you're working with subprocessors or MDRs that are using your PHI or PII data to do investigations, you're probably comfortable having an AI SOC do the same thing since it's the same process and honestly less risk because there's no human that's going to go and copy and paste this to some resource and share it on the internet."

Design move: Let the AI decide when to remediate; keep how locked to a small set of deterministic, pre-approved API calls.

The Path to Autonomous Operations

Currently, Prophet Security closes "95 plus percent of our investigations automatically as false positive with all of that explainability and transparency. For that additional 5% of things that are malicious or that we have a question on, we think bringing in a human is still the right approach today just to have eyes on, validate the activity, confirm remediation actions and move on."

But Grant sees this evolving: "I think that's more of where the market is and less of where the product is. I think we're gonna move more and more to a state where only if you have an issue, a threat has been identified and it's been remediated in three minutes. This has all happened. You get a rollup report of what's been observed and your team isn't escalated to because the threat was mitigated. There's no further action to do."

The technology is ready, but operations teams may not be: "I actually don't think the operations teams are ready to be there, and that's okay. I think trust becomes the important element." This mirrors the broader theme of Grant's insights that successful AI SOC adoption in regulated or non-regulated environments ultimately comes down to building trust through transparency, explainability, and demonstrated consistency.

The Future: From Investigation to Security Program Management

Looking forward, Grant sees AI SOC evolving beyond individual alert triage: "Where I see AI SOC continuing to move is taking the groundwork out of SOC operations, the grunt work level tasks out of people's purview. Instead, operate more as a manager in the loop where I'm managing my detection program."

This includes capabilities like threat hunting: "How can I ask bigger hypothesis driven questions and have AI systems go and pull larger sets of data for me and start to find unidentified threats in my environment?"

It also encompasses detection management and posture: "How can I look over alerts that I've seen in the past, identify my gaps in line with like MITRE ATT&CK framework or similar and suggest tuning recommendations?"

The vision is for security professionals to shift from conducting individual investigations to orchestrating an AI-driven security program: "Have that orchestration happen by an army of agents and you're getting the feedback to make decisions on whether this is helpful or expending energy that's unneeded in your organization."

Grant's perspective: "I continue to think that AI SOC is going to shift to build security programs that I honestly dreamed of in past places."

RELATED RESOURCES

• MITRE ATT&CK Framework - Knowledge base of adversary tactics and techniques for detection planning

• NIST AI Risk Management Framework - Framework for managing AI system risks in regulated environments

• EU AI Act Compliance Resources - European Union AI regulation guidance

• FedRAMP Authorization for Cloud Services - Federal authorization program for cloud service offerings

Related Podcast Episodes 🎧

How to Build Trust in an AI SOC for Regulated Environments

Question for you? (Reply to this email)

 🤖 What would it take for you to let an AI SOC auto-close alerts?
Choose 1 or both or something else:

• A time threshold (e.g., “sub-5-minute investigations”),

• The minimum audit trail you’d need to sign off.

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!

Shilpi Bhattacharjee

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

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter Topic we cover - The IaC "Lift & Shift" Playbook: Migrating 200 Apps to Multi-Cloud (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

This week brings one of the biggest strategic moves in cloud security Palo Alto Networks’ $3.35B acquisition of Chronosphere alongside a global Cloudflare outage that disrupted major platforms like X, ChatGPT, and SaaS applications worldwide.

To help you navigate this rapidly shifting landscape, we bring insights from Matthias Mertens, Cloud Solution Architect at Swiss Insurance, supported by commentary from Ashish Rajan. Matthias led a high-speed migration of 200 applications from data centers into AWS and Azure, providing one of the most grounded, enterprise-proven blueprints for modernizing cloud architectures while maintaining regulatory compliance and operational resilience.

📰 TL;DR for Busy Readers

• Cloudflare Outage: Multi-CDN architectures are no longer optional.

• Palo Alto x Chronosphere: Observability + security are converging into unified data platforms.

• Zero-Day: Patch the actively exploited Windows Kernel EoP zero-day (CVE-2025-62215).

• Azure DDoS: 15.7 Tbps attack proves endpoint-level resilience matters.

• UK Cyber Bill: NIS2-level penalties + 24-hour reporting for critical incidents.

• Swiss Insurance Case Study (with Matthias Mertens): Terraform at scale, serverless modernization, and multi-cloud resilience.

📰 THIS WEEK'S SECURITY HEADLINES

1. 💰 Palo Alto Networks to Acquire Chronosphere for $3.35B, Driving Observability-Security Convergence

Palo Alto Networks announced an agreement to acquire Chronosphere, a cloud-native observability platform, for $3.35 billion. The deal aims to combine Chronosphere's massive telemetry pipeline (metrics, traces, logs) with Palo Alto Networks' AI-powered security automation platform, Cortex AgentiX, to move towards real-time, autonomous security and performance remediation.

Why It Matters: 

• CISOs must prepare for a world where security platforms require observability-scale data to effectively protect AI-driven, distributed applications. This acquisition forces a critical re-evaluation of siloed security data lakes and legacy tooling that cannot handle the scale or context required for modern cloud operations.

• This deal signals the formal convergence of security + observability + AI into unified platforms.

• Security data lakes built only for logs or SIEM-tier data will struggle to keep up with observability-scale telemetry (traces, metrics, distributed spans).

• CISOs must also re-evaluate:

  • future licensing lock-in

  • data gravity and ingestion patterns

  • where AI-driven detection should live

• This convergence directly relates to the multi-cloud complexity discussed by Matthias Mertens(in our expert insights in the following section). If Insurances had to manage two separate data pipelines (one for AWS, one for Azure, one for security, one for observability), the integration challenge would be geometrically harder. The push toward consolidated data and automation (like Terraform for IaC) is essential for solving complexity at scale.

 Read More: Palo Alto Networks Press Release, The Wall Street Journal

2. ☁️ Microsoft Azure Mitigates Record-Breaking 15.7 Tbps DDoS Attack

Microsoft reported successfully neutralizing a record-breaking, multi-vector Distributed Denial of Service (DDoS) attack against a single Azure endpoint in late October. The attack measured 15.72 Tbps and 3.64 billion packets per second (pps), believed to be the largest single attack ever recorded in the cloud, originating from the Aisuru botnet.

Why It Matters: 

• The event confirms the unprecedented scale of volumetric attacks. Cloud architects must validate their cloud provider's DDoS Protection tiers (Standard/Advanced) and assume that application-specific endpoints will be targeted. This underscores the need for robust, layered network controls (WAF, rate limiting) and stress testing to ensure service resilience against campaigns far exceeding historical benchmarks.

• DDoS scale has reached a point where per-endpoint resiliency matters as much as region-level protections.

• Azure’s mitigation worked, but your DDoS protection tier may not match the level required for modern botnets.

• Cloud architects should stress-test based on 10+ Tbps scenarios, not outdated benchmarks.

• Expert insight for distributed workloads across AWS and Azure help reduce single-cloud blast radius critical in a world where per-endpoint attacks can reach multi-terabit scale.

 Read More: Cybersecurity Dive

3. 🤖 Proofpoint Warns of Indirect Prompt Injection Hijacking Autonomous AI Agents

Researchers highlighted the growing threat of Indirect Prompt Injection, where malicious instructions are secretly embedded in external, untrusted data (like hidden text in a document). When an LLM-powered assistant or autonomous AI agent scans this data for context, it executes the hidden instruction, potentially leading to unauthorized actions like data exfiltration or internal system manipulation.

Why It Matters: 

• This is a foundational new risk for enterprises adopting AI-powered tools. Cloud security teams must recognize that the trust boundary is now between the model and the data it consumes. CISOs need to implement strict sandboxing and Least-Privilege principles for AI agents and enforce a human-in-the-loop requirement for any high-risk actions (e.g., modifying configuration or sending communications).The threat boundary now includes every dataset consumed by an LLM, not just “prompts.”

• Enterprises must implement:

  • sandboxed scanning pipelines

  • least-privileged agent roles

  • human approval for high-risk AI actions

•  Expert emphasis on separating regulated vs. non-regulated workloads mirrors the need to classify AI systems by privilege tiers to avoid accidental overexposure through agent automation.

 Read More: Proofpoint Blog, OWASP Gen AI Security Project 

4. 🇬🇧 UK's New Cyber Security and Resilience Bill Introduces NIS2-Level Penalties

The UK Government introduced the Cyber Security and Resilience Bill, proposing an overhaul of the existing NIS Regulations. The new legislation introduces new obligations for third-party tech suppliers and data centers, and grants regulators power to impose tougher, turnover-based financial penalties for serious breaches targeting critical infrastructure sectors. Harmful incidents must now be reported within 24 hours.

Why It Matters: 

• This marks a significant elevation of regulatory risk, mirroring the compliance pressure seen with NIS2 and GDPR. Accountability is shifting down the supply chain to MSPs, cloud platform teams, and data centers. CISOs must urgently review MSSP/MSP contracts, implement continuous compliance monitoring (e.g., using a CSPM), and validate that incident response plans can meet the new, aggressive 24-hour reporting deadline for harmful incidents.

• Enterprises must validate that suppliers and cloud partners meet new compliance minimums.

• Third-party risk management becomes a regulator-enforced requirement.

• Incident response plans should include:

  • accelerated reporting windows

  • automated evidence capture

  • vendor coordination mechanisms

• Experts shared that regulated workloads show why multi-cloud isolation and cloud-native services matter; different clouds may offer better compliance alignment for specific workloads.

 Read More: GOV.UK, Pinsent Masons

5. 🌐 Cloudflare Outage Disrupts Global Services, Highlights Configuration Risk

A major global outage at Cloudflare caused widespread service disruptions for platforms like X, ChatGPT, and many other applications. Cloudflare confirmed the cause was a latent bug in a bot mitigation service that triggered a crash after a routine configuration change caused a massive configuration file to propagate across their network. It was not a cyberattack.

Why It Matters: 

• This incident is a powerful reminder of third-party risk and resilience planning. Enterprise cloud architects must design for multi-CDN or multi-Cloud distribution for mission-critical applications to avoid single points of failure. The root cause of a configuration bug underscores the need for strict, automated change management and pre-deployment verification for core infrastructure as code (IaC) and network configuration files.

• Even trusted providers can become single points of failure.

• Multi-CDN strategies aren’t “nice-to-have” ; they're an operational necessity.

• IaC-based network configuration must include pre-deployment validation pipelines to prevent cascading outages

 Read More: Cloudflare Blog (Post-Mortem), The Guardian

🎯 Cloud Security Topic of the Week:

How Swiss Insurance Migrated 200 Apps in One Year Without Breaking the Business

This week’s featured topic distills Matthias Mertens’ experience executing a fast, regulated, multi-cloud migration for an enterprise with legacy workloads, tight deadlines, and compliance constraints.

What makes this discussion uniquely valuable is that Matthias had to migrate 200+ applications under real-world pressure, coordinating AWS and Azure adoption simultaneously while retiring costly data center leases.

The speed and scope of cloud migrations often compromise security architecture, leading to technical debt. The experience of Insurances in migrating 200 applications from legacy data centers to a multi-cloud AWS/Azure environment within one year provides a clear blueprint for prioritizing speed through automation while ensuring a secure foundation for future modernization..

Featured Experts This Week 🎤

• Matthias Mertens - Cloud Solution Architect, Helvetia Assurances Suisse

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

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

• Lift-and-Shift: The strategy of moving an application and its associated virtual machines or workloads from an on-premises environment (data center) to a cloud provider with minimal changes. This is often done to meet tight deadlines for data center exit.

• ECS Fargate: An AWS compute engine for Amazon Elastic Container Service (ECS) that allows you to run containers without having to provision, configure, or scale clusters of virtual machines. It is a serverless container service.

• Terraform Module: A reusable IaC package that ensures consistent networking, security, and configuration across hundreds of cloud accounts.

• CSPM (Cloud Security Posture Management): Automated tools that continuously monitor cloud environments (AWS, Azure, GCP) for configuration drift, misconfigurations, and compliance violations, directly supporting the regulatory needs.

• Multi-CDN Strategy: Using two or more CDN providers so no single outage takes your global applications offline.

This week's issue is sponsored by Dropzone

New independent research from Cloud Security Alliance proves AI SOC agents dramatically improve analyst performance.

In controlled testing with 148 security professionals using Dropzone AI, analysts achieved 22-29% higher accuracy, completed investigations 45-61% faster, and maintained superior quality even under fatigue.

The study reveals that 94% of participants viewed AI more positively after hands-on use. See the full benchmark results.

📤 Read the Full Study from CSA

💡Our Insights from this Practitioner 🔍

The Terraform "Lift & Shift" Playbook: Migrating 200 Apps to Multi-Cloud with Terraform (Full Episode here)

The primary driver for their cloud migration was a rapid data center exit due to license and lifecycle issues, necessitating a lift-and-shift approach for 200 applications within a year. This strategy prioritized speed and cost savings (ending leases) over immediate modernization. The security lessons lie in the enablers that made this massive, rapid, multi-cloud move possible and sustainable.

1. Start with Lift-and-Shift-Modernize Later

Matthias’ team moved 200 applications in one year. The only feasible approach? “We decided for a lift-and-shift approach… because we needed to empty our data center as fast as possible.” - Matthias Mertens

This echoes a pattern seen at companies like Airbnb and Capital One modernization succeeds faster when decoupled from high-pressure migrations.

2. Multi-Cloud Was Not a Luxury - It Was a Regulatory Requirement

The Company chose a multi-cloud architecture (AWS and Azure) for deliberate risk separation, both physical and legal. "And having different, uh, cloud providers also helps this. . . For regulation issues. Yeah, because it's good to have workloads separated again, physically and also legally." – Matthias Mertens

For senior leaders, this is a clear strategic decision to mitigate concentration risk, a lesson reinforced by the Cloudflare outage. When regulatory compliance is involved (as in the insurance sector), spreading workloads across providers helps satisfy requirements for resilience, sovereignty, and regional disaster recovery.

3. IaC Automation is the Only Way to Secure at Scale

The sheer scale of the 200-application migration meant that manual deployment was impossible. Insurances relied on the cloud-agnostic Terraform to manage infrastructure across both AWS and Azure.

• Automation of the Foundation: Terraform was used to automate the deployment of new cloud accounts and subscriptions. This is a critical security win, as it ensures all new cloud environments start with the necessary security controls: networking, IAM access management, and base policies. Matthias noted this allowed them to "create an account within minutes". This capability is essential for fast, secure enablement, reflecting the purpose of their Cloud Enablement team.

• The Power of Modules: Their partner used Terraform modules to describe and deploy the virtual machines for the lift-and-shift, ensuring consistency and integrating surrounding services like monitoring. This modular, repeatable approach made the 200-app migration feasible within the tight one-year deadline.

4. Serverless Containers for Modernizing Legacy Container Workloads

When faced with deploying a vendor-provided Docker image, Matthias's team rejected running it on a traditional Virtual Machine, stating: "it make no sense to run a Docker container on a virtual machine in production. Yeah, no way we would do that". They also lacked the resources to manage a Kubernetes (K8s) cluster for a single application.

Their solution was AWS ECS Fargate, a fully managed, serverless container service.

"We use ECS Fargate... And with this one, we can run containers without having to manage any underlying infrastructure." – Matthias Mertens

This decision provides key security takeaways:

• Reduced Attack Surface: By leveraging Fargate, the security team offloads the responsibility of patching and managing the underlying host operating system from the Cloud Shared Responsibility Model to AWS.

• Focus on Application Security: The team could then focus on securing the surrounding services essential for production-grade deployment: load balancing, certificates, secret storage, and logging. For security leaders, this proves that serverless technologies enable SecOps to shift focus from infrastructure patching to the higher-value tasks of application governance and data protection.

5. Choose the Right Partner-Don’t Self-Inflict Risk

Matthias is straightforward about this: “You do not do this kind of project just… ‘let’s try.’ Find a partner with experience.”

This is a hallmark of mature cloud programs at companies like Block, Atlassian, and Shopify, all of whom lean heavily on expert integrators during major transitions.

Actionable Takeaways for Senior Cloud Professionals:

1. Mandate Cloud-Agnostic IaC: Ensure your Cloud Enablement team uses tools like Terraform for provisioning cloud accounts and subscriptions. This enforces a secure baseline across multi-cloud environments from day one, which is vital for compliance with new regulations like the UK Bill.

2. Use Serverless Containers Strategically: Avoid placing containers on managed VMs to reduce operational overhead and attack surface. Leverage Fargate/Azure Container Apps for isolated workloads to dedicate security resources to the application layer (WAF, IAM, Secrets Manager).

Embed Security in Migration Planning: As Ashish Rajan summarized, the key is to prioritize and "figure out what applications are suitable to be deployed in the first place" and assess the risks, even in a block move scenario.

RELATED RESOURCES

• OWASP Top 10 for LLMs

Related Podcast Episodes 🎧

The Terraform "Lift & Shift" Playbook: Migrating 200 Apps to Multi-Cloud with Terraform

Question for you? (Reply to this email)

 🤖 Is your cloud architecture resilient against a Cloudflare-scale outage, or are you still relying on a single CDN?

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!

Shilpi Bhattacharjee

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

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter Topic we cover - Securing AI Agents in Production: From LLM Applications to Autonomous Systems (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.

As AI agents move from experimentation to production deployments, security teams face an entirely new threat landscape, one where traditional monitoring falls short and autonomous systems create "covert channels" we never anticipated. This week, we're joined by Mohan Kumar, Production Security Lead at Box with over 14 years in cybersecurity, who breaks down the critical security challenges of agentic AI and shares practical threat modeling approaches for organizations deploying autonomous agents.

Meanwhile, the security news cycle has been dominated by critical infrastructure vulnerabilities: three high-severity runC container escape flaws affecting every major cloud provider, active exploitation of Cisco firewall zero-days, and a China-linked APT breach of the U.S. Congressional Budget Office.

📰 TL;DR for Busy Readers

• Container breakout risk: Patch runC CVEs immediately affects Docker, Kubernetes across AWS, Azure, GCP

• AI agents ≠ LLMs: Autonomous agents create new attack surfaces through dynamic tool use and memory poisoning

• Active exploitation: Cisco ASA/FTD zero-days now weaponized for both RCE and DoS attacks

• Nation-state escalation: Chinese APT Silk Typhoon breached Congressional Budget Office systems

• Identity remains critical: Granular access controls and session isolation are foundational for AI agent security

📰 THIS WEEK'S SECURITY HEADLINES

1. Bugcrowd Acquires Mayhem Security for AI-Driven Offensive Security Testing

What Happened: Bugcrowd announced the acquisition of Mayhem Security on November 4, 2025, adding AI-driven offensive security testing capabilities to its crowdsourced vulnerability testing platform. The acquisition aims to augment human security researchers with AI-powered automation for discovering and exploiting vulnerabilities at scale.

Why This Matters: This M&A signals a significant shift in the offensive security market toward AI-augmented testing. As AI agents become more sophisticated, security testing must evolve beyond human-only approaches. The combination of crowdsourced human expertise with AI-driven automation could dramatically increase vulnerability discovery rates and testing coverage. Security teams should monitor how this affects the bug bounty landscape and consider whether their vulnerability disclosure programs are prepared for AI-augmented researcher capabilities.

• Signals a shift toward AI-augmented bug bounties and offensive testing

• Increases the volume and sophistication of findings your teams will see

• Forces security orgs to ask: “Are we ready for researchers who come with AI agents out of the box?”

Read More: BugCrowd Press Release

2. Critical runC Container Vulnerabilities Enable Escape Across All Major Cloud Providers

What Happened: Three high-severity vulnerabilities (CVE-2025-31133, CVE-2025-52565, CVE-2025-52881) were disclosed in runC, the underlying container runtime powering Docker, Kubernetes, and containerized workloads across AWS, Azure, and Google Cloud. These flaws enable container escape attacks, allowing attackers to break out of isolated containers and access the host system. AWS, Azure, and GCP all issued security bulletins with patches on November 5, 2025.

Why This Matters: Container escape represents one of the most serious threats in cloud-native environments. These vulnerabilities affect the foundational layer of container orchestration, meaning any organization running containerized workloads is potentially at risk. The swift disclosure and patching demonstrates the maturity of the container security ecosystem, but organizations must prioritize immediate patching across their Kubernetes clusters and container hosts. This isn't just a Kubernetes problem any Docker-based deployment is vulnerable.

• This is a foundational runtime issue, not “just” a Kubernetes misconfig

• Any Docker-based deployment (including CI runners and self-hosted services) is in scope

• The window between “patch available” and “weaponised PoC” is typically measured in days

Read More: Sysdig Threat Research, AWS Security Bulletin

3. Google Mandiant Exposes Ongoing Gladinet Triofox Zero-Day Exploitation

What Happened: Google Mandiant revealed that threat actor UNC6485 has been exploiting a critical authentication bypass vulnerability (CVE-2025-12480) in Gladinet Triofox file-sharing platform since August 2025. This marks the third Triofox vulnerability exploited in 2025, indicating sustained attacker interest in the platform. The flaw enables authenticated remote code execution, providing attackers with deep access to enterprise file-sharing infrastructure.

Why This Matters: Enterprise file-sharing platforms are treasure troves of sensitive data and often have broad access to cloud storage systems. The sustained exploitation since August suggests this may be part of a broader campaign targeting file-sharing infrastructure. Organizations using Triofox or similar platforms should audit access logs, verify patch levels, and review authentication mechanisms. The pattern of multiple exploited vulnerabilities in one platform within a year raises questions about the vendor's security posture.

• File-sharing platforms sit close to crown-jewel data and often bridge on-prem and cloud

• Three exploited vulns in a year suggest a structural maturity problem at the vendor

• Auth bypass + RCE = full platform takeover and stealthy data exfil

Read More: The Hacker News, Google Mandiant Threat Intelligence Report

4. Microsoft Publishes Azure Blob Storage Attack Chain Analysis with AI-Powered Detection

What Happened: Microsoft released detailed analysis of attack chains targeting Azure Blob Storage, accompanied by new AI-powered detection capabilities in Defender XDR. The guidance covers cloud misconfiguration exploitation, unauthorized access patterns, and lateral movement techniques specific to Azure storage infrastructure. The updates enhance Microsoft's ability to detect and respond to cloud storage threats using machine learning models.

Why This Matters: Cloud storage is often the final destination for data exfiltration campaigns and frequently suffers from misconfiguration issues. Microsoft's investment in AI-powered detection for storage attack chains reflects the evolving threat landscape where traditional signature-based detection falls short. Security teams should review their Azure Blob Storage configurations against Microsoft's attack chain analysis, enable Defender XDR enhancements, and ensure storage access logging feeds into their SIEM. This is particularly relevant for organizations storing AI/ML training data in cloud object storage.

• Blob/S3/GCS are often the final stop for data exfil

• Storage buckets also underpin AI/ML training data – poisoning and theft risks are high

• AI-assisted detections can help close blind spots around subtle access patterns

Read More: Microsoft Security Blog

5. Google Cloud Forecasts Surge in AI Agent Exploitation and Prompt Injection for 2026

What Happened: Google Cloud released its Cybersecurity Forecast 2026, predicting a significant increase in prompt injection attacks, AI agent exploitation, and cyber-physical attacks targeting European infrastructure. The report emphasizes how adversaries are weaponizing AI capabilities and developing new attack vectors specific to autonomous agent systems. Google's threat intelligence team identifies AI agent security as a critical emerging risk for 2026.

Why This Matters: This forward-looking intelligence directly connects to our main topic this week AI agent security. Google's prediction isn't speculative; it's based on observed threat actor behavior and the rapid adoption of AI agents in enterprise environments. As Mohan Kumar discusses in detail below, AI agents introduce fundamentally new attack surfaces including memory poisoning and tool misuse. Organizations deploying or planning to deploy AI agents should incorporate these threat predictions into their 2026 security roadmaps and investment decisions.

• Attackers already experiment with indirect prompt injection into RAG pipelines

• Early agent-to-agent abuse patterns are emerging

• Enterprises are rolling out agents faster than guardrails

Read More: Google Cloud Security Blog

🎯 Cloud Security Topic of the Week:

Securing AI Agents in Production: From LLM Applications to Autonomous Systems

The transition from single-shot LLM applications to goal-driven AI agents represents one of the most significant architectural shifts in cloud security since the move to containers.

Unlike traditional LLM applications that process a prompt and return a response, AI agents operate autonomously thinking, acting, observing, and adapting their behavior in runtime. They connect to external tools, maintain memory across sessions, communicate with other agents, and make decisions without human intervention. This autonomy creates entirely new attack surfaces that traditional security controls weren't designed to address.

Featured Experts This Week 🎤

• Mohan Kumar - Production Security Lead, Box

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

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

• AI Agent vs. LLM Application: An LLM application provides one-shot responses to prompts (like ChatGPT's basic chat interface). An AI agent is dynamic and goal-driven, following a think-act-observe cycle, accessing external tools, maintaining memory, and making autonomous decisions to achieve objectives.

• Memory Poisoning: An attack technique where adversaries inject malicious information into an AI agent's long-term, short-term, or entity memory stores. Since agents trust their own memory when making decisions, poisoned memory can alter future behaviors and decisions without the agent's awareness.

• Tool Misuse: Exploitation of an AI agent's access to external tools and APIs. Even legitimate tools (like calendar APIs or file systems) can be abused if agents don't have proper permission scoping and validation.

• MCP (Model Context Protocol): An emerging standard for connecting AI agents to external tools and services. When configured incorrectly (particularly the "sender identification" flag), MCP can enable attackers to impersonate trusted users.

• Agentic Orchestration: The central coordination layer that manages task delegation between multiple specialized AI agents, similar to how Kubernetes orchestrates containers. This layer is becoming a critical security control point.

• Maestro Framework: Cloud Security Alliance's seven-layer threat modeling framework specifically designed for agentic AI systems, covering foundation models, data operations, agent frameworks, infrastructure, observability, security controls, and the agent ecosystem..

This week's issue is sponsored by Brinqa

What If You Could See Risk Differently?

On Nov 19, Brinqa experts will show how a shift in perspective, adding context, can change everything about how you prioritize risk. Fast-paced, real, and surprisingly fun.

📤 Register here

💡Our Insights from this Practitioner 🔍

Threat Modeling the AI Agent: Architecture, Threats & Monitoring (Full Episode here)

The Fundamental Shift: Why AI Agents Aren't Just Better LLMs

Mohan Kumar opens with a critical distinction that many security teams miss: "A typical LLM application is different than an AI agent. Think of more LLM applications as a one shot response to a prompt... it cannot make autonomous decisions or any actions on our behalf. But whereas an agent in contrast is pretty dynamic. They're goal-driven."

This isn't semantic nitpicking, it's the foundation of an entirely new security paradigm. Traditional LLM applications operate within bounded interactions: you send a prompt, the model processes it, you receive a response. The attack surface is relatively contained. AI agents, however, operate in a continuous think-act-observe loop, adapting their behavior in runtime, connecting to external tools, and persisting context across sessions.

Kumar explains the three-step process that defines agent behavior: "You give some query to the agent and then the agent thinks and then acts, and then does some observation and how things are going." This seemingly simple loop creates profound security implications. Each "act" phase might involve calling external APIs, accessing databases, modifying files, or communicating with other agents all based on dynamic runtime decisions rather than predetermined workflows.

For enterprise security architects, this means rethinking threat models from the ground up. You're no longer securing a stateless API endpoint; you're securing an autonomous system that makes real-time decisions about what tools to use, what data to access, and how to achieve goals you've only described in natural language.

The Top Three AI Agent Threats Enterprise Teams Must Address

Kumar identifies three critical threat categories that keep him up at night, starting with what he considers the highest risk:

1. Memory Poisoning and Context Manipulation

"Memory poisoning... involves exploiting the three kinds of memory that I laid out [long-term, short-term, and entity memory]. And the context manipulation involves the agent's context window," Kumar explains. The attack vector is particularly insidious: "Agent typically trust its memory, because it's its own memory... if its own memory is being compromised, then, these agents think, hey, you know, I'm just doing the job that I'm intended to do. But the goal or the context itself has been changed."

This is fundamentally different from traditional injection attacks. You're not exploiting input validation, you're poisoning the agent's knowledge base so it believes it's operating correctly while actually executing attacker-defined objectives. Kumar points to indirect prompt injection as the primary vector: malicious information inserted into RAG (Retrieval Augmented Generation) pipelines that the agent consumes as trusted context.

For production deployments, this demands implementing memory content validation, session isolation, and robust authentication specifically for memory access controls that don't exist in traditional application security frameworks.

2. Tool Misuse Through Inadequate Permission Scoping

Kumar uses a practical example to illustrate the risk: "I rely on a copilot that has access to calendar tool to book my meetings. What if an attacker are able to abuse this processes and misuse the tools here. The tools is a calendar. So instead of sending a regular calendar invite... we could misuse the same Calendar tool to exfiltrate data."

The problem isn't that the calendar API is vulnerable, it's that the agent has legitimate access to it for one purpose (scheduling meetings) but lacks the contextual boundaries to prevent abuse for another purpose (data exfiltration). Traditional API security focused on authentication and authorization at the endpoint level. AI agents require contextual authorization understanding not just who is calling the API, but why and whether that aligns with the agent's intended goal.

Kumar's mitigation guidance is clear: "We have to scope like a minimal scope with short duration as much as possible. And then if there is like high risk action that has to be like a human in the loop involved." This represents a significant shift from "set it and forget it" API keys to dynamic, context-aware permission grants with built-in time limits.

3. Privilege Compromise Through Misconfiguration

While this threat applies broadly across security domains, Kumar emphasizes its particular relevance to AI agents: "This privileged compromise will be a huge threat... mostly through the misconfiguration in the agent. An attacker executes queries and RAG databases to access files and data that it shouldn't be able to access."

The challenge here is that AI agents, by their nature, need broader access than traditional applications to be useful. An agent designed to help with data analysis might legitimately need read access to many databases. The security control isn't binary (access or no access) it's about granular, conditional access that adapts based on the specific task and context.

The Monitoring Gap: Traditional Tools Won't Cut It

When asked how security teams can detect these new threats, Kumar's response underscores a hard truth: "Traditional tooling today is not gonna fully flag these all the behaviors. That's why we need more of these either in-house or from vendors that can dynamically listen and observe the actions and flag the risky operations."

The fundamental challenge is that AI agents operate faster than human review cycles and make decisions in ways that don't align with traditional signature-based detection. Kumar suggests an innovative approach: "We could have some secondary agent who can help in monitoring that can follow the behaviors... over the time there has to be some baseline said, hey, for these kind of goal-driven actions, these are the new norm."

This represents AI-powered security for AI systems using one agent to monitor another's behavior against learned baselines. Kumar emphasizes the need for "granular access control, which means getting into more granular, as much as possible, and when the identity shift, those log has to be in place."

For production operations, this translates to:

• Implementing comprehensive logging of all agent actions, tool calls, and identity shifts

• Taking regular snapshots of agent memory for forensic analysis

• Establishing behavioral baselines for normal agent operations

• Deploying secondary monitoring agents to detect anomalies in real-time

• Ensuring human-in-the-loop authorization for high-risk actions

The Architecture of AI Agent Security: Six Critical Components

Kumar breaks down AI agent architecture into six components that security teams must threat model:

1. Role Playing: The specialized function the agent is trained to perform

2. Focus: The specific goal or objective driving agent decisions

3. Tools: External APIs and services the agent can access

4. Cooperation: How agents communicate and coordinate with each other

5. Guardrails: Both operational and security-focused controls

6. Memory: Long-term, short-term, and entity-specific information stores

Each component presents unique security considerations. Kumar emphasizes that "when we do threat model these agents, there are various frameworks that can be adopted. OWASP Top 10 LLM applications and Agent AI is a great list. And then Agentic AI threat modeling framework, which is dubbed as Maestro by the Cloud Security Alliance, is a great one."

The Maestro framework provides a seven-layer approach covering foundation models, data operations, agent frameworks, deployment infrastructure, evaluation and observability, security and compliance, and the broader agent ecosystem. Kumar stresses this systematic approach: "Security teams can use that as a blueprint to systematically analyze where controls are needed."

The Model-Agnostic Reality of AI Vulnerabilities

A common misconception is that premium AI providers like OpenAI and Anthropic are immune to the vulnerabilities affecting open-source models. Kumar dispels this myth: "I would say it's vendor agnostic at this point. All the models out there can spill credential leaks... any model is susceptible for those kind of tricks."

He explains the fundamental vulnerability through the "Grandma Trick" example, a prompt engineering technique where attackers manipulate the model by framing harmful requests as benign storytelling. "Models are generally non-deterministic in nature, so no matter if it's OpenAI model or Claude model, most of them because there are few guardrails at the model layer but they're just basic... it's easy to trick those models in a way they can get into those bias nature and follow the things that you would ask for."

This has critical implications for enterprise deployment decisions. You can't simply outsource AI agent security by choosing premium providers you must implement controls at the orchestration, data, and tool-access layers regardless of which foundation model you're using.

The Path Forward: Three Layers of Security Evolution

Looking ahead, Kumar predicts security improvements will concentrate in three critical layers:

The Orchestration Layer

"There will be a lot of guardrails which will be introduced because these orchestrations are the central brain that delegate tasks... perhaps inspired by Kubernetes in cloud. Kubernetes started adding lot of security features once it became a standard orchestration. Similarly, agent orchestration platforms will come up with more security features."

The Data Layer

"We talked about memory poisoning and how can we ensure this memory is not poisoned... that boils down to verifying the trust source or the source information. We might be able to see better those detections if those memories indeed poisoned, if the knowledge base is being poisoned."

The Interface Layer

"More from the UI the user will be able to see more of these under-hood actions visibly so that they can intervene if needed... more transparency are, hey, you know, ask me before doing X, Y, Z kind of interface."

This evolution mirrors the maturity curve we saw with container security starting with minimal controls and gradually building comprehensive security frameworks as the technology moved to production at scale.

Practical Implementation Guidance for Security Leaders

Based on Kumar's insights, security teams deploying AI agents should prioritize these immediate actions:

1. Implement Memory Protection Controls

• Validate all data entering agent memory stores

• Isolate sessions to prevent cross-contamination

• Implement authentication specifically for memory access

• Take regular snapshots for forensic analysis

2. Enforce Granular, Time-Limited Permissions

• Replace static API keys with dynamic, context-aware grants

• Implement minimum necessary scope for each tool

• Set automatic expiration on permissions

• Require human approval for high-risk actions

3. Deploy Multi-Layer Monitoring

• Log all agent actions, tool calls, and identity shifts

• Establish behavioral baselines for normal operations

• Consider deploying monitoring agents to watch production agents

• Integrate agent logs into existing SIEM platforms

4. Adopt Systematic Threat Modeling

• Use frameworks like CSA's Maestro or OWASP Top 10 for LLM Applications

• Threat model all six agent architecture components (role, focus, tools, cooperation, guardrails, memory)

• Don't assume premium AI providers eliminate security risks

• Plan for model-agnostic security controls

5. Prepare for the Evolution

• Invest in orchestration-layer security as it matures

• Develop capabilities for detecting poisoned memory and knowledge bases

• Design interfaces that provide visibility into agent decision-making

• Build human-in-the-loop workflows for critical operations

The transition to AI-augmented operations isn't optional; organizations that don't deploy these capabilities will fall behind competitors who do. But rushing into production without addressing these fundamental security concerns creates risks that traditional security tools can't detect or prevent. Kumar's guidance provides a roadmap for navigating this transformation strategically.

RELATED RESOURCES

• OWASP Top 10 for LLM Applications

• Cloud Security Alliance Maestro Framework for Agentic AI Threat Modeling

• Anthropic Research on AI Agent Security

• AWS Container Security Best Practices

• Sysdig Container Escape Techniques

• Kubernetes Security Hardening Guide

• Google Mandiant Threat Reports

• CrowdStrike Threat Intelligence

• Microsoft Defender for Cloud Blog

• Azure Blob Storage Security Best Practices

• AWS S3 Security Configuration Guide

Related Podcast Episodes 🎧

Threat Modeling he AI Agent: Architecture, Threats & Monitoring

Question for you? (Reply to this email)

 🤖 Are your AI agents auditable? (Yes/No/Maybe)
Could you reconstruct their decision chain after a security incident?

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!

Shilpi Bhattacharjee

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

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter Topic we cover - Breaking Down Silos: How AI Security Demands AppSec and CloudSec Convergence (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

As AI reshapes application development and cloud security at an unprecedented pace, traditional security boundaries are dissolving. This week, we examine critical vulnerabilities in collaboration platforms that 320 million users depend on daily, alongside the emergence of AI-powered polymorphic malware that can dynamically evade detection. More importantly, we bring you a candid conversation with Tejas Dakve (Application Security Leader at Bloomberg Industry Group), Aditya Patel (Security Architect at a major cloud provider), and Ashish Rajan about how enterprises are breaking down the historical silos between application security and cloud security teams to address AI-native threats that refuse to respect traditional organizational boundaries.

The key insight: security teams can no longer operate as gatekeepers. As Tejas puts it, teams must transform "from department of no to department of safe yes" while building guardrails that enable rather than obstruct innovation.

📰 TL;DR for Busy Readers

• Wiz x Google: DOJ antitrust cleared; expect deeper GCP ↔ Wiz coupling. 

• Teams flaws: Silent edits + spoofed identities → zero-trust verification for high-stakes comms.

• Identity & Collab: Microsoft Teams spoofing/vulns mean treat chat as authoritative systems of record with controls.

• M&A: Dataminr buys ThreatConnect ($290M) → external signals + internal intel.

• AI-polymorphic malware: “PROMPTFLUX” queries Gemini for JIT obfuscation → behavior over signatures.

• Supply chain / Dev: React Native CLI RCE (CVE-2025-11953) → protect dev laptops & CI

• AppSec + CloudSec convergence required for AI security T-shaped engineers with cross-functional knowledge becoming the new baseline

• Paved road solutions work: provide secure defaults and automated approval workflows instead of manual security gates

• Agentic AI shifts focus from conversational threats to IAM policies and action-based permissions across cloud environments

📰 THIS WEEK'S SECURITY HEADLINES

1. DOJ clears Alphabet’s $32B acquisition of Wiz (antitrust review)

What Happened

The U.S. Department of Justice(DOJ) approved Alphabet/Google's planned $32B purchase of Wiz, removing the last major regulatory hurdle. This is the largest security deal on record and cements Google's push to own more of the enterprise cloud security stack.

Why it matters (practitioner take):

• Expect tighter Wiz ↔ Google Cloud integrations (posture/CNAPP/AI-assisted detections).

• Re-check vendor concentration and dual-vendor exits in FY26 plans.

Do this now

• Board brief: “Wiz x Google—integration paths and lock-in risk.”

• Risk register: Add vendor-exit play + multi-cloud coverage test.

• Red team tasker: Simulate GCP-native ↔ Wiz control gaps during M&A integration.

Read More: Reuters

2. Microsoft Teams vulns allow message manipulation & exec impersonation

What happened: Check Point disclosed four Teams issues enabling silent edits, spoofed identities, and forged call/caller notifications; one tracked as CVE-2024-38197; fixes landed through 2024–Oct 2025.

Why it matters: Teams is an authoritative system of record for many workflows (approvals/IR/chatOps). Silent history edits + spoofed senders undermine financial approvals, IR channels, and change control.

Do this now

• Policy: Treat chat like code → require out-of-band verification for $$/secrets.

• Controls: Inline DLP/Malware scanning for Teams file/message payloads.

• Detection: Alert on retroactive edits in high-risk channels (finance/IR).

• Admin: Confirm October 2025 client/service updates are deployed org-wide.

Read More: Check Point Research, The Hacker News

3. AI-powered malware (“PROMPTFLUX”) performs JIT self-obfuscation

What happened: Google Threat Intelligence tracked PROMPTFLUX, an experimental VBScript dropper that calls Gemini to generate new evasion code at runtime. Also notes other families abusing LLMs.

Why it matters: First publicly documented use of LLM JIT obfuscation static signatures will lag; behavioral + API telemetry becomes table stakes.

Do this now

• EDR: Prioritize behavioral rules (script child-process anomalies, LOLBins).

• Egress: Monitor/alert on unexpected LLM API calls from endpoints/servers.

• Hunt: Search for metamorphic VBS with periodic network beacons to AI APIs.

Background: Google’s prior work on Gemini for large-scale malware analysis

Read More: The Hacker News, Google Cloud Blog

4. Major M&A: Dataminr Acquires ThreatConnect for $290M

What happened: Dataminr combines external signals with ThreatConnect’s intel/TIP; SecurityWeek logged 45 cyber M&A deals in Oct 2025; Veeam–Securiti also announced.

Why it matters: Expect agentic correlation (external+internal) and recommendations in SOC stacks; fewer point tools, more platform workflows.

Do this now

• SOC roadmap: Define intel→detection→response data flows before tooling.

• Contracting: Tie SLAs to false-positive budgets + MTTD improvements.

• Privacy: Re-review data residency for external signal ingestion.

Read More: SecurityWeek

5. Critical React Native CLI Vulnerability Exposes 2 Million Weekly Users

What happened: JFrog disclosed command injection in @react-native-community/cli-server-api; Metro dev server binds to all interfaces by default, making a local bug remotely exploitable. Affects 4.8.0 → <20.0.0; fixed in 20.0.0.

Why it matters: Developer laptops and CI agents become cloud pivots; supply chain risk.

Do this now

• Patch: Pin @react-native-community/cli-server-api ≥ 20.0.0 (every repo).

• Network: Isolate dev subnets; block Metro ports from WAN/LAN cross-talk.

• CI: Rotate tokens/SSH keys; scan for indicators of compromise on dev hosts.

Read More: SecurityWeek, JFrog

🎯 Cloud Security Topic of the Week:

Breaking Down Silos: How AI Security Demands AppSec and CloudSec Convergence

The rise of AI-native applications is forcing a fundamental reckoning with how security teams are structured and operate. For years, application security and cloud security have existed as distinct disciplines with separate tools, threat models, and areas of responsibility. But as AI becomes deeply embedded into both application logic and cloud infrastructure, this separation is no longer tenable.

The challenge: Agentic AI crosses app logic, IAM, data, and multi-cloud APIs two separate threat models that interlock.

Field lessons (Bloomberg + Cloud Architects):

• Move from gates → guardrails: pre-approved “paved road” paths with automated checks.

• Treat agents like non-human workloads: identity-first design; least-privilege scopes.

• Continuous threat modeling: automated prompts + human in loop; update as threats evolve.

• Build T-shaped teams: deep specialty + broad fluency (AppSec understands IAM; CloudSec groks prompt/LLM issues).

Starter blueprint

• Org: Cross-functional pods (AppSec, CloudSec, Data, Platform, Compliance, Product).

• Identity: Agent roles with action-scoped permissions; rotate secrets from a vault; no static MFA hacks.

• Pipelines: Governance-as-code checks + AI eval gates; approvals in hours, not weeks.

• Ops: AISPM mindset assets: datasets, models, agents, embeddings, endpoints.

Featured Experts This Week 🎤

• Tejas Dakve - Senior Manager Application Security, Bloomberg Industry Group

• Aditya Patel - Security Architect, 

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

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

• Agentic AI: LLMs that act (APIs/emails/resources), not just chat.

• T-Shaped Engineer: Deep in one, conversant across adjacent domains.

• Paved Road: Secure-by-default patterns + auto approvals.

• JIT AI Malware: Malware that calls LLMs at runtime for new obfuscation.

• CVE-2025-11953: React Native CLI RCE via Metro server exposure.

This week's issue is sponsored by Dropzone

New independent research from Cloud Security Alliance proves AI SOC agents dramatically improve analyst performance.

In controlled testing with 148 security professionals using Dropzone AI, analysts achieved 22-29% higher accuracy, completed investigations 45-61% faster, and maintained superior quality even under fatigue.

The study reveals that 94% of participants viewed AI more positively after hands-on use. See the full benchmark results.

📤 Read the Full Study from CSA

💡Our Insights from this Practitioner 🔍

AI is already breaking the Silos Between AppSec & CloudSec(Full Episode here)

The Volume Problem: AI-Generated Code Overwhelms Traditional Security Gates

The conversation began with a stark reality check about the scale challenge facing security teams. As Tejas Dakve explains, "The speed of writing the code and the volume of code that security teams have to secure is unparallel. It's absolutely impossible to use our traditional security gates where security teams used to be a gate checker."

This isn't hyperbole. When developers leverage AI coding assistants like GitHub Copilot or Cursor, they're producing code at 3-5x their previous velocity. But security teams haven't scaled proportionally. The math simply doesn't work anymore for manual review processes.

Aditya Patel reinforces this point with a practical example: "The problem is now we have to acknowledge the fact that new attacks are being introduced or new sort of architectural considerations that need to be there for multi-agent or Agentic workflows." Traditional threat modeling frameworks like STRIDE or PASTA don't address prompt injection, data poisoning, or model theft threats that require specialized knowledge.

The solution both practitioners advocate? Automated, continuous threat modeling paired with "paved road" solutions that provide secure defaults developers can adopt without friction.

From "Department of No" to "Department of Safe Yes"

Perhaps the most striking cultural insight came from Tejas Dakve's reframing of security's role: "Security leaders we have traditionally been recognized as a department of no. I think we have to change our mindset from department of no to department of safe yes."

What does "safe yes" look like in practice? It means building guardrails instead of gates. When a developer wants to use an open-Read More LLM model from Hugging Face, the old model required a two-week security review. The new model involves an automated request workflow that:

1. Triggers automated scans for LLM-specific vulnerabilities

2. Evaluates model resiliency and hallucination risks

3. Routes to compliance and legal for licensing review

4. Provides approval within hours, not weeks

As Tejas emphasizes, "We have to take security into the AI lifecycle the way we took security and baked it into CI/CD pipelines." This isn't about lowering security standards it's about automating the evaluation and approval processes so velocity doesn't suffer while maintaining rigor.

The Silo Problem: When AppSec and CloudSec Can't See the Full Picture

One of the most illuminating moments in the discussion revealed how organizational silos create blind spots for AI security. Tejas described a common scenario: "There is a gap between application security and cloud security when it comes to agentic AI, because AppSec cares about source code, logic, things like that. But we don't always have visibility into roles, permissions, policies associated with that agent."

This is where the traditional division breaks down. An AppSec team threat modeling an AI agent might focus on prompt injection and output validation critical concerns, but incomplete. Meanwhile, the cloud security team owns IAM policies but may not understand what actions the agent is designed to perform or what data it accesses.

Aditya Patel offers a concrete distinction: "For all practical purposes, these are two different threat models. There's a threat model for the underlying platform or the cloud, and then there's a threat model for the application itself."

The solution? Cross-functional pods that bring together AppSec, CloudSec, data security, compliance, and product engineering. As Tejas notes, "These teams need to come together, and only then we can have some sort of AI governance within an organization before Shadow AI starts taking place everywhere."

Agentic AI: The Authentication Challenge Nobody Talks About

When the conversation turned to agentic workflows, Aditya Patel highlighted a technical challenge that many organizations haven't fully grasped. Traditional authentication mechanisms assume a human user. But what happens when an AI agent needs to authenticate across five or ten different endpoints, some internal and some external?

"For authentication, you can authenticate using something you know and something you have," Aditya explains. "For an agent, it needs to pass a secret password or certificate to authenticate itself. Hopefully it's not hard coded. So hopefully there's an API call where it goes to a vault or a secrets manager and fetches the credential."

But it gets more complex: "What about if there is an MFA? Then it needs to have a way of getting the OTPs from somewhere. And one more thing you need to keep in mind is bot detection or CAPTCHAs. It needs to solve CAPTCHAs and because most things like Akamai or CloudFront or Cloudflare, they have automated bot detection."

This technical reality underscores why Tejas emphasizes IAM policies as the critical security control for agentic AI: "With agentic AI, the IAM role policies, permissions associated with that agent, becomes a very important factor. My focus would be more on what are IAM roles and permissions and policies associated with it. What can go wrong if that agent gets controlled by some malicious actors?"

The Skills Evolution: T-Shaped Engineers and Security Generalists

Both practitioners were candid about how the expectations for security professionals have evolved and how overwhelming it can feel. Tejas laid out the progression: "Before introduction of AI, security engineers were expected to know core AppSec concepts like threat modeling, web penetration testing, mobile related threats. Then came along cloud security 10 years ago. Then in between came DevSecOps. Couple of years back, AI came into the limelight."

The solution isn't to become a "jack of all trades" both emphasized the importance of depth. Instead, they advocate for "T-shaped engineers": professionals with deep expertise in one domain (the vertical bar of the "T") but broad understanding across multiple areas (the horizontal bar).

Aditya drew an analogy from David Epstein's book "Range," contrasting Tiger Woods (who played only golf from age two) with Roger Federer (who played everything before focusing on tennis as a teenager). "There are two types of environments," Aditya explains. "One is like a very deterministic environment like chess or music, or even golf. But the other one is more like a non-deterministic environment: tennis or science, arts, or cybersecurity. If you have the multidisciplinary background training there, that helps."

The practical advice for security leaders? Create paths for cross-functional learning and reward breadth as well as depth. Tejas adds, "We have to develop T-shaped engineers. We want security engineers who are experts in their own domain, but they should also be able to connect dots between various different sections."

Automated Threat Modeling: The GitHub Copilot Example

To illustrate why periodic threat modeling matters for AI systems, Tejas offered a compelling case study: "GitHub Copilot when it got rolled out, almost every organization did some sort of threat modeling before they introduced it into their development ecosystem. Then a few months back, a researcher released a paper saying that GitHub Copilot can be tricked to introduce backdoor into your product."

This emergence of new threats makes previous threat models obsolete. The solution? Automated, continuous threat modeling that evolves with the threat landscape. And yes, using AI for this purpose. As Aditya suggests: "Use AI for it, right? You can just ask your chatbot to give you top 10 threats. This is my architecture, these are my business cases, use cases, technical use cases. Give me what threats to expect."

But both practitioners emphasized a critical caveat: human expertise remains essential. Aditya warns, "I don't think we are at a point where we can completely rely on these systems. There has to be a human in the loop from a security point of view." The term he uses for AI-generated outputs is memorable: "These chatbots are dreaming up the internet. They have read the internet, and now they are word by word, they're dreaming up things."

Prioritization at Scale: The Quality Over Quantity Shift

With thousands of vulnerabilities flooding security dashboards, how do teams decide what to fix? Tejas advocates for a pipeline approach: "Accumulate all vulnerabilities onto one single platform, a posture management type solution. Create a pipeline from all vulnerabilities to just top 5% or 1% of vulnerabilities that matter to you the most."

The factors in this pipeline include:

• Applicable and reachable vulnerabilities

• EPSS scores and CISA KEV advisories

• Internet-facing versus internal-only

• Proof of concept availability

• Actual exploitation paths

The mindset shift is crucial: "Your CTO is not going to care about the fact that you fixed a hundred vulnerabilities. What if half of those vulnerabilities are internal only or have no exploitation path? Fix only five vulnerabilities which are internet facing with highest likelihood of exploitation."

Aditya adds a cloud-specific dimension: separating environments by velocity requirements. "You can have more restrictive IAM policies in regulated or business-critical workloads. But you also need environments where the restrictions are not as much, where velocity needs to be higher, so developers don't have to come back to the security team."

Advice for Those Starting Their AI Security Journey

For organizations just beginning their AI security maturity journey, both practitioners offered pragmatic guidance. Aditya drew a memorable analogy: "AI is on a similar curve to the five stages of grief denial, anger, bargain, depression, and acceptance. Some companies are on the denial stage still, but most have moved past that stage. Very few have reached the acceptance stage."

The first step? Acceptance that AI is here to stay and requires dedicated attention. From there, mature organizations are:

1. Building paved road solutions with secure defaults

2. Investing in specialized tooling for AI-specific threats

3. Reorganizing teams into cross-functional pods

4. Creating risk matrices specific to AI threats

5. Developing remediation libraries for common AI security issues

6. Establishing AI governance through clear policies

Tejas emphasizes governance as the foundation: "Mature organizations have gone ahead and established AI governance through some sort of AI related policy. That clearly describes what is okay, what is not okay, and how to pursue what is okay."

For individuals looking to transition into AI security, Aditya recommends working backward from job market requirements: "Don't create this ideal plan that, 'Hey, I will learn only AppSec, or I will learn AppSec first and then CloudSec.' It's a security generalist type of role. You need to know a bit about everything."

Tejas adds practical career advice for those struggling to break into security: "Look for other entry level roles: IT help desk, tier one or tier two support, network engineer. You don't have to start in cybersecurity. Those skills like how to network, how to communicate, how to troubleshoot are important in cybersecurity as well."

The Bottom Line

AI security isn't a separate discipline; it's forcing the convergence of application security, cloud security, data security, and compliance into unified, cross-functional teams. The silos that worked when applications and infrastructure were separate are breaking down because AI systems span both layers intrinsically.

Security leaders must shift from gatekeepers to enablers, building automated guardrails that allow innovation at AI speed while maintaining rigorous security standards. The challenge is significant, but as both Tejas and Aditya emphasize, the fundamentals haven't changed authentication, authorization, encryption, and defense in depth still matter. What's changed is the attack surface, the velocity of development, and the need for security professionals who can bridge multiple domains.

RELATED RESOURCES

• OWASP Top 10 for LLMs

• MITRE ATLAS Framework 

• Cloud Security Alliance AI Security Guidance

• NIST AI Risk Management Framework 

• Securing AI Agents: A Practitioner's Guide (Google Cloud)

• GitHub Advanced Security for AI-Generated Code

• Supply Chain Levels for Software Artifacts (SLSA)

• Threat Modeling AI/ML Systems (Microsoft)

• AI Incident Database (Partnership on AI)

Related Podcast Episodes 🎧

AI is already breaking the Silos Between AppSec & CloudSec

Question for you? (Reply to this email)

 🤖 Are your AppSec and CloudSec still siloed or are you already building T-shaped pods with agent-aware IAM and paved roads?

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!

Shilpi Bhattacharjee

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

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter Topic we cover - AI Agents for SOC: Hype Curve vs. Measurable ROI (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 convergence of AI augmentation and traditional security operations reached a critical inflection point this week. While CISA ordered emergency patching of actively exploited Windows Server Update Services vulnerabilities demonstrating how legacy infrastructure remains a vector for supply chain compromise OpenAI's Atlas browser launch simultaneously exposed fundamental architectural challenges in agentic AI security that traditional defenses cannot address.

This week, we feature Edward Wu, Founder and CEO of Dropzone AI, whose recent Cloud Security Alliance research quantifies what many security leaders have only intuited: AI-augmented SOC analysts operate 45-60% faster with measurably higher accuracy than unassisted teams. With patents in anomaly detection using device relationship graphs and eight years building detection and response capabilities for enterprises, Edward brings both technical depth and operational wisdom to the AI SOC transformation conversation.

📰 TL;DR for Busy Readers

• ⚠️ WSUS RCE (CVE-2025-59287) enables unauthenticated RCE treat as supply chain attack vector, not “isolated server issue”, not “just Windows.” Your cloud admin laptops are in scope.

• 🧠 AI-augmented SOC analysts investigate alerts 45-60% faster with higher completion rates CSA research validates operational ROI

• 🏥 Healthcare, public sector, and industrial/OT environments are at active, systemic risk. Ransomware payment rates are down, but attacker sophistication is up.

• 🔐 Microsoft Entra Conditional Access is no longer guidance; it’s policy enforcement. Identity is now a gated control plane.

• 🤖 OpenAI Atlas browser's prompt injection attacks within days of launch expose fundamental AI agent security challenges requiring defense-in-depth

📰 THIS WEEK'S SECURITY HEADLINES

1. . CISA Orders Urgent Patching of Actively Exploited WSUS Flaw in Windows Server

What Happened: CISA issued a binding directive requiring federal agencies to immediately patch a critical Windows Server Update Services (WSUS) vulnerability (CVE-2025-59287) after evidence of active exploitation. The flaw, rated 9.8/10, allows unauthenticated remote code execution through deserialization of untrusted data on exposed WSUS servers. Microsoft shipped an emergency fix post-Patch Tuesday, and security researchers from Huntress, Eye Security, and Shadowserver observed attackers scanning WSUS servers on default ports 8530/8531, with thousands of internet-facing instances identified. Federal agencies face a November 14, 2025 deadline to patch or shut down vulnerable systems.

Why This Matters: WSUS persists in legacy infrastructure even within predominantly cloud organizations, and its privileged access makes it a critical supply chain risk. If attackers achieve SYSTEM-level access on WSUS, they can push malicious updates to downstream Windows fleets enabling lateral movement from a single exposed server into hybrid AD/Azure AD joined endpoints and potentially cloud admin workstations. This represents a software supply chain attack vector that traditional perimeter defenses cannot prevent.

Sources: TechRadar, CISA advisory

2. ⚠️ OpenAI's Atlas Browser Under Fire: Prompt Injection Attacks Surface Within Days of Launch

What Happened: Within days of OpenAI's ChatGPT Atlas AI-powered browser launch, security researchers demonstrated successful prompt injection attacks that manipulated the browser to exfiltrate data, modify settings, and execute unintended actions. Researchers from Brave Security, Johann Rehberger, and others published exploits showing malicious instructions embedded in web pages, Google Docs, and screenshot content could hijack AI agent behavior. OpenAI CISO Dane Stuckey acknowledged that "prompt injection remains a frontier, unsolved security problem" requiring significant adversary investment to exploit.

Why This Matters: This represents the enterprise security community's first major production exposure to agentic AI browser risks. Traditional web security models break when AI agents act with user credentials and the same-origin policy becomes irrelevant because the AI assistant executes with authenticated privileges. Security researcher Johann Rehberger notes that prompt injection "cannot be 'fixed' as soon as a system takes untrusted data and includes it in an LLM query, the untrusted data influences the output." For enterprises considering agentic AI adoption, this requires fundamental architectural changes: capability limiting, data boundary controls, sandboxed execution, least privilege enforcement, and comprehensive logging. Treat agentic browsing as authenticated privilege escalation as a service.

Sources: The Register, Brave Blog,Palo Alto Networks Unit 42 

3. 🎯 Trellix Report: AI-Powered Malware and Nation-State Convergence Accelerate

What Happened: Trellix's October 2025 CyberThreat Report reveals significant AI tool adoption among cybercriminals, with APT28's LameHug the first publicly reported AI-powered infostealer discovered in July 2025. The malware integrates an LLM for dynamic command generation, sending prompts and receiving tailored command sequences for reconnaissance and data exfiltration. Qilin ransomware became the most active group with 441 victim posts (13.45% of activity), while the industrial sector emerged as the primary target with 890 posts (36.57% of attacks). The U.S. accounted for approximately 1,285 victims, representing 55% of geo-identified incidents.

Why This Matters: LameHug represents the industrialization of AI-enhanced threats its operational deployment against Ukrainian organizations demonstrates AI-powered attack tools have transitioned from theoretical to weaponized in state-sponsored arsenals. The convergence of nation-state operations and financially motivated campaigns erodes traditional threat attribution models. In July-August 2025, Iran-aligned threat actors resumed active operations, with over 35 pro-Iranian hacktivist groups coordinating attacks against Israeli targets during the escalated Israel-Iran conflict. For industrial and critical infrastructure operators, this combination of most-targeted sector status with AI-accelerated attacker capabilities demands immediate OT security investment.

Sources:  Industrial Cyber, Trellix CyberThreat Report

4. 📉 Ransomware Evolution: Payments Drop to 23% as Attack Sophistication Increases

What Happened: Ransomware payment rates reached a historic low of 23% of breached companies, while Hornetsecurity's 2025 report shows attacks increased to 24% of organizations (up from 18.6% in 2024), with only 13% paying ransoms. Qilin ransomware escalated rapidly with approximately 700 attacks targeting critical sectors, while new groups like WorldLeaks (rebranded from Hunters International) and Sinobi emerged using pure extortion tactics. Microsoft's Digital Defense Report covering July 2024-June 2025 highlights that over half of cyberattacks with known motives were extortion or ransomware-driven, with 97% of identity attacks being password-based and a 32% surge in identity-based attacks in H1 2025.

Why This Matters: Declining payment rates signal organizational backup and recovery maturity, but attackers are adapting. The 39.5% quarter-over-quarter spike in email-borne malware suggests threat actors pivot toward persistence-based payloads, while 46% of incidents still begin with phishing combined with compromised endpoints and credential theft. For cloud security leaders, the shift from encryption-focused to data exfiltration-first tactics means cloud storage, databases, and SaaS applications are now primary targets rather than just on-premises file servers. This evolution fundamentally changes security architecture requirements from backup-centric to data loss prevention and exfiltration detection capabilities.

Sources: BleepingComputer, Hornetsecurity, Microsoft Blogs

5. 🏛️ Public Sector Under Siege: 196 Government Entities Hit by Ransomware in 2025

What Happened: Approximately 196 public sector entities worldwide fell victim to ransomware campaigns in 2025, with operational downtime costs between 2018-2024 reaching $1.09 billion for government entities alone. The United States experienced the highest number with 69 confirmed victims, followed by Canada (7), the United Kingdom (6), and France, India, Pakistan, and Indonesia (5 each). The most active threat actors include Babuk (43 confirmed victims), Qilin (21), and INC Ransom (18). The first half of 2025 witnessed a 60% increase in government sector attacks compared to the same period in 2024.

Why This Matters: Public institutions represent critical national infrastructure soft targets that often lack resources and technical depth for robust cybersecurity defenses. Services such as police dispatch systems, court operations, and public health portals face immense pressure to restore functionality quickly, creating leverage that attackers exploit through aggressive timelines and public data exposure threats. For private sector security leaders, government agencies are often required technology partners for regulated industries (healthcare, finance, defense contractors), creating supply chain risk. The 60% year-over-year surge suggests threat actors systematically catalog and exploit public sector limited security maturity tactics and tools proven against government targets will eventually target similarly under-resourced private enterprises.

Sources: CyberSecurity News

6. 🏥 Massive Healthcare Imaging Breach: 1.2M Patient Records Exposed

What Happened: SimonMed Imaging, one of the largest outpatient radiology providers in the U.S., disclosed a breach affecting approximately 1.2 million patients. Stolen data includes medical records, diagnostic reports, financial details, and patient identifiers. Reports indicate data has already circulated in criminal channels. The disclosure became public between October 24-27, 2025.

Why This Matters: Healthcare has become nearly fully hybrid: PHI is stored, shared, and analyzed across cloud PACS systems, AI diagnostic pipelines, and third-party billing SaaS. When imaging, billing, and identity data are stolen together, attackers can build extremely high-fidelity synthetic identities and commit high-value fraud at scale. For defenders in any regulated sector (finance, government, critical infrastructure), this warns about vendor blast radius: a single specialized provider can quietly aggregate crown-jewel data across multiple hospitals and insurers. Organizations must revisit BAAs/DPAs with imaging, billing, and AI-diagnostics vendors to ensure right-to-audit on cloud posture, logging, and incident response. Treat PHI/PII fusion data stores (images + financial + ID) as Tier 0 assets with tighter tokenization/encryption than generic "medical records."

Sources: Yahoo, CyberGuy

7. 🤖 AWS Ships "Nova Web Grounding" to Reduce Hallucination in AI Apps

What Happened: On October 28, 2025, AWS announced "Amazon Nova Web Grounding," a Bedrock/Nova capability that automatically retrieves current, attributed information from external sources and injects it into model responses. The positioning focuses on reducing hallucination and increasing traceability in AI-generated answers by attaching live referenced context.

Why This Matters: This advancement addresses more than answer quality it's about evidence and auditability. Most enterprises block or throttle AI assistants because they cannot prove where answers originate, breaking audit, SOX compliance, model risk management, and legal defensibility. Grounded and cited responses become prerequisites for AI copilots making change recommendations to IAM/SCP, firewall rules, and Kubernetes manifests; automated policy generation that can pass audit review; and AI agents acting in production with traceable justification. This lands directly in AI governance and SecOps workflows: organizations cannot approve autonomous changes without attribution. Security teams should ask whether their AI assistants can show provenance for every suggested security control change (network rule, IAM role, token TTL) if not, auto-apply should be prohibited. Start logging AI assistant citations alongside change control tickets to create audit trails when regulators ask, "Why did you trust this AI?"

Source: Amazon Web Services, Blog.

8. 🔐 Microsoft Entra Conditional Access Quietly Becoming Enforcement, Not "Best Practice"

What Happened: Microsoft continues pushing Entra Conditional Access as the mandatory Zero Trust policy engine for accessing Microsoft 365, Azure, and other corporate resources. Recent Microsoft guidance (updated through late September, reinforced through October) ties Conditional Access and MFA enforcement directly to baseline security expectations, and Microsoft has already begun mandating MFA for privileged Azure operations.

Why This Matters: "Identity is the new perimeter" has transitioned from slideware to product policy. Microsoft is moving from "we recommend MFA/CA" to "you will run MFA/CA to touch Azure." For multinational organizations, this effectively outsources access control policy to your cloud provider and creates audit artifacts you don't fully control. Simultaneously, it raises the bar for attackers: token theft, browser session hijack, and SIM swap aren't sufficient if Conditional Access policies enforce device posture, location, and risk signals at authentication time. Security teams should treat Conditional Access configurations like Terraform for firewalls: version them, peer-review them, and run change control on them. Align Conditional Access policies with data classification (production tenant ≠ test tenant). If everything has "global admin if you pass MFA," you've missed the point. Capture Conditional Access decision logs centrally IR teams will need that telemetry when investigating suspicious console activity originating from "trusted" sessions.

Source: Microsoft Learn

🎯 Cloud Security Topic of the Week:

From Hype to Reality: How AI-Augmented SOC Analysts Deliver Measurable ROI

The cybersecurity community has watched AI promises cycle through hype and skepticism for years. Security automation through playbooks and SOAR platforms has existed for over a decade, yet alert fatigue persists and tier-one analyst turnover remains painfully high. The fundamental question isn't whether AI can theoretically improve SOC operations it's whether AI augmentation delivers measurable, reproducible outcomes that justify the investment, complexity, and organizational change required.

This week, we examine findings from Dropzone AI's Cloud Security Alliance research that quantifies AI augmentation's impact on real-world SOC operations. Drawing on insights from Edward Wu whose company recently completed benchmark testing with 148 operational security analysts investigating AWS S3 bucket policy changes and Microsoft Entra ID failed login alerts we explore what AI augmentation actually delivers, where it falls short, and how security leaders should approach SOC transformation in 2025 and beyond.

Featured Experts This Week 🎤

• Edward Wu - Founder & CEO, Dropzone AI

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

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

• Agentic AI: AI systems that can autonomously take actions, make decisions, and adapt strategies based on context rather than following rigid, pre-programmed workflows. In SOC operations, agentic AI goes beyond simple automation to replicate the investigative reasoning and adaptive decision-making of expert human analysts.

• Alert Investigation: The process of analyzing security alerts to determine whether they represent genuine threats, gathering evidence, formulating hypotheses, and validating or invalidating those hypotheses through additional data collection fundamentally resembling detective work in the physical world.

• Prompt Injection: A fundamental security vulnerability in AI systems where malicious instructions embedded in external content (web pages, documents, screenshots) can manipulate the AI agent's behavior to execute unintended actions. Security researchers note this cannot be "fixed" through traditional means because untrusted data inherently influences LLM outputs.

• SOAR (Security Orchestration, Automation, and Response): Traditional security automation platforms that use playbooks rigid, pre-programmed sequences of API calls and actions to automate routine SOC tasks. While useful for deterministic workflows, SOAR lacks the adaptive reasoning required for complex security investigations.

• Tier-One Analyst: Entry-level SOC analysts primarily responsible for initial alert triage, basic investigation, and escalation to senior analysts. These roles face high turnover due to repetitive work, alert fatigue, and limited career development opportunities.

This week's issue is sponsored by Dropzone

New independent research from Cloud Security Alliance proves AI SOC agents dramatically improve analyst performance.

In controlled testing with 148 security professionals using Dropzone AI, analysts achieved 22-29% higher accuracy, completed investigations 45-61% faster, and maintained superior quality even under fatigue.

The study reveals that 94% of participants viewed AI more positively after hands-on use. See the full benchmark results.

📤 Read the Full Study from CSA

💡Our Insights from this Practitioner 🔍

The Vibe Coding Trap: Why AI SOC Requires More Than LLM Prompts(Full Episode here)

Where SOC Automation Actually Delivers Value - Today?

For years, security leaders have heard vendors promise that automation will solve SOC analyst shortage, eliminate alert fatigue, and dramatically accelerate incident response. Yet traditional SOAR platforms delivered underwhelming results. Edward Wu explains why: "The challenge with these type of automation is they are very robotic. From our perspective, the technology has underdelivered compared to the promise that they are made."

The fundamental limitation of traditional security automation lies in its rigidity. Playbook-based systems require security architects to anticipate every possible investigation path and explicitly code API calls, parameters, and decision logic. This works for simple, repetitive tasks but fails for the complex, adaptive reasoning required in security investigations. As Edward notes, "If we look at the type of tasks we're trying to automate within the SOC, like alert investigations being a SOC analyst or investigating alerts require somebody to go through a sequence of steps that actually resembles being a detective in the physical world. You have to look at the evidence, you have to look at, you know, blood stains or fingerprints on the window trims and start to formulate hypothesis and gather additional evidence to validate or invalidate hypothesis."

Quantifying AI Augmentation: The CSA Research Findings

Dropzone AI's Cloud Security Alliance research provides rare, quantified evidence of AI augmentation's operational impact. The study recruited 148 operational security analysts individuals actively working in SOC roles and tested them on two common alert types: AWS S3 bucket policy changes and Microsoft Entra ID failed login attempts. Half the analysts investigated these alerts manually, while the other half used AI augmentation.

The results exceeded expectations. Edward shares: "Maybe the biggest surprise is the actual magnitude of the differences were honestly larger than we originally anticipated. Because keep in mind these... recruited 148 participants. So they are operational, they are in the seat of security analysts. And this is their first time using our product. So we're looking at the impact of AI assistance when it is the first time they have even experienced such technology."

The quantified outcomes speak to both velocity and quality:

• 45-60% faster alert investigation speed for first-time AI-augmented users

• Higher investigation completion rates and accuracy

• Reduced analyst fatigue across tier-one through tier-three skill levels

These improvements materialized immediately without training periods, learning curves, or workflow optimization. For security leaders evaluating AI augmentation ROI, this represents measurable operational impact from day one.

What AI Augmentation Actually Means for SOC Staffing

The natural question following any automation discussion is: will AI replace security analysts? Edward provides a nuanced, realistic assessment: "Can AI SOC analyst automate everything in a SOC? And as a security leader, you can fire everybody in your SOC. That's not going to happen. I do see a world where in the future there will not be that many tier one security analysts as a job role. What we will have is a whole lot more security architects, a whole lot more, you know, security transformation folks."

This shift mirrors transformations in software development. Just as AI coding tools like Cursor didn't eliminate developers but changed their work from writing every line of code to architectural design and solution orchestration, AI SOC augmentation will evolve analyst roles from manual alert processing to higher-level security architecture and strategic decision-making.

Edward elaborates on this parallel: "With AI coding tools, what we have seen is it's a lot more important for software developers to essentially pick up more program management or project management skills, because now with an army of AI coding agents, a single software developer can operate as a team of developers. That means as a human developer, there's actually more quasi-like managerial technical leadership tasks, like you have to divvy up the feature into different components and then you will assign each component to an AI coding agent or Cursor to help you with it."

For SOC operations, this translates to analysts spending less time on repetitive alert triage and more time on:

• Architecting detection logic and response workflows

• Tuning and configuring AI agents for maximum efficiency

• Evaluating investigation quality and identifying edge cases

• Strategic threat hunting and security transformation initiatives

The Complexity and Cost of Building AI SOC Capabilities

Given the hype surrounding generative AI, many organizations consider building internal AI SOC capabilities. "How hard can it be to attach an AI to my SIEM or my log aggregator?" is a common refrain. Edward provides sobering reality checks on this assumption.

"Obviously nowadays it's very cool to start new projects around, hey, you know, I can take this open source library, I can connect it to a couple APIs, and voila, I have an AI SOC analyst," Edward notes. "Based on what we have seen in the field, it's definitely not this easy. In fact, you might have noticed there are close to 30 or 40 different startups building, trying to build similar technologies, but very few actually have working technology, so it's much more difficult than it looks on paper."

The technical challenges extend far beyond connecting APIs to large language models. Edward emphasizes the core difficulty: "The biggest challenge when building AI agents for security is how do you manage large language models? How do you find the right balance between allowing large language models to improvise and adapt while keeping them within certain guardrails so they can offer trustworthy and deterministic outputs. And that's actually very difficult."

The financial reality underscores this complexity. Edward shares: "At Dropzone, if we look at 2020, by the end of 2026, Dropzone would have spent close to $20 million purely on R&D to build this technology. Unless as a security organization you are maybe allocating five or $10 million of budget to build such a technology, you are probably not going to be able to get it right."

Organizations attempting internal builds also face talent challenges. Building agentic AI systems requires not just security expertise but also:

• Data science and machine learning engineering capabilities

• Data pipeline architecture and management

• LLM fine-tuning and prompt engineering specialization

• Iterative testing and validation frameworks

For most organizations, buying mature AI SOC technology delivers faster time-to-value than multi-year, multi-million-dollar internal development efforts.

Who Benefits Most from AI-Augmented SOC Operations

AI augmentation isn't equally valuable across all organizational contexts. Edward identifies two primary beneficiary groups based on Dropzone's customer base.

The first group comprises mid-market to enterprise organizations (typically 200+ employees) with internal SOC teams. "Those are the folks who are leveraging internal resources. They have full-time security analysts," Edward explains. "Those security teams will definitely benefit from our technology."

However, the second group represents perhaps the more transformative use case: managed security service providers (MSSPs) and managed detection and response (MDR) providers. Edward notes: "AI augmentation actually drastically increase the quality of the security services that service providers like MSPs or MDRs can offer. So this is where I don't think with AI, like if you are an organization of 200 employees, I still think security service providers are the best way to get the initial set of security protections and capabilities. But now with AI augmentation, you can get a whole lot more from your security service providers."

This insight has important strategic implications. Smaller organizations that historically couldn't justify full-time SOC analysts can now access sophisticated security operations through AI-augmented service providers at price points previously impossible. The service provider economic model where a single analyst team serves multiple clients combines powerfully with AI augmentation that multiplies each analyst's investigation capacity 1.5-2x.

Training and Skill Development in the AI SOC Era

As security leaders plan year-end training budgets, understanding which skills matter in AI-augmented environments becomes critical. Edward's guidance mirrors software development transformations: "A lot of that is, again, using software development as analogies. With AI coding tools, what we have seen is it's a lot more important for software developers to pick up more program management or project management skills."

The specific capabilities Edward recommends SOC teams develop include:

• Technical leadership: The ability to function as a tech lead, dividing complex security projects into smaller, manageable components that AI agents can execute

• Quality assessment: Developing the judgment to distinguish high-quality from low-quality AI-generated investigations and recommendations

• AI agent configuration: The ability to coach, tune, and configure AI solutions to achieve maximum efficiency within organizational context

• Strategic architecture: Moving beyond tactical alert response to designing detection strategies, response workflows, and security transformation initiatives

Training programs should shift focus from teaching analysts "how to investigate alerts" to "how to architect, oversee, and optimize automated investigation systems." This parallels how software engineering education now emphasizes system design, API integration, and solution architecture over memorizing syntax.

Practical Implementation: What Security Leaders Should Do Now

For security leaders evaluating AI SOC augmentation, Edward's research and operational experience suggest several concrete actions:

1. Test AI augmentation with realistic scenarios. Don't rely on vendor demos. Request proof-of-concept evaluations using your actual alert types, your SIEM data, and your analysts. The CSA research used common alerts (S3 bucket policy changes, Entra ID failed logins) precisely because they represent real-world SOC workloads.

2. Measure velocity and quality, not just speed. AI augmentation should improve both investigation speed (45-60% faster) and completion rates/accuracy. If a solution only improves speed by generating low-quality investigations, it will create downstream problems rather than solving them.

3. Realistically assess build vs. buy economics. Unless you can allocate $5-10M and multi-year timelines for AI SOC development, buying mature technology will deliver faster ROI. The 30-40 startups attempting to build this technology with only a few succeeding demonstrates the difficulty.

4. Evolve SOC career paths proactively. Communicate to your teams that tier-one analyst roles will evolve, but that security careers aren't disappearing; they're becoming more strategic, architectural, and impactful. Invest in training that prepares analysts for these elevated responsibilities.

5. For smaller organizations, prioritize AI-augmented service providers. If your organization has fewer than 200 employees and lacks dedicated SOC staff, leverage MSSPs and MDR providers that use AI augmentation. You'll access enterprise-grade capabilities at small-business price points.

6. Establish AI agent governance frameworks now. As agentic AI systems gain more autonomy, you need guardrails, approval workflows, and audit trails. Start simple: require human approval for any AI-suggested changes to production systems, log all AI agent actions, and establish review processes for AI investigation quality.

The transition to AI-augmented SOC operations isn't theoretical; it's happening now, with measurable outcomes that validate the investment. Security leaders who approach this transformation strategically, grounded in evidence rather than hype, will build more resilient, scalable, and effective security operations for the hybrid cloud era.

RELATED RESOURCES

• Cloud Security Alliance: Dropzone AI SOC Benchmark Research Report   Comprehensive analysis of AI augmentation impact on SOC analyst performance with 148 operational participants

• Dropzone AI Test Drive   Ungated, live environment demonstrating AI SOC analyst investigations across different alert types (Dropzone.ai)

• CISA Known Exploited Vulnerabilities Catalog   Authoritative list of actively exploited vulnerabilities requiring immediate patching (cisa.gov/known-exploited-vulnerabilities)

• Microsoft Entra Conditional Access Documentation   Implementation guidance for Zero Trust identity controls in Azure and Microsoft 365 environments

• Trellix CyberThreat Report October 2025   Analysis of AI-powered malware evolution and nation-state threat convergence

• Johann Rehberger's Prompt Injection Research   Security researcher's analysis of fundamental AI agent vulnerabilities and mitigation strategies

• AWS Security Best Practices for AI/ML Workloads   Cloud-native guidance for securing AI model deployments and data pipelines

• MITRE ATT&CK Framework for Cloud   Comprehensive matrix of cloud-specific tactics, techniques, and procedures (attack.mitre.org)

Related Podcast Episodes 🎧

AI Agents for SOC: Hype Curve vs. Measurable ROI

Question for you? (Reply to this email)

 🤖 Is your SOC ready to trust AI agents for autonomous alert investigation what's the first use case you'd pilot?

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!

Shilpi Bhattacharjee

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

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter Topic we cover - The Vibe Coding Trap: Why AI SOC Requires More Than LLM Prompts (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

This week brings critical enforcement deadlines for the F5 breach, a major AWS outage that tested multi-region resilience, and groundbreaking research showing how prompt injection can lead to remote code execution in AI agents.

We're joined by Ariful Huq, CEO of Exaforce and former Palo Alto Networks veteran, who shares hard-earned lessons from building an AI-native SOC platform from first principles tackling everything from data architecture to detection engineering and the evolution of security teams in an AI-driven future.

📰 TL;DR for Busy Readers

• $1.73B Data Consolidation: Veeam to acquire Securiti AI in a ~$1.73 billion cash-and-stock deal. Data resilience + DSPM/privacy/AI-trust are converging. Expect backup inventories and multi-cloud data maps to unify.

• F5 Enforcement Starts Now (Oct 22):
  CISA ED-26-01 deadlines in effect. Treat BIG-IP as Tier-0. Remove internet-exposed mgmt, apply Oct QSN patches, add TMSH/API anomaly detections.

• Expert Insights from the Cloud Security Podcast Episode

  • Data > SIEM:
    Legacy SIEM + AI “bolt-ons” fail without unified logs + config + code + permissions context.

  • SaaS Blind Spots:
    GitHub, Snowflake, and Workspace lack native detections — require domain-specific engineering.

  • Cost Reality:
    Cloud telemetry (100× traditional logs) breaks ingestion-priced SIEMs; separate hot vs cold data for speed + economy.

  • SOC Evolution:
    Future teams = full-stack security engineers; AI handles triage, humans own investigation.

📰 THIS WEEK'S SECURITY HEADLINES

1. Veeam Acquires Securiti AI for $1.73B: Data Resilience Meets DSPM

Veeam announced plans to acquire DSPM and AI data governance vendor Securiti AI for $1.725 billion in a cash and stock deal expected to close in Q4 2025. The acquisition aims to unify backup and disaster recovery capabilities with data discovery, privacy management, DSPM, and AI trust functions.

Why this matters: This represents major consolidation at the intersection of data resilience and data security posture management. Enterprise security leaders should anticipate tighter integrations between backup inventories and multi-cloud data mapping across S3, Azure Blob, GCS, and SaaS platforms. For organizations running Veeam today, this creates an opportunity to converge policies around retention, privacy, data sovereignty, and response orchestration that spans both backup restoration and data-level containment. Key questions for your Veeam roadmap discussions: How will auto-classification work for backed-up data? What cross-cloud toxic data flow detection capabilities will emerge? How will immutable restore capabilities extend to AI model rollback scenarios?

This consolidation signals that data-centric security is moving beyond point solutions toward integrated platforms that understand both where data lives and how to recover it securely.

Sources: Bloomberg, Veeam press release

2. CISA Emergency Directive on F5 Breach Reaches Critical Enforcement Deadlines

Following F5's disclosure that a nation-state actor stole BIG-IP source code and internal vulnerability data, CISA issued Emergency Directive 26-01 ordering federal agencies to inventory and patch or replace affected F5 devices. Enforcement deadlines began October 22, with new reporting highlighting hundreds of thousands of internet-reachable BIG-IP instances at risk.

Why this matters: Source code and vulnerability intelligence theft fundamentally changes the threat landscape for these devices. This isn't just about known CVEs attackers now have the blueprint to craft 0-day exploits against ADC and WAF gateways that front critical applications in both on-premises and hybrid cloud environments. For enterprise security architects, BIG-IP and related F5 infrastructure should be reclassified as Tier-0 assets requiring immediate action: restrict management plane access, enforce MFA, remove any internet-exposed management interfaces, apply F5's October Quarterly Security Notification packages, and implement CISA ED 26-01 hardening actions including asset discovery, configuration review, and log analysis. Additionally, security teams should add custom detections for anomalous TMSH and API activity, and hunt for any credential or API key leakage patterns referenced in the advisories going back at least 12 months.

Sources: CISA Emergency Directive & Alert, F5 Advisory

3 - AWS US-East-1 Outage: A Multi-Region Resilience Wake-Up Call

A multi-hour incident in AWS's US-East-1 region on October 20 cascaded across load balancers and dependent services, disrupting thousands of major consumer and government applications. AWS attributed the trigger to internal infrastructure issues, and service has been restored.

Why this matters: While not a security breach, this outage serves as a critical resilience test for cloud architects. The incident exposed dependencies that many organizations didn't realize existed particularly around authentication services, payment processing, and messaging infrastructure that assumed US-East-1 availability. Key architectural reviews for your team: Revisit cell and region isolation strategies for critical paths, validate control-plane dependencies including Route 53 health checks, ELB/ALB configurations, and IAM token lifetime assumptions. Most importantly, prove graceful degradation and blast-radius limits through game-day exercises, and ensure incident communication automations don't depend on the impaired region. This outage reinforces that multi-region architecture isn't just about disaster recovery it's about maintaining operations when a primary region experiences prolonged disruption.

Sources: The Guardian, AWS Health Dashboard

4 - MuddyWater APT Targets 100+ Government Entities with Phoenix Backdoor

New reporting details a broad phishing campaign from MuddyWater (Iranian state-sponsored group) using compromised mailboxes and VPN infrastructure to deliver macro-enabled payloads containing the Phoenix backdoor. The campaign targets government organizations across the Middle East and Africa.

Why this matters: Organizations that federate identities to Office 365 or Google Workspace and operate hybrid workloads in MEA regions should expect living-off-the-land persistence techniques and mailbox-to-mailbox lateral movement. The campaign demonstrates sophisticated use of compromised infrastructure to evade traditional perimeter defenses. Immediate hardening steps: Tighten conditional access policies, disable legacy authentication protocols, restrict macro execution via Attack Surface Reduction (ASR) rules, and enrich detection logic with VPN exit node indicators and suspicious OAuth token grant patterns. This campaign also highlights the importance of monitoring for anomalous authentication patterns and mailbox rules that could indicate compromise.

Source: Dark Reading

5 - CISA Adds Five Actively Exploited Vulnerabilities to KEV Catalog

CISA updated the Known Exploited Vulnerabilities catalog on October 20, highlighting multiple bugs under active exploitation in the wild. Separate reporting confirms exploitation of a patched Windows SMB vulnerability.

Why this matters: KEV-listed vulnerabilities must be prioritized over CVSS-only scoring approaches. These represent confirmed threats that attackers are actively weaponizing. Security teams should integrate KEV feeds into vulnerability management programs to auto-create SLAs and prioritize remediation workflows. Where immediate patching isn't feasible, verify compensating controls are in place particularly network segmentation, SMB signing enforcement, and EDR coverage on domain controllers and file servers that underpin cloud synchronization services. The Windows SMB exploitation is especially concerning given how critical these services are to hybrid cloud authentication and file sharing architectures.

Source: CISA Alert

6- Healthcare Cyberattack Forces Massachusetts Hospitals to Divert Patients

A cyber incident on October 20 forced two Massachusetts hospitals to take IT and radiology systems offline and divert ambulance traffic. Early indicators point to ransomware as the attack vector.

Why this matters: This incident underscores that clinical systems including PACS/RIS and imaging workstations alongside affiliate and third-party network connections represent critical weak points in healthcare infrastructure. For security leaders supporting healthcare workloads, this reinforces the need to: isolate imaging networks from general IT infrastructure, require privileged access workstations for administrative functions, and rehearse downtime procedures including cloud-hosted EHR failover capabilities. The attack also highlights how ransomware continues to target healthcare organizations where operational disruption directly impacts patient care, making these organizations more likely to pay ransoms under duress.

Source: Bank Info Security

7 - AI Security Research: Prompt Injection Leads to Remote Code Execution

Trail of Bits published research demonstrating complete attack chains from prompt injection to remote code execution in LLM agent systems through tool use and environment bridges. The research coincided with commentary from OpenAI's CISO emphasizing risk concerns for newly launched agent features.

Why this matters: Organizations piloting agent-assisted SecOps or internal copilots with cloud tool access must treat these systems as untrusted execution environments similar to web browsers. Security teams should: constrain agent tools with least-privilege access and time-boxed tokens, implement out-of-process sandboxes, add content provenance checks including URL/domain allowlists and HTML/script stripping, enforce model-side policy guards, log all tool invocations comprehensively, and bind guardrails to secrets managers with no inline keys. This research demonstrates that AI agents aren't just productivity tools they're potential attack surfaces that require the same security rigor as any privileged system with access to production environments.

Sources: Trail of Bits Blog, Simon Willison's commentary

8 - AWS Releases Amazon Corretto Quarterly Security Patches

AWS released Corretto (OpenJDK) quarterly security and critical updates across all LTS versions (25, 21, 17, 11, 8). Many Java-based services including Lambda functions and containerized microservices pin these runtimes as base dependencies.

Why this matters: Java supply-chain risk frequently enters through base container images and managed runtime environments. Security and DevOps teams should ensure CI/CD pipelines rebuild container images against the updated Corretto versions, rotate JDK installations in Elastic Beanstalk, EKS, and ECS environments, and redeploy Lambda functions using updated layers. This seemingly routine patching cycle represents a critical supply-chain security control especially given how widely Java runtimes are deployed across enterprise cloud workloads.

Source: AWS "What's New" (Corretto)

🎯 Cloud Security Topic of the Week:

Building AI-Native SOC Platforms: Why Traditional SIEM + AI Bolt-Ons Fall Short

“Can you simply use Claude Code or any advanced LLM to build an AI SOC?“
This question reflects broader confusion in the market about what it truly takes to operationalize AI in security operations. This week, we explore the architectural and operational realities of building AI-native SOC capabilities lessons that challenge conventional wisdom about "bolting AI onto existing tools."

Featured Experts This Week 🎤

• Ariful Huq - CEO and Co-founder, Exaforce

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

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

• AI-Native SOC: A security operations center built from first principles with AI capabilities embedded at every layer from data ingestion to detection, triage, investigation, and response rather than AI features added to existing SIEM platforms.

• DSPM (Data Security Posture Management): A category of security tools that discover, classify, and monitor sensitive data across multi-cloud and SaaS environments, providing visibility into data exposure, access patterns, and compliance risks.

• SIEM (Security Information and Event Management): Traditional platforms that aggregate logs and events for correlation and analysis. Legacy SIEMs primarily process event data without broader context like configuration, code, or business logic.

• Agentic SOC: Security operations platforms that use autonomous AI agents to perform multi-step security tasks including detection, triage, investigation, and response with minimal human intervention.

• Detection Engineering: The practice of creating, testing, and maintaining threat detection logic including rules, behavioral analytics, and machine learning models to identify security incidents across infrastructure and applications.

This week's issue is sponsored by Exaforce

Exaforce transforms how security teams operate by delivering enterprise-grade SOC capabilities without increasing headcount.

Powered by agentic, multi-model AI and advanced data exploration capabilities, the Exaforce platform automates detection, triage, investigation, and response with expert analyst-level accuracy at machine speed.

Cut false positives by up to 80%, reduce MTTR by 70%, and lower costs while strengthening coverage across IaaS, SaaS, code, and identity.

Build or scale your SOC in hours, not months, and give your team the intelligence edge it deserves.

📤 See Agentic SOC Platform in Action

💡Our Insights from this Practitioner 🔍

The Vibe Coding Trap: Why AI SOC Requires More Than LLM Prompts(Full Episode here)

"Can I just use Claude Code to build an AI SOC?" This question surfaces constantly in enterprise security discussions, fueled by impressive demos of LLMs generating code and solving problems. Ariful Huq, who has spent the past two years building Exaforce's AI-native SOC platform, offers a nuanced perspective that every security leader evaluating AI capabilities should understand.

"I think this technology is incredibly powerful," Ariful begins. "It's given me superpowers as a product person. Just over the weekend, I was building session hijacking demos and exploring APIs things I wouldn't have done five years ago without a coding background." However, the critical distinction emerges when discussing production SOC platforms versus exploratory tooling: "If you're starting from scratch and thinking about building a data platform with everything on top of it from a management and resourcing perspective, that might not be worthwhile."

The core issue isn't whether LLMs can generate useful code (they can), but whether organizations understand the full stack required for production security operations at scale. Traditional approaches that "bolt on" AI capabilities to existing SIEM architectures encounter fundamental limitations rooted in data architecture, context, and operational maturity.

1️⃣ First Principles: Starting With Data Architecture, Not Detection Rules

Drawing an analogy to autonomous vehicles, Ariful explains why point solutions fall short: "If you look at Tesla and Waymo, they're not building bolt-on autonomous vehicles. They've built the infrastructure, the cameras, the data collection, the training. You can see they're making the most progress because they own the underlying platform."

This same principle applies to AI-native SOC platforms. "I think the bolt-on approach is tough. If you're really looking for good outcomes, you really need to think about an approach starting from first principles with the data," Ariful emphasizes. "It's well more than just logs and event data, it's config, code context, bringing it all together. I think it's going well beyond what SIEMs are capable of."

The data challenge manifests in several dimensions that enterprise SOC teams face today:

Volume Explosion from Cloud Infrastructure: At Exaforce, analyzing their own security telemetry revealed that IaaS logs specifically from public cloud platforms generate 100 times the volume of all other data sources combined. This astronomical scale puts tremendous pressure on architectural choices made for traditional on-premises environments. Legacy SIEM architectures that charge based on data ingestion become prohibitively expensive when cloud workloads generate petabytes of security-relevant telemetry.

The Real-Time Processing Tax: Security operations fundamentally differs from other data analytics use cases because SOC teams require real-time threat detection and response. Ariful highlights a critical insight about data lake economics: "If you're building a SIEM on top of Snowflake, every time you run a query or detection, you're getting charged. The real-time data processing is the critical thing here."

This continuous processing requirement drove Exaforce to architect a hybrid approach: hot data in memory for real-time querying, combined with cold storage leveraging Snowflake and Apache Iceberg on S3 for historical analysis. "We had to decouple ourselves to leverage technologies like Snowflake for what they're good at, while not getting charged for every real-time detection query," Ariful explains.

One customer example crystallizes the problem: they stored all cloud logs in S3 using Athena for queries resulting in 50 minutes to one hour query times. The cost savings from avoiding SIEM ingestion fees were completely negated by operational paralysis. Another customer tried sending all cloud logs to their existing SIEM, watching costs skyrocket before pulling back and seeking augmentation technologies to handle cloud telemetry separately.

2️⃣ Context Is Everything: Why Log Data Alone Fails AI Systems

The most common mistake organizations make when attempting to build AI SOC capabilities centers on data completeness. Traditional SIEMs excel at processing logs and events, but AI systems require substantially more context to produce reliable, actionable results.

Ariful illustrates this with a concrete example: "Let's say you're trying to do insider threat detection. One behavior is somebody without edit permissions copying files and making them public. To build that detection, you need event data about the action, config information on the resource, and permission data to determine if they had edit rights."

This pattern repeats across cloud security use cases. Investigating anomalous S3 bucket access requires understanding: Who performed the action? What IAM role or user identity was assumed? Who provisioned the S3 bucket originally? What sensitivity classification applies to the objects? Which specific keys were accessed?

"You have to give LLMs the right context. You can remove the guesswork," Ariful explains, drawing a human analogy. "If you ask me a vague question, my thought process could go many different directions. But if you remove the guesswork and give me preciseness plus reasoning freedom, you'll get consistent answers even between different people. That's exactly what we're trying to do with LLMs to remove guesswork by providing context from logs, config, code, and business understanding."

This insight proved pivotal in Exaforce's development journey. In their first year, they started with third-party detections and leveraged LLMs for triage. "The results were unpredictable, not precise, not what we expected," Ariful recalls. "It really boiled down to the data. We needed config context, permission information, code context for GitHub not just event logs."

3️⃣ Detection Engineering at Scale: The SaaS Blind Spot

Modern enterprises operate across dozens of SaaS platforms: GitHub for code, Snowflake for analytics, Google Workspace for collaboration, OpenAI for AI capabilities. A critical gap emerges: none of these platforms provide native threat detection capabilities.

"GitHub has no native threat detection," Ariful points out. "If you have a personal access token or SSH key compromised, you need your own detections to figure that out." This reality creates a detection coverage gap that traditional endpoint and email security tools don't address those problems are largely solved by CrowdStrike, Sentinel One, and mature email security providers.

Exaforce focused detection engineering efforts specifically on SaaS platforms, but the work required goes far beyond writing simple correlation rules. "You need domain-specific understanding of data. You almost need to build domain-specific knowledge by understanding events, resources, and platform intricacies for every single data source. GWS has its own intricacies. GitHub has its own intricacies."

Detection engineering at this level requires understanding platform-specific concepts like GitHub personal access tokens, Google Workspace OAuth scopes, and Snowflake account privileges. Teams must then build statistical models on top of this domain knowledge to identify anomalous patterns. "You have to figure out what is potentially anomalous, build statistical models, and determine thresholds," Ariful explains. "It's hard to just build rule-based detections where step one happens, step two happens, fire alert. It's much more complex. You need anomaly detection capabilities that many SIEMs simply don't provide."

This detection engineering challenge explains why organizations with strong detection engineering teams still struggle with SaaS coverage. Even with skilled engineers, building and maintaining domain-specific detection logic across a dozen SaaS platforms becomes a Sisyphean task without purpose-built tooling and data integration.

4️⃣ The Trust and Transparency Problem: How Do You Know AI Got It Right?

Perhaps the most challenging question for AI SOC platforms centers on trust. In security operations, false positives erode analyst confidence while false negatives create blind spots. When AI makes triage decisions, security leaders rightfully ask: "How do I know it got this right?"

Ariful's response draws again on the autonomous vehicle analogy: "There's no magic pixie dust for trust. For some time, you didn't see Waymo vehicles drive autonomously; you saw them with somebody inside. That's the phase we're in with SOC operations where you still need people driving."

Exaforce approached this through three mechanisms:

Transparency Through Complete Context: "You have to provide every aspect of the decision, the data the agent relied on, all relevant questions it answered to reach conclusions. You can't ask people to context switch to other data platforms to validate decisions." The system must surface all reasoning paths and supporting evidence inline.

Human-in-the-Loop Learning: Exaforce built a dedicated team to review AI triage decisions as humans, labeling true positives versus false positives. This evolved into a Managed Detection and Response (MDR) service that serves dual purposes: providing customers with better outcomes through human oversight while simultaneously improving the product through labeled training data. "We invest in MDR not just as a service but as a mechanism to build better technology," Ariful explains.

Continuous Learning from Historical Context: The system maintains historical data about past detections and their classifications. When a specific alert type has been marked as a false positive with documented reasoning, that context informs future triage decisions. Organizations can also provide business context knowledge bases, operational playbooks, environment-specific details that the system incorporates into every analysis.

"There's no easy answer," Ariful admits. "It's a combination of transparency, human validation loops, and continuous learning from historical classifications that helps us get better results over time."

5️⃣ Rethinking SOC Teams: The Rise of Full-Stack Security Engineers

If AI can handle alert triage, investigation assistance, and even multi-step response workflows, what does this mean for SOC staffing? Ariful sees a fundamental shift emerging that elevates rather than replaces human talent.

"I really think the future is where security engineers become full stack. You're not an analyst," Ariful states. "Your best analyst doesn't want to be the guy that's just doing investigations. Your best analyst is probably someone incredibly valuable to the organization in many other ways."

This perspective aligns with what Exaforce observes across customer engagements. Growth-stage companies rethinking their SOC approach are hiring differently: "They're not hiring analysts. They're hiring individuals that can perform all these tasks: security engineering, some detection work, incident response because they're going to leverage a combination of human talent and AI."

The traditional SOC staffing model buying a SIEM, hiring detection engineers, hiring L1/L2 analysts requires massive upfront capital and headcount investment with value realization potentially taking more than a year. In contrast, an AI-native approach allows a small team of full-stack security engineers to leverage technology for the mundane work while focusing on high-value threat hunting, complex investigations, and security engineering projects.

"If you're in the SOC, leverage AI to be a builder and a better defender not to do mundane tasks," Ariful emphasizes. This shift particularly benefits early-career security professionals. Those with 2-3 years of experience who know enough to ask good questions but want to advance to senior roles can use AI capabilities to punch above their weight class. They can engage with complex investigations and advanced analysis previously reserved for principal-level engineers, while AI handles the repetitive triage work that has historically created burnout and high turnover among SOC analysts.

6️⃣ Beyond Bedrock: The Engineering Reality of Production AI Systems

For organizations building on AWS, Amazon Bedrock provides an obvious starting point for LLM capabilities. Exaforce leverages Bedrock extensively and even won AWS's Partner Startup of the Year award. However, Ariful cautions that Bedrock alone doesn't constitute a production AI agent system.

"Bedrock is incredibly beneficial it's a native AWS service, so all your data stays within AWS infrastructure, which helps with data residency and sovereignty questions," Ariful notes. "But it's not just about Bedrock. Building a robust agent system goes well beyond what Bedrock offers."

Production requirements that teams must build themselves include:

• Retry mechanisms: When agents reach out to third-party systems or individuals, how do you handle failures?

• Asynchronous processing: If an agent performs multiple tasks, should they execute sequentially or in parallel?

• Upgrade handling: When upgrading software, how do you ensure in-flight agent tasks complete or restart appropriately?

• State management: How do you track agent progress across distributed systems?

Exaforce's engineering team evaluated open-source frameworks like LangChain but ultimately built custom infrastructure because production requirements exceeded what generic frameworks provided. "We obviously started with Bedrock quickly that's the benefit of cloud," Ariful explains. "But then there's all this other infrastructure you have to build for enterprise reliability."

This reality check matters for security leaders evaluating build-versus-buy decisions. The impressive demos of LLMs solving problems don't capture the operational complexity of running agent systems at scale in production security environments with SLAs and compliance requirements.

RELATED RESOURCES

• Threat Intelligence & Research

  • CISA Emergency Directive 26-01 Full Text - Complete guidance on F5 BIG-IP remediation requirements

  • Trail of Bits: Prompt Injection to RCE Research - Technical deep-dive on AI agent security vulnerabilities

  • AWS Multi-Region Architecture Best Practices - Official guidance on region failover design

• AI Security & Development

  • Amazon Bedrock Documentation - Technical reference for building AI applications on AWS

  • LangChain Documentation - Framework for developing LLM applications

  • OWASP LLM Top 10 - Security risks in LLM applications

Related Podcast Episodes 🎧

Can You Build an AI SOC with Claude Code? The Reality vs. Hype

Question for you? (Reply to this email)

⚙️ Is your SOC team spending more time managing queries or hunting threats?

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!

Shilpi Bhattacharjee

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

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter Topic we cover - Building Automated Incident Response for the Cloud Age (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 past week has reinforced a sobering reality for enterprise cloud security teams: sophisticated nation-state actors are targeting critical infrastructure software, and our incident response capabilities must evolve to match the complexity of modern cloud architectures. From F5's disclosure of persistent access by nation-state actors to Harvard's confirmation as a victim in the Oracle EBS zero-day campaign, the stakes have never been higher.

This week, we're featuring insights from Damien Burks, a seasoned cloud security engineer with over six years of experience building incident response platforms in highly regulated financial services environments. Damien has hands-on experience automating containment for complex Kubernetes environments and brings practical wisdom on navigating the increasingly sophisticated cloud security landscape.

📰 TL;DR for Busy Readers

• F5 BIG-IP breach: Nation-state actors stole source code; treated as supply-chain exposure for all BIG-IP deployments including cloud VE instances. Treat F5 BIG-IP as software provenance risk; verify image digests and lock down management planes now.

• Oracle EBS zero-day @ Harvard: 1.3TB exfiltrated via CVE-2025-61882; check EBS integrations with cloud IAM and data warehouses

• GitHub Copilot CamoLeak: CamoLeak proves AI dev tools can exfiltrate secrets via hidden prompt injection; restrict scopes and disable risky render paths.

• AWS & Google updates: Guardrails for AI agents + Drive anti-ransomware AI align with your data-protection strategy.

• EKS containment: Use in-VPC automation (e.g., Lambda in cluster VPC/SG) to execute kubectl playbooks without bastions.

📰 THIS WEEK'S SECURITY HEADLINES

1. F5 BIG-IP Source Code Stolen in Nation-State Breach

What Happened: F5 disclosed that sophisticated nation-state actors maintained persistent access to its internal systems from an unknown date until discovery on August 9, 2025, successfully exfiltrating portions of BIG-IP source code and information about undisclosed vulnerabilities. The U.S. Department of Justice granted a one-month disclosure delay citing national security concerns marking one of the first public acknowledgments of DOJ intervention in SEC cybersecurity disclosures. CISA issued Emergency Directive ED 26-01 ordering all federal civilian agencies to immediately mitigate unauthorized access risks and report detailed F5 BIG-IP inventories by December 3, 2025.

Why This Matters to Cloud Security Leaders:

This incident represents a textbook supply-chain compromise affecting thousands of enterprises running BIG-IP appliances in cloud VPCs and on-premises data centers. For cloud security architects, the implications extend beyond traditional on-prem ADC deployments. Many organizations deploy F5 virtual editions (VE) from AWS Marketplace, Azure Marketplace, or as custom AMIs all potential attack surfaces if adversaries possess source code and vulnerability intelligence.

The multi-month detection gap is particularly concerning. As Damien Burks emphasizes in this week's featured interview: "Without automation, in a regulated environment, it's gonna take you hours" to respond to incidents in complex environments. The F5 breach underscores why detection alone is insufficient. Organizations need automated response capabilities that can contain threats within minutes, not hours.

From an architectural perspective, BIG-IP often sits at the network boundary between internet-facing services and application tiers, making compromised instances ideal pivot points for lateral movement. Cloud security teams should treat this as an opportunity to harden management plane access, implement zero-trust network segmentation, and deploy enhanced telemetry on ADC zones.

Sources: Bloomberg, SecurityWeek, The Record, Help Net Security

2. Harvard Confirms Breach in Oracle EBS Zero-Day Campaign

What Happened: Harvard University became the first confirmed victim of a widespread Oracle E-Business Suite exploitation campaign orchestrated by the Cl0p ransomware group. Attackers exploited CVE-2025-61882 (CVSS 9.8), a critical authentication bypass vulnerability allowing unauthenticated remote code execution, to exfiltrate 1.3 TB of data including financial records, HR information, and internal source code. Google Threat Intelligence and Mandiant report that dozens of organizations were targeted beginning as early as July 10, 2025, with the campaign accelerating through October.

Why This Matters to Cloud Security Leaders:

Oracle EBS presents a critical attack surface that often flies under the radar of cloud security programs focused on native cloud services. EBS is deeply embedded in financial operations, human resources, supply chain management, and customer relationship systems across Fortune 500 companies. More importantly for cloud security teams, EBS instances frequently integrate with cloud IAM systems, data warehouses (Snowflake, Redshift, BigQuery), and SaaS platforms (Salesforce, Workday), making compromised instances potential bridges into broader cloud environments.

The FBI characterized CVE-2025-61882 as a "stop-what-you're-doing and patch immediately" vulnerability. The multi-month exploitation window before public disclosure highlights a detection gap that sophisticated threat actors exploit repeatedly. As Damien Burks notes when discussing incident response complexity: "You have to understand how your environment is configured to begin with" a principle that applies equally to understanding how legacy ERP systems like Oracle EBS connect to modern cloud infrastructure.

This incident also reinforces the importance of data classification and egress monitoring. Harvard lost 1.3 TB of sensitive data, suggesting inadequate data loss prevention controls between EBS and external networks. Cloud security teams should implement enhanced monitoring for unusual data exfiltration patterns from any system with access to sensitive data stores.

Sources: SecurityWeek, Security Affairs, Dark Reading, The Record

CamoLeak: GitHub Copilot Vulnerability Enables Silent Data Exfiltration

What Happened: Legit Security detailed CamoLeak, a critical vulnerability chaining remote prompt injection (hidden in pull request content) with an image-proxy CSP bypass to exfiltrate secrets and private repository code via GitHub's own infrastructure. The vulnerability received a CVSS score of 9.6. GitHub mitigated the issue by disabling image rendering in Copilot Chat.

Why This Matters to Cloud Security Leaders:

CamoLeak confirms what many security teams feared: AI assistants represent new data egress channels that can bridge from source control systems to external endpoints. For cloud security programs, this vulnerability is particularly concerning because private repositories often contain cloud access keys, API credentials, and information about undisclosed vulnerabilities exactly the type of data exfiltrated in the F5 breach.

The attack vector is sophisticated yet practical: adversaries can hide malicious instructions in pull request content that Copilot processes, bypassing traditional security controls. As organizations increasingly adopt AI-powered development tools, the attack surface expands beyond traditional application security boundaries into the toolchain itself.

This connects directly to Damien Burks' emphasis on understanding entry points and preventing incidents before they require response: "Secure coding is definitely recommended. I mean, like it's enforced in a heavily regulated environment." The same rigor applied to application code must now extend to AI assistant configurations and permissions.

Sources: Legit Security Research

4. LevelBlue to Acquire Cybereason in MDR/XDR Consolidation Move

What Happened: MSSP LevelBlue signed a definitive agreement to acquire Cybereason (XDR/DFIR platform). SoftBank Corp., SoftBank Vision Fund 2, and Liberty Strategic Capital will become investors in LevelBlue, with former U.S. Treasury Secretary Steven Mnuchin joining the board. The integration will fold Cybereason's XDR and digital forensics capabilities into LevelBlue's managed detection and response portfolio.

Why This Matters to Cloud Security Leaders:

This acquisition represents continued consolidation in the detection and response market, with implications for organizations running XDR agents in cloud workloads. The integration will likely result in bundled MDR/XDR/IR offerings with tighter sensor-to-SOC integration across cloud and endpoint environments.

For cloud security teams, M&A activity among security vendors creates operational risk around roadmap changes, SKU consolidation, and potential disruptions to existing telemetry pipelines. Organizations running Cybereason agents in containerized workloads (EKS, AKS, GKE) should proactively engage with vendor account teams to understand migration plans and ensure continuity of cloud-native detection capabilities.

Source:Business Wire press release; LevelBlue newsroom/blog

🎯 Cloud Security Topic of the Week:

The Kubernetes Incident Response Automation Gap: Why Manual Containment Fails in Regulated Environments

• One of the most pressing challenges in cloud incident response doesn't involve detection tools, threat intelligence, or even adversary tactics; it's the fundamental operational reality that containerized workloads, particularly Kubernetes clusters, remain extraordinarily difficult to contain during active incidents.

• This week's conversation with Damien Burks, who built an incident response platform from the ground up in financial services, reveals a sobering truth: despite billions spent on runtime security and CNAPP solutions, most organizations still manually respond to Kubernetes incidents, often taking hours to achieve containment that should happen in minutes.

Featured Experts This Week 🎤

• Damien Burks   Senior Cybersecurity Engineer (FinTech)

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

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

• EKS (Elastic Kubernetes Service): AWS-managed Kubernetes control plane service. While AWS manages the control plane, customers are responsible for worker nodes, networking, and security configurations.

• Private Cluster: A Kubernetes cluster configuration where the API endpoint is not accessible from the public internet, requiring requests to originate from within the same VPC or through VPN/VPC peering connections.

• CNAPP (Cloud-Native Application Protection Platform): Security platform category that combines multiple cloud security capabilities including CSPM, CWPP, and runtime protection for cloud-native applications.

• CSPM (Cloud Security Posture Management): Tools that continuously monitor cloud infrastructure for misconfigurations and compliance violations against security best practices and regulatory standards.

💡Our Insights from this Practitioner 🔍

Building Automated Incident Response for the Cloud Age (Full Episode here)

The conversation with Damien Burks reveals fundamental truths about incident response that every cloud security leader should internalize: detection is only half the battle, and in complex cloud environments, manual response processes guarantee unacceptable containment times.

1️⃣ From Hours to Minutes: The Case for Automation in Regulated Environments

Perhaps the most striking insight from Damien's experience comes from his work in financial services, where he built an incident response platform specifically designed for private EKS clusters. The contrast between manual and automated approaches is stark.

"Without the automation, in a regulated environment, it's gonna take you hours," Damien explains. "I was able to contain an EKS node within about 10 minutes."

This isn't merely about efficiency, it's about reducing blast radius during active incidents. In regulated industries, manual containment requires navigating multiple approval layers, establishing secure access to isolated environments, and coordinating across teams that may span different time zones. Meanwhile, adversaries continue to operate, exfiltrate data, establish persistence mechanisms, and pivot to additional targets.

The Lambda-based automation Damien developed addresses the core challenge of private clusters: "I had to create a Lambda function and basically automate the creation of the Lambda function to throw itself into the cluster's VPC, subnet, and then also the security group." This approach solves the networking isolation problem that defeats traditional security tools while maintaining security boundaries.

For security leaders, the lesson is clear: in 2025, incident response automation isn't optional it's a fundamental requirement for protecting cloud workloads, particularly in containerized environments where architectural complexity makes manual response impractical.

2️⃣ The Sophistication Gap: Why Commercial Tools Fall Short

Despite the proliferation of CNAPP and CSPM vendors promising comprehensive cloud security, Damien found a consistent gap when evaluating commercial platforms: "The majority of what I see is there isn't a sophisticated approach to automating incident response or containment activities and actions inside of those type of complex environments."

The problem stems from a fundamental misalignment between how security tools are architected and how modern cloud infrastructure actually works. Detection is relatively straightforward; runtime agents can identify suspicious processes, unauthorized network connections, or privilege escalation attempts. But responding to those detections in private, network-isolated clusters requires understanding Kubernetes networking, AWS VPC configurations, IAM-to-RBAC mappings, and the specific architectural choices each organization makes.

"Let's say for instance, you have a private cluster in EKS," Damien explains. "You cannot reach out. To, you have to be in the same networking configuration. Same VPC, subnet and Security Group in order for you to be able to interact with the Kubernetes cluster."

Commercial tools that work across multiple cloud platforms often sacrifice this level of deep integration for broader compatibility. As a result, they excel at telling you what's wrong but offer little help fixing it within the constraints of your specific architecture.

This creates an imperative for security teams: build custom automation for your specific environment, or accept that incident response will remain a manual, time-consuming process. Given the stakes particularly in the face of sophisticated nation-state actors as revealed in the F5 breach the choice should be obvious.

3️⃣ The Multi-Layer Authentication Challenge

One of the most technically complex aspects of Kubernetes incident response involves the intersection of cloud IAM and Kubernetes RBAC. Damien describes this challenge in detail:

"Whatever role that you're using, you gotta make sure that that role is mapped to the config map that's attached to an RBAC role within the Kubernetes cluster. If you don't have that there, then of course it's not going to give you the permissions or access that you need."

This represents a fundamental shift from traditional incident response. In conventional cloud environments, IAM permissions alone determine what actions you can perform. In Kubernetes, you need:

1. AWS IAM permissions to call EKS control plane APIs

2. Kubernetes RBAC roles defined within the cluster

3. aws-auth ConfigMap mappings linking your IAM identity to Kubernetes identities

4. Network connectivity to the API endpoint (either direct or through VPN/bastion)

5. Valid kubeconfig with authentication tokens

Each layer introduces complexity and potential failure points during incidents. Security teams must document these dependencies in advance and test incident response procedures regularly to ensure all pieces work together under pressure.

For organizations just beginning their Kubernetes security journey, Damien's experience offers a clear roadmap: "I need to understand Kubernetes first. I need to understand how it works internally." Without this foundational knowledge, incident response becomes guesswork and in regulated environments with strict compliance requirements, guesswork is unacceptable.

4️⃣ Prevention Through Developer Enablement

While much of the conversation focuses on response and containment, Damien emphasizes the critical role of prevention, particularly through secure development practices. His perspective reflects years of working across application security, cloud security, and DevSecOps:

"From an application security side, secure coding is definitely recommended. I mean, like it's enforced in a heavily regulated environment."

The layers of defense he describes represent a comprehensive approach:

1. Secure coding to prevent injection attacks and common vulnerabilities

2. Dependency scanning to identify vulnerable open-source components

3. Container hardening to limit the impact of application compromise

4. Kubernetes cluster configuration following best practices for network policies, service accounts, and pod security

This layered approach acknowledges a fundamental truth: no single security control will prevent all incidents. Instead, defense-in-depth reduces the attack surface at each layer and increases the work required for adversaries to achieve their objectives.

Notably, Damien emphasizes the importance of understanding the developer's perspective when implementing security controls: "Programming is something that a DevSecOps engineer can benefit from...you have to put yourself in a developer's shoes." This human-centered approach to security increases adoption of controls and improves the quality of security outcomes.

5️⃣ The Specialization Imperative: Why Multi-Cloud Is Chaos

Perhaps the most controversial insight from this week's conversation challenges the widespread push toward multi-cloud architectures and multi-platform expertise. Damien is blunt in his assessment:

"Multi-cloud to me just means chaos. I don't see that being, that's, to me, that's not realistic."

His reasoning stems from practical experience trying to maintain expertise across platforms: "How can you focus your time across multiple different cloud service providers and stay up to date with everything?"

AWS alone releases hundreds of service updates annually. Azure and Google Cloud maintain similar innovation velocities. For individual practitioners or even small security teams, attempting to master all three platforms simultaneously results in surface-level knowledge of everything and deep expertise in nothing.

"I think that you get good at one. You specialize in that one. And you lock into that one," Damien advises. "Growth is T-shaped. You specialize and then spread after the fact."

This specialization philosophy has important implications for both individual career development and organizational security strategy. For practitioners, deep expertise in one platform makes you more valuable than shallow knowledge of multiple platforms. For organizations, hiring specialists for each cloud platform you use produces better security outcomes than expecting generalists to secure everything.

The comparison to programming languages illustrates the point: "It's like learning a programming language, right? While the concepts of parallelism and concurrency, recursion, object oriented programming may be the same, the implementation is very different."

AWS IAM, Azure AD/Entra, and Google Cloud IAM all implement identity and access management, but the specific mechanisms, best practices, and edge cases differ significantly. Security teams that specialize can navigate these nuances; generalists inevitably make mistakes that sophisticated adversaries exploit.

6️⃣ Practical Guidance for Incident Responders Transitioning to Cloud

For incident response professionals with deep data center or traditional security backgrounds, Damien offers specific guidance on transitioning to cloud security:

"Go get the cloud certifications and learn the theoretical aspects of it. And then some CSPs have incident response practices and guides to help you navigate those things."

The certification path he recommends provides structured learning: AWS Solutions Architect Associate for foundational knowledge, followed by the Security Specialty certification for deeper security focus. But certifications alone aren't sufficient:

"Start playing around in your own project. And then from there you keep moving forward."

Hands-on experience with cloud services, combined with coding/scripting skills, enables incident responders to build the automation that makes cloud incident response practical. The theoretical knowledge from certifications provides context; the practical experience builds competence.

Importantly, Damien emphasizes that incident responders already possess critical knowledge that translates directly to cloud: "You have the knowledge and you have the background...You just have to understand how the cloud services all work together and how they can be architected."

This perspective should encourage traditional security professionals concerned about cloud skills gaps. The fundamentals of incident response, understanding attack vectors, analyzing logs, containing threats, and preserving forensic evidence remain constant. The challenge lies in applying those fundamentals within cloud architectures that differ from traditional data center environments

🧭 What Security Leaders Should Do Now

1. Automated incident response is no longer optional for containerized workloads, particularly in regulated industries where manual processes take hours

2. Private Kubernetes clusters require purpose-built automation that can operate within network isolation constraints

3. Commercial security platforms excel at detection but often lack sophisticated automated response capabilities for complex cloud architectures

4. IAM-to-RBAC mapping complexity in Kubernetes creates authentication challenges that must be solved in advance of incidents

5. Specialization in one cloud platform produces better security outcomes than surface-level multi-cloud expertise

6. Prevention through secure development practices remains crucial, but detection and response must assume prevention will sometimes fail

7. The cloud security role has expanded dramatically to include application security, container security, AI/ML security, and data governance

8. Time-to-containment metrics should be measured and optimized, with targets in minutes rather than hours

9. Build custom automation for environment-specific response actions while leveraging commercial tools for detection and visibility

10. Test incident response procedures regularly in environments that mirror production complexity

RELATED RESOURCES

• Kubernetes Security & Incident Response:

  • AWS EKS Best Practices Guide for Security: https://aws.github.io/aws-eks-best-practices/security/docs/

  • Kubernetes Hardening Guide (NSA/CISA): https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF

  • Falco Open Source Runtime Security: https://falco.org/

  • Kubernetes Security Checklist and Requirements: https://kubernetes.io/docs/concepts/security/

  DevSecOps & Cloud Security Learning:

  • DevSecOps Blueprint (Damien Burks): https://devsecblueprint.com

  • Cloud Security Alliance (CSA) Security Guidance: https://cloudsecurityalliance.org/research/guidance/

  • OWASP Cloud-Native Application Security Top 10: https://owasp.org/www-project-cloud-native-application-security-top-10/

Related Podcast Episodes 🎧

Incident Response of Kubernetes and how to Automate Containment

Question for you? (Reply to this email)

⚙️ Have you tested your Kubernetes incident response procedures in a private cluster environment, what was your time-to-containment?

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!

Shilpi Bhattacharjee

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

Hello from the Cloud-verse!

This week’s Cloud Security Newsletter Topic we cover - The Truth About AI in the SOC: From Alert Fatigue to Detection Engineering (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

This week in cloud and cyber, a ransomware recovery, a massive consulting leak, and a fresh wave of AI-driven initiatives redefine the operational risk landscape.

We examine how Asahi Group’s ransomware recovery, Red Hat’s GitLab breach, and Google’s AI Bug Bounty reveal the dual challenge of defending hybrid infrastructure while embracing generative AI.

Guiding this week’s theme are insights from Allie Mellen (Principal Analyst, Forrester) and Ashish Rajan (Cloud Security Podcast), who explore what they call the “SOC reset.”
“This is a moment of reset… the next five years are gonna be wild,” Allie shared, reflecting on how the role of detection engineering and AI are reshaping security operations.

📰 TL;DR for Busy Readers

• Asahi’s ransomware recovery underscores the cost of weak OT–cloud segmentation.

• Red Hat Consulting’s GitLab breach is a wake-up call for secret sprawl in vendor repositories.

• Google’s New AI bug bounty sets the stage for responsible AI security testing.

• SOC modernization means replacing alert queues with detection engineering + task-specific AI agents.

• Information sharing gaps caused by the U.S. government shutdown could hinder threat visibility; strengthen private channels.

📰 THIS WEEK'S SECURITY HEADLINES

1) Red Hat Consulting GitLab breach exposes 28k repos and 800+ client projects

What happened: A threat group calling itself “Crimson Collective” claims to have exfiltrated 570GB of data from Red Hat’s internal GitLab system, including customer source code, cloud configurations, and API keys. Red Hat has confirmed the incident and initiated rotations.

Why it matters: Consulting repositories often store privileged cloud access data, CI/CD secrets, and customer network maps making them high-value breach amplifiers.

Action: Rotate all credentials shared with Red Hat since 2020, revoke aged tokens, and ensure that contracts mandate time-based key expiry and minimal retention of customer data.

Sources: Dark Reading, BleepingComputer, SecurityWeek, Red Hat Official Statement

2) U.S. Cybersecurity Information Sharing Act expires amid government shutdown

What happened: The U.S. government’s temporary shutdown caused a lapse in the law granting liability protection for private-sector threat-intelligence sharing. Legal advisors warn this could reduce participation by up to 80% until renewal.

Why it matters: Enterprises depending on ISAC/ISAO threat feeds may see slower sharing and weaker correlation visibility.

Action: Use bilateral intelligence-sharing NDAs, reinforce internal intel routing, and diversify with commercial feeds and automated peer exchanges.

Sources: Washington Post, World Economic Forum

3) Qilin ransomware halts Asahi Group beer production; factories restart

What happened: The Qilin ransomware gang crippled Asahi’s production operations in Japan and Europe last week. The company has restored operations after isolating OT networks and rebuilding key systems.

Why it matters: Asahi’s experience reinforces that OT–IT convergence can magnify cloud risk. Cloud backups, API tokens, and telemetry data are frequent pivots for ransomware groups.

Action: Segment OT environments, apply immutable storage controls (S3 Object Lock / Azure Immutable Blob), and rotate long-lived service credentials.

Sources: Reuters, The Record

4) DraftKings reports new wave of credential-stuffing attacks

What happened: Sports betting platform DraftKings detected mass credential-stuffing campaigns using reused passwords and automated bots. The company enforced password resets and additional MFA challenges.

Why it matters: Consumer cloud apps remain low-hanging fruit for account takeover; credential reuse continues to undermine MFA adoption.

Action: Implement adaptive MFA, WebAuthn for high-risk actions, and layered rate-limiting on login APIs.

Sources: Reuters, BleepingComputer

5) Discord breach linked to compromised Zendesk third-party provider

What happened: Attackers compromised a third-party Zendesk instance used by Discord’s support team, accessing user emails and ticket data. Attribution points to the Scattered Lapsus$ Hunters group.

Why it matters: SaaS support ecosystems can become indirect threat paths; sub-processor security is an often-overlooked part of vendor governance.

Action: Require sub-processors to use SSO + FIDO2, apply retention limits, and add DLP controls to ticketing systems.

Sources: Check Point Research

6) Google launches AI Vulnerability Reward Program

What happened: Google introduced a dedicated AI bug bounty, offering up to $30,000 for findings such as prompt-injection exploits or unsafe agent actions in Gemini, Search, Workspace, and Google Home.

Why it matters: It formalizes a security-testing channel for generative AI acknowledging that AI-driven features are now a core enterprise attack surface.

Action: Include prompt-injection testing in application security programs, adopt policy-as-code to restrict model tool access, and define AI QA gates before production release.

Sources: The Verge, Google Security Blog

🎯 Cloud Security Topic of the Week:

SOC 2025: From Alert Queues to Detection Engineering and Task-Specific AI Agents

Traditional L1/L2/L3 SOC tiers are collapsing under alert fatigue and data deluge. Modern teams are shifting to detection engineering, data pipeline optimization, and AI-driven assistance.

“No one knows how to secure AI… this is a moment of reset,” said Allie Mellen, noting that GenAI will rewrite how security teams manage data and automation.

Ashish Rajan echoed the same sentiment: “AI should reduce L1 toil so people graduate to L2 work context building, incident narrative, and detection creation.”

Key transformation patterns:

• Flattened SOC structure: Move from queue-based triage to cross-functional detection pods that own rules, telemetry, and automation.

• Data-driven focus: Align log ingestion to active detections and cost efficiency feed only what fuels high-confidence analytics.

• AI as augmentation: Build specialized agents for triage and enrichment, not chatbots; each must have human oversight and explainability.

• Governance for AI tools: Enforce “least agency” for AI restrict agent tool access, monitor decisions, and track data provenance.

30-minute actions:

1. Map detections to telemetry sources; drop unused feeds to a cheaper lake tier.

2. Define least-agency policies for internal or vendor AI integrations.

3. Convert repetitive alert playbooks (phishing or brute-force triage) into task agents with QA oversight.

Featured Experts This Week 🎤

• Allie Mellen Principal Analyst, Forrester

• Ashish Rajan - CISO | Co-Host AI Security Podcast , Host of Cloud Security Podcast

Definitions and Core Concepts 📚

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

• Detection Engineering: Analysts who both create and maintain detections; a hybrid of developer and responder.

• Security Data Lake: Structured, cost-efficient telemetry storage aligned with OCSF and long-term analytics.

• Agentic AI: Task-specific AI built for defined security workflows with explainability and guardrails.

• Least Agency: Limiting AI or automation access to only necessary tools and scopes.

• AI Observability: Capturing prompt inputs, tool calls, and decisions for monitoring and auditing model behavior.

💡Our Insights from this Practitioner 🔍

The Great SOC Reset: From Human Bottlenecks to Human-Guided Automation

Security operations in 2025 are at a breaking point. The sheer velocity of alerts, hybrid data sources, and AI-generated telemetry has outpaced the human SOC’s linear model. As Allie Mellen puts it, “No one knows how to secure AI… this is a moment of reset.”

This reset isn’t about replacing people, it's about re-architecting how they operate. The modern SOC must behave like an engineering team: building, testing, and shipping detections and automations the same way developers ship code.

1️⃣ Why Traditional SOC Models Are Failing

Forrester’s latest field data shows the L1/L2/L3 hierarchy breaks under cloud-scale telemetry. Analysts spend 60–70% of their time on enrichment, correlation, and false-positive filtering tasks that machines can now automate.

Allie notes that “the structure evolving to detection engineer should stay consistent regardless of AI.” This means moving from a tiered hierarchy to cross-functional detection pods that own their use cases end-to-end: data sourcing, rule logic, validation, and metrics.

When incidents like Asahi’s ransomware outbreak occur, success depends not on alert volume but on how fast those pods can pivot detections from IT to OT telemetry proving architecture beats manpower.

2️⃣ The Rise of the Detection Engineer