Hello from the Cloud-verse!

This week’s Cloud Security Newsletter topic: Reachable vs. Exploitable — The Distinction That Decides What You Actually Fix (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 week did not hand us a single marquee breach. It handed us five variations on the same failure: the credential or key an attacker wants is now reachable, and the only question left is whether the surrounding context makes it exploitable. FortiBleed turned tens of thousands of exposed FortiGate firewalls into a working credential feed for two ransomware crews. A Langflow authorization-bypass flaw let one operator read other tenants' flows and walk off with their LLM and AWS keys. Fake Paysafe and Skrill SDKs sat in build pipelines returning fake success while reading AWS and GitHub tokens out of the environment.

That mechanic is exactly what Harry Wetherald, co-founder and CEO of Maze, spends his days on. His argument: reachability tells you a vulnerability might be exploitable; exploitability tells you an attacker actually has everything needed to trigger it — and reasoning across code and cloud context to answer the second question is the shift AI finally makes possible.[Listen to the episode]

⚡ TL;DR for Busy Readers

• 🚨 FortiBleed is now a ransomware pipeline. SOCRadar tied the mass FortiGate credential theft (~430,000 firewalls targeted) to the INC and Lynx crews. Reset FortiGate admin and VPN credentials and enforce MFA today — the exposure already happened at config-read time.

• 🚨 A CVSS 6.1 flaw did the real damage. CISA's July 7 KEV batch includes Langflow's cross-tenant IDOR (CVE-2026-55255), used to steal other tenants' LLM and AWS keys, alongside a CVSS 10.0 ColdFusion flaw exploited within hours. Patch by July 10; pull exposed Langflow behind auth and rotate every reachable key.

• Fake payment SDKs raided build pipelines. 17 typosquatted Paysafe/Skrill/Neteller packages on npm and PyPI harvested AWS, GitHub, and npm tokens from CI runners. Audit runner env-var scopes; move build secrets to short-lived OIDC.

• Your own bucket can be turned against you. Unit 42 detailed a global-namespace bucket-hijacking flaw that reroutes live data streams to an attacker-owned bucket with a reused name. Never delete-and-forget a bucket name referenced anywhere.

• ADFS can hand over a live signing key. Mandiant showed active ADFS token-signing keys recoverable from machine DPAPI, enabling MFA-bypassing SAML forgery. Audit AutoCertificateRollover state and certificate drift.

📰 THIS WEEK'S TOP 5 SECURITY HEADLINES

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

1.  FortiBleed credential-theft campaign confirmed as a ransomware pipeline for INC and Lynx

Primary source: BleepingComputer 
Reporting: SOCRadar STRU · Recorded Future · SecurityWeek

What Happened

SOCRadar's threat research unit tied the mass FortiGate credential-theft campaign known as FortiBleed to the INC and Lynx ransomware operations. This is the first confirmed link between the harvesting and downstream ransomware deployment. Investigators found an operator with FortiBleed infrastructure access logged into both the INC and Lynx negotiation panels, and INC victims overlapping with FortiBleed data. The campaign is assessed to have targeted more than 430,000 internet-facing FortiGate firewalls, deployed packet sniffers on roughly 19,000 devices, and cracked configuration-file hashes into verified working administrator credentials for tens of thousands of systems.

Why It Matters

The FortiGate SSL-VPN is the identity edge for most hybrid enterprises, and a cracked admin credential there is not a vulnerability to patch because it is a valid login that survives patching. The credential inventory is now demonstrably feeding two active ransomware crews, turning "we have MFA-less VPN admins" from a hygiene finding into a named, in-progress ransomware precursor.

Action for defenders: Reset all administrative and VPN credentials on internet-facing FortiGate devices, enforce MFA on every admin and remote-access account, and pull VPN auth logs for anomalous admin logins and any sign of packet-capture tooling.

2. CISA adds four exploited flaws to KEV, including a Langflow cross-tenant IDOR that steals LLM and AWS keys

Primary source: CISA KEV alert 
Reporting: The Hacker News 
Analysis: Sysdig

What Happened

On July 7 CISA added four actively exploited flaws to the KEV catalog with a July 10 federal deadline: Adobe ColdFusion path traversal CVE-2026-48282 (CVSS 10.0), two JoomShaper/PageBuilder unauthenticated file-upload RCEs (CVE-2026-56290 and CVE-2026-48908, both CVSS 10.0), and Langflow authorization-bypass IDOR CVE-2026-55255 (CVSS 6.1). Sysdig reported a single operator chaining the Langflow IDOR with an unauthenticated RCE (CVE-2026-33017) against internet-exposed instances between June 22 and June 25, using the cross-tenant IDOR to read other tenants' flows and steal their LLM-provider and AWS keys. The ColdFusion flaw was exploited within hours of disclosure.

Why It Matters

The CVSS ordering is inverted from the risk — the 6.1 Langflow bug, not the 10.0s, is the one that handed an attacker a live credential set for someone else's cloud account. An AI-orchestration platform is a credential vault, and a cross-tenant IDOR against it is a supply route into every cloud those flows touch.

Action for defenders: Patch all four by July 10; for Langflow, pull any internet-exposed instance behind authentication immediately and rotate every LLM-provider and cloud key any hosted flow could reach — treat exposed instances as already harvested.

🛠 If you only do one thing this week: Find every internet-exposed AI-orchestration or agent platform (Langflow and anything like it), put it behind authentication, and rotate every LLM and cloud key it could reach. This week's Langflow story is the proof that a "medium" CVSS flaw on a credential-holding platform is the one that actually converts to cloud compromise — reachable became exploitable the moment those keys were sitting there.

☁️ 3. Fake Paysafe, Skrill and Neteller SDKs on npm and PyPI harvest CI/CD secrets

Primary source: Socket 
Reporting: BleepingComputer · The Hacker News

What Happened
Socket flagged a coordinated cluster of 17 malicious packages — 13 on npm, 4 on PyPI, typosquatting the Paysafe, Skrill and Neteller payment SDKs, published July 7. The packages expose the expected payment APIs and return fake success responses while collecting environment variables and exfiltrating them, including via an Ngrok endpoint and an AWS-hosted C2. Captured variables include PAYSAFE_API_KEY, AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN and NPM_TOKEN. The npm packages were flagged as malicious within roughly six minutes of publication, each shipping four rapid versions with per-version obfuscation keys to defeat hash-based tracking.

Why It Matters
The target is not the payment platform, it is the CI runner, a package that pretends to process payments while reading AWS and GitHub tokens out of the build environment turns a routine install into cloud-credential exfiltration. The six-minute flag time helps teams using package firewalls and does nothing for teams that pull latest on every build, because the payload runs at install.

Action for defenders
Block the named packages, audit CI/CD environment-variable scopes so a compromised install cannot read cloud or registry tokens, and move build-time secrets to short-lived OIDC tokens rather than static keys in the runner environment.

🏥 4. Unit 42 details a cloud bucket-hijacking flaw that reroutes your data to an attacker-owned bucket

Primary source: Palo Alto Networks Unit 42 
Reporting: The Hacker News

What Happened

Unit 42 described a bucket-hijacking technique affecting major cloud providers, which it characterizes as a fundamental architectural issue rather than a single-vendor bug. Because storage-bucket names occupy a globally unique namespace, an attacker who learns the name of a decommissioned or deletable bucket can delete it and immediately recreate it under their own account with the same name, that was silently rerouting any data stream still writing to that name (critical logs, telemetry, sensitive data) into attacker-controlled storage. Unit 42 notes the echo of Aqua Security's 2024 "Bucket Monopoly" method and says there is no evidence of in-the-wild abuse to date.

Why It Matters

The trust assumption being broken is that a bucket you configured as a destination stays yours. Global-namespace reuse means a name you stop owning can become someone else's inbound pipe without a single credential being stolen, which reframes bucket naming and lifecycle from housekeeping into a data-exfiltration control.

Action for defenders
Inventory every hard-coded bucket destination in logging, backup, and data pipelines; never delete-and-forget a bucket whose name is referenced anywhere, and adopt naming with account-scoped random suffixes so a released name cannot be re-registered as a data sink.

🛡️ 5. Mandiant recovers active ADFS token-signing keys from machine DPAPI, enabling MFA-bypassing SAML forgery

Primary source: Mandiant / Google Cloud Threat Intelligence 
Reporting: SecurityBrief

What Happened

Mandiant disclosed that in ADFS deployments where AutoCertificateRollover is disabled and certificates are rotated manually, configuration drift can leave an active token-signing key exposed in machine-scoped DPAPI while the Windows Internal Database still references a stale certificate. An attacker who recovers that live private key can forge SAML assertions for any user in the federated environment, reaching ADFS-tied applications including Microsoft 365 and Entra ID while bypassing MFA. The technique avoids touching LSASS and the live ADFS process, reducing the telemetry most monitoring relies on. Mandiant frames it as an evolution of the Golden SAML attack.

Why It Matters

This turns a documentation-level operational detail — "we rotate ADFS certs by hand" into a full cloud-identity compromise, because the forged SAML token is trusted by every downstream cloud app federating through ADFS. The MFA bypass is the sharp edge: the control most enterprises treat as their identity backstop is not in the path when the assertion itself is signed with a valid key.

Action for defenders: 
Audit ADFS for AutoCertificateRollover state and any drift between the certificate the service is actively signing with and the record in the configuration database; where manual rotation is used, confirm no orphaned active signing key remains recoverable from machine DPAPI.

6.  European Commission presents an Action Plan on Cybersecurity and Artificial Intelligence

Primary source: European Commission 
Reporting: Commission press corner · MLex

What happened: On July 7 the European Commission presented its Action Plan on Cybersecurity and Artificial Intelligence, framed around defending against AI-accelerated attacks and enabling safe use of AI in security. It directs the Commission to strengthen Europe's capacity to evaluate AI models before they enter the EU market in line with the AI Act, to work with ENISA on a European Blueprint for secure access to advanced AI systems for cybersecurity, and to stand up a secure platform to test AI for cybersecurity by the end of 2026. Analysts note the plan emphasizes implementing existing frameworks rather than new legislation.

Why it matters:  Pre-market model evaluation tied to the AI Act moves AI security from a vendor-attestation question to a market-access condition, which changes procurement for any cloud or security platform shipping model capabilities into the EU. Expect model-provenance and secure-access-to-AI questions to surface in supervisory conversations the way DORA incident-reporting expectations did this year.

Action for defenders: If you operate in or sell into the EU, map which AI capabilities in your cloud stack will fall under AI Act pre-market evaluation, and track the ENISA secure-access Blueprint as an input to AI governance and vendor assessment.

🎯 Cloud Security Topic of the Week:

Reachable vs. Exploitable — The Distinction That Decides What You Actually Fix

Two of this week's stories are token problems wearing different clothes. Azure CLI issued tokens through an OAuth flow that never met the policy; SimpleHelp accepted tokens it never verified were signed. Kahn's episode is the conceptual layer under both: as autonomous agents multiply, the same two questions is this identity real, and is this access still appropriate — stop being solved by static permissions and start requiring standards built for identities whose goals change every day. The through-line for the week is that the management and identity plane is where the damage now lands, and agent identity is the version of that problem heading straight for every enterprise that shipped an agent this quarter. [Listen to the full episode →]

Featured Experts This Week 🎤

• Harry Wetherald — Co-founder & CEO, Maze

• 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:

• Reachability: Whether an attacker can at least get to the vulnerability — in cloud, roughly whether it can be reached from the network; in code, whether the vulnerable function is actually active rather than dead code. Signals only that something might be exploitable.

• Exploitability: Whether all the context is present for an attacker to actually trigger the specific vulnerability (e.g., can a triggering request pass input sanitization and surrounding controls). The deeper determination AI now automates.

• Cross-tenant IDOR: An Insecure Direct Object Reference where an authenticated user references another tenant's object (here, another Langflow tenant's flow ID) to read data — in CVE-2026-55255, other tenants' LLM and AWS keys.

• FortiBleed: The name for the mass credential-compromise campaign against internet-facing FortiGate firewalls, extracting configuration files and cracking stored credential hashes, now linked to INC and Lynx ransomware.

• Golden SAML: An attack in which a stolen ADFS token-signing key is used to forge SAML assertions for any federated user, bypassing MFA; Mandiant's machine-DPAPI key recovery is an evolution of it.

• Bucket hijacking (global-namespace reuse): Re-registering a released, globally unique storage-bucket name under an attacker account to silently receive data still being written to that name.

• SCA / SAST: Software Composition Analysis (third-party/dependency code, e.g., CVEs) and Static Application Security Testing (your own code). Maze Code ships one product for each.

• "Security brain": Wetherald's term for a persistent, enriched, cached context layer plus threat model and human-defined priorities that a coding agent queries before and while writing code — his proposed successor to "shift left."

This week's issue is sponsored by Maze

💡Our Insights from this Practitioner 🔍

Reachable vs. Exploitable, and the AI-Native AppSec Program

Harry Wetherald has spent two years building AI agents that reason across code and cloud. The through-line: the tooling finally exists to answer the question that actually matters, but only for teams that treat reliability and cost as first-class engineering problems rather than vendor talking points.

1. Reachable means "the code is alive." Exploitable means "the attacker has everything they need."

Wetherald's opening move is to separate two words the industry uses interchangeably. Reachability is a blunt filter; exploitability is the full-context judgment call.

"So that difference really is a difference between reachable, but is the code alive i, in the simplest terms? And exploitable is, is all the context kind of there for the attacker to actually be able to trigger the specific vulnerability?"

In code, that means first filtering out dead code, then testing whether a request that triggers the vulnerability can actually pass input sanitization and the controls around the application. The same logic applies in cloud and it maps directly onto this week's Langflow story, where "reachable" and "exploitable" were only a set of exposed keys apart.

 2.  Untuned AI is confidently wrong, the failure mode moved from "obvious false positive" to "detailed, plausible false positive"

Old rule-based scanners drowned teams in obvious noise. Out-of-the-box models are more accurate on a first pass but wildly inconsistent run to run, and their errors now arrive wrapped in convincing detail.

"they give very confident but sometimes wrong results 'cause they'll go very deep in an investigation, take one wrong turn along the way, and then give you the wrong answer."

The fix is training agents to run investigations reliably and to catch their own mistakes, plus heavy monitoring and validation on top. Run the same agent on the same data in a poorly built system, Wetherald notes, and it can return a different answer five times out of ten.

3. The frontier labs' security tools test as inferior and more expensive

One of the sharper takes in the conversation. Wetherald argues the lab-built security offerings are side projects that can't match tools honed for a year or two on a specific domain, and — unusually — they cost more, because the labs' incentive is to sell tokens.

"what we've seen from Claude Code Security and from other, the Google and, and OpenAI equivalents is when you test them, they're far inferior to the more domain-specific tools that people have spent a year, two years honing, refining, training, et cetera."

His buying advice: evaluate them the way you once evaluated bundled Microsoft or Google security — fine if "good enough" for the use case, but if security is strategic, go to specialists and avoid locking into one lab.

4.  Cost IS accuracy, the case for 100x optimization, not 20%

Because customers have a fixed budget ceiling, every place you cut cost without losing accuracy frees budget to spend on deeper analysis elsewhere. Cost engineering isn't a margin lever; it's the accuracy lever.

"if you run Mythos, uh, on every PR for a 10,000-person software company, it comes out as $52 million a year."

Wetherald's grounding story: the first Maze cloud run at a Fortune 100 customer extrapolated to roughly "$4 million a week" — about the company's total funding at the time — which forced cost to become a core product constraint. The takeaway for buyers is to ask how a vendor cuts cost by ~100x (dynamic routing across expensive and cheap models, or no model at all for some steps), not by a token percentage.

5. The number-one buyer red flag is a black box

Because LLM-based tools inherently produce long chains of reasoning, a modern AI security product that behaves like an opaque box has no excuse. Auditability — "how did you reach that decision" — is the thing to demand.

"If you're talking to an, like, AI-based product and it looks like a black box and it's not telling you in really clear detail what it's doing, I would run a mile."

His second buyer test: ask what the vendor built on top of the out-of-the-box models. If anyone could replicate it by pointing a frontier model at a codebase with a few prompts, the vendor has added nothing.

6. Tear down the AppSec/cloud wall — and put a "security brain" behind the coding agent

Wetherald argues the historic separation of AppSec and cloud security was an artifact of tooling, not of the risk — the same underlying issue is often handled by two teams. LLMs act as a translator across the two domains, so the wall should come down.

"We shouldn't be sat here in five years' time and going, our AppSec and our cloud security program runs completely separately."

Looking forward, he sees coding agents (Cursor, Claude Code, Devin) needing a security "brain" to call — an enriched, cached context layer plus the org's threat model and priorities — rather than each agent crawling raw data in the moment it writes code. That, in his view, is the useful successor to "shift left."

7. Fully delegate the verifiable decisions; keep humans on remediation — for now

Where a decision is logically verifiable, Wetherald wants humans out of the loop, because it has to run across potentially millions of findings.

"where it's kinda logically verifiable, so exploitability ... in both camps, cloud and AppSec ... I don't think we should be having humans in the loop of that decision."

Remediation is where teams still want a human on the final step. The path to more automation is data-driven, not a switch: if an action has succeeded several times, consider automating the next one, starting with simple, well-understood code and cloud fixes.

📚 RELATED RESOURCES 🎧

• CISA Known Exploited Vulnerabilities Catalog — authoritative list of what's being exploited; the July 7 additions carry a July 10 deadline

• Palo Alto Networks Unit 42 — Cloud Bucket Hijacking Risks — the global-namespace reuse technique in detail

• Mandiant — Recovering Active ADFS Signing Keys via Machine DPAPI — the Golden SAML evolution and detection guidance

• Socket — npm/PyPI Payment-SDK Typosquat Campaign — package list and IOCs

• European Commission — Action Plan on Cybersecurity and AI — the policy backdrop to the week's AI-exposure stories

• Maze — Harry Wetherald's company; recently launched Maze Code (SCA + SAST-style AI agents)

Podcast Episode

• Cloud Security Podcast  : Episode with Harry Wetherald

Question for you? (Reply to this email)

🤔  When you triage a finding, do you stop at "reachable" or do you actually confirm it's exploitable before it costs your team a week?

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: Agent Identity and the Control Plane — Why "MFA Is On" Stopped Being the Right Question(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 week did not produce one dramatic incident. It produced a cluster with a single tell: SimpleHelp remote management, Cisco Unified Communications Manager, Kemp LoadMaster, Oracle PeopleSoft's environment-management hub, and the Azure CLI login path all took direct fire in five days. These are not customer-facing apps. They are the interfaces that administer other systems, and the reader's exposure this week is less about any one CVE than about which admin surfaces are internet-reachable and whether their authentication actually covers every path in.

Underneath that runs a sharper thread. In the Azure CLI spray and the SimpleHelp bypass, multi-factor authentication was present and got skipped anyway, not brute-forced but routed around, through a deprecated OAuth flow in one case and a forged, unsigned identity token in the other. That is the exact failure mode Ely Kahn spends this episode on — the Chief Product Officer at Okta, who joined five months ago specifically to work on agent identity after co-founding Sqrrl (acquired by AWS), launching AWS Security Hub, and serving as CPO at SentinelOne. His argument: the building blocks of identity have not changed, but the environment has, and the place teams keep getting hurt is the long-lived, overprivileged token.[Listen to the episode]

⚡ TL;DR for Busy Readers

• Nissan employee data breached via Oracle PeopleSoft zero-day (CVE-2026-35273): the victim-disclosure phase of a management-hub flaw — HR system-of-record for four countries reached through one internet-exposed admin component. Confirm no PSEMHUB instance is externally reachable.

• 🚨 Azure CLI password spray hit 78 accounts by routing around Conditional Access: 81M attempts against the ROPC OAuth flow that issues tokens without an interactive MFA prompt. Set Conditional Access to All cloud apps / All client app types and block ROPC.

• 🚨 SimpleHelp RMM OIDC bypass (CVE-2026-48558) added to KEV, July 2 deadline: the tool checked that a token existed but never checked it was signed by the real issuer — a supplier-shaped blast radius across every downstream customer. Patch above 5.5.15 and rotate reachable cloud/AI keys.

• Cisco Unified CM SSRF (CVE-2026-20230) actively exploited, federal deadline already passed June 28: blast radius decided by a config flag (WebDialer enabled), not a version number. Query for WebDialer enablement, not just patch level.

• Kemp LoadMaster pre-auth RCE (CVE-2026-8037) now has a public exploit: root on a load balancer is a position above the apps it fronts. No confirmed in-the-wild exploitation yet — patch or restrict the management API before scanning catches up.📰 THIS WEEK'S TOP 5 SECURITY HEADLINES

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

1.  Nissan discloses employee data breach from the Oracle PeopleSoft zero-day (CVE-2026-35273)

Primary source: BleepingComputer 
Reporting: SecurityWeek, Infosecurity Magazine

What Happened

Nissan North America notified current and former employees that attackers exploiting Oracle PeopleSoft zero-day CVE-2026-35273 accessed personnel records. The flaw is a CVSS 9.8 unauthenticated SSRF-to-RCE bug in the PeopleTools Environment Management Hub (PSEMHUB); Oracle shipped emergency mitigations on June 10. Nissan filed its breach notification June 25, with public reporting on June 29. Researchers attribute the campaign to a cluster tracked as UNC6240, linked to the ShinyHunters extortion group; exposed data spans employees in the US, Canada, Mexico, and Brazil and may include payroll, banking, and government ID numbers.

Why It Matters

 The CVE itself was covered in the June 18 brief; this is the victim-disclosure phase, where the enterprise cost of a management-hub flaw becomes visible. PSEMHUB administers PeopleSoft environments, so one exposed instance handed attackers the HR system of record for four countries. The exploitation window (May 27 to June 9) closed before Oracle's June 10 mitigation, so patch-on-disclosure was already too late for anyone internet-exposed. Programs that inventory only production customer apps and treat internal HR/ERP admin components as low priority keep learning about these through a breach-notification letter.

Action for defenders:  Confirm whether any PeopleSoft PSEMHUB instance is reachable from outside your management network; if PeopleTools is at 8.61/8.62, verify the June 10 Oracle mitigation is applied and hunt for SSRF-pattern requests to PSEMHUB back to late May.

2. Azure CLI password-spray campaign compromised 78 accounts by routing around Conditional Access

Primary source: Huntress 
Reporting: The Hacker News, SecurityWeek

What Happened

Huntress documented an automated password-spray campaign against Microsoft's Azure CLI login path, running more than 81 million attempts between June 12 and June 26 from an IPv6 range operated by LSHIY LLC (AS32167). At least 78 accounts across roughly 64 organizations were compromised. The attackers replayed breach-corpus username and password pairs against the Resource Owner Password Credentials (ROPC) OAuth flow, which posts credentials straight to the /token endpoint and issues tokens without an interactive MFA prompt.

Why It Matters

This is MFA that was configured and still bypassed. The Conditional Access policies at the affected orgs were real but scoped, enforced for admin portals or named apps rather than "All cloud apps" and "All client app types," and ROPC lives in the gap. The control did not fail as code; it failed as coverage. This is the news-side proof of what Kahn argues in the interview: the question stopped being "is MFA on?" and became "which authentication flows can reach a token without ever hitting the policy?"

Action for defenders: In Entra, set Conditional Access to All cloud apps / All client app types, enable the userStrongAuthClientAuthNRequired tenant setting to block ROPC outright, then pull sign-in logs for ROPC/legacy-auth token grants over the June 12–26 window.

🛠 If you only do one thing this week: Pull your Entra sign-in logs for ROPC and legacy-auth token grants over the June 12–26 window, then flip Conditional Access to All cloud apps / All client app types. Both this week's identity incidents (Azure CLI and SimpleHelp) succeeded by reaching a token through a path the policy never covered — closing the uncovered flow is the 30-minute action that maps directly to the week's editorial thesis.

☁️ 3. SimpleHelp RMM OIDC bypass (CVE-2026-48558) added to KEV, exploited to drop the Djinn stealer

Primary source: CISA KEV 
Reporting: Help Net Security 
Analysis: Arctic Wolf, Horizon3.ai

What Happened
CISA added CVE-2026-48558 to the KEV catalog on June 29 with a July 2 deadline. The flaw is an OIDC authentication bypass in SimpleHelp RMM (versions 5.5.15 and earlier, plus 6.0 pre-releases): when OIDC is enabled, the software does not verify the cryptographic signature on identity tokens, so a remote unauthenticated attacker can forge a token, land a fully authenticated technician session, and bypass MFA in some configurations. Blackpoint Cyber documented attackers using the forged session to deploy a Node.js loader (TaskWeaver) and a new credential stealer (Djinn).

Why It Matters
RMM is a supplier-shaped blast radius. SimpleHelp is widely used by MSPs and IT-service providers, so one forged technician token is not one endpoint but every downstream customer that provider reaches. The failure is precise: the tool checked that a token existed but never checked it was signed by the real issuer, so MFA sat behind a step the attacker could skip. This is Kahn's identity-proof point made concrete knowing a session is who it claims to be is the whole game, and reporting that the forged access harvested cloud and AI API keys turns a remote-support compromise directly into cloud-account access.

Action for defenders
If you run SimpleHelp, patch above 5.5.15 immediately and rotate any cloud/AI provider keys reachable from serviced endpoints; if a vendor uses SimpleHelp to support you, ask them today which version they run and whether they have hunted for TaskWeaver/Djinn indicators.

🏥 4. Cisco Unified CM SSRF (CVE-2026-20230) added to CISA KEV with a June 28 federal deadline

Primary source: CISA KEV alert (2026-06-25) 
Reporting: BleepingComputer, The Hacker News

What Happened

CISA added CVE-2026-20230, a CVSS 8.6 server-side request forgery bug in Cisco Unified Communications Manager, to the KEV catalog on June 25 and set a June 28 remediation deadline for federal agencies under BOD 26-04. Cisco patched the flaw on June 3; the SSRF targets the WebDialer service and lets an unauthenticated attacker write arbitrary files to the underlying OS, which chains to root-level code execution. The security firm Defused reported in-the-wild exploitation beginning the weekend of June 21–22, after a public write-up exposed the file-write path.

Why It Matters

The exploit reached active use only after a proof-of-concept made the SSRF-to-file-write step concrete - a live example of the disclosure-to-exploitation gap collapsing once someone publishes the hard part. Blast radius here is set by a configuration flag, not a version number: only deployments with WebDialer enabled are exploitable, and WebDialer is off by default. That inverts the usual triage. A program sorting purely by CVSS will either over-rotate on patched-but-not-vulnerable hosts or miss the enabled ones.

Action for defenders
Query your Unified CM estate for WebDialer enablement rather than version alone; where it is on and not needed, disable it, and confirm the June 3 Cisco patch is applied on any host exposing the service.

🛡️ 5. Public exploit chain drops for critical Progress Kemp LoadMaster pre-auth RCE (CVE-2026-8037)

Primary source: watchTowr Labs 
Reporting: The Hacker News, Cyber Security News

What Happened

On June 29, watchTowr Labs published a full technical write-up and working exploit chain for CVE-2026-8037, a CVSS 9.8 pre-authentication RCE in Progress Kemp LoadMaster. The bug is an uninitialized-memory/string-termination flaw in the escape_quotes() function meant to sanitize input before it reaches a shell command; anyone who can reach the appliance API can run arbitrary commands as root with no credentials. Progress published its advisory on June 4 (the flaw was reported by Syed Ibrahim Ahmed of TrendAI Research) and says it has no reports of exploitation, but a working PoC is now public.

Why It Matters

A load balancer sits in front of application traffic and terminates sessions, so root on the LoadMaster is a position above the apps it fronts, not beside them. The clock started June 29: the vendor advisory sat for three-plus weeks at low urgency, and the watchTowr publication is the event that converts it into a mass-scan target because it hands attackers the exact primitive. This is the pre-exploitation window in real time — patch status, not incident response, is still the lever, but only until scanning catches up. To be precise: there is no confirmed in-the-wild exploitation yet, so treat this as a public-PoC story, not an active-exploitation one.

Action for defenders: 
Treat any internet-reachable Kemp LoadMaster management API as urgent: apply the Progress fix from the June 4 advisory, and if patching lags, restrict API access to a management network now rather than waiting for exploitation reports.

6. Aflac Japan discloses breach affecting 4.38 million customers

Primary source: SecurityWeek 
Reporting: The Japan Times, Security Affairs

What happened: Aflac Life Insurance Japan, the Japan subsidiary of US insurer Aflac, disclosed on June 30 that attackers reached its customer website and related systems, exposing data on about 4.38 million customers and roughly 40,000 agencies. Intruders accessed systems repeatedly between June 15 and June 25, when a traffic surge revealed the activity. Exposed records include names, addresses, dates of birth, and policy details, plus bank account numbers used for premium payments for about 230,000 customers; credit card and national ID numbers were not affected, and Aflac says its US systems are not involved.

Why it matters:  For this reader base the signal is subsidiary-and-parent risk, not the raw record count. A US-headquartered insurer's non-US subsidiary was breached on infrastructure the parent likely does not administer or monitor directly, yet the parent's name carries the disclosure. The month of dwell between first access (June 15) and detection-by-load-surge (June 25) is the tell: detection came from a performance anomaly rather than a security control, which is what happens when a subsidiary sits outside the parent's monitoring perimeter. The banking data for 230,000 customers is the part that turns this from notification into fraud exposure.

Action for defenders: If your org has subsidiaries or acquired entities on separately managed stacks, confirm they feed the same detection and logging pipeline as the parent; a load-driven discovery a month in is evidence the perimeter did not extend to them.

🎯 Cloud Security Topic of the Week:

Agent identity: who the agent is, what it can reach, what it's doing and how do you offboard it?

Two of this week's stories are token problems wearing different clothes. Azure CLI issued tokens through an OAuth flow that never met the policy; SimpleHelp accepted tokens it never verified were signed. Kahn's episode is the conceptual layer under both: as autonomous agents multiply, the same two questions — is this identity real, and is this access still appropriate — stop being solved by static permissions and start requiring standards built for identities whose goals change every day. The through-line for the week is that the management and identity plane is where the damage now lands, and agent identity is the version of that problem heading straight for every enterprise that shipped an agent this quarter. [Listen to the full episode →]

Featured Experts This Week 🎤

• Ely Kahn — Chief Product Officer, Okta

• 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:

• Non-human / AI-agent identity: the identity assigned to a software agent or workload rather than a person. Kahn's point is that the building blocks (least privilege, governance, monitoring) are the same as for humans, but agents get new goals constantly, so static permission models break.

• ROPC (Resource Owner Password Credentials): an OAuth flow that posts a username and password straight to the token endpoint and returns a token without an interactive MFA prompt — the flow the Azure CLI campaign abused to sit in the gap left by scoped Conditional Access.

• OIDC (OpenID Connect): an identity layer on top of OAuth. The SimpleHelp flaw was an OIDC bypass: the software accepted identity tokens without checking their cryptographic signature, so a forged token passed as authentic.

• XAA (Cross-App Access): as Kahn describes it, "an extension of OAuth" and an open standard led by Okta with partners including Anthropic, letting apps and agents "securely pass the baton to one another" without static master keys or per-action consent pop-ups. Now built into the MCP server protocol. Developer resource: xaa.dev.

• ID-JAG (identity assertion grant): the mechanism under XAA that puts an identity provider in the middle of app-to-app interactions and grants access without consent pop-ups.

• SPIFFE: gives every workload or agent a unique, verifiable digital identity, cryptographically encoded into a short-lived document (typically an X.509 certificate) used to prove identity within an environment.

• Intent-based security: a model with zero standing privilege where, at tool-invocation time, an assessment checks whether the tool call aligns with the agent's intent; a dynamic permission is generated for that single call and revoked on completion.

• Guardian agents: agents that assess whether a given tool invocation is acceptable and aligned to what the monitored agent was set up to do — the enforcement mechanism when human approval can't scale.

• Kill switch / universal logout: an Okta capability, originally for human identities and now extended to agents, to cut off a compromised agent's access immediately and universally.

• MCP (Model Context Protocol): the standardized way agents connect to external tools and data; Kahn notes XAA is now part of the MCP server protocol maintained by Anthropic.

This week's issue is sponsored by Maze

💡Our Insights from this Practitioner 🔍

Agent Identity and the Control Plane

Kahn frames agent identity as a paradox: in the mechanics it is not new, and in the environment it is completely new. "In some ways it's not different at all in that you need, uh, least privileged identities. You need to govern those identities through things like IGA. You need to provision access to privileged resources through things like PAM." The building blocks — IGA, PAM, ISPM, ITDR — carry over. What breaks is the assumption underneath them.

1. The breach is the long-lived, overprivileged token

Human roles are stable enough to tolerate static permissions. Agents are not. "You're giving them new problems to solve all of the time, and the most effective agents are the ones that are gonna be very autonomous. And it's very hard to predefine every permission that autonomous agent may need." The workaround teams reach for is the dangerous one:

"People give agents long-lived, broadly scoped permissions to basically do anything that they may need to do in the future, and this is where companies can get into trouble."

Kahn's example is a recent one he keeps unnamed on purpose. "There was a big one in April, a vibe coding company had their entire source code" stolen:

"They had their entire source code stolen basically because of an attacker found a token, a long-lived, overprivileged token associated with the agent that they were using, this was a third-party agent, and then used that to move into the company, move laterally, and ultimately get access to that source code."

That is the same primitive as this week's Azure CLI and SimpleHelp stories: a credential that outlived its need and reached further than it should have.

 2. Assume breach on agents, because prompt injection isn't going away

Kahn's reason that identity is "suddenly invited to the cool kids' table" is blunt:

"I think the reason for this is agents will be breached. I don't think this problem of prompt injection is, is gonna go away anytime soon. And we have to assume breach on agents."

Ashish Rajan, who started his own career in identity, agreed from the research side:

"prompt injection is almost an impossible problem to solve with the way we use systems today."

The consequence is a shift in where the effort goes. If you cannot reliably stop the agent from being manipulated, you contain what a manipulated agent can do. In Kahn's words, "ensuring that they have secure, least privilege identities is the highest ROI security action that you can do."

3. XAA is the middle path between master keys and consent-popup fatigue

Ask an agent to check Slack, read a calendar, and update a project board, and historically developers had two bad options:

"Either give that AI agent a permanent master key, like a static API key, which is, as we know, very unsafe if leaked... or bombard the user with constant annoying, 'Do you give permission?' pop-ups every single time the AI tries to do something."

Cross-App Access is Kahn's answer: predefine which apps an agent may reach, then let an identity provider broker access via ID-JAG without per-action prompts. It operates on behalf of a human at the intersection of the human's and the agent's permissions — "so it'll always be least privilege" — or fully autonomously with the agent's own identity. Kahn is emphatic that this is not proprietary lock-in: "this is an open standard. It can be used by anyone," and it is now part of the Anthropic-maintained MCP server protocol.

4. SPIFFE and XAA solve different halves of the same puzzle

Teams that already run SSO and SAML ask which new standard to pick. Kahn's answer is that it is not a choice:

"SPIFFE is, you know, is this, what's the identity of this agent?... versus XAA is really about what resources can that agent connect to."

SPIFFE proves identity inside your environment with a short-lived X.509 credential; XAA governs what that proven agent can reach across apps, which fits SaaS-heavy estates. Kahn also flags newer cross-company work — a Linux Foundation initiative modeled on DNS that would give each agent a "passport ID" that works across domains.

5. Authorization has four maturity levels, and the top one has no standing privilege

Kahn lays out a ladder. Service-account API keys with broad access sit at the bottom ("that's where we need to move away from as quickly as possible because the blast radius is so big"). Coarse-grained scopes with short-lived ephemeral tokens are next — how XAA works. Fine-grained access that honors data sensitivity and labels comes after. The top rung is aspirational:

"the agent has zero standing privilege. No access is given to the agent in terms of standing privileges. And instead, at tool invocation time, an assessment is made as to whether that agent is trying to make a tool call that is aligned with the intent of that agent. And then a dynamic permission is generated and granted for that agent to make just that single tool call, and then is revoked once it's completed."

Because human approval cannot scale to autonomous-agent volume, Kahn expects "guardian agents that are assessing whether that tool invocation is acceptable or not."

6. Nobody is offboarding agents and there needs to be a kill switch

Rajan raised the gap directly: "I don't know anyone who's talking about offboarding an AI agent... People just make agents and they walk away from it." Kahn's answer runs on two tracks. Governance-side, agent offboarding "does look a lot like human off-boarding" — joiner/mover/leaver reviews, access campaigns, and analysis of toxic permission combinations, with AI layered in to flag agents that hold scopes they never use. Runtime-side, there is the kill switch:

"once you've identified that there is malicious or suspicious behavior, you want an ability to cut off agent access immediately and universally. And this is where the idea of a kill switch comes into play."

7. The MVP governance bar is three questions

For a CISO adding agents to an existing identity program, Kahn reduces the bar to three questions: where are my agents (known and shadow, including browser-level and locally installed agents and their MCP servers), what can they connect to (XAA and agentic identity governance), and what are they doing (runtime monitoring through an agent or MCP gateway that logs every tool invocation and feeds anomaly detection). If a team can only start in two places, he is specific:

"knowing where your agents are and importing them into a registry. And then secondly, ensuring that you're at least assigning those AI agents coarse-grained scopes, and not using API access keys with broad permissions."

Which lands back where the week started: the reachable, overprivileged, unverified credential is the exposure, whether it belongs to an admin interface or an agent.

📚 RELATED RESOURCES 🎧

AppSec & DevSecOps Guidance

• Huntress — Azure CLI password-spray research

• CISA Known Exploited Vulnerabilities Catalog

• CISA KEV alert, June 25, 2026 (Cisco Unified CM)

• watchTowr Labs — Kemp LoadMaster pre-auth RCE write-up

• BleepingComputer — Nissan / Oracle PeopleSoft breach

• Arctic Wolf — SimpleHelp CVE-2026-48558 analysis

• SecurityWeek — Aflac Japan breach

• Okta - Cross App Access

• https://xaa.dev/ 

Podcast Episode

• Cloud Security Podcast  : Episode with Ely Kahn

Question for you? (Reply to this email)

🤔  Do you know which authentication flows in your tenant can reach a token without ever hitting your MFA policy?

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: Data-first attacks break forensic assumption and logging is the only fix that scales(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 pattern across this week's incidents is hard to miss: bug discovery is moving at AI speed while the damage still runs through old, ordinary plumbing — an abandoned OAuth token, a decades-old C bug, stolen RDP credentials. That gap is exactly where Simon Biggs spends his time. Biggs is a cyber incident response specialist on the forensics team at Varonis, with roughly 15 years in the field, starting in UK cyber law enforcement and later doing consultancy IR at NCC Group. Ashish Rajan sat down with him at Infosecurity Europe to ask the question on everyone's mind this year: is there actually a wave of sophisticated AI attacks, and what does forensics look like when the attacker is automating?

His answer is more useful than the hype. AI is not unlocking the impossible — it is lowering the barrier to entry and compressing the timeline. The defensive consequence is concrete and unglamorous: if you can't trace a clear path from your data back to an endpoint, and you haven't classified your data in advance, you won't be able to tell a customer, a regulator, or a contractually-armed third party what was taken.[Listen to the episode]

⚡ TL;DR for Busy Readers

• Klue OAuth breach → Salesforce CRM theft: A forgotten, never-revoked OAuth token let attackers exfiltrate CRM data from Klue's customers, with extortion group "Icarus" claiming the theft. Pull your Salesforce Connected Apps OAuth usage and revoke any integration without an owner.

• AI is finding old bugs faster than you can patch them: "Squidbleed" (a 1997 Squid proxy flaw) was surfaced with help from Anthropic's Mythos model the same week OpenAI shipped GPT-5.5-Cyber. Treat disclosure-to-exploit windows as effectively zero for perimeter assets.

• PixelSmash (CVE-2026-8461) puts RCE in your media-processing tier: Any service that transcodes or thumbnails uploaded media via FFmpeg/libavcodec is exposed pre-auth. Inventory what links libavcodec and patch to 8.1.2.

• Attacks are now data-first, not encryption-first: Biggs sees crafted SQL queries pulling credentials and PII within minutes of access. Without database and egress logging, forensics can't tell you what left.

• Prepare before the breach: Data classification and a clean audit path from data to endpoint are the difference between "your data is out of scope" and "we don't know." Run a dry-run IR exercise on one critical data store this week.

📰 THIS WEEK'S TOP 5 SECURITY HEADLINES

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

1. Klue OAuth breach feeds 'Icarus' extortion across multiple security vendors

Primary source: BleepingComputer 
Reporting: TechCrunch, The Hacker News, CSO Online

What Happened

Competitive-intelligence vendor Klue was compromised through a long-lived OAuth credential created years earlier for an abandoned integration and never revoked. The attacker pivoted into Klue's infrastructure, harvested the OAuth tokens Klue used to connect to customers' Salesforce tenants, and ran automated REST API queries to enumerate and exfiltrate CRM records. Salesforce disabled the Klue Battlecards integration on June 11. By June 22, reported victims included Huntress, Recorded Future, Tanium, Jamf, Sprout Social, Gong, and Insurity [VERIFY — victim names from secondary reporting]. A group calling itself Icarus, active since late April, claimed the theft and sent 48-hour extortion emails.

Why It Matters

Initial access was not a zero-day or a phished password — it was a forgotten OAuth token with no expiry. The detection surface is your third-party integration inventory, not your endpoint telemetry. A Salesforce-connected app holds standing API access to CRM data, so one compromised vendor becomes direct CRM exfiltration across its entire customer base without ever touching a customer's perimeter. That several reported victims are themselves security vendors makes the point: blast radius follows the integration graph, not the maturity of the target.

Action for defenders:  Pull the full list of authorized connected apps in Salesforce (Setup → Connected Apps OAuth Usage), revoke tokens for any integration without an active business owner, and apply token expiry and IP restrictions to the rest.

2. PixelSmash: FFmpeg decoder flaw (CVE-2026-8461) turns one video file into RCE

Primary source: JFrog Vulnerability Research 
Reporting: SecurityWeek

What Happened

JFrog disclosed a heap out-of-bounds write in FFmpeg's MagicYUV decoder, CVE-2026-8461 (CVSS 8.8). A crafted AVI, MKV, or MOV file processed by any application linked against libavcodec can corrupt heap metadata and hijack an internal FFmpeg callback pointer. JFrog demonstrated a full chain overwriting the AVBuffer.free pointer with system() to run arbitrary commands, including RCE against Jellyfin. Confirmed-affected software includes Kodi, mpv, ffmpegthumbnailer (used by GNOME, KDE, XFCE), Jellyfin, Emby, Nextcloud, Immich, PhotoPrism, and OBS Studio. FFmpeg shipped the fix in version 8.1.2 on June 17.

Why It Matters

The vulnerable path runs wherever media gets transcoded or thumbnailed automatically — upload pipelines, NAS appliances, and self-hosted apps like Nextcloud and Immich that decode user-supplied files with no human in the loop. Exploitation is pre-authentication and server-side for any service ingesting media, so the exposure sits in your file-processing tier, not on user desktops. FFmpeg is a transitive dependency most teams don't track, so the question is "which of my running services link libavcodec," not "do we use FFmpeg."

Action for defenders: Inventory services that decode or thumbnail uploaded media, confirm the bundled libavcodec/FFmpeg version, and apply 8.1.2 or your distro's backport. Where immediate patching isn't possible, restrict the decoders and container formats FFmpeg will accept.

🛠 If you only do one thing this week: Run a 30-minute inventory of where stolen credentials or user-supplied files get standing access in your environment — Salesforce Connected Apps and any media-decoding service that links libavcodec. Revoke ownerless OAuth tokens and confirm your FFmpeg builds are at 8.1.2. Both of this week's worst stories (Klue, PixelSmash) start in places most teams never inventory.

☁️ 3. 'Squidbleed' (CVE-2026-47729): a 1997 Squid proxy bug, surfaced by an AI model

Primary source: Calif.io research blog 
Reporting: The Hacker News, SecurityWeek

What Happened
Calif.io publicly disclosed a heap over-read in Squid's FTP gateway, CVE-2026-47729, that returns raw heap memory to a requester including other users' Authorization headers, cookies, and API keys. The bug traces to a 1997 commit. Calif credits Anthropic's Claude Mythos Preview model with flagging the root-cause quirk. PoC code is public; as of June 22 no in-the-wild exploitation had been reported. Reporting on the fixed version conflicts: some coverage cites Squid 7.6, other coverage points to 7.7 

Why It Matters
Squid sits as a shared egress and caching proxy in front of many enterprise and cloud networks, so a memory disclosure here crosses user and tenant boundaries — one user's request can leak another's session token inside the component meant to broker trust. The Heartbleed comparison is about shape, not scale: passive, hard-to-detect leakage with no crash and no log entry. The discovery method is the second story a 29-year-old bug that survived decades of human review was surfaced by a model.

Action for defenders
Inventory FortiSandbox appliances and confirm a fixed build, restrict WEB UI and management access to an admin segment, and hunt for the vendor/Defused indicators across the June window.

🏥 4. OpenAI ships GPT-5.5-Cyber for automated vulnerability finding and patching

Primary source: OpenAI 
Reporting: Infosecurity Magazine

What Happened

OpenAI released GPT-5.5-Cyber under its Daybreak program, a model tuned to find vulnerabilities, validate exploitability, and generate patches in one workflow. OpenAI reported benchmark scores of 85.6% on CyberGym, 39.5% on ExploitGym, and 69.8% on SEC-bench Pro [VERIFY — vendor-reported]. Access is restricted to vetted defenders under added monitoring. OpenAI also updated its Codex Security plugin, which it says has scanned over 30 million commits across more than 30,000 codebases since March.

Why It Matters

This lands the same week Squidbleed showed a competing model finding a real 29-year-old bug, so the "AI finds and fixes vulnerabilities" claim now has production data points on both ends of the lifecycle. The consequence is asymmetry: the same exploit-generation capability that speeds your triage also lowers the cost of weaponizing a fresh disclosure, which compresses patch windows.

Action for defenders
Treat disclosure-to-exploit windows as shorter by default in your patch SLAs. If you run an AppSec program, evaluate gated defensive models against your current SAST and triage baseline rather than assuming parity.

🛡️ 5. Accenture takes majority stake in Dragos, buys runZero and NetRise in ~$4.1B OT push

Primary source: Accenture Newsroom 
Reporting: SecurityWeek, Industrial Cyber

What Happened

Accenture announced it will take a majority stake in OT security firm Dragos (valued around $3.25B) and acquire runZero and NetRise outright, for a combined enterprise value near $4.1B [VERIFY — combined figure varies across sources]. The three together generate roughly $208M in annual recurring revenue, with the transactions expected to close in August or September 2026. Announced June 18, just outside the strict window, but included as the period's structurally significant M&A.

Why It Matters

A systems integrator buying its way to a majority stake in the leading independent OT threat-intel vendor changes the buying calculus for asset owners. OT security shifts from a best-of-breed product decision toward a bundled integrator engagement — a procurement-structure change, not a logo swap. For cloud security leads with IT/OT convergence in scope, the open question is whether Dragos's roadmap and vendor neutrality survive inside a services firm.

Action for defenders: 
If you run Dragos, runZero, or NetRise, get contract-renewal and roadmap-continuity questions to your account team now. If you're evaluating OT monitoring, weigh integrator lock-in in the decision.

6. New 'Prinz Eugen' ransomware encrypts newest files first and skips the ransom note

Primary source: BleepingComputer 
Reporting: SC Media

What happened: BleepingComputer reported a new Go-based ransomware, Prinz Eugen, that prioritizes the most recently modified files for encryption (alphabetical order on timestamp ties) and leaves no ransom note on the host. ThreatDown found hands-on-keyboard operators using legitimate RMM tooling and living-off-the-land binaries, with likely initial access through stolen RDP credentials and manual execution of a payload named servertool.exe. It uses ChaCha20-Poly1305 with Argon2id-derived keys and is not run as ransomware-as-a-service. At least five victims were identified, including Standard Bank, which refused a 1-BTC demand.

Why it matters: Encrypting recently modified files first inverts the usual recovery assumption: high-value in-flight working data is hit before bulk archives, so an early detect-and-kill response that would normally cap damage can still lose the data that matters most. No ransom note and no affiliate model means the usual leak-site and negotiation-portal indicators are absent, so detection has to come from RMM and LOLbin behavior. The RDP-credential entry point and living-off-the-land tradecraft are exactly the "acting like users" pattern Biggs describes as the new normal.

Action for defenders: Audit external RDP exposure and remote-access MFA, add detection for unexpected RMM tools and for servertool.exe executed by non-admin processes, and confirm backups capture active working directories at a tight enough interval to survive recent-files-first encryption.

🎯 Cloud Security Topic of the Week:

Data-first attacks broke the forensic assumption

The throughline of this week's news is the throughline of the episode: attackers don't need new capabilities, they need speed and reach, and AI gives them both. Biggs's sharpest observation is that the goal of the attack has changed. "Attacks predominantly used to be... encryption first, right?... Now it's data first, practically no encryption." That single shift rewrites the incident response playbook. When the objective is exfiltration rather than encryption, the question your lawyers, regulators, and contractually-armed partners will ask is not "is it back up?" but "what left, and whose was it?"

Here is the uncomfortable part, and the thing senior teams most often get wrong: forensics frequently cannot answer that question on its own. Windows artifacts show where an attacker moved and what they touched on a box, but they rarely prove what data went out the door. Without database query logging, without firewall egress that ties back to a specific endpoint, and without data classification done in advance, the honest answer to "was my data taken?" becomes "we don't know" — and that is the answer that ends customer relationships. The fix isn't a new product category. It's the unglamorous preparation work: a clean audit path from data to endpoint, and a first-pass classification of your CRMs and cloud storage so you can rule data in or out fast.[Listen to the full episode →]

Featured Experts This Week 🎤

• Simon Biggs — Cyber Incident Response Specialist, Varonis

• 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:

• OAuth token (standing API access): A long-lived credential that grants an integration ongoing API access without re-authentication. In the Klue breach, a token created for an abandoned integration and never revoked became the initial access path into customer Salesforce tenants.

• Data-first attack: An exfiltration-led intrusion with "practically no encryption," replacing the older encryption-first ransomware model (Biggs).

• Living off the land (LOLbins): Attackers acting like legitimate users — using compromised credentials and built-in/legitimate tooling instead of dropping malware — which shrinks the detection opportunity. Seen this week in the Prinz Eugen ransomware tradecraft.

• BloodHound / Metasploit / Kali Linux: Prepackaged offensive tool sets that historically lowered the barrier to entry. BloodHound maps Active Directory attack paths; Biggs uses these as the analogy for what AI now does on the fly.

• Shadow AI: Users routing around sanctioned, locked-down models to less-secure alternatives — "a massive risk" (Biggs).

• Prompt injection: Crafted input that makes an AI assistant carry out an unintended instruction. Varonis Threat Labs found a prompt-injection flaw in Microsoft Copilot.

• Mythos: Anthropic's Claude Mythos Preview model, credited this week with helping surface the Squidbleed Squid proxy bug; named by Biggs as a strong example of AI-assisted vulnerability research.

• Heap out-of-bounds write / over-read: Memory-safety bugs underlying both PixelSmash (write → RCE) and Squidbleed (over-read → secret disclosure).

This week's issue is sponsored by Varonis

AI Security Requires More Than Visibility. It Requires Control. 

Security leaders are under pressure to enable AI innovation while managing a rapidly expanding attack surface across cloud, identity, and data layers. AI agents and copilots can introduce new access paths, automated high-impact actions, and accelerate threat timelines. 

Varonis Atlas helps organizations secure AI end-to-end - from understanding usage and enforcing guardrails to detecting suspicious activity and reducing risk dynamically. watch the recording to learn how Varonis Atlas can help security teams operationalize AI security at scale. 

💡Our Insights from this Practitioner 🔍

A single-guest conversation that doubles as a field report from someone who works real breaches. The throughline: AI changes the speed and reach of attacks, not their fundamental nature — and the defensive answer is preparation, not a new control category.

1: AI lowers the barrier and raises the speed — it is not a new class of attack

Biggs's front-line read cuts against the year's loudest marketing. AI increases scale and volume and lowers the skill required, but he is not seeing goals that were previously unachievable.

"But is AI driving something that's completely unseen? No, that's not what I'm seeing on the front line... I just think that it's lowering that technical barrier to entry. They're getting quicker. They're able to achieve better outcomes quicker during an attack." — Simon Biggs

Existing layered controls still work, and they matter more, because they slow attackers moving faster through the same paths.

 2: Post-compromise automation now happens with no hands on the keyboard

The clearest AI signal Biggs sees is timing — automated action arrives in seconds.

"We're seeing sort of Microsoft Graph queries coming in like minutes, seconds after that token's been r- stolen via relay. That is unusual. Like that suggests there's no hands on the keyboard and, these AI kits are out there and are being used en masse, which is a big sea change..." — Simon Biggs

This is the practitioner mirror of the Klue story above: a stolen token is exercised almost immediately. Signature-based detection fails against ephemeral, briefly-lived phishing infrastructure on cloud and containerized platforms.

3: AI is the new "Metasploit/BloodHound" — it removes the operator's expertise

Ashish Rajan framed the shift directly: "it's almost like what Metasploit did for Script Kiddies. Is this something similar?" — Ashish Rajan

Biggs agreed, and took it further. Where chaining BloodHound output into Metasploit once required real expertise, models now pull the whole workflow together.

"So you don't actually have to be able to code, you don't actually have to really understand Active Directory... you can kinda get there without really any major technical skill, which is quite scary b- because that used to be, like a red team capability." — Simon Biggs

4: Attacks flipped from encryption-first to data-first

"Attacks predominantly used to be... encryption first, right?... Now it's data first, practically no encryption." — Simon Biggs

Response planning has to center on what data left, not what got encrypted. Biggs describes attackers taking a database schema, returning, and running a crafted query within minutes to pull credentials, payment contracts, and PII — behavior that used to be the preserve of nation-states and now shows up in ordinary ransom breaches.

5: Forensics can rarely tell you what was taken — and most teams overestimate it

"something I think people overestimate the ability of forensics to do is forensics to tell you what data's been taken... there's not many forensic artifacts that... will definitively tell you." — Simon Biggs

Windows forensics shows movement, not egress. Without database logging and per-endpoint firewall attribution, the answer to a lawyer's "did it leave?" is a hunch and lawyers don't notify on hunches. As Biggs puts it, "it's part of the incident response lifecycle, the preparation stage. That's where the battle is, is won or lost."

6: The defensive playbook is the same fundamentals — run the attacker's models against yourself

There are no magic new controls. Shadow-AI discovery, permissions hygiene, inventory and auditing, and automated response are the same problems as shadow IT and excessive permissions, extended to a new platform. The agent "is just an extension of the user" and should be audited as one.

"I'm an advocate of saying run BloodHound or run Metasploit. So... come from the point of view of the attacker and see what you find. I think it's the same. Like, run the same models, do the same thing to your environment and see what it finds." — Simon Biggs

7: AI-driven research widens the target surface, and same-day PoCs collapse patch windows

"from something getting released in the patch, people have working proof of concepts the same day. In a lot of cases we're seeing proof of concepts for things that aren't even patched yet or aren't even announced as vulnerabilities." — Simon Biggs

The economics have shifted with it: "You're not necessarily buying zero days for $50,000, $100,000. Somebody could get that in their bedroom. If they can afford the tokens." For perimeter assets, treat the disclosure-to-exploit window as effectively zero. PixelSmash and Squidbleed this week are the live examples.

8: Stolen data will be weaponized in new ways because AI lets attackers post-process at scale

"this information that's taken is gonna be weaponized in new and novel ways... what AI allows attackers to do is post-process data. So getting 10 terabytes of data is overwhelming... But now with AI, actually, they could be post-processing that data and... finding new and novel ways of monetizing it." — Simon Biggs

The liability follows. Third-party contracts increasingly require breach notification inside tight windows (often 72 hours, ahead of regulators like the ICO), and bigger partners "will come down heavy." An up-front classification pass on CRMs and cloud storage — which Biggs calls an "easy win" — lets you rule a terabyte out of scope instead of notifying everyone on a hunch.

Practical Takeaways for Cloud Security Leaders

Three things a senior team can act on: get a clean, queryable audit path from each critical data store back to an endpoint (logs that resolve to a real entity, not just an aggregator IP); do a first-pass data classification on CRMs and cloud storage so breach scope is answerable in minutes, not weeks; and run a dry-run IR exercise with someone offensive plus your blue team to find where the forensic trail dead-ends before an attacker does.

📚 RELATED RESOURCES 🎧

AppSec & DevSecOps Guidance

• Klue OAuth breach reporting — BleepingComputer

• PixelSmash / CVE-2026-8461 research — JFrog

• Squidbleed / CVE-2026-47729 research — Calif.io

• GPT-5.5-Cyber announcement — OpenAI

• Accenture / Dragos OT acquisition — Accenture Newsroom

• Prinz Eugen ransomware reporting — BleepingComputer

• Varonis Threat Labs - Blog

Podcast Episode

• Cloud Security Podcast  : Episode with Simon Biggs

Question for you? (Reply to this email)

🤔   If you were breached today, could you prove what data left — or would the honest answer be "we don't know"?

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 SOC is only as good as the data it reasons over (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 pattern this week was uncomfortable: the systems an enterprise runs to see, operate, or protect everything else were the ones under attack. A pre-auth RCE chain landed in Splunk, the box your IR team would use to spot an intruder. FortiSandbox, the appliance that detonates files you don't trust, came under active exploitation. And Oracle PeopleSoft, the system of record for HR and payroll data, was exploited by ShinyHunters before any patch existed. When the exploited surface is the control plane, the blast radius isn't one host — it's the tooling you'd otherwise use to find and contain the others.

That makes this week's episode well-timed. Ashish Rajan sat down with Aqsa Taylor, Chief Security Evangelist at Exaforce (and formerly a product lead on Twistlock and Prisma Cloud), for a conversation about "vibe hunting" applying AI agents to threat hunting the way vibe coding applies them to development and what actually separates an AI SOC that earns trust from one that buries a real alert. Her throughline connects directly to the news: the AI is only as good as the data and context it reasons over. (Disclosure: Exaforce sponsored this episode.)[Listen to the episode]

⚡ TL;DR for Busy Readers

• 🚨 Oracle's patch arrived after the compromise had already begun. Review logs back to late May, not just the disclosure date.

• A critical Splunk flaw exposed a surprising reality: deployment topology may matter more than patch status when assessing exposure.

• FortiSandbox exploitation turned a security control into the attack surface itself.

• Cisco SD-WAN and LiteSpeed joined CISA's KEV list, continuing a trend of attackers targeting management and control systems.

• AI developer tooling became the latest supply-chain target, with compromised packages and fake AI assistants hunting for API keys.

• 🎯 The pattern matters more than the CVEs: attackers spent this week targeting the systems used to manage, detect, analyse, and govern everything else.

• 🤖 From this week's podcast: Aqsa Taylor (Exaforce) explains why AI SOC platforms fail without context, why "vibe hunting" is gaining traction, and why the future of detection depends more on the data model than the model itself.

📰 THIS WEEK'S TOP 5 SECURITY HEADLINES

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

 1. Oracle PeopleSoft zero-day (CVE-2026-35273) exploited by ShinyHunters before disclosure

Primary source: CISA KEV Catalog 
Reporting: Oracle Security Alert · BleepingComputer · Help Net Security 
Analysis: Rapid7

What Happened

Oracle issued an out-of-band alert for CVE-2026-35273 (CVSS 9.8), a server-side request forgery flaw in PeopleSoft PeopleTools 8.61 and 8.62 that is remotely exploitable without authentication and can lead to remote code execution. Mandiant and the Google Threat Intelligence Group attributed pre-disclosure exploitation to ShinyHunters (UNC6240), with activity running roughly May 27 to June 9 — before any patch existed. CISA added it to KEV on June 12 with a federal deadline of June 15. Stolen data was published on the ShinyHunters leak site.

Why It Matters

PeopleSoft is the system of record for HR and financial data at large institutions, so an unauthenticated SSRF-to-RCE converts directly into bulk exfiltration of the most regulated data an enterprise holds, plus a credential-harvesting foothold into federated identity systems. Exploitation predated the advisory by about two weeks, so log review back to late May matters more than racing the June 15 clock.

Action for defenders: Confirm PeopleTools is patched per Oracle's alert; pull web-tier and Integration Broker logs for SSRF patterns and anomalous outbound requests from late May onward, and treat any PeopleSoft-adjacent service-account credentials touched in that window as exposed.

🚨 2. Splunk Enterprise pre-auth RCE chain (CVE-2026-20253) is exposed by default on AWS

Primary source: Orca Security 
Reporting: CyberSecurityNews · The Cyber Express

What Happened

Researchers disclosed CVE-2026-20253 (CVSS 9.8), an unauthenticated RCE chain in Splunk Enterprise 10 and later that abuses a misconfigured PostgreSQL sidecar. The sidecar isn't always enabled on-prem but runs by default in Splunk Enterprise on AWS, so cloud deployments are exposed out of the box. Exploitation allows file creation/destruction on the host, code execution inside the Splunk environment, and SSRF pivoting to internal resources. Splunk has released a fix. 

Why It Matters

The SIEM holds credentials and network reach into nearly every system it monitors, so pre-auth RCE on Splunk is a detection-and-response decapitation — the attacker lands inside the tool your IR team would use to spot them. The default-on AWS exposure is the operative detail: "we didn't enable that service" is right on-prem and wrong in cloud, making deployment topology the thing to check first.

Action for defenders: Identify Splunk Enterprise 10+ instances on AWS, apply the fix, and until patched, restrict network reach to the PostgreSQL sidecar and keep the management interface on a hardened admin path

🛠 If you only do one thing this week: Take 30 minutes to map which of your security and detection tooling — SIEM, sandbox, log pipeline, AI gateway — is reachable from anything other than a hardened admin path, and on which platform. This week's Splunk and FortiSandbox flaws both turn on deployment topology, and the episode's core point is the same: the tool you'd use to catch the intruder is exactly what's being targeted.

☁️ 3. Fortinet FortiSandbox flaws under active exploitation

Primary source: CyberScoop 
Reporting: SecurityWeek · The Hacker News 
Analysis: CISA KEV

What Happened
Threat-intel firm Defused reported active exploitation of a pair of FortiSandbox flaws Fortinet disclosed earlier this year — 49 exploitation events from 11 IPs over six days, traced to nine countries. Reporting ties the activity to an OS-command-injection flaw (CVE-2026-39808) and a path-traversal flaw (CVE-2026-39813), the latter confirmed exploited June 15. Fortinet separately patched a WEB UI command-injection flaw, CVE-2026-25089 (CVSS 9.1); SOCRadar reported ~30,000 exposed Fortinet firewalls.

Why It Matters
FortiSandbox detonates files an organization doesn't trust, so code execution on the sandbox hands the attacker a privileged position inside the pipeline meant to contain malicious code — the containment tool becomes the execution environment. For hybrid estates feeding cloud-bound mail and file flows through FortiSandbox, a compromised appliance can poison verdicts and pass malware as clean into cloud workloads downstream.

Action for defenders
Inventory FortiSandbox appliances and confirm a fixed build, restrict WEB UI and management access to an admin segment, and hunt for the vendor/Defused indicators across the June window.

🏥 4. CISA's June 15 KEV additions: LiteSpeed cPanel root escalation and a second Cisco SD-WAN flaw

Primary source: CISA Alert (June 15) 
Reporting: The Hacker News · BleepingComputer · SecurityAffairs

What Happened

CISA added two actively exploited flaws to KEV on June 15. CVE-2026-54420 (CVSS 8.5) is a symlink-handling flaw in the LiteSpeed cPanel plugin (before v2.4.8; LiteSpeed WHM Plugin before 5.3.2.0) that lets a user with FTP or web-shell access escalate to root on shared-hosting servers running CloudLinux or CageFS; the federal deadline was June 18. The second add, CVE-2026-20262 in Cisco Catalyst SD-WAN Manager, is an arbitrary-file-write / path-traversal flaw distinct from the command-injection flaw (CVE-2026-20245) covered in the June 10 brief.

Why It Matters

A symlink-to-root flaw on CloudLinux/CageFS breaks the per-tenant isolation shared hosting sells as its core control, so one tenant with a web shell reaches every other tenant on the box — a multi-tenant blast radius on the hosting tier many SaaS and agency workloads still run on. A second Cisco SD-WAN Manager flaw in two weeks means the controller is under sustained probing; reopen that item if you closed it after June 10.

Action for defenders
Upgrade the LiteSpeed WHM/cPanel plugin and review hosting-server logs for symlink-abuse indicators; for Cisco SD-WAN Manager, confirm both CVE-2026-20245 and CVE-2026-20262 remediations and restrict management-plane access to a hardened jump path.

🛡️ 5. Supply-chain attacks shift to AI developer tooling: Mastra npm namespace and fake JetBrains plugins

Primary source: The Hacker News 
Reporting: Help Net Security

What Happened

Two near-simultaneous supply-chain compromises aimed at AI development tooling. Roughly 144 npm packages under the Mastra namespace were compromised after a single account mass-published 140-plus malicious packages within a short window on June 17. Separately, a coordinated JetBrains Marketplace campaign published at least 15 malicious plugins posing as AI coding assistants that exfiltrate AI-provider API keys to attacker-controlled servers.

Why It Matters

The credential these campaigns steal is the AI-provider API key, now a billing-and-data primitive — a leaked key buys model access on the victim's account and the data flowing through it. Targeting the AI-coding-assistant supply chain means the malicious code lands inside the developer's agentic toolchain, which already has filesystem, repo, and often cloud-credential reach. It's the news-side mirror of what Aqsa Taylor describes below: attacks that ride GitHub and package registries and look like normal developer activity until you have repo-layer context.

Action for defenders: 
Inventory Mastra packages and AI-coding-assistant IDE plugins across engineering, rotate any AI-provider API keys reachable from dev machines or CI in the June 17 window, and add AI-provider keys to the secret-scanning and short-TTL policies you apply to cloud credentials.

🛡️ 6. Databricks acquires Panther Labs, consolidating the security-data layer for AI-era detection

Primary source: Tech Startups 
Reporting: Infosecurity Magazine

What happened: Databricks agreed to acquire Panther Labs, a cloud-native security-data and detection platform whose customers include Anthropic. Reporting frames it as Databricks' third cybersecurity acquisition and a move to compete with CrowdStrike and Cisco-owned Splunk as enterprises rebuild detection for AI-driven threats. Financial terms were not disclosed.

Why it matters: A data-platform vendor buying a SIEM-class detection layer points at where security operations is consolidating — onto the same lakehouse that already holds the enterprise's analytics data. For architects it reframes a procurement question (which SIEM) into a data-gravity question: if detection moves to where the data already lives, tool-selection independence narrows toward whoever owns the lakehouse. It rhymes with the episode's argument that the AI SOC is defined by its data model, not its label.

Action for defenders: If Panther or Databricks is in your stack, map current detection-content and data-residency dependencies now, so a post-acquisition consolidation doesn't quietly relocate where your security telemetry lives or who governs access to it.

🎯 Cloud Security Topic of the Week:

The AI SOC is only as good as the data it reasons over.

This week's news kept hitting the tools security teams rely on — the SIEM, the sandbox, the package registry developers trust — and that is exactly the surface Aqsa Taylor's argument is about. The pitch for "AI SOC" is everywhere; by her count there are more than 54 startups in the category, plus every legacy SIEM and SOAR rebadging into it. Her test for separating signal from marketing isn't the model but the data: what config, identity, code, and posture context does the platform fold in before it tells you what's a false positive? As she put it, "AI can help, but it can also hurt without the right context." The same week attackers compromised npm and JetBrains plugins that look like ordinary developer activity, that's not abstract — it's the difference between a tool that catches the anomaly and one that waves it through. [Listen to the full episode →]

Featured Experts This Week 🎤

• Aqsa Taylor — Chief Security Evangelist, 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:

• Vibe hunting — "If you're using AI for code development, it's vibe coding. If you're using AI for threat hunting in SOC, vibe hunting." The analyst's skill stays; AI makes the hunt faster and higher-confidence.

• AI SOC — A contested umbrella label. SIEM and SOAR vendors now market themselves as AI SOC too, so the category name tells you little; the data the AI reasons over tells you everything.

• The four pillars — Detection, investigation, triage, response. Triage is the commoditized layer; the differentiated value is level-two investigation and, carefully, response.

• Semantic / real-time knowledge graph — A "living graph" fusing events with configuration, identity, code, and posture context, retaining business-context exceptions over time.

• Peer-group baselining — Judging a user's behavior against their team's baseline, not only their own.

• MFA fatigue / "spray and pray" — Flooding a user with auth attempts so they approve one MFA prompt; response is session/token revocation and blast-radius containment.

• ITDR / ISPM — Identity threat detection and response / identity security posture management.

• CNAPP — Cloud-native application protection platform, where code-repo and posture context typically live before it reaches the SOC.

This week's issue is sponsored by Varonis

AI Security Requires More Than Visibility. It Requires Control. 

Security leaders are under pressure to enable AI innovation while managing a rapidly expanding attack surface across cloud, identity, and data layers. AI agents and copilots can introduce new access paths, automated high-impact actions, and accelerate threat timelines. 

Varonis Atlas helps organizations secure AI end-to-end - from understanding usage and enforcing guardrails to detecting suspicious activity and reducing risk dynamically. watch the recording to learn how Varonis Atlas can help security teams operationalize AI security at scale. 

💡Our Insights from this Practitioner 🔍

1. "Vibe hunting" came from the SOC floor, not the marketing team

Aqsa is explicit that the term originated with her company's own MDR team during a live hunt, then stuck because it mirrored vibe coding. The substance underneath is automation agents that update detection logic continuously as indicators publish, instead of an analyst manually chasing blogs and Substacks.

"If you're using AI for code development, it's vibe coding. If you're using AI for threat hunting in SOC, vibe hunting." — Aqsa Taylor

Point agents at trusted IOC sources so detection logic updates as indicators land, while checking the environment's exposure window from configuration and posture data — not only from inbound events.

2. AI without context can hurt, not just help

The sharpest take is a warning, not a pitch. An AI layer that just wraps event severity can bury a real alert among false positives, because it lacks the context to judge what matters.

"AI can help, but it can also hurt without the right context." — Aqsa Taylor

Her example is the HackerBot Claw campaign: not a code vulnerability but malicious pull requests, where a payload manipulated Claude's auto-merge instructions and altered a README. PR-change requests aren't something traditional scanners alert on — the same repo-layer blind spot this week's Mastra and JetBrains compromises exploited.

3. Fix the data model before you trust the agents

Trust in AI agents depends on the underlying data model, not the model's raw intelligence. A more powerful frontier model doesn't remove the need for context.

"even before we move into AI, I think the data model on which the AI runs is so important to be able to then trust the AI agents" — Aqsa Taylor

She contrasts a static prompt-with-Claude approach — which works only on the data you feed it — against a "proactive model" where the data is a living graph that surfaces exposure on its own.

4. The hardest detections look exactly like normal activity

The detection problem worth solving is the legitimate-looking behavior. Aqsa's example is a North Korean "fake employee" with valid access who exfiltrates by copying a sensitive file and sharing the copy.

"They could copy the contents and then share the copied file with external, and you would not see that as a shared event because you're seeing the main file." — Aqsa Taylor

Catching that requires SaaS-layer visibility across Google Workspace, GitHub, Okta, and Slack, plus peer-group baselining: comparing a new hire's behavior to their team's, not just their own short history.

5. "AI SOC" is a crowded label — interrogate the data, not the badge

When Ashish notes buyers face 50-plus vendors, Aqsa's answer is to stop selecting on the label.

"there's over 54 in the startup world ... in AI SOC. And then I'm not even counting all the traditional platforms who have pivoted to AI SOC messaging more recently." — Aqsa Taylor

The buying question to ask instead: what factors — config, identity, code, location — does the platform weigh when it reduces false positives, and is it proactive enough to run its own detections rather than waiting on upstream providers?

6. AI doesn't change the threats; it changes the volume and the timeline

Across the four pillars, most platforms only do triage — enriching upstream events. The real value is reaching the judgment of an experienced level-two analyst.

"where defenders really need help with AI and where AI can give a lot more is level two threat investigation." — Aqsa Taylor

She expects 2026 to be when teams move past level-one and level-two triage into investigation and, carefully, response — but only after the first three pillars build trust. Response agents are real (she cites customer testimonials recorded during an RSA panel), but they earn autonomy.

7. Response works when one platform owns the whole kill chain

The response pillar becomes viable when the foundation pillars feed it — so the platform runs detection, identity mapping, blast-radius, and containment without hopping between ITDR, threat-hunting, and SOAR tools.

"we saw a credential stuffing attempt where there were like 390 authentication attempts across 14 accounts." — Aqsa Taylor

In that MFA-fatigue case, tying the detection to identity risk (who clicked phishing before), impact radius (which sensitive files the account can reach), and recent sharing activity — then revoking sessions — collapses a multi-tool workflow into one chain.

8. Don't build it yourself — equip your defenders instead

Both host and guest land on the same build-versus-buy conclusion. Ashish frames the trap from a CISO's chair:

"I am actually employing people to build a product in my own company. Is that what I'm going towards?" — Ashish Rajan

Aqsa agrees: DIY with Claude can help with smaller scripts, but it doesn't remove the context, accuracy, and confidence-scoring burden — "it's almost like you're changing the effort, but you're still putting effort." Her recommended starting point: begin with level-one triage on top of your existing SIEM using a dedicated platform, and "start from data" by asking what the platform weighs before you trust its verdicts.

"You need to make sure that you're equipping your defenders, your team, with the same advantage that the attackers have." — Aqsa Taylor

Practical Takeaways for Cloud Security Leaders

• Map which security tooling (SIEM, sandbox, AI gateway) is reachable outside a hardened admin path, and on which platform — this week's flaws turn on topology.

• Rotate AI-provider API keys reachable from dev machines and CI, and scan for them like cloud credentials.

• When evaluating an AI SOC, ask what data (config, identity, code, location) it weighs — not whether it says "AI."

• Start with level-one triage on your existing SIEM; treat the full four-pillar model as the destination, not the first project.

📚 RELATED RESOURCES 🎧

AppSec & DevSecOps Guidance

• CISA Known Exploited Vulnerabilities Catalog — authoritative exploitation status for this week's CVEs

• Oracle Security Alert — PeopleSoft CVE-2026-35273

• Rapid7 — Active exploitation of the PeopleSoft zero-day

• Orca Security — Splunk Enterprise RCE (CVE-2026-20253)

• CISA Alert — June 15 KEV additions

• CyberScoop — FortiSandbox exploitation

Podcast Episode

• Cloud Security Podcast  : Episode with Aqsa

Question for you? (Reply to this email)

🤔  When did a "normal-looking" action — a copied file, a pull request — turn out to be the incident? What gave it away?

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: Segmentation for the week the patches didn't come — hybrid mesh firewall and staged micro-segmentation (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's Cloud Security Newsletter topic: Segmentation for the week the patches didn't come — hybrid mesh firewall and staged micro-segmentation.

No single breach carried this week. The pattern did: a cluster of actively exploited vulnerabilities in control-plane infrastructure, several added to CISA's KEV catalog within 48 hours, and vendors increasingly responding with ACLs and config changes instead of code. If your triage starts with "is there a patch," this was the week that question stopped working.

That makes the timing of this week's episode useful. Ashish Rajan sat down with Murali Rathinasamy, Senior Director of Product at Cisco, for a conversation about hybrid mesh firewall: what the category actually is, where it differs from CNAPP, and a staged approach to micro-segmentation that starts with blocking ports your own traffic data says you never use. (Disclosure: Cisco sponsored this episode. This week's news also includes an actively exploited Cisco SD-WAN flaw, covered on its merits below.)[Listen to the episode]

⚡ TL;DR for Busy Readers

• Check Point VPN auth bypass (CVE-2026-50751, CVSS 9.3) ran exploited for about a month before the June 8 hotfix, with a Qilin ransomware affiliate among the users. Apply the hotfix and retire IKEv1 now.

• Cisco SD-WAN Manager zero-day (CVE-2026-20245) is exploited with no patch or mitigation available. Restrict management-plane access to a hardened jump path and rotate netadmin credentials today.

• LiteLLM RCE (CVE-2026-42271) is the first KEV-listed AI-gateway flaw. Patch to ≥1.83.7, block the /mcp-rest/test/* endpoints, and rotate every model-provider key the proxy held.

• Arista EOS tunnel flaw (CVE-2026-7473): exploited, no patch planned, and it bypasses the VXLAN/GRE segmentation your fabric design assumes. ACLs are the permanent fix.

• From the episode: treat full micro-segmentation as the destination, not the project. Start agentless, block what observed traffic shows is unused (SMB 445 first), and save agents for crown jewels.

📰 THIS WEEK'S TOP 5 SECURITY HEADLINES

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

 1. LiteLLM RCE chain exploited in the wild; CISA adds first AI-gateway flaw to KEV

Primary source: CISA KEV Catalog 
Reporting: The Hacker News · Help Net Security 
Analysis: Horizon3.ai

What Happened

CISA added CVE-2026-42271, a command-injection flaw in BerriAI's LiteLLM proxy (CVSS 8.7), to the KEV catalog on June 8, citing active exploitation. Two MCP-server preview endpoints accepted a full server config in the request body and spawned the supplied command as a subprocess on the proxy host. Horizon3.ai chained it with CVE-2026-48710, a Starlette host-header validation bypass, to reach unauthenticated RCE. Fixed in LiteLLM 1.83.7 and Starlette 1.0.1.

Why It Matters

The LLM proxy is where enterprises now concentrate model-provider API keys, internal endpoint credentials, and the routing config for every AI app behind it. A shell on that host means the blast radius is every model credential the gateway holds, not one application. This is the first KEV-listed AI-gateway RCE, and it reframes the LLM proxy as a tier-0 identity asset that belongs in the same patch SLA as a domain controller.

Action for defenders: Inventory LiteLLM deployments, confirm version ≥1.83.7, block the two /mcp-rest/test/* endpoints at the reverse proxy if you cannot patch immediately, then rotate any model-provider keys the proxy stored.

🚨 2. Check Point VPN auth bypass exploited for a month; Qilin affiliate among the users

Primary source: Check Point advisory 
Reporting: BleepingComputer · SecurityWeek 
Analysis: Rapid7

What Happened

Check Point disclosed CVE-2026-50751 on June 8, a CVSS 9.3 logic flaw in certificate validation that lets a remote, unauthenticated attacker establish a Remote Access or Mobile Access VPN session without a valid password. It affects deployments using the deprecated IKEv1 protocol and Spark firewalls. Check Point traces exploitation to May 7 (vendor's own assessment) and ties it to at least one Qilin ransomware intrusion that used Rclone for exfiltration. CISA set a June 11 federal KEV deadline. A related flaw, CVE-2026-50752, affects IKEv1 site-to-site certificate validation.

Why It Matters

Roughly a month of in-the-wild use before a fix existed, and the entry point is the appliance fronting the corporate network. A ransomware affiliate gets the same network position as an authenticated remote employee, minus the credential. The IKEv1 dependency makes this a configuration-debt story: the exposed set is everyone who never migrated to IKEv2, so remediation is an architecture audit, not just a hotfix.

Action for defenders: Apply the hotfix. If you cannot, switch Remote Access VPN to IKEv2-only, make machine-certificate authentication mandatory, enable IPS, and hunt logs for the published VPS-hosted source IPs.

☁️ 3. Cisco Catalyst SD-WAN Manager zero-day exploited; no patch available

Primary source: Cisco Security Advisory 
Reporting: Help Net Security · BleepingComputer · The Hacker News

What Happened
Cisco confirmed active exploitation of CVE-2026-20245 (CVSS 7.8) in Catalyst SD-WAN Manager, a command-injection flaw that lets an authenticated attacker with netadmin privileges execute commands as root by uploading a crafted file. Google Mandiant reported it, and Cisco observed attackers pushing configuration changes down to edge devices. No patch or mitigation is available. The netadmin role can be obtained via stolen credentials or by chaining earlier SD-WAN flaws (CVE-2026-20182, CVE-2026-20127).

Why It Matters
SD-WAN Manager is the control plane for branch and cloud-edge connectivity. Root on the manager is not one box; it is the ability to rewrite routing and policy on every managed edge device, which is pre-positioning capability rather than a single-host compromise. With no patch on offer, the defensive question shifts from "when do we deploy the fix" to "who can reach the manager's CLI at all."

Action for defenders
Restrict management-plane access to a hardened jump path, audit netadmin accounts and rotate their credentials, and review edge-device config history for unexpected pushes.

🛠 If you only do one thing this week: List which of the four exploited access-broker products you run — Check Point IKEv1 VPN, Catalyst SD-WAN Manager, Arista tunnel-decap endpoints, LiteLLM — and for each one write down either the patch version deployed or the named compensating control and its owner. Thirty minutes, and it converts this week's thesis (the patch isn't coming; compensate at the network layer) into a checklist your team can act on.

🏥 4. ServiceNow discloses unauthenticated API flaw used to query customer instance data

Primary source: BleepingComputer 
Reporting: Hackread

What Happened

ServiceNow disclosed on June 9 that attackers exploited an unauthenticated-access flaw in one of its API endpoints to run queries against customer instances. Observed activity traces to June 2–3; ServiceNow remediated hosted instances on June 5 with no customer action required. Community reporting points to a Scripted REST Resource deployed with requires_authentication=false. The bulletin centers impact on the Australia platform release and older releases with certain config changes.

Why It Matters

This is a multi-tenant SaaS auth bypass in the provider's own platform code, not a customer misconfiguration, so "harden your instance" would not have prevented it. Because the vendor fixed it server-side, most affected customers will see no signal unless they go looking. "The provider patched it for you" and "you have no exposure" are different claims; log review is the only way to know which one applies to you.

Action for defenders
Pull instance logs for requests to the affected endpoint and the published indicator IP (51.159.98.241) across the June 2–5 window, and confirm with your account team whether your release was in the impacted set.

🛡️ 5. Google patches fifth actively exploited Chrome zero-day of the year

Primary source: CISA KEV 
Reporting: Help Net Security · BleepingComputer · The Hacker News

What Happened

Google patched CVE-2026-11645, an out-of-bounds read/write in the V8 JavaScript engine allowing arbitrary code execution in the browser sandbox via a crafted HTML page. An exploit exists in the wild; CISA added it to KEV on June 9. It is the fifth actively exploited Chrome zero-day of 2026 and, because the bug is in Chromium, it also affects Edge, Opera, and other Chromium-based applications. Fixed in Chrome 149.0.7827.102/.103.

Why It Matters

The exposure is not just user browsers. Chromium is embedded across cloud workloads, headless automation, and CI rendering, so "patch the browser" understates where the engine runs. The instances that stay exploitable after every desktop updates are the build pipelines and serverless functions shipping a bundled Chromium nobody patches on Google's cadence.

Action for defenders: 
Force-update managed Chrome/Edge fleets, then inventory container images and Lambda/Cloud Run layers that bundle Chromium or Puppeteer and rebuild against the patched version.

🎯 Cloud Security Topic of the Week:

Segmentation for the week the patches didn't come!

Three of this week's exploited flaws shipped with no patch, and the vendor guidance in each case was a network-layer control: ACLs on Arista fabric, access restriction on SD-WAN Manager, protocol migration on Check Point. That is compensating-control work, and it lands on whoever owns segmentation. Murali Rathinasamy's argument on the podcast is that this work stalls for a predictable reason. As he put it: "Micro-segmentation always stalls in the phase of how do I know what I need to go protect, and what policy should I go use?" His staged answer, starting from observed traffic and agentless enforcement rather than a multi-year agent rollout, is the practical core of this edition's insights section. [Listen to the full episode →]

Featured Experts This Week 🎤

• Murali Rathinasamy - Senior Director of Product, Cisco

• 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:

• Hybrid mesh firewall — As the guest describes it: the evolution after perimeter and next-gen firewalls, recognizing that enterprise networks now span data centers and clouds. A distributed set of enforcement points (physical, virtual, container, cloud-native; inline and out-of-band) managed uniformly: "uniformly managing this entire distribution of inline and out-of-band detection and threat capabilities." A category, not a single product.

• Micro-segmentation — Locking down communication at the level of individual VMs, containers, and devices. The guest's framing: the end state where "every individual VM, every individual container, every individual device is really locked down."

• North-south vs east-west — Perimeter traffic (inspection, decryption, DLP, WAF-style inbound protection) versus traffic between internal workloads (segmentation territory).

• Compensating control — A control that reduces exploitability when fixing the flaw itself isn't possible: a virtual-patch rule, step-up MFA in front of a vulnerable app, or an ACL where no patch is coming. The connective tissue between this week's news and the episode.

• KEV (Known Exploited Vulnerabilities) catalog — CISA's list of flaws with confirmed active exploitation, carrying federal remediation deadlines. Four of this week's stories involve KEV additions inside one 48-hour stretch.

• Blue-green upgrade — Standing up the new version alongside the old and cutting traffic over, eliminating upgrade downtime. The operational expectation cloud teams now hold firewalls to, per the RCSI example.

• IKEv1 — The deprecated IPsec key-exchange protocol whose continued use defines the exposed population for CVE-2026-50751.

This week's issue is sponsored by Varonis

AI Security Requires More Than Visibility. It Requires Control. 

Security leaders are under pressure to enable AI innovation while managing a rapidly expanding attack surface across cloud, identity, and data layers. AI agents and copilots can introduce new access paths, automated high-impact actions, and accelerate threat timelines. 

Varonis Atlas helps organizations secure AI end-to-end - from understanding usage and enforcing guardrails to detecting suspicious activity and reducing risk dynamically. watch the recording to learn how Varonis Atlas can help security teams operationalize AI security at scale. 

💡Our Insights from this Practitioner 🔍

1. Cloud and on-prem are one network; treating them as islands is the root failure

The tooling split, CNAPP and CSPM for cloud and appliance firewalls for on-prem, forces a divide that the org chart doesn't actually have. The same network security team usually owns both halves.

"What we've seen in the industry is the challenge is that customers will often think about their cloud security as one island in one pocket of the world, but then their on-prem is a different pocket of the world. Really though no enterprise thinks about them separately. It's all one hybrid network, and wherever the application are and wherever the users are, they wanna pro- uh, protect that in totality." — Murali Rathinasamy

The practical version of this insight: asking an on-prem firewall admin to also master CNAPP, CSPM, and per-cloud native tooling for only half their environment is a skills tax most teams can't pay. Royal College of Surgeons in Ireland (RCSI) is the worked example below.

2. AI agents look like users but don't behave like users

Murali's sharpest AI observation is about identity, not models. Agents inherit a user's identity and then access things in patterns no human baseline predicts.

"You now have new applications because at the end of the day, everyone is now an application developer because they can go and create their own applications. These agents now can sort of look like a user, but they're doing things in ways that users don't do. So even traditional behavioral analysis tools may not work because you'll see user Murali traditionally uses this application, and now his agents are going all over the place." — Murali Rathinasamy

This pairs directly with the LiteLLM story above. If agents defeat behavioral baselines and the AI gateway concentrates credentials, the controls that still work are the structural ones: segmentation that limits what an agent can reach, and inspection at the choke point between workload and model.

3. The single-cloud security story collapses at enterprise reality

A former AWS product manager arguing against all-in on cloud-native firewalling carries some weight:

"As a former AWS product manager, I would tell you that I would've said the exact same thing. 'Hey, you're in the AWS ecosystem. We have, we've got the best in class services. Go and use ours entirely.' However, the reality for all the enterprises I work with, literally all of the enterprises that I work with is none of them are one cloud provider. A, none of them are one cloud provider. All of them have at least two cloud providers, and then B, they all have on-prem deployments as well." — Murali Rathinasamy

His decision lens is ownership: if a centralized security team is responsible for every workload everywhere, per-cloud native tooling means re-skilling that team on each platform and stitching policy visibility across VPCs, Azure, and GCP by hand. Where cloud providers win, he concedes, is scalability; where customers tell him they're not there yet is security feature depth.

4. RCSI: virtual firewalls in the cloud fail on operations, not security

RCSI, a 200-year-old institution , ran Cisco FTD on-prem and lifted virtual firewalls into the cloud, then hit route-table plumbing, transit gateway config, self-managed scaling, and upgrade downtime.

"What RCSI realized was like, hey, this is just not a scalable model. Like, any time I need to do a software upgrade for the firewall, I have to go take downtime? My cloud application teams are like, 'That's crazy.' Like, no cloud team really thinks about downtime to do an upgrade. It's always a blue-green upgrade." — Murali Rathinasamy

The fix wasn't a different security product; it was operating the same firewall like a cloud service (orchestrated deployment, auto-scaling, blue-green upgrades via Multicloud Defense). The lesson generalizes beyond Cisco: when network security tooling can't match the operational bar cloud teams hold everything else to, the security tool loses the argument.

5. Micro-segmentation stalls on "what do I protect?" — make it the destination, not the project

Ashish's framing set up the episode's most useful exchange:

"Micro-segmentation. It's probably the most spoken, yet least implemented space of the industry." — Ashish Rajan

Murali's response is the staged model. First, recognize you've already started: a perimeter firewall is one segment, and most enterprises already firewall crown jewels or cloud boundaries. Second, use observed traffic to cut obvious attack surface agentlessly, without touching applications:

"While we, you know, uh, enterprises talk quite a bit about segmentation and micro-segmentation, at the end of the day, micro-segmentation always stalls in the phase of how do I know what I need to go protect, and what policy should I go use?" — Murali Rathinasamy

His concrete examples: Windows Server SMB (445) is among the most exploited ports in a data center and almost never legitimately used; block it. SSH should only originate from jump hosts; block 22 from everywhere else. A large healthcare provider in California (unnamed) deployed micro-segmentation agents only on its EMR, the crown jewels, and used existing Cisco firewalls agentlessly for everything else, cutting the lateral path from systems like payroll to the EMR.

"Worry about the north star of true micro-segmentation where every individual VM, every individual container, every individual device is really locked down. Think of that as the destination, don't think of that as the journey." — Murali Rathinasamy

6. AI doesn't change the threats; it changes the volume and the timeline

"To me, like the AI world is really more about, it's not a different set of threats. It, it's the same sort of threats, it's just a much higher volume of those threats on a much shorter timeline, right?" — Murali Rathinasamy

That reframe has a budget implication: the answer to AI-era threats is mostly not new threat categories or new tools, it's shrinking time-to-control on the ones you have. On the prompt layer specifically, his point is architectural: there is already a firewall between your users or workloads and the LLM, so that's where inspection belongs, including prompt-injection detection and blocking responses that leak what they shouldn't.

7. Compensating controls are the answer to software you can't patch

The quote that could have been written about this week's news: "Cisco is, uh, working very closely with Mythos on being able to identify vulnerabilities in our own software to patch them very quickly, and we're realizing that Mythos is the new reality in the world of all CISOs and CIOs, CTOs have known that all software is gonna have vulnerabilities. It's really about how do you close those vu- vulnerabilities quickly and use compensating controls to make sure that they're not, uh, exploited w- before you can kind of fix it." — Murali Rathinasamy

For COTS applications and legacy systems (his example: MRI machines on Windows XP-era software), patching is not in your control. The realistic play is a virtual-patch rule for a Log4j-style flaw, or step-up MFA in front of an app you know is vulnerable, while the vendor or app team builds the fix. Set against Arista's "no patch planned" and Cisco SD-WAN's "no patch available," this stopped being a vendor talking point and became the week's operating reality.

Practical Takeaways for Cloud Security Leaders

• Embed AppSec in the engineering loop not after it. If your team is still receiving code and generating tickets, you are operating legacy AppSec. Start conversations with engineering about where security testing can run inside the CI/CD pipeline itself.

• Shift from false positive tolerance to true positive precision. A 90% false positive rate is a testing architecture problem, not a signal problem. Test inside the development environment to eliminate WAF and CDN interference.

• Treat AI agents as service identities, not applications. Apply your IAM governance framework to every agentic workload before production deployment. Default permissions are almost always too broad. BYOSA on Vertex AI; scoped service accounts everywhere else.

• Audit your CI/CD supply chain assumptions today. Pin GitHub Actions to full commit SHAs, not floating tags. Assume any runner that executed Trivy, LiteLLM, Telnyx, or Axios between March 19–31 is compromised until proven otherwise.

Position security as a business enabler for AI transformation. CISOs who approach AI as purely a risk management exercise will be sidelined. Those who help engineering teams ship AI features securely and at speed will own one of the most important mandates in their organization.

📚 RELATED RESOURCES 🎧

AppSec & DevSecOps Guidance

• CISA Known Exploited Vulnerabilities Catalog — authoritative exploitation status for this week's CVEs

• Cisco Security Advisory — SD-WAN Manager CVE-2026-20245

• Check Point hotfix advisory — IKEv1 VPN flaws

• Arista Security Advisory 0137 — EOS tunnel decapsulation

• Horizon3.ai — LiteLLM RCE chain analysis

• Rapid7 — Check Point VPN zero-day analysis

Podcast Episode

• Cloud Security Podcast Episode with Murali

Question for you? (Reply to this email)

🤔  Which of your controls exist because a patch never shipped — and would you know if one quietly stopped working?

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

This week's Cloud Security Newsletter topic: Security at the Speed of Engineering — Guardrails, Not Gates (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

No single breach defined the week. What defined it was reuse and speed: offensive tooling getting mass-produced and recycled faster than defenders — or governments — can measure it, landing squarely on the identity edge and the container boundary. A credential-stealing worm rode a maintainer’s GitHub account straight past code review into Red Hat’s npm namespace. A three-year-old container-escape bug earned a fresh KEV listing the day after in-the-wild exploitation was reported. And Sophos pulled apart a ransomware crew’s AI-coordinated lab built to test malware against three named commercial EDRs.

This week’s conversation features Nick Reva, who runs global security engineering at DoorDash, and Shivani Doke, a GRC engineer, recorded live in front of a San Francisco audience and hosted by Ashish Rajan. The thread running through both the news and the episode: AI lowers the barrier on both sides of the fight, so the durable controls are the ones embedded in the development lifecycle and validated continuously, with humans in the loop only at the decisions that matter. [Listen to the episode]

⚡ TL;DR for Busy Readers

- Miasma worm hit Red Hat’s npm namespace. At least 32 
@redhat-cloud-services releases tampered to steal AWS/GCP/Azure 
keys, Kubernetes service-account tokens, and Vault tokens at 
install time. Rotate cloud and CI secrets on any host that 
pulled affected versions since June 1.

- Two KEV deadlines this week. PAN-OS GlobalProtect auth bypass
 (CVE-2026-0257, mitigate by June 1) and Linux cgroups v1 
container escape (CVE-2022-0492, due June 5). Triage by 
config and node image, not CVSS.

- AI-built EDR-evasion lab surfaced. Sophos documented a 
crew using AI agents to iterate payloads against Sophos, 
CrowdStrike, and Microsoft Defender. Treat EDR as a detection 
layer to validate, not trust.

- Prompt-injection metrics don’t compare across labs. No two 
of the four major AI providers measure injection resistance 
the same way. Demand a vendor’s test methodology before 
deploying agents in sensitive workflows.

- Reva + Doke’s frame: run security at engineering speed. 
Embed small security pods in product teams, surface findings 
on the pull request, triage AI-generated bug-bounty noise with 
AI, and reserve humans for the novel work.

 THIS WEEK'S TOP SECURITY HEADLINES

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

1. Miasma Supply-Chain Worm Compromises @redhat-cloud-services npm Packages and Harvests Cloud Credentials

Primary source: Wiz Research
Reporting: BleepingComputer · Cybersecurity Dive · Aikido
Analysis: Palo Alto Unit 42

What happened: Wiz Research reported on June 1 that at least 32 package releases under the @redhat-cloud-services npm namespace carried unauthorized modifications that didn’t match their source repositories. The payload is “Miasma,” a new variant of the Mini Shai-Hulud credential-stealing worm whose code TeamPCP previously open-sourced. A compromised Red Hat employee GitHub account was used to push malicious orphan commits to two RedHatInsights repositories, bypassing code review; the tampered packages ran obfuscated preinstall scripts at install time, attempting to collect GitHub Actions tokens; AWS, Google Cloud, and Azure credentials; HashiCorp Vault tokens; Kubernetes service-account tokens and kubeconfig files; npm and PyPI publishing tokens; SSH keys; Docker registry credentials; and .env files. Affected packages average ~80,000 weekly downloads. Wiz called the TeamPCP link TTP overlap, not definitive attribution.

Why it matters: Once Shai-Hulud was open-sourced, the worm became commodity code anyone can fork — so “is this TeamPCP?” stops being the useful question. The intrusion rode a maintainer’s account and orphan commits past code review into a trusted vendor namespace, and the theft executes at npm install on developer and CI hosts, not at runtime. The credential target list reads like a cloud-platform team’s secret store.

2. CISA Adds PAN-OS GlobalProtect Authentication Bypass (CVE-2026-0257) to KEV — June 1 Federal Deadline

Primary source: CISA KEV Catalog · Rapid7
Reporting: BleepingComputer · The Hacker News
Vendor advisory: Palo Alto Networks

What happened: CISA added CVE-2026-0257, an authentication bypass in PAN-OS and Prisma Access GlobalProtect, to the KEV catalog on May 29 with a June 1 federal mitigation deadline. Rapid7 MDR observed exploitation across multiple customers, earliest activity on May 17, and reported no successful lateral movement from affected devices. The flaw lets an unauthenticated remote attacker establish a VPN connection through the GlobalProtect gateway when authentication-override cookies are enabled alongside a specific certificate configuration.

Why it matters: The bypass turns the remote-access gateway — the control meant to gate who reaches the network — into an unauthenticated entry path. Exposure depends on a specific configuration, not mere presence of the product, so CVSS-only triage won’t tell a team which appliances are actually reachable. The disclosure-to-KEV interval was short (exploitation observed May 17, listed May 29), ahead of normal monthly patch rhythms.

3. CISA Adds Linux Kernel cgroups Container-Escape Flaw (CVE-2022-0492) to KEV — Due June 5

Primary source: CISA alert
Reporting: SecurityWeek
Analysis: Palo Alto Unit 42 · Aqua Security

What happened: On June 2, CISA added CVE-2022-0492 — a privilege-escalation flaw in the Linux kernel’s cgroups v1 control-groups feature — to the KEV catalog with a June 5 federal remediation deadline (the same alert added Android Framework zero-day CVE-2025-48595). The cgroups bug lets a process modify the release_agent file, which executes as root in the host namespace; combined with a new user namespace, it allows container escape to the host. Only cgroups v1 is affected. Technical details were published roughly three years ago, but in-the-wild exploitation was reported only recently — one day before CISA’s alert.

Why it matters: A three-year-old kernel flaw earning a fresh KEV listing is the week’s quiet but pointed item: the payoff is escape from a container to its host, which on a shared Kubernetes node means crossing the tenancy boundary teams treat as a containment line. The operative signal is recency-of-exploitation, not recency-of-disclosure.

4. Sophos Uncovers an AI-Coordinated Lab Built to Test Malware Against Named EDRs

Primary source: Sophos research (via BleepingComputer)
Reporting: Help Net Security · CyberSecurityNews

What happened: Sophos disclosed a threat actor’s Git repository containing an automated Active Directory discovery panel and a lab that iteratively develops and tests malware against Sophos, CrowdStrike, and Microsoft Defender EDR agents. Per Sophos, the framework used multiple AI agents coordinated by a Claude Opus 4.5 agent, connected via Model Context Protocol to Git repositories and built with tools including Cursor and Ludus, testing a Python payload tool’s ~80 modules and 70-plus evasion techniques across dedicated VMs. Sophos linked the activity to ransomware and data-theft operations but didn’t name the group. It also noted the lab’s own documentation claimed the evasion modules improved with refinement, but the test data didn’t support those claims — likely LLM hallucination in the attacker’s tooling.

Why it matters: The signal isn’t “AI writes malware” — it’s that the crew built an automated test rig against three named commercial EDRs, compressing the develop-test-refine loop that previously demanded a skilled operator. The hallucination caveat runs in the defender’s favor: the self-reported evasion rates were inflated, so the real capability may trail what the repo advertises. Two of the three targeted EDRs are widely deployed across cloud-hosted endpoint estates.

5. Cross-Lab Review: The Four Major AI Providers Measure Prompt Injection With Incompatible Metrics

Primary source: VentureBeat Security
Related coverage: VentureBeat

What happened: A VentureBeat comparison published June 1 found that Anthropic, OpenAI, Google, and Meta each released prompt-injection disclosures in 2026, but no two used the same metrics — different test conditions, attack types, and success-rate definitions, with no shared adversarial test suite. Anthropic reported browser-agent hijacking rates; other labs focused on indirect injection in tool-calling or document-summarization tasks. The review advised teams to treat each lab’s numbers on their own terms and to request methodology before deploying agents in sensitive workflows.

Why it matters: Enterprises evaluating AI agents have no common denominator — a “31% before safeguards engaged” figure from one lab and a tool-calling success rate from another aren’t comparable, so procurement can’t rank models on injection resistance the way it ranks a CVSS score. With agents now writing and testing offensive code (story 4) and propagating through package ecosystems (story 1), the measurement gap sits on a control teams increasingly depend on.

6. White House Executive Order Sets Voluntary Federal Review and Cyber-Capability Benchmarking for Frontier AI Models

Primary source: The White House
Reporting: Roll Call · Council on Foreign Relations

What happened: On June 2 the White House issued “Promoting Advanced Artificial Intelligence Innovation and Security.” It directs Treasury, the NSA, and CISA to design, within 60 days, a voluntary framework under which developers may submit a frontier model for federal evaluation; “covered frontier models” would be made available to the government for up to 30 days before public release. The order establishes a classified NSA-led benchmarking process for offensive cyber capabilities and a voluntary AI cybersecurity clearinghouse to coordinate vulnerability discovery and patching. It explicitly creates no mandatory licensing, preclearance, or permitting requirement.

Why it matters: The load-bearing elements for security teams are the clearinghouse and the cyber-capability benchmark, not a compliance mandate — this is the government building a pre-release read on what frontier models can do offensively, the same measurement the Sophos lab (story 4) and the prompt-injection gap (story 5) show the private sector can’t yet produce consistently. Framing it as “increased regulatory scrutiny” overstates an order that imposes no obligation today.

7. Cisco Restructures Vulnerability Disclosure Around the AI-Compressed Exploit Gap, Adds Runtime Live Protect

Primary source (reporting): Axios · Help Net Security
Vendor primary: Cisco — disclosure cadence · Cisco — Live Protect

What happened: At Cisco Live 2026, Cisco said it will move to scheduled twice-monthly security advisories on the first and third Wednesdays of each month starting in July, with seven days’ advance notice of which technologies each release covers and a stronger risk-based emphasis on flaws under active exploitation. Cisco cited Talos data showing the interval between disclosure and first observed exploitation is compressing as attackers adopt AI automation. It also introduced Live Protect, which applies runtime compensating controls to shield a device against exploitation of a newly disclosed flaw — no reboot or upgrade required — while a permanent patch is staged.

Why it matters: The disclosure-cadence change is the signal, not the product: a major infrastructure vendor is rebuilding how it releases advisories because the disclosure-to-exploitation window is shrinking — the same dynamic the PAN-OS (story 2) and cgroups (story 3) KEV timelines show this week. Predictable windows let teams pre-stage change windows, but they also concentrate patch load on dates adversaries can anticipate. Live Protect is a bet that runtime compensating controls, not patching speed alone, become the near-term answer.

🎯 Cloud Security Topic of the Week:

Security at the Speed of Engineering — Guardrails, Not Gates

Every story above shares a clock problem. The Miasma worm executed at install time, the PAN-OS and cgroups flaws hit KEV faster than monthly patch cycles, the Sophos lab compressed the malware develop-test loop, and Cisco is rebuilding disclosure cadence specifically because the disclosure-to-exploitation window is shrinking. The week’s news is, in aggregate, a story about offense moving faster than the controls built to catch it.

That is exactly the problem Nick Reva designs around at DoorDash. His answer isn’t a new product — it’s a placement decision: put small security teams inside the product teams, and make the security signal arrive where engineers already work, on the pull request, at the speed they ship. Shivani Doke makes the parallel case for governance: stop treating GRC as an annual document refresh and start embedding controls in the lifecycle, validated at runtime. Two halves of one argument about where a control has to live to survive a faster attacker. [Listen to the full episode →]

Featured Experts This Week 🎤

• Nick Reva — Global Security Engineering lead, DoorDash (previously Snapchat, SpaceX)

• Shivani Doke — GRC Engineer

• 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:

• Shift far left: Nick Reva’s extension of “shift left” — embedding small (3–5 person) security tiger teams directly into the product teams building AI features, hardening each surface in its own context with guardrails rather than approval gates.

• Forward-deployed security teams / pods: Small embedded security teams that own the highest-priority product areas, credited on stage to Jason Chan’s “Netflix model.” Distinct from a central AppSec-tooling team that lacks per-team, per-month context.

• Promptfoo: An open-source prompt-injection testing framework Reva likened to Burp Suite for AI — packaged rules you tweak to test for prompt injection, model efficacy, and model ethics, run as an integration test on the pull request.

• “Claude Kiddies”: Reva’s coinage (a play on “script kiddies”) for low-skill actors who use AI to generate bug-bounty reports — and then to argue back against triage teams.

• Security Knowledge Graph: Reva’s runtime control-validation system built on the open-source Cartography framework — it aggregates cloud and endpoint telemetry into a node graph, checks whether a designed control is operating against live runtime data (via eBPF probes observing pod security and Docker exposure), and auto-routes drift to the owning team via Slack or Jira.

• GRC engineering: Shivani Doke’s discipline — moving GRC from point-in-time PDF-policy refreshes to controls embedded in the development lifecycle and validated continuously (runtime monitoring, RASP, attack-surface and supply-chain scanning, compliance enforced as code).

• Nth-party / transitive vendor risk: Third-party vendors carry their own vendors (fourth-, fifth-, Nth-party); a breach anywhere in the transitive dependency chain can expose your data. Current Nth-party monitoring tooling is immature.

• Human-in-the-loop: Reva’s design pattern for autonomous offensive/defensive agents — humans gate the critical decision points; the main-line work is mostly automated.

This week's issue is sponsored by CheckPoint

77% have an AI strategy. Only 26% can enforce it.

Enterprises are adopting AI faster than security can keep up. GenAI, copilots, and autonomous agents are getting greenlit at the top — then landing on teams with no way to see, govern, or stop them when something goes wrong.

The strategy exists. The enforcement doesn't.

Join Ashish Rajan with Check Point's David Haber and Paul Barbosa to work through where traditional security models fall short on AI, and what real-time enforcement actually takes across cloud, SaaS, endpoint, and hybrid.

[Register here for to join the LIVE Event]

💡Our Insights from this Practitioner 🔍

1. Shift far left: guardrails, not gates

The reason the week’s news keeps beating monthly patch cycles is that the attacker’s loop now runs at engineering speed. Reva’s response is to move security to where the engineers already are. Beyond the familiar “shift left,” he frames it as “shift far left”: small security teams embedded inside the product teams building AI features.

“far left means you embed small teams, small tiger teams of security engineers into the development teams are working on the AI initiatives to harden the AI initiatives.”  — Nick Reva

The mechanism is deliberately not a gate. At a three-sided marketplace — dashers, merchants, customers — each surface carries a different AI experience and so a different threat model, and the control has to fit the way each team ships:

“the shift far left is establishing guardrails not gates into your product development story.”  — Nick Reva

Concretely, that means integrating Promptfoo into every repo where AI development happens, writing lint-style rules that look for prompt injections in the agent frameworks in use, and building middle-tier service layers that filter both the prompt and the response. The connection to this week’s news is direct: story 5’s finding that the four major labs can’t agree on how to measure prompt-injection resistance is the strategic version of the same problem Reva solves tactically — if you can’t buy a comparable injection metric, you test injection yourself, in your own pipeline, against your own tool-calling paths.

2. Make the security signal arrive on the pull request

Guardrails beat gates because engineering teams move at engineering speed and won’t stop to ask permission. Reva’s design puts the security check inline, where an engineer is already looking:

“if, for example, an engineer opens up a PR on the repo for one of the… agent frameworks and Promptfoo runs as an integration test and gives them direct feedback on the PR, they’re gonna respond to it like, no, no engineer wants to ship… an agent framework that has prompt injection.”  — Nick Reva

“You have to meet the team at the speed of that the team is operating at.”  — Nick Reva

He noted the open-source version of Promptfoo is powerful enough that buying the commercial tier hasn’t been necessary, though they make it fit their SDLC — and that the same framework does double duty for model-efficacy and model-ethics testing. This is the practitioner answer to Cisco’s story-7 bet: when the disclosure-to-exploitation window shrinks, the control has to be already running where the work happens, not staged for a future change window.

3. Scale scarce security pods with AI-assisted threat modeling

Headcount never matches engineering scale, so the move is to make a small number of forward-deployed engineers far more productive.

“I have 2,500 engineers and I have three of these security pods… I don’t have 10, I don’t have 20, I probably never will from a headcount perspective. So how do I make those three people like really good at their job?”  — Nick Reva

The experiment is AI-assisted threat modeling and product-security review — not generic ChatGPT, but context-specific models wired into the GitHub repos under review. The maturity sequence Reva described: make the human pods better first, iterate the model, then expose it to product teams as self-service.

“the idea is to make the forward deployed security engineer more productive. And then later the idea is to take this and give it to the product teams as like a Chrome extension… this agentic security review framework… we’ll have a virtual security engineer that’ll give you feedback that’s like really calibrated.”  — Nick Reva

An audience practitioner described the same shape from the other side: a “baseline automated prodsec” approach that democratizes a SAST/DAST/SCA/threat-model baseline so every feature gets immediate early feedback, with humans reserved for complex code reviews, complex threat models, and tabletop exercises, gated by risk-based acceptance criteria before production.

4. Security decisions are business decisions — fund and own them accordingly

The forward-deployed model only works if everyone agrees on who owns the call. Reva is blunt that the security team isn’t the decision-maker:

“We’re led to believe security decisions are a security team responsibility. They’re not, they’re a business decision ultimately… The security team is the fact finder about risk and we help them provide technical solutions to solve problems, right? But ultimately the business makes the decision on what we wanna do.”  — Nick Reva

The pod model itself he credits to a lineage:

“Jason Chan invented this idea of forward deployed security teams… that were deployed into the product areas in small tiger teams… And I’ve adopted this at DoorDash.”  — Nick Reva

The budgeting takeaway he offered: align the pod’s funding ask with whatever business line security reports into (DoorDash’s reports into Legal, which he said works fine), and treat AI risk as one novel, complex category of business risk the board must hear about — not a siloed security cost.

5. “Claude Kiddies”: AI collapses the attacker skill floor — so triage with AI

Asked what AI attack actually keeps him up, Reva’s answer wasn’t novel malware. It was volume and the disappearance of the skill bar for low-end offense:

“the hobbyist level people are getting involved… There used to be like a… level of technical proficiency that you have to have to do this kind of work. It’s gone… ’cause they’re vibe coding the bug bounty reports.”  — Nick Reva

His coinage for them — a play on “script kiddies” — was the line of the night: they’re “Claude Kiddies.” An audience member noted curl recently closed its bug-bounty program over an influx of AI-generated reports. Reva’s response is symmetric, and maps onto the Sophos lab in story 4 (offense automated, defense automates back):

“if they’re using Claude to generate bug bounty reports, we have to use Claude to triage those reports.”  — Nick Reva

The nuance worth keeping: he argued bug bounties absolutely should still exist, because the genuinely novel, high-complexity vulnerabilities still won’t be found by automated pentest tooling, and “there shouldn’t be a race to the bottom in every category.” Triage the AI noise with AI; reserve human researchers for the consequential, novel work.

6. Human-in-the-loop at the critical decision points, automation on the main line

The bug-bounty discussion ran into the harder question: an autonomous offensive agent has no “rules of engagement” the way a human pentester does — you can’t easily tell it “this is far enough.” Reva’s model, which he tied to the Anthropic framing, is to gate the decisions that matter and automate the rest:

“it’s human in the loop for the critical decision points. And then… maybe like the main line aspects of it are… mostly automated, right?”  — Nick Reva

For teams deploying offensive or autonomous security agents, the design pattern is to place explicit human approval at the consequential points — scope expansion, exploitation, lateral movement — rather than trying to encode complete rules of engagement up front, and automate the routine work between those gates. It’s the same principle the story-6 executive order reaches for at national scale: build the measurement and the review checkpoint, don’t pretend full autonomy is safe.

7. GRC engineering: move off the annual PDF refresh and embed controls in the lifecycle

Shivani Doke’s half of the conversation reframes governance the same way Reva reframes appsec. The reputation problem, she argued, comes from GRC being a point-in-time, document discipline:

“that’s where the beef… against the GRC folks really comes because we mostly focus on having all these policies. There’s this annual policy refresh where we just make some edits in the Word document in the PDFs… But we have to move away from that towards… really embedding these security controls within our development life cycles.”  — Shivani Doke

On ownership, she rejects a one-team answer:

“who owns AI risk really depends on the use case.”  — Shivani Doke

A business unit that requests an AI-forward vendor owns that vendor’s risk (via third-party assessment, model cards, continuous scanning); an in-house fine-tuned or foundational model puts ownership on the IT or developer-experience team building it. The concrete GRC-engineering control she described: if policy says no AI-agent-authored code can be merged, implement an automated flag — a two-person control — that blocks that code in the pipeline rather than attesting it in a document. An audience practitioner added the audit-automation angle: run a “SOC 2 every morning at 10:00 AM” to check whether built controls are still intact, and tie breaks to business risk before they become audit risk.

7. Continuous validation across an Nth-party attack surface

The most cloud-relevant control of the night ties both speakers together. Reva offered his “Security Knowledge Graph” — built on the open-source Cartography framework — as GRC engineering in practice: aggregate cloud and endpoint telemetry into a node graph and check, at runtime, whether a designed control is actually operating.

“you can even take controls that you’ve designed and say, is this control operating based on real time runtime data? So you have like eBPF probes, like observing your pod security… you can actually do that at runtime to see if that control is implemented. And if it isn’t… then you can fire a Slack notification or a Jira ticket to that owning team.”  — Nick Reva

Doke supplied the reason that runtime validation now has to reach down the supply chain — the vendor surface is transitive:

“when you onboard a third party vendor, you’re also onboarding that third party vendor’s other dependencies, other vendors. So basically that becomes a transitive dependency. So if something happens to my data that’s been hosted on the third party’s cloud and the third party’s cloud security provider has a breach, then my data has been breached.”  — Shivani Doke

This is the conversation’s tightest link to the week’s lead story. The Miasma worm (story 1) is exactly an Nth-party compromise — a trusted vendor’s namespace, poisoned upstream, stealing Kubernetes service-account tokens at install time — and the cgroups escape (story 3) is exactly the pod-boundary failure Reva’s eBPF probes are watching for. Doke flagged that current Nth-party monitoring tooling is “not… state of the art” and can’t yet be fully relied on; the practical posture is to interrogate each vendor’s own AI dependencies and downstream sub-processors, and to validate the controls you depend on against live runtime data rather than a signed attestation.

Practical takeaways for cloud security leaders

A few things senior cloud security leaders can act on in the next 30–60 days:

• Put the security signal on the pull request. Run prompt-injection testing (e.g., Promptfoo) as an integration test in every repo where AI development happens, so engineers get inline feedback rather than a gate they route around.

• Test injection yourself — don’t buy a comparable metric. The labs don’t agree on how to measure it, so run adversarial tests against your own tool-calling and retrieval paths before deploying an agent in a sensitive workflow.

• Validate controls at runtime, not on paper. Stand up control-validation against live telemetry (eBPF pod-security probes, cloud + endpoint graph) and auto-route drift to the owning team via Slack or Jira.

• Triage AI bug-bounty noise with AI. Use automation to clear the low-skill, AI-generated report volume and reserve human researchers for novel, high-complexity findings.

• Reach down the supply chain. Treat install-time scripts and transitive (Nth-party) dependencies as a credential-theft surface — monitor preinstall/postinstall execution and interrogate each vendor’s own AI dependencies and sub-processors.

🧠 Mental Model — The Vendor List Was the Inventory. The Inventory Is Now the Vendor List.

For 20 years, security ran on gates: a review step that work had to pass through before it shipped. The gate worked because the attacker’s loop was slower than the approval cycle — there was time to stop, inspect, and sign off.

That timing assumption is now inverted. The Miasma worm executed at install time, the KEV deadlines beat monthly patch cycles, the Sophos lab compressed the malware develop-test loop, and Cisco is rebuilding its disclosure cadence around a shrinking disclosure-to-exploitation window. When offense runs at engineering speed, a gate is just a place the attacker has already passed.

The control that survives is the one already running where the work happens — on the pull request, in the pipeline, against live runtime telemetry — with a human reserved only for the consequential decision. Guardrails, not gates. Embed the control in the lifecycle, validate it continuously, and put the human at the point of risk acceptance, not at the door.

📚 RELATED RESOURCES 🎧

• Wiz Research — Miasma supply-chain attack on Red Hat npm packages

• Palo Alto Unit 42 — Monitoring npm supply-chain attacks

• CISA Known Exploited Vulnerabilities (KEV) Catalog

• Palo Alto Unit 42 — CVE-2022-0492 cgroups container-escape analysis

• Aqua Security — Escaping containers by abusing cgroups

• Sophos research (via BleepingComputer) — AI-built ransomware toolkit automates EDR evasion

• The White House — Promoting Advanced AI Innovation and Security (executive order)

• Promptfoo — open-source prompt-injection / LLM testing framework 

• Cartography — open-source asset/relationship security graph framework

Podcast Episode

• Full Episode with Nick Reva and Shivani Doke — Complete transcript and audio for this week's featured conversation

Question for you? (Reply to this email)

🤔 Is your security signal arriving on the pull request, or still waiting at a gate the attacker already ran past?

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

This week's Cloud Security Newsletter topic: Third-Party Risk in the AI Era — Why Your Vendor Inventory Is Already Wrong (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 week, Europe codified digital sovereignty as procurement law the same week the Netherlands used its investment-screening authority to block a US company from buying the host of its national identity system. Two actively-exploited vulnerabilities (Drupal, Microsoft Defender) hit federal patch deadlines. A North Korean Lazarus subgroup went fully memory-resident, neutralizing most filesystem-based forensics in financial-sector intrusions. And Anthropic shipped a free in-IDE security review plugin for Claude Code that moves AppSec scrutiny inside the AI coding loop developers are already using.

This week's conversation is with Igor Andriushchenko, CISO at Lovable (and 4x prior CISO across telco, AI, and medical-device companies), and Jasper Mills, co-founder and CEO of ethira, hosted by Ashish Rajan. The thread running through both the news and the episode: trust assumptions are breaking faster than the programs built to manage them. The vendor list is wrong because half the new vendors are five-person AI companies. The "vendor" category itself is wrong because every employee building with AI is functionally introducing third parties without procurement ever seeing them.[Listen to the episode]

⚡ TL;DR for Busy Readers

- Netherlands blocks Kyndryl–Solvinity acquisition (DigiD host). EU Tech Sovereignty Package follows next day. CLOUD Act is now a procurement gate, not a legal-theory debate.

- Drupal CVE-2026-9082 actively exploited. CISA federal deadline today. PostgreSQL-only, CVSS 6.5 understates the operational risk.

- Microsoft pushed out-of-band patches for two Defender zero-days (RedSun, UnDefend) after six weeks of LPE exploitation. The EDR is the escalation path.

- Lazarus deployed memory-only RemotePE against financial and crypto firms. Filesystem-based EDR triage fails. Memory acquisition belongs in your IR runbook now.

- Igor + Jasper's frame: "second-party risk" — every employee vibe-coding an app with an MCP attached is a vendor your TPRM program does not know about.

📰 THIS WEEK'S TOP SECURITY HEADLINES

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

1. Netherlands Blocks Kyndryl–Solvinity Acquisition; EU Tech Sovereignty Package Lands the Next Day

Primary source: European Commission Digital Strategy 
Reporting: TechCrunch · DutchNews 
Analysis: CNBC · TheNextWeb

What happened: On May 26, Dutch State Secretary for the Digital Economy Willemijn Aerdts issued a "complete prohibition" on Kyndryl's acquisition of Solvinity — the Dutch cloud provider that hosts DigiD, the national digital identity system used by millions of citizens to access tax, health, and government services. It is the first acquisition the Dutch Investment Screening Bureau (BTI) has ever fully blocked. The Dutch competition authority cleared the deal on antitrust grounds in February; the separate investment-screening review reached the opposite conclusion on public-interest grounds. The named concern was the US CLOUD Act.

One day later, the European Commission unveiled its long-delayed Tech Sovereignty Package, which includes the Cloud and AI Development Act (CADA) and Chips Act 2.0. The package proposes to restrict EU member-state governments from using US-headquartered cloud platforms for sensitive public-sector data in healthcare, finance, and judicial systems. CLOUD Act is again the named cause. The package still requires all 27 member-state approvals.

Why it matters: This is the first time the CLOUD Act has been codified as a procurement-disqualifying condition at EU scale rather than litigated through Schrems II–style data-protection rulings. The threat model is no longer hypothetical legal risk — it is a procurement gate. For US-headquartered enterprises with EU operations, the assumption that AWS, Azure, and GCP regions in Frankfurt, Dublin, or Paris are functionally interchangeable with sovereign-EU alternatives for sensitive public-sector contracts is now wrong. For European enterprises in regulated sectors, sovereignty review is moving from a contracts question to an architecture question. This connects to Jasper's point in this week's conversation: contractual accountability under DORA is the closest existing analogue, and the same mechanism — written guardrails that follow the data — is what regulators are now extending across the rest of EU procurement.

2. Drupal CVE-2026-9082 — Actively Exploited, CISA Federal Deadline Today

Primary source: Drupal advisory SA-CORE-2026-004 
Reporting: The Hacker News · BleepingComputer 
Analysis: CISA KEV Catalog

What happened: Drupal disclosed CVE-2026-9082 on May 19 — an unauthenticated SQL injection in Drupal Core's database abstraction API affecting PostgreSQL-backed deployments. Drupal rated it "highly critical" (23 of 25 on its internal severity scale). Discovered by Google/Mandiant researcher Michael Maturi. Within 48 hours of patch release, Drupal updated its advisory to confirm exploitation in the wild. CISA added the CVE to KEV on May 22 with a federal civilian remediation deadline of May 27 under BOD 22-01. Imperva reported observing over 15,000 attack attempts against nearly 6,000 sites across 65 countries, with gaming and financial services sites comprising roughly half the attack traffic. MySQL, MariaDB, and SQLite-backed deployments are not affected.

Why it matters: Drupal Core sits behind a long tail of government, education, research, and enterprise public-facing sites. The vulnerability is unauthenticated and the gap between disclosure and in-the-wild exploitation was under 48 hours. Programs that triage by CVSS alone will deprioritize this — the score is 6.5, lower than the operational risk. EPSS and KEV are the better signals. The PostgreSQL specificity is a natural triage gate, but only if asset inventory is current enough to answer "which Drupal sites are on Postgres?" without paging someone.

3. Microsoft Defender Zero-Days RedSun and UnDefend — Out-of-Band Patches After Six Weeks of Exploitation

Primary source: Microsoft Security Response Center 
Reporting: BleepingComputer · SecurityWeek 
Analysis: TechTimes (Huntress confirmation)

What happened: On May 21, Microsoft pushed out-of-band patches for two Windows Defender zero-days — CVE-2026-41091 "RedSun" (CVSS 7.8) and CVE-2026-45498 "UnDefend" (CVSS 4.0) — after six weeks of confirmed in-the-wild exploitation. RedSun is a local privilege escalation in the Microsoft Malware Protection Engine ≤1.1.26030.3008 caused by improper link resolution before file access. A low-privileged user can manipulate a symbolic link or directory junction during a Defender scan to escalate to SYSTEM. UnDefend is a DoS flaw exploited by standard users to block Defender definition updates. Both were originally disclosed publicly without coordination by a researcher operating under the aliases "Chaotic Eclipse" / "Nightmare Eclipse" between April 3 and April 16. The first in the series (BlueHammer, CVE-2026-33825) was patched April 14. RedSun and UnDefend went unpatched for six weeks while Huntress confirmed exploitation in hands-on intrusions. The same engine update (Microsoft Defender Antimalware Platform 4.18.26040.7) also fixes CVE-2026-45584, a heap-based RCE (CVSS 8.1) not yet confirmed exploited. CISA added RedSun and UnDefend to KEV on May 20 with a federal deadline of June 3.

Why it matters: The exploited flaws are in the endpoint agent itself. The defensive control becomes the privilege-escalation vector — compromised low-privilege accounts reach SYSTEM through the AV the SOC trusts. This inverts the trust direction of the control, which makes it the most consequential class of EDR/EPP bug. For Windows cloud workloads (VDI, RDS gateways, jump boxes, Citrix farms on Azure, AWS, or GCP), this is the lateral-movement layer. CVE-2026-45584 — RCE without user interaction — is the one to watch. Exploitation isn't confirmed yet, but the technical bar is the lowest in the bundle.

4. Microsoft SharePoint CVE-2026-45659 — RCE with Only Site Member Permissions

Primary source: Microsoft Security Response Center advisory 
Reporting: The Hacker News · Help Net Security 
Analysis: Dark Reading

What happened: Microsoft released patches for CVE-2026-45659 (CVSS 8.8), a high-severity RCE in on-premises SharePoint disclosed as part of May 2026 Patch Tuesday (advisory published May 21, broader coverage May 26–27). The flaw is a deserialization-of-untrusted-data issue (CWE-502). An attacker with only Site Member permissions — no admin rights, no elevated privileges — can execute code remotely on a SharePoint Server instance. Network vector, low complexity, no user interaction. Affected: SharePoint Server Subscription Edition, SharePoint Server 2019, and SharePoint Enterprise Server 2016. Microsoft assesses exploitation as "less likely" with no public PoC at disclosure, but the 2025–26 pattern for SharePoint deserialization bugs has consistently been reclassification upward within weeks once PoCs surface — CVE-2026-32201 followed that pattern and was added to CISA KEV in April.

Why it matters: "Authenticated but only Site Member" is almost no bar at all. SharePoint Site Member permissions are routinely granted to contractors, vendors, business-line partners, and broad employee groups. Treat this as one credential-compromise hop from RCE. The conservative move is to patch on Microsoft's original cadence, not the assessed-likelihood cadence. SharePoint Online is patched centrally by Microsoft; the hybrid and on-prem footprint is where the residual risk concentrates.

5. Lazarus Group Deploys RemotePE — Fully Memory-Resident RAT Against Financial and Crypto Firms

Primary source: Fox-IT (NCC Group) 
Reporting: SC Media · The Hacker News 
Analysis: Cryptopolitan

What happened: On May 22, NCC Group subsidiary Fox-IT published research on a new toolset deployed by a North Korea-linked Lazarus subgroup (overlapping with AppleJeus, Citrine Sleet, UNC4736, and Gleaming Pisces) in IR engagements against financial and crypto organizations. The toolset has three components forming a chain: DPAPILoader decrypts and loads RemotePELoader from disk using the Windows Data Protection API; RemotePELoader beacons to a C2 server and receives RemotePE, a RAT executed entirely in memory with no filesystem artifacts. The chain uses environmental keying via DPAPI (the second-stage loader can only be decrypted on the originally-infected host), Hell's Gate direct syscalls, and ETW patching. Initial access is via Telegram social engineering, with the actor impersonating trading-firm employees using cloned Calendly and Picktime scheduling pages. This toolset replaced the actor's previous ThemeForestRAT and PondRAT.

Why it matters: Memory-only execution plus DPAPI environmental keying defeats most filesystem-based forensics. The standard EDR triage workflow — pull artifacts, find the dropped binary, hash and pivot — collapses. The DPAPI keying is the technically interesting part: even if defenders capture RemotePELoader, they cannot decrypt the next stage on a different machine. That is anti-collaboration design by construction. The targeting (trading firms, DeFi, banks with international operations) is the same population that runs the most sensitive cloud workloads. AWS, Azure, and GCP credentials, BI tool API keys, and trading-platform integrations are the actual prize.

6. Iranian APT Nimbus Manticore — AI-Assisted MiniFast Backdoor, AppDomain Hijacking, SEO Poisoning

Primary source: Check Point Research 
Reporting: The Hacker News · SecurityWeek 
Analysis: Infosecurity Magazine

What happened: On May 22, Check Point Research published "Fast and Furious — Nimbus Manticore Operations During the Iranian Conflict," documenting three waves of activity between February and April 2026 by the IRGC-affiliated threat actor Nimbus Manticore (also tracked as UNC1549, Screening Serpens). The campaigns coincide with Operation Epic Fury, the joint US–Israeli military operation that began February 28. Targets: aviation, software, defense, and telecommunications organizations across the US, Europe, Saudi Arabia, and Australia. Three tradecraft shifts: AppDomain hijacking replaces DLL sideloading (a trojanized XML .config file placed next to a legitimate .NET application loads an attacker-controlled DLL via the AppDomainManager class); a new backdoor named MiniFast replaces the older MiniJunk family, with hallmarks Check Point attributes to AI-assisted development; and SEO poisoning via a counterfeit Oracle SQL Developer download page. The March wave used a trojanized Zoom installer.

Why it matters: AppDomain hijacking is well-known but underweighted relative to DLL sideloading in most hunt programs. The detection signal — an XML .config file appearing next to a legitimate .NET binary, named after the abused binary with a .config suffix — is concrete and hunt-friendly. AI-assisted malware development is no longer a forecast. Check Point's fingerprints (excessive error handling on trivial functions, verbose repetitive naming, debug-style status strings) are now indicators. State-actor capability ramp times are getting shorter. Aviation, defense, and software-supplier organizations in Australia and Saudi Arabia in scope is worth flagging for AU/NZ readers — Iranian APT activity is not historically the top concern for that region.

7. Anthropic Ships Claude Code Security-Guidance Plugin and Self-Hosted Sandbox

Primary source: Anthropic announcement (via SecurityWeek) 
Reporting: Help Net Security · Cybersecurity News 
Analysis: Anthropic open-source reference (GitHub)

What happened: At the Code w/ Claude event in London the week of May 26, Anthropic announced two security-relevant features for Claude Code, its terminal-based AI coding agent. The security-guidance plugin (free, all plans, launched May 26) is a three-layer reviewer that runs inside the Claude Code session. Layer one is a deterministic regex pass with no model call — it catches around 25 dangerous patterns (eval, os.system, child_process.exec, pickle deserialization, dangerouslySetInnerHTML and similar) at zero usage cost. Layers two and three are deeper agentic reviews triggered on model turns and on commits, reading surrounding callers and sanitizers to minimize false positives. Anthropic's internal rollout reported a 30–40% reduction in security-related PR comments. Anthropic separately announced a public-beta self-hosted sandbox: Claude Managed Agents now run tool execution in customer-controlled environments (the customer's own infrastructure or a managed provider like Cloudflare, Daytona, Modal, or Vercel), while the orchestration loop stays on Anthropic infrastructure. Files, repositories, and runtime images stay inside the customer perimeter.

Why it matters: AppSec embedded in the AI coding loop is the architectural shift the senior reader's developers are already living through. Free, zero-config security review at the point of code creation collapses the developer-friction tax that has been the longstanding gap in shift-left. The self-hosted sandbox addresses the most concrete enterprise objection to agentic AI coding — that agent-executed code, files, and secrets leave the corporate perimeter. Cloud security architects now have an architecture pattern to point to: agent reasoning external, execution internal. This connects directly to Igor's framing in this week's conversation. When employees build with AI agents and connect MCPs to internal data, the company is creating second-party risk on a continuous basis. Tooling that catches issues at the point of creation is the only realistic way to keep up.

🤖 8. Akamai to Acquire LayerX for $205M — Browser-Layer AI Usage Control Becomes a Platform Feature

Announced May 14 — outside the strict 5-day window but included as the largest cybersecurity M&A of May 2026 and directly relevant to the AI-governance thread running through this week's news.

Primary source: Akamai press release 
Reporting: SecurityWeek · Help Net Security 
Analysis: BankInfoSecurity

What happened: Akamai announced a definitive agreement to acquire LayerX, a Tel Aviv–based browser-native security firm, for approximately $205 million in cash. LayerX provides AI usage control and secure-enterprise-browser (SEB) technology that runs on top of standard browsers (Chrome, Edge, Safari) rather than requiring users to switch to a proprietary browser. The platform covers shadow AI discovery, gen-AI data loss prevention, access controls for AI tools, and protection for agentic browsers (Atlas, Comet). The deal is expected to close in Q3 2026. This is Akamai's third Israel-based security acquisition after Guardicore (2021, ~$600M) and Noname Security (2024, ~$450M).

Why it matters: Browser-layer telemetry is becoming a category. The deal validates that "AI usage control" — which workforce uses which models with which data — is a platform requirement, not a standalone product. For cloud security architects, this signals a likely shift in vendor roadmaps: browser-based DLP, SaaS access governance, and AI-tool inventory will converge with ZTNA and CASB rather than sit alongside them. Expect Zscaler, Palo Alto, and Netskope to respond with comparable consolidation moves. The agentic-browser detail (Atlas, Comet) is the forward-looking part. If workforce starts using AI browsers that act on their behalf, the security control point has to live there — network-layer DLP cannot see what a browser-resident agent does inside a session.

🎯 Cloud Security Topic of the Week:

Third-Party Risk in the AI Era - Why Your Vendor Inventory Is Already Wrong

The pre-AI state of third-party risk management was, in Igor's word, "abysmal." A spreadsheet of 200-question vendor checklists, hours filled out by both sides, generating documentation nobody reads until an auditor asks for it. Both sides know it is a paper exercise. Both sides do it anyway.

What Igor and Jasper lay out in this week's conversation is that the program was barely surviving the old model when AI broke three assumptions underneath it at once. The vendor list shrank from a handful of large suppliers to dozens of five-person AI companies whose risk profile a 200-question checklist cannot meaningfully assess. The "vendor" boundary itself stopped holding — when an employee builds an internal app with AI and wires an MCP server into Salesforce, no procurement event has occurred, but a third party has effectively been introduced inside the perimeter. And the pace at which both sides operate started moving toward agent speed. Pactum is already running agent-to-agent procurement negotiations. The same architecture applied to vendor questionnaires is technically obvious. The only thing holding it back is comfort.

That is the framing for this week's conversation. Igor and Jasper are not predicting a distant future. They describe a transition already happening in pieces — and a series of practical decisions cloud security leaders need to make in the next 12–18 months about what to automate, where to keep humans in the loop, and how to inventory a class of "vendors" the existing TPRM program cannot see. [Listen to the full episode →]

Featured Experts This Week 🎤

• Igor Andriushchenko — Head of Information Security & CISO, Lovable

• Jasper Mills — Co-founder & CEO, ethira

• 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:

• Third-Party Risk Management (TPRM): Assessing, monitoring, and governing the security and compliance posture of external suppliers — historically driven by vendor questionnaires (SIG, CAIQ), SOC 2 reports, pen test attestations, and contractual clauses.

• Second-Party Risk: Igor's term for the risk introduced when internal employees or departments build their own applications with AI — functionally creating new "vendors" the procurement-driven TPRM program never sees.

• MCP (Model Context Protocol): A protocol that lets AI agents connect to external tools and data sources through standardized connectors. An MCP server bridges a language model to systems like Salesforce, Git, databases, or internal APIs. From a TPRM perspective, every MCP connection is a privileged integration point.

• Shadow AI: AI tools adopted by employees without security or procurement review. A common pattern: employees bypass enterprise restrictions on a sanctioned tool by creating a personal account and re-enabling the feature there.

• DORA (Digital Operational Resilience Act): EU financial-sector regulation that requires ongoing, contractual accountability for ICT third-party providers — including subcontractors, exit strategies, and continuous monitoring. The closest existing analogue for how regulators will likely govern AI agents.

• Agent-to-Agent (A2A): The emerging pattern where one organization's AI agent communicates directly with another organization's AI agent — for procurement negotiation, vendor onboarding, or security questionnaire exchange. Pactum is one of the early production examples.

• CLOUD Act: US law (2018) that lets American law enforcement compel US-headquartered cloud and technology providers to disclose customer data regardless of where the data is physically stored. The named concern behind both the Dutch Kyndryl–Solvinity block and the EU Tech Sovereignty Package this week.

This week's issue is sponsored by Tamnoon

The Alert Crisis: 14M Cloud Threats Found… But Who's Fixing Them?

Tamnoon's 2026 State of Cloud Remediation Report analyzed over 14 million CNAPP detections across hundreds of enterprise environments and 10 CNAPPs.

With 53% of detections still open across cloud environments, critical alerts taking 150 days to close, and vulnerability management MTTR increasing by 22% since last year, it’s clear more work needs to be done.

Read the 2026 State of Cloud Remediation Report for a full breakdown of what's improving, what's regressing, and the benchmarks your board will ask about next quarter.

Want to know the one category that got slower this year? See the full report.

💡Our Insights from this Practitioner 🔍

1. The pre-AI state was a paper exercise. AI doesn't fix it — it raises the stakes.

The opening framing from Igor lands the first point hard:

"If you take a security program, right? There is a whole bunch of security program dedicated, any security program dedicated to third-party risk management. You can fail a lot of audits on it. It requires a lot of documentation, a lot of rigor. And the more, the bigger company becomes, the more impossible it becomes to control your vendors the way you actually bring value. It becomes this kind of paper exercise where you do something for the sake of doing it." — Igor Andriushchenko

Jasper's experience implementing DORA at her previous company hit the same wall from a different direction — DORA's accountability requirements collided with the AI-tooling wave at exactly the moment her organization was trying to onboard productivity tools at speed:

"The process of, like, using the tools on the market felt like I'd been catapulted to 1979. It was the worst experience of my professional career." — Jasper Mills

The practical implication for senior cloud security leaders: the program does not need optimization. The cadence at which AI-driven vendors arrive, and the rate at which employees create new internal applications that behave like vendors, is fundamentally incompatible with a checklist-driven model. Optimization within the existing frame produces the same paper exercise faster.

2. Second-party risk is the new category — and the existing program cannot see it

The most useful new vocabulary in the conversation is Igor's distinction between third-party and second-party risk:

"Should we treat each of these people or their departments as mini vendors? Because essentially we need to apply to those, whatever they produce, some kind of rules, some kind of governance. And that governance is very similar in its nature to third party risk. You're, like, it's almost like it's a second party risk. It's your employees, it's your builders." — Igor Andriushchenko

Jasper's working example crystallizes the operational problem:

"Or maybe John built it themselves... and then he found an MCP that he has spun up and now it's going to Salesforce and, like, fetching whatever it wants." — Jasper Mills

There is no procurement event for John. No SOC 2 review. No vendor questionnaire. There is an MCP server reaching into a CRM, configured by someone in a non-technical team, governed by nothing. From a TPRM program's perspective, John's app does not exist. From an actual risk perspective, it is one of the highest-velocity new sources of exposure in the organization.

The practitioner translation: TPRM coverage has to extend to inventory the program does not currently own. Discovery of internal apps, MCP servers, and the data sources they touch needs to live alongside the vendor inventory — and the same risk-tiering language needs to apply to both.

3. The "kindergarten with a nuclear bomb" problem

Jasper's most-quoted line in the episode comes from a customer conversation, and it captures why the AI-productivity push is currently outrunning the controls:

"A CISO called me and he said, like, 'We have just given a kindergarten a nuclear bomb.'" — Jasper Mills (recounting a customer conversation)

The CISO had enabled AI tooling for sales and other non-technical teams. The technology worked. The productivity gains were real. Visibility into what those teams were doing with the tooling — where data was going, which integrations had been wired up — was effectively zero. The control plane lagged the adoption plane by months.

Igor frames the dynamic from the other side — what's happening inside the user's head when they make the choice to bypass a sanctioned tool:

"People just create a personal workspace, and they just enable that feature. Everything feels solvable, just, like, one toggle away." — Igor Andriushchenko

When the friction between "thing I want to do" and "thing I can do" collapses, the security implication is no longer a calculation most users perform. The ergonomic gap between sanctioned and unsanctioned has to close, or the workforce will close it for the program.

4. What actually gets automated — and what stays human

Both speakers are practical about where the line sits today. Jasper described what ethira automates and what it explicitly does not:

"We can do all of that autonomously. Where we actually pull the humans in is at the end. So we basically aggregate everything that we cannot get, or we'll give an analysis based on your risk tolerance — this is sort of what we would recommend, and these are the mitigating factors if you want to onboard or not." — Jasper Mills

The automation absorbs data gathering, financial and news checks, GitHub-based open-source maintenance signal, pen test request workflows, and the back-and-forth that historically dominated TPRM analyst time. Human judgment stays at the point of risk acceptance, where it belongs.

Igor reinforces the same pattern from the consumer side and recommends an underrated starting point that does not require new procurement:

"I'm very excited about AI doing inventory of everything that's going on in the company, 'cause we already have some solutions. They just look into telemetry from the device. Let's say they take CrowdStrike telemetry, they take any other agent kind of running on your computer telemetry, and then they analyze it, and it was like, 'Oh, I found these 75 vendors here.'" — Igor Andriushchenko

Practitioner takeaway: AI-driven inventory is the highest-leverage place to start. Most enterprises already have the telemetry sitting in their EDR. What they don't have is a vendor list reconciled against it. Running AI over existing endpoint telemetry to produce a continuous vendor inventory closes a gap the spreadsheet has never been able to close.

5. Build vs. buy for the TPRM stack — both speakers come down on "buy"

This is one of the rare sections where two AI-native operators arrive at the same conclusion from different angles. Igor's reasoning is operational, not philosophical:

"Imagine you have to build your third party risk management from scratch... how many people are working on that really? Like, is there one engineer who's vibe coding it? Good. But then what happens next? It needs to be maintained. Somebody needs to take a look at logs, at alerts, at telemetry... and you end up with somebody whose full-time job is just maintaining that app." — Igor Andriushchenko

He extends the point to audit posture: if it was your own fault, you decided to take that risk and build it yourself, then it could be a more serious issue.

Jasper makes the same point from the vendor side — the unique data sources and hallucination-mitigation work that a serious TPRM product invests in are not realistic to replicate as a side project. For cloud security leaders evaluating whether to build internal TPRM tooling on top of foundation-model APIs, the maintenance tail and the audit-defensibility tail are typically larger than the build cost, and neither shows up in the initial estimate.

6. Where this ends up: agent-to-agent procurement, contractual accountability as guardrails

Both speakers point at the same destination. Igor names the year:

"I've heard it many times, 2027 is the year of agent to agent. We are looking at third party management agent, risk management agents talking to company agents, like vendor agents that are just there listening for anyone coming in, asking about pen test results or NDA or something like that... It may sound bad, but there is no place for humans in that loop." — Igor Andriushchenko

Jasper draws the architectural line back to the regulatory anchor that the whole conversation circles:

"DORA, one of the key sort of foundations is contractual accountability. And one of the things that we've thought about is if you think about people, if you think about agents, if you think about vendors, historically what you've been able to do, if you look at when something goes wrong, you go back to the contract, you call a person up. But actually what you're able to do with vendors, with third-party agents, even with first-party agents, you can then actually take the contract that you have and create guardrails." — Jasper Mills

The contract becomes the guardrail. The guardrail becomes the policy the agent operates under. The audit trail becomes the proof that the policy was followed. That sequence — contract → guardrail → enforceable policy on agent behavior — is the most actionable architectural insight in the episode for senior cloud security leaders thinking about how their TPRM program survives 2027.

7. The "IT becomes HR" frame — managing agents like contracted workforce

Jasper's closing prediction is the one to sit with:

"IT will end up being like HR, in the fact that it will be like your contracted workforce. So you'll have a lot of contracted agents, you'll have a life cycle, you'll have a cost within that. They have their own credentials. But I think you'll manage it very similarly to third party risk, and the vendors will eventually have their own agents that are working in your systems." — Jasper Mills

Igor extends the metaphor into something more uncomfortable — and useful for designing controls:

"What defines a person is the agency. We have free will. We decide what to do next. The agents have that too. Not to the same extent, of course. There is a program where there is intention we give them, but still, sometimes they do things we do not expect." — Igor Andriushchenko

"The moment we start thinking, 'Hey, this thing will behave deterministically,' we've failed as security people." — Igor Andriushchenko

The practical implication: the controls that work for non-deterministic actors (humans, contractors, agents) are different from the controls that work for deterministic systems. Audit logging at every action, source-and-destination metadata, scoped credentials, lifecycle management with onboarding and offboarding, and behavioral monitoring against a baseline — these are HR-adjacent controls. They are not the controls most TPRM programs are set up to run.

Practical takeaways for cloud security leaders

A few things senior cloud security leaders can act on in the next 30–60 days:

• Start inventory with the telemetry you already have. Run AI over existing EDR telemetry to build a continuous vendor and application inventory before paying for a new tool. Most enterprises have the data — they just don't have the reconciled list.

• Add a "second-party" track to TPRM. Internal apps built with AI and connected to internal data sources (especially via MCP) need a risk-tiering process equivalent to the one used for external vendors. Procurement isn't going to catch these.

• Treat MCP servers as privileged integrations. Every MCP connection from an internal app to a SaaS data source (Salesforce, Git, internal APIs, CRM) is a privileged integration. Inventory, scope, and audit them with the same rigor applied to service accounts.

• Pick the autonomy level deliberately. Match the toggle to the risk class. Agent-to-vendor questionnaire negotiation is reversible and low-blast-radius; agent-driven risk acceptance is not.

• Map contractual accountability to agent policy now. Whether the organization is regulated under DORA or not, the contract → guardrail → policy sequence is the architectural pattern that survives the agent-to-agent transition. The teams that have written this out before 2027 will not have to retrofit it under regulatory pressure.

🧠 Mental Model — The Vendor List Was the Inventory. The Inventory Is Now the Vendor List.

For 20 years, TPRM ran on a procurement-driven vendor list. Procurement onboarded a supplier, security reviewed it, the supplier went on the list, the list got audited. The list was the inventory.

That sequence is now backwards. The inventory — what your EDR sees running, what your network sees connecting, what your developers have wired up — is the source of truth. The vendor list is a downstream projection of it, and an increasingly incomplete one. Procurement no longer sees a meaningful share of the third parties operating inside the perimeter, because employees are creating them with AI faster than procurement can intake them.

The program that survives 2027 starts from inventory and projects out to a vendor list. Not the other way around.

📚 RELATED RESOURCES 🎧

• ethira — Jasper's company; product focus on automated TPRM and agent governance

• Lovable — Igor's company; AI-native app builder

• EU Digital Operational Resilience Act (DORA) — Official text and guidance for financial-sector ICT third-party accountability

• Anthropic Model Context Protocol (MCP) — Protocol documentation and best-practice guidance for securing AI agent connectors

• CISA Known Exploited Vulnerabilities (KEV) Catalog — For Drupal, Microsoft Defender, and SharePoint vulnerability tracking referenced this week

• Fox-IT — RemotePE technical research — Lazarus toolset analysis and detection guidance

• Check Point Research — Nimbus Manticore — IRGC-affiliated APT activity, AppDomain hijacking, and AI-assisted malware fingerprints

• OWASP Top 10 for Agentic Applications — For organizations extending AppSec frameworks into AI-assisted development

Podcast Episode

• Full Episode with Igor Andriushchenko and Jasper Mills — Complete transcript and audio for this week's featured conversation

Question for you? (Reply to this email)

🤔 Is your TPRM program seeing the apps your own employees built with AI this quarter or just the vendors procurement onboarded?

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

This week's Cloud Security Newsletter topic: The Cybersecurity Verification Law — Why Offence Has a Superpower and What Defence Can Do About It (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's news has one through-line: trust is breaking down in the developer tooling layer. TeamPCP reached 3,800 GitHub internal repositories through a single poisoned VS Code extension on one employee's laptop. The Mini Shai-Hulud worm compromised TanStack's legitimate release pipeline and dragged OpenAI, Mistral, UiPath, and Guardrails AI into the blast radius. Grafana's GitHub token was lifted and its codebase extorted. Microsoft Exchange OWA has been under active exploitation for six days with no patch. And Verizon's 2026 DBIR confirmed it at industry scale: vulnerability exploitation has overtaken stolen credentials as the #1 initial access vector for the first time in 19 years.

This week's conversation is with Sergej Epp, CISO at Sysdig and former CISO at Deutsche Bank and Palo Alto Networks, hosted by Ashish Rajan. Sergej's framing pulls the news together: offense has cheap binary verifiers — pop a shell, capture the flag, exfiltrate the secret. Defense doesn't. Until that gap closes, the speed asymmetry only widens.[Listen to the episode]

⚡ TL;DR for Busy Readers

- GitHub confirmed ~3,800 internal repos stolen via poisoned VS Code extension. TeamPCP's 5th 2026 supply chain hit. Audit dev extensions now.

- Exchange OWA zero-day (CVE-2026-42897) active 6+ days, no patch. EEMS mitigation doesn't cover IE-mode users. Run ExchangeHealthChecker.

- Verizon DBIR 2026: vuln exploitation overtakes credential theft for first time in 19 years. 22,000 confirmed breaches, 60% YoY rise in third-party involvement.

- Mini Shai-Hulud worm hit 170+ packages May 11 — caught two OpenAI 
  employee devices. First malicious npm package with valid SLSA provenance.

- Sergej Epp's argument: offense has cheap binary verifiers (shell popped or not), defense doesn't. The program that wins takes humans out of the response loop before attackers do.

📰 THIS WEEK'S TOP SECURITY HEADLINES

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

1. GitHub Confirms ~3,800 Internal Repositories Stolen via Poisoned VS Code Extension

Primary source: GitHub statement on X (May 20) 
Reporting: SecurityWeek · BleepingComputer 
Analysis: Help Net Security · Infosecurity Magazine

What happened: GitHub confirmed on May 20 that approximately 3,800 internal repositories were exfiltrated after a single employee installed a malicious Visual Studio Code extension. "Our current assessment is that the activity involved exfiltration of GitHub-internal repositories only. The attacker's current claims of ~3,800 repositories are directionally consistent with our investigation so far," GitHub stated. The TeamPCP group claimed responsibility on the Breached cybercrime forum, listing the data for $50,000 with a threat to leak it free if no buyer surfaces. GitHub has stated there is no evidence of customer repository impact, but the investigation is ongoing. This is TeamPCP's fifth major supply chain compromise of 2026. The group has previously compromised Aqua's Trivy security scanner, CheckMarx's KICS, the LiteLLM library, the Telnyx SDK, TanStack, MistralAI, and other packages that depended on those.

Why it matters: A single VS Code extension on one employee's machine reached 3,800 internal GitHub repositories. "Developer workstations are the number one target in supply chain attacks right now, and this is exactly why," Aikido Security's Mackenzie Jackson said. "Most security teams still have zero visibility into what extensions or packages are on their developers' machines, or how recently they were published." For cloud security architects, this collapses three trust boundaries at once: the IDE marketplace as a software distribution channel, the developer workstation as a privileged access endpoint, and the source-code repository as a sensitive data store. GitHub is the platform 90% of the Fortune 100 builds on; the breach hit its own internal code, meaning downstream organizations now face a 6–12 month window where attackers may probe leaked source for novel exploits.

Action for defenders: Build a real inventory of IDE extensions across your engineering org — VS Code, JetBrains, Cursor, Windsurf. Restrict installation to an allowlist of verified publishers. Treat developer workstations as Tier-0 assets with EDR coverage matching domain controllers. Move CI/CD authentication to short-lived OIDC tokens. Rotate any GitHub PATs, npm tokens, or cloud credentials a developer may have touched in the past 30 days.

2. Microsoft Exchange OWA Zero-Day (CVE-2026-42897) Under Active Exploitation - No Patch Six Days In

Primary source: Microsoft Security Response Center advisory 
Reporting: SecurityWeek · BleepingComputer 
Analysis: Dark Reading

What happened: Microsoft confirmed on May 14 that CVE-2026-42897 — a cross-site scripting flaw in the Outlook Web Access component of Exchange Server 2016, 2019, and Subscription Edition — is under active exploitation in the wild. An attacker needs only to send a crafted email; if the recipient opens it in OWA, arbitrary JavaScript executes inside their authenticated browser session, enabling session token theft, mailbox impersonation, and email rule manipulation without the attacker ever touching the server itself. No permanent patch exists.

CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on May 15, giving Federal Civilian Executive Branch agencies until May 29 to apply mitigations. A May 18 update added that the mitigation does not protect users accessing OWA through Internet Explorer or Microsoft Edge in Internet Explorer compatibility mode. Exchange Online is not affected.

Why it matters: Six days into active exploitation with no permanent patch, mitigations that disable features, and an explicit carveout for IE-compatibility-mode users. On-prem Exchange remains one of the most consistently exploited entry points to enterprise environments, and an XSS-class flaw in OWA can convert directly to session-token theft and mailbox impersonation — and from there, into lateral movement into cloud identity systems via Entra Connect.

Action for defenders: Verify EEMS is enabled and mitigation M2.1.x has been applied automatically. Run aka.ms/ExchangeHealthChecker. For air-gapped environments, manually apply EOMT. Identify any user populations still using IE or Edge IE-mode for OWA and force them off until a patch ships. Treat any anomalous mailbox rule creation in your OWA logs from May 14 onward as a high-priority IR signal.

3. Verizon 2026 DBIR: Vulnerability Exploitation Overtakes Credential Theft for the First Time in 19 Years

Primary source: Verizon DBIR 2026 announcement 
Reporting: SecurityWeek · Dark Reading 
Analysis: Qualys research partner breakdown

What happened: Verizon published its 19th annual Data Breach Investigations Report on May 19. More than 22,000 confirmed breaches, nearly double last year's 12,195. For the first time in DBIR history, software flaws (31%) surpassed stolen credentials as the leading initial access vector — and AI accelerating attacks from months to hours is the proximate cause.

Other findings: ransomware in 48% of confirmed breaches (up from 44%); median ransom payment dropped below $140,000; only 31% of victims paid. Third-party-involved breaches up 60% YoY to 48% of total. On AI: 67% of users access AI services from corporate devices using non-corporate accounts; 45% of employees are now regular AI users, up from 15% last year.

The patching crisis is the report's structural finding: only 26% of critical KEV vulnerabilities were fully remediated in 2025, down from 38% the previous year. Median resolution time increased by two weeks (43 days, up from 32), and organizations had 50% more critical bugs to patch than last year.

Why it matters: This is the year's anchoring industry baseline. Qualys, a DBIR research partner, frames it directly: this dataset may be an initial measurement of a "speed of light" for vulnerability remediation processes — a theoretical limit on what any model bound by human triage, change-windows, and approval gates can deliver. Sergej Epp's Zero Day Clock data lines up: in 2020 the disclosure-to-exploitation window was over 18 months; today it sits between 8 hours and 3 days.

Action for defenders: Re-anchor your vulnerability program on exposure window, not patch SLA. Pull your KEV remediation curve for the last 12 months and compare against the DBIR survival analysis. Prioritize by active exploitation, not CVSS. Treat shadow AI (67% bypassing corporate accounts) as a DLP problem today, not a future one.

4. Mini Shai-Hulud Supply Chain Worm Catches OpenAI, Mistral, UiPath, Guardrails — TeamPCP's Fourth Wave

Primary source: OpenAI disclosure · TanStack postmortem 
Reporting: Wiz analysis · Snyk 
Analysis: The Hacker News

What happened: On May 11, TeamPCP executed the fourth wave of the Shai-Hulud npm worm. The attacker published 84 malicious versions across 42 @tanstack/* packages between 19:20 and 19:26 UTC, chaining the pull_request_target "Pwn Request" pattern, GitHub Actions cache poisoning, and runtime extraction of an OpenID Connect (OIDC) token from runner process memory. The coordinated attack compromised over 170 npm packages and 2 PyPI packages, totaling 404 malicious versions — including Mistral AI's SDK suite, UiPath's automation tooling, OpenSearch, and Guardrails AI.

On May 15, OpenAI disclosed it had been caught: "Two employee devices in our corporate environment were impacted by this attack ... unauthorized access and credential-focused exfiltration activity, in a limited subset of internal source code repositories to which the two impacted employees had access."

The payload is built for cloud CI/CD. It steals GitHub tokens, npm tokens, AWS credentials (via IMDSv2), GCP and Azure credentials, Kubernetes service account tokens, HashiCorp Vault tokens, and environment variables — then identifies packages the victim has publish access to and propagates. It is also the first documented case of a malicious npm package carrying valid SLSA provenance.

Why it matters: SLSA provenance was a control model many cloud security programs were planning to lean on. TeamPCP just broke it. And as story #1 makes clear, this campaign was a dry run — the same playbook produced the GitHub internal repo breach nine days later.

Action for defenders: Treat any developer machine or CI runner that installed an affected package version on May 11 as compromised. Rotate every credential reachable from that host. Search for the gh-token-monitor daemon at ~/Library/LaunchAgents/com.user.gh-token-monitor.plist (macOS) or ~/.config/systemd/user/gh-token-monitor.service (Linux) and remove before revoking tokens, to avoid the wiper. Pin all GitHub Actions to full commit SHAs. Block git-tanstack[.]com and *.getsession.org at egress.

5. Grafana Confirms GitHub Codebase Theft After Coinbase Cartel Extortion Attempt

Primary source: Grafana Labs statement 
Reporting: Cybersecurity Dive · The Record 
Analysis: The Hacker News · SecurityWeek

What happened: On May 17, Grafana Labs publicly confirmed an unauthorized party used a compromised token to access its GitHub environment and download the company's codebase. The Coinbase Cartel extortion group listed Grafana on its leak site on May 15. Grafana refused to pay.

Grafana operates an open-source observability platform with more than 25 million users and 7,000 customers globally — including Nvidia, Microsoft, and Anthropic. No customer data or personal information was accessed during the attack.

CoinbaseCartel emerged in September 2025, assessed to be an offshoot of the ShinyHunters, Scattered Spider, and LAPSUS$ ecosystems. The group focuses purely on data theft and extortion, and has amassed 170 victims across healthcare, technology, transportation, manufacturing, and business services.

Why it matters: Three days before GitHub itself was breached through a different vector, Grafana lost its codebase through a stolen GitHub token. The trust model around source-code repositories is breaking down on multiple axes at once. Stolen source code remains risky because private repositories may contain internal logic, secrets, build processes, or unreleased features attackers can analyze for novel exploits.

Action for defenders: Inventory every PAT, app installation token, and OAuth grant against your GitHub org. Set token TTLs as low as your CI/CD architecture tolerates. Apply phishing-resistant MFA across all maintainer accounts.

6. GitHub Action Tag Hijack: actions-cool/issues-helper Compromised via Imposter Commits

Primary source: StepSecurity disclosure 
Reporting: The Hacker News · SC Media

What happened: On May 18, StepSecurity disclosed that the widely used GitHub Action actions-cool/issues-helper had been compromised through a tag-redirection attack. "Every existing tag in the repository has been moved to point to an imposter commit that does not appear in the action's normal commit history," StepSecurity researcher Varun Sharma said. "That commit contains malicious code that exfiltrates credentials from CI/CD pipelines that run the action." A second action, actions-cool/maintain-one-comment, was hit the same way. The exfiltration domain has previously been observed in the Mini Shai-Hulud campaign, suggesting a potential link between the two activities.

Why it matters: The tag-redirection technique exploits the fact that most workflows pin to floating version tags (@v3) rather than full commit SHAs. Any workflow that references the action by version pulls the malicious code on its next run. Only workflows pinned to a known-good full commit SHA are unaffected.

Action for defenders: Audit every workflow for references to the compromised actions. Treat any CI run executing either as a credential exposure event. Implement an org-wide policy requiring SHA pinning for third-party GitHub Actions.

7. NYC Health + Hospitals: 1.8 Million Patients, Including Fingerprints and Palm Prints, Stolen via Third-Party Vendor

Primary source: NYC Health + Hospitals breach notice 
Reporting: TechCrunch · TechRadar

What happened: On May 18, NYC Health + Hospitals disclosed a months-long breach exposing data on at least 1.8 million people. NYCHHC detected the attack on February 2 and secured its network; the hackers had been inside since approximately November 25, 2025 — more than two months of access before detection.

The breach is particularly sensitive because hackers stole biometric information, including fingerprints and palm prints, which affected individuals have for life and cannot replace. NYCHHC tied the intrusion to an unnamed third-party vendor.

Why it matters: Another data point in the DBIR's 60% YoY rise in third-party breach involvement — but with biometric data, where the consequences are permanent. A stolen Social Security number can be replaced. A compromised password can be changed. A fingerprint cannot.

Action for defenders: Audit which third-party vendors store biometric data on your behalf and what the recovery path looks like when one is breached. Force a real conversation with any vendor whose contract permits indefinite biometric retention.

🤖 8. Anthropic to Brief Financial Stability Board on Mythos Vulnerabilities — Bank of England Asked

Primary source: Financial Times reporting (May 18)
Reporting: PYMNTS · TechRadar

What happened: Anthropic agreed to meet with members of the Financial Stability Board (FSB) to discuss its Mythos model. The meeting was requested by Bank of England Governor Andrew Bailey, who is also an FSB member. Many FSB members have grown concerned that Mythos and AI models from other US tech companies could expose weaknesses in banks' cyber defenses. Anthropic said last month that Mythos had "found thousands of high-severity vulnerabilities, including some in every major operating system and web browser," with potential fallout for "economies, public safety and national security."

Why it matters: First time a sovereign-level financial stability regulator has formally engaged with an AI lab on the systemic risk of AI-assisted vulnerability discovery. For CISOs at financial institutions across the FSB's footprint, expect questions in your next exam about exposure window measurement and how your program scales if AI-discovered vulnerabilities arrive at 2–5× current volume in 2026–27.

🎯 Cloud Security Topic of the Week:

The Cybersecurity Verification Law — Why Offense Has a Superpower and What Defense Can Do About It

If you read this week's news brief and felt the underlying mechanic was familiar, Sergej Epp has a name for it: the Cybersecurity Verification Law. The argument goes like this. In every domain where AI has surged — chess, Sudoku, mathematics, benchmark coding — what made the surge possible was cheap verification. You can tell instantly whether the move worked, whether the proof is valid, whether the test passed. AI compounds capability fastest where the feedback loop is binary and cheap.

Map that principle onto cybersecurity and the picture is uncomfortable. Offense has cheap binary verifiers everywhere: you pop a shell or you don't, you capture the flag or you don't, you exfiltrate the secret or you don't. Defense has almost none. "Is this binary 56% malicious?" is not a verifier. "How confident is the SIEM alert?" is not a verifier. That asymmetry is structural — and it explains why offensive AI capability is sprinting ahead of defensive AI capability even when both sides have access to the same models.

That's the framing thread for this week's conversation with Sergej, who's spent 15 years inside cyber defense at Deutsche Bank, Palo Alto Networks, and now as CISO at Sysdig. [Listen to the full episode →]

Featured Experts This Week 🎤

• Sergej Epp — CISO, Sysdig | Former CISO Deutsche Bank, Palo Alto Networks

• 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:

• Cybersecurity Verification Law: Sergej's framing for why offensive AI is outpacing defensive AI. Wherever a domain has cheap binary verifiers (exploit worked / it didn't), AI compounds capability fast. Offense has these natively; defense doesn't.

• Zero Day Clock: Sysdig's running measurement of the time between a CVE being disclosed and being exploited in the wild. In 2020 the window was over 18 months. As of this year it's between 8 hours and 3 days, depending on the cohort.

• YOLO mode (Claude Code): Auto-approve mode in which the agent runs end-to-end without per-action confirmation. Sergej uses this as the offensive analogue for what defense now needs to build — autonomous response loops where the human is not in the per-event approval path.

• Objective verifiers vs. environmental verifiers: Sergej's distinction. Offense owns objective verifiers (did the exploit fire?). Defense owns environmental verifiers (does this action match how my environment actually works — naming conventions, identity patterns, expected network flows?).

• Honey tokens: One of the few cleanly binary signals on the defense side — a decoy credential or object that, when touched, conclusively indicates malicious activity.

• Runtime security: Real-time detection and response inside production workloads, as opposed to point-in-time posture management or scanning. Sergej argues runtime telemetry is the ground truth that makes AI-driven defensive action reliable rather than hallucinated.

This week's issue is sponsored by Ent Security

Most security tools are built to detect. They watch, log, and alert after the fact, when the damage is already done. Threats now move faster than humans can respond. Security has to move closer to where work actually happens.

Ent is an AI-native endpoint security platform built around one idea: understanding intent. Ent runs at the edge, sees what users see and do, and intervenes before damage is done. Adaptive by design, it continuously learns what normal looks like for every person and workflow in your organization, without data leaving your environment. Ent brings prevention at the speed of work.

See how it works: schedule a 1:1 conversation.

💡Our Insights from this Practitioner 🔍

1. The Cybersecurity Verification Law — Where Offense Got Its Superpower

Sergej's opening move in the conversation reframes the AI security debate. The interesting question isn't who has the better model. It's where each side gets a clean signal that the model worked. "In every domain where you can measure something and verification is easy... AI is becoming very good. So all the benchmarks we've created so far across all the domains, AI was able just to reach 90, 95% of successes." — Sergej Epp

Apply that principle to security and the picture inverts. "It turns out offense is dominating. If you pop a shell, if you exploit, you get a very easy binary feedback. You get this feedback loop during the training, but also during the inference when AI agents are working — that yes, this happened really, now you've got this. Capture the flag, you've got this token, you've got the flag, the exploit worked. And so offense has this very cheap verifiers." — Sergej Epp

Defense doesn't have that. The signals are probabilistic, the alerts are noisy, the confidence scores are themselves model outputs. Sergej's blunt summary:"In defense, we don't really have this deterministic, binary verifiers. And therefore that explains a lot we're seeing right now — that offense is pretty much getting the superpower and accelerating much more compared to defense." — Sergej Epp

What to do with this: This is the lens that makes the rest of the conversation coherent. If your defensive program is being asked to "use AI" without first asking where your verifiers are, the AI investment compounds into the same noise floor you already had — just faster. The architectural work is making defense more like chess: identifying the places where you can produce binary signal, and building scaffolding everywhere you can't.

2. The Zero Day Clock — From 18 Months to 8 Hours

The Verification Law sounds abstract until Sergej puts a number on it. Sysdig publishes a running measurement called the Zero Day Clock that tracks the time from CVE disclosure to active exploitation. "It was more than one and a half years... And now we are like under a day. Under, under 24 hours. I think it's just varying between eight hours and one to three days... You can expect this is going to drop to minutes or hours." — Sergej Epp

The mechanism is mundane and powerful at the same time. "Effectively when a vendor ships a patch, it ships the blueprint of the vulnerability. And the AI is really good right now in reconstructing this blueprint and building the exploit out of this blueprint. So right now, as a bad nation state, you can just deploy a lab and then collect all these different patches and instantly create exploits." — Sergej Epp

The patch is the disclosure. The diff is the spec. AI-assisted analysis turns N-day vulnerabilities into working exploits inside the time most enterprises take to schedule a change advisory board meeting. That maps directly onto Verizon's DBIR finding this week: only 26% of critical vulnerabilities were fully remediated by organizations in 2025, compared to 38% the previous year. The defenders aren't getting worse. The window is.

Cloud security takeaway: If your patch SLA is 30/60/90 and your change-management window is two weeks, you're now permanently out of band with the threat.

3. The 8-Minute AWS Compromise — Why Speed of Attack Forces Speed of Defense

The Verification Law explains the trajectory. Sergej then drops the operational example that grounds it. "We just saw recently — we detected one AWS environment being compromised. The attacker moved from zero — he just got some stolen credentials — to full admin in eight minutes." — Sergej Epp

The attacker was using AI, and Sergej's team could tell because of the artifacts the AI left behind: "He was assuming roles which were called 'Claude'. Whenever the AI was stuck — for instance trying to spin up some GPU to mine cryptocurrency — when it was stuck, it was just trying to call an Anthropic GitHub repo which didn't exist." — Sergej Epp

Eight minutes from stolen credential to full admin. Sergej's framing of what this requires: "How is a SOC analyst supposed to cope with an attack which is taking under 10 minutes? We have to take the human out of the loop." — Sergej Epp

The link back to story #3 in the news brief: the DBIR doesn't just say patching is slow. It says the speed-of-defense ceiling is hitting a wall that human triage and approval cycles can't break through.

4. What Defenders Actually Have — Honey Tokens and the First-Principle Advantage

If the Verification Law makes defense sound hopeless, Sergej's deeper point is that it isn't — defense just has different verifiers than offense, and most programs aren't using them.

The cleanest binary signal on the defense side: "Honey tokens. If you look at any EDR, XDR solution — all of them are throwing around honey tokens to detect ransomware. Because it's the only unique binary signal that something is happening. Somebody's eliminating these honey tokens. Same in the cloud." — Sergej Epp

The first-principle advantage: "The attackers do not understand the environment. So every time they're just going to go in and reach the objective... they're going to start to perform steps from scratch based on the training data. So they will try to assume certain roles with certain usernames, based on trying to hallucinate down something. And that's going to create a lot of noise. You can hear this noise — you can start build your detection around that." — Sergej Epp

The 8-minute AWS incident is the proof point. The attacker's AI hallucinated Claude-named roles and reached for a non-existent Anthropic GitHub repo because it had no idea what the actual environment looked like. That noise is detectable — but only if the defender has done the work of mapping their environment first. "If you can explain how your environment is looking like — for instance, what kind of naming conventions you're using for your clusters, what kind of naming conventions you're using for your identities — starting to understand that, equipping your team with this understanding, building detection rules on top of that, is quite powerful. And that's by the way, something also vendors will not be able to help with. Because that's your unique experience, insights you have as a company." — Sergej Epp

Cloud security takeaway: Build the environment graph and the naming-convention catalog as a first-class artifact, not an afterthought. The detection signal that catches a TeamPCP-style intrusion is unlikely to be a CVE signature — it's a service account assuming a role with a name that doesn't exist in your taxonomy.

5. Runtime Security as the Ground Truth

If detection has to happen inside the attack window, the data layer that supports it has to be real-time and high-fidelity. "If a hack is happening within eight minutes, your inventory posture management is not going to help. Whatever's just misconfigured, you'll not be able to go back, send this, open up a ticket in Jira and have the engineer just work on that." — Sergej Epp

Why runtime, not posture: "To have this ground truth — what's going on. Because if you just have parts of it — five or six events suggesting, oh, something happened in this Kubernetes container — but I don't really know what processes were running, I don't really know if container escapes were performed. If I don't have a lot of this telemetry, I'm not going to be confident to say 'I'm going to kill this container.'" — Sergej Epp

The architectural prescription: runtime telemetry produces ground truth, deterministic rules produce binary signal, and only then does AI come in to reason across the noise. This inverts how most "AI for SOC" pitches are structured — and it lines up with where the news brief landed: Mini Shai-Hulud, the actions-cool tag hijack, and the GitHub VS Code extension breach all depended on activity inside developer or CI/CD workloads that posture scanning can't see in real time.

6. AI Agent Risk — Simon Willison's Three Categories

When the conversation pivots to securing AI agents inside the enterprise, Sergej grounds it in a mental model from security researcher Simon Willison. Agents do three things; the safe configuration takes at least one off the table. "What kind of access to data is the AI agent having? Can the AI agent execute commands? Does the AI agent have access to the internet? Simon Willison posted about this recently — you have to take at least one of these out. Otherwise it's going to be a huge blast radius and could lead to a nightmare scenario." — Sergej Epp

Sergej is realistic about how hard this is in cloud: "Even if you take one of those aspects out, you can't really take out the network capability in the cloud. Let's say you're going to say it cannot run commands — I'm even not sure that's possible, because even if you analyze a PDF or whatever, the AI is going to write a script and then the script is going to do something." — Sergej Epp

His operational fallback is the same as for any other privileged workload: runtime visibility into every LLM and coding agent in production.

Cloud security takeaway: Apply Willison's three-category test to every AI agent deployment before production. If your coding agent has data access, execution rights, and network egress, document why and what control compensates.

7. Two Team Archetypes — Architects of Security and Validators of Security

The conversation moves to organizational design. Sergej's argument is that the discipline-based team structure (cloud security, AppSec, IR, etc.) doesn't survive AI-speed operations. What replaces it is a two-archetype split. "We're going to see two types of roles going forward. The ones where you have all the security engineering, forensics coming together — the architects of security. And the validators of security: people who are building a validation architecture. Trying to understand: now I've got these controls — what kind of ground rules, what kind of data are those controls collecting? Is this EDR really in the position to explain this type of attack and reconstruct it back? Are these rules really validated?" — Sergej Epp

The third leg is the operating assumption: "You have simply to assume breach. That's the reality we are living in. And based on that, you build up your runtime, real-time controls — where you take the human out of the loop." — Sergej Epp

Cloud security takeaway: If your current org chart has a discipline-based shape (one team per technology), start thinking about how to overlay an architect/validator split on top of it. The validator role specifically — the team whose job is to continuously verify that your detections and controls actually fire on the attacks you claim they cover — is the one most programs don't have today.

8. The Sysdig Hackathon — Why Culture Beats Mandate for AI Adoption

The most practical part of the conversation is also the most underrated. Sergej described running an internal hackathon to let his security team build with AI rather than mandating tool adoption from the top. "A lot of companies are trying to mandate from the top — you have to use AI, this is the tool you have to use. I think the first thing AI is going to disrupt is the entire management layer. Because the experts understand the pain points, they understand the problem. So let them try out how the AI is working, let them try to fix these problems." — Sergej Epp

The output surprised him: "I had a lot of IT people who didn't have an understanding of security, and a threat researcher who never wrote a line of code. And she was able then to come up with a framework to check if any APIs of Azure had drift, and how to adopt automatically the rules on top of that." — Sergej Epp

Cloud security takeaway: A half-day cross-functional hackathon — explicitly framed as exploration, not delivery — surfaces use cases your org chart doesn't predict.

🧠 Mental Model — Offense Owns Objective Verifiers. Defense Owns Environmental Verifiers.

Offense knows when the exploit worked. Defense doesn't natively know when the detection was right.

The program that wins in 2026 is the one that asks, for every control in its stack, "what's the binary signal that this fired correctly?" — and replaces the controls where the answer is "we don't really know."

Honey tokens give you that signal. Environment graphs give you that signal. Naming-convention catalogs give you that signal. CSPM dashboards mostly don't.

📚 RELATED RESOURCES 🎧

• Zero Day Clock — Sergej's running dashboard tracking the gap between CVE disclosure and active exploitation

• Sysdig Strategic Research — Cloud threats and runtime security publications

• Verizon 2026 DBIR — Full report and industry-specific breakdowns

• CISA Known Exploited Vulnerabilities Catalog — Authoritative list of what's being exploited

• Simon Willison's writing on AI agent risk — The three-category mental model Sergej references

• OWASP LLM Top 10 — For teams building the AI agent governance layer

Podcast Episode

• [Full Episode with Sergej Epp (Sysdig)] — Complete transcript and audio for this week's featured conversation

Question for you? (Reply to this email)

🤔 If you mapped your defensive controls against Sergej's Verification Law tomorrow, which ones produce binary signal — and which are just probabilistic noise dressed up as detection?

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

This week’s Cloud Security Newsletter topic: Guardrails Are Dead — What Replaces Them in the Agentic 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

The week of May 8–13 produced two stories that sit at exactly the same intersection: AI is now both the attacker's tool and the attack surface. Google Threat Intelligence Group disrupted the first documented case of a criminal actor using an AI-generated zero-day exploit. Microsoft published research showing how prompt injection in its own Semantic Kernel framework escalates to host-level remote code execution in two separate code paths. And TeamPCP's Mini Shai-Hulud worm, which the same Google report attributed to UNC6780, compromised 172 packages across 403 versions, including the first malicious npm package ever to carry valid SLSA provenance.

This week's conversation is with David Haber, VP AI Security at Check Point and founder of Lakera (the team behind Gandalf, the AI red-team game that has logged over 100 million human-AI interactions), and Paul Barbosa, VP of Cloud and SASE at Check Point, hosted by Ashish Rajan. The framing is sharp: David's position, "I believe guardrails are dead," is the editorial spine of this week's news as much as it is of the episode. [Listen to the episode]

⚡ TL;DR for Busy Readers

- Mini Shai-Hulud (CVE-2026-45321) compromised 172 npm/PyPI packages including TanStack, Mistral AI, UiPath, and OpenSearch. First malicious npm package with valid SLSA provenance. Rotate every secret that touched affected pipelines May 10–12.

- Google disrupted the first AI-generated zero-day: a Python 2FA bypass authored by an LLM and identified before mass exploitation. Assume exploit dev is now faster than your patch cycle.

- Microsoft Semantic Kernel CVEs (CVE-2026-26030, CVE-2026-25592) turn prompt injection into host RCE. If your agent calls tools, prompt injection is now a code-execution problem with blast radius equal to the agent's IAM.

- PAN-OS CVE-2026-0300 (CVSS 9.3) actively exploited by a likely state-sponsored cluster. Restrict Captive Portal to internal zones now; patches start May 13.

- David Haber's central argument: Stop layering perimeter guardrails. Move to contextual intelligence: evaluating agent intent, system instructions, and behavioral traces against what the agent is currently doing.

📰 THIS WEEK'S TOP SECURITY HEADLINES

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

1. Google Disrupts the First Documented AI-Generated Zero-Day

Primary source: Google Cloud Threat Intelligence 
Reporting:  Bloomberg

What happened: On May 11, Google Threat Intelligence Group disclosed the first known case of a criminal threat actor using an AI-generated zero-day exploit: a Python script that bypassed two-factor authentication on a popular open-source, web-based system administration tool. GTIG identified the exploit before mass exploitation and attributes AI authorship with high confidence based on hallucinated CVSS scores, abundant educational docstrings, and textbook Pythonic formatting. Gemini was not the LLM used. The same report documents North Korea-linked APT45 running thousands of recursive prompts to validate PoC exploits at scale, China-linked UNC2814 using persona jailbreaks ("act as a senior security auditor") to research TP-Link firmware flaws, and a Chinese actor deploying agentic offensive tools Strix and Hexstrike against East Asian targets.

Why it matters: This is the operational confirmation defenders have been forecasting for two years. AI-assisted vulnerability discovery has moved from theory to a working capability in the wild. For cloud security teams, the implication is concrete: if a single LLM-augmented researcher can produce weaponizable exploits faster than your patch cycle can absorb them, patch SLAs alone are no longer a viable program. Weight has to shift toward compensating controls: behavioral detection, least-privilege scoping for service accounts and non-human identities, and rapid containment playbooks that work without a patch in hand. The 72-minute breakout-time benchmark Unit 42 cited earlier this year now looks like the floor, not the ceiling.

2. Mini Shai-Hulud Worm: 172 Packages Compromised, Including the First Malicious Package with Valid SLSA Provenance 🚨

Primary source:  Wiz · Snyk 
Advisory: NHS England Cyber Alert 
Analysis: The Hacker News

What happened: Between 19:20 and 19:26 UTC on May 11, TeamPCP (tracked as UNC6780 in Google's report this week) published 84 malicious versions across 42 @tanstack/* npm packages in under six minutes, then propagated to Mistral AI, UiPath, OpenSearch, Guardrails AI, and PyPI within hours. By May 12 the campaign had hit 172 unique packages across 403 malicious versions with cumulative downloads exceeding 518 million. TanStack's compromise was assigned CVE-2026-45321 (CVSS 9.6). The attack chain hijacked GitHub Actions via a pull_request_target trigger, used cache poisoning, and extracted OIDC tokens from /proc memory on the runner. npm tokens were never stolen; the publish pipeline itself was compromised. Payloads exfiltrate AWS IAM keys, GitHub PATs, HashiCorp Vault tokens, Kubernetes secrets, and 1Password/Bitwarden vaults, and inject persistence hooks into Claude Code (.claude/settings.json) and VS Code (tasks.json with runOn: folderOpen).

Why it matters: This is the most consequential supply chain attack of 2026 to date, and it breaks an assumption cloud security programs were starting to rely on: SLSA provenance attestation no longer guarantees a package wasn't tampered with. Any CI/CD environment that mints OIDC tokens (i.e., most modern GitHub Actions pipelines) is in scope. The persistence vector into AI coding agents is novel and underappreciated: a single .claude/settings.json injection turns a developer's daily AI assistant into a sustained execution channel. This is also the precise scenario David Haber describes in this week's episode: agents with tool access, untrusted inputs, and the autonomy to act.

3. Microsoft Research: Semantic Kernel Prompt Injection Becomes Host-Level RCE

Primary source: Microsoft Security Blog — Semantic Kernel research disclosure Advisory: CVE-2026-26030 (Python semantic-kernel < 1.39.4) · CVE-2026-25592 (.NET SessionsPythonPlugin) Analysis: Vibe Graveyard · Windows Forum

What happened: On May 7, Microsoft disclosed and patched two CVEs in its Semantic Kernel AI agent framework. CVE-2026-26030 (critical, Python semantic-kernel < 1.39.4) is in the In-Memory Vector Store / Search Plugin path: a single crafted prompt launches calc.exe on the agent's host machine when the agent uses the default filter functionality. CVE-2026-25592 is in the .NET SDK's SessionsPythonPlugin, which is meant to isolate Python execution inside Azure Container Apps dynamic sessions but exposed a sandbox-to-host file-transfer helper as a kernel function. Once the LLM could invoke it as a tool, the local file path became attacker-controlled, enabling arbitrary host file writes from inside what was supposed to be an isolated sandbox. Microsoft framed the research as a class problem, not a one-off.

Why it matters: This is the cleanest existing demonstration that AI agent security cannot be reduced to prompt safety. When an agent can call functions, query stores, run scripts, or touch cloud APIs, prompt injection is an application-security and identity problem with blast radius proportional to the agent's privileges. The story lands the same week David Haber argues, for unrelated reasons, that guardrail-style perimeter defenses are no longer sufficient against exactly this class of attack. The Microsoft research is the proof.

4. PAN-OS Captive Portal Zero-Day Actively Exploited — Likely State-Sponsored 🚨

Advisory: Palo Alto Networks Advisory
Analysis: Unit 42 Threat Brief  · Wiz 
Reporting: The Hacker News

What happened: Palo Alto Networks disclosed CVE-2026-0300 (CVSS 9.3) on May 6, with patches starting May 13. The flaw is an unauthenticated buffer overflow in the PAN-OS User-ID Authentication Portal (Captive Portal) on PA-Series and VM-Series firewalls, enabling RCE with root privileges via crafted packets. Prisma Access, Cloud NGFW, and Panorama are unaffected. CISA added it to KEV on May 6 with a May 9 federal patching deadline. Unit 42 attributes limited observed exploitation to CL-STA-1132, a likely state-sponsored cluster that achieved RCE on April 16 after a week of unsuccessful attempts beginning April 9, injected shellcode into an nginx worker, deployed EarthWorm and ReverseSocks5 tunneling tools, and conducted Active Directory enumeration using the firewall's service account credentials.

Why it matters: A second story this week reinforcing the same theme as #1 and #2: internet-exposed security infrastructure is a primary target, not a hardened boundary. The post-exploitation pattern (pivot from the firewall's service account into AD enumeration) is textbook state-sponsored playbook and reinforces why firewall service accounts deserve tier-zero-equivalent treatment in your identity model. Approximately 225,000 internet-facing PAN-OS instances exist globally per Shodan, though only a subset run Captive Portal on ports 6081/6082.

5. Instructure Pays Ransom to ShinyHunters After Double Canvas Breach Hits 275M Users

Primary source: Inside Higher Ed · The Register
Reporting:  The Hacker News 

What happened: Instructure, parent of the Canvas LMS used by ~41% of North American higher-ed institutions, confirmed on May 11 it reached an agreement with ShinyHunters after a two-stage breach. The initial intrusion on April 29 (disclosed May 1) exploited a flaw in the Canvas Free-for-Teacher account program to exfiltrate 3.65 TB of data: ~275 million records across 8,809 institutions including Harvard, Princeton, Columbia, Stanford, Penn, and Georgetown. After Instructure declined to negotiate and attempted to patch, ShinyHunters returned on May 7, defaced ~330 Canvas login portals worldwide, and took the platform offline during US finals week. Instructure subsequently stated it received "digital confirmation of data destruction (shred logs)," a strong implication of a ransom payment the company has not explicitly confirmed. The Free-for-Teacher program has been permanently shut down.

Why it matters: This is the largest education-sector breach on record and a textbook SaaS concentration-risk case. A single under-governed product feature gave the adversary a path into the production multitenant Canvas environment. ShinyHunters' 2026 playbook (third-party integrator compromise to reach downstream customers at scale) builds on its 2024 Snowflake-customer campaign and 2025 Salesforce campaign. The broader question for enterprise CISOs: many organizations now depend on a small number of critical SaaS platforms but lack mature playbooks for tenant compromise, platform-wide outage, or third-party-driven data exposure. The gaps this incident exposes for ed-tech are equally true for HR, CRM, identity, and collaboration SaaS.

🎯 Cloud Security Topic of the Week:

Guardrails Are Dead - What Replaces Them in the Agentic Era

The thread running through every story above is the same: attackers no longer need to break the perimeter when they can manipulate the systems that operate inside it. The Google-disrupted AI zero-day worked because LLMs collapse the cost of producing weaponizable exploits. The Mini Shai-Hulud worm worked because trusted CI/CD primitives (OIDC tokens, SLSA attestations, GitHub Actions triggers) could be weaponized inside a pipeline that defenders had explicitly designed as trusted. The Semantic Kernel CVEs work because an agent's tool-calling layer is, by design, a privileged execution channel that text from anywhere can reach.

David Haber and Paul Barbosa's argument is that the security industry's response to this class of problem, layering more guardrails, more perimeter checks, more "don't do that" rules at the prompt level, is structurally finished. What replaces it is something Haber calls contextual intelligence: evaluating intent, system instructions, behavioral traces, and tool calls in real time against what the agent is actually supposed to be doing. It is a harder problem and a different operating model.

Featured Experts This Week 🎤

• David Haber — VP AI Security, Check Point | Founder & former CEO, Lakera (creators of Gandalf)

• Paul Barbosa — VP, Cloud and SASE, Check Point

• 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:

• Direct prompt injection: User input crafted to override an LLM's system instructions. The original form ("ignore your previous instructions and do as I say") exploits the fact that LLMs do not architecturally distinguish between system instructions, retrieved data, and user input. It is all text and tokens.

• Indirect prompt injection: Malicious instructions delivered to an agent via the data and tools it consumes: a shared document, an email, an MCP-connected drive, an output from another agent. The victim does not interact with the malicious content; the agent does. As David Haber puts it, indirect prompt injections are often invisible, both hard to spot in real time and undetectable after the fact.

• Gandalf: Lakera's open-source AI red-teaming game launched ~2.5 years ago. Has reached tens of millions of people and logged over 100 million human-AI interactions, one of the largest datasets of how people actually try to exploit LLMs.

• Contextual intelligence (as a defense pattern): The replacement Haber proposes for perimeter guardrails. Evaluates the agent's design, system instructions, behavioral traces, and current actions in real time to reason about whether the agent is being manipulated. Requires substantially more telemetry than guardrail-based defenses.

• Non-human identity (NHI): Service accounts, API keys, OAuth tokens, and AI-agent identities. The credentials that AI agents and automation use to act inside cloud and SaaS environments.

• Language as the new executable: Paul Barbosa's framing that the domain of exploitation has shifted from code (requiring CS expertise and tool fluency) to natural language (bounded only by human creativity).

This week's issue is sponsored by Beyond Identity

AI Agents Are Running With Keys Your Security Stack Can't See

The pressure to ship AI agents is real: do more with less, automate everything, yesterday. But every agent you deploy carries API keys, accesses sensitive systems, and executes actions your security tools were never designed to see. Legacy architectures leave you choosing between AI velocity and actual governance. Ceros eliminates that tradeoff. It controls the agent launch point with hardware-bound identity and continuous authorization, giving you full visibility into every tool call, MCP connection, and data flow.

Try Ceros for Free

💡Our Insights from this Practitioner 🔍

1. The Threat Model Shift: Language Is the New Executable

The opening frame of the conversation is one cloud security leaders should sit with. Paul Barbosa describes the moment he understood why prompt injection is qualitatively different from prior classes of vulnerability:

"The domain of exploit was very code driven. You had to know what you were doing. But with prompt injection, it's language. And we're only bound by like the limits of human creativity, which we know is boundless." — Paul Barbosa

The implication is that the population of people who can produce a working exploit has expanded by orders of magnitude. Haber confirms this empirically from Gandalf's 100M+ interaction dataset:

"The most beautiful example we see — 12-year-old kids that are very successful playing the game. And we see some of the most advanced hackers that are also very successful at playing the game." — David Haber

That observation is the editorial bridge to this week's Google Threat Intelligence report. AI-assisted vulnerability research is not theoretical for state actors. APT45's recursive PoC validation runs and the criminal actor who produced the disrupted 2FA bypass are both empirical confirmations of what Haber has been seeing from the offensive side for two years.

What to do with this: Audit which assumptions in your threat model still depend on "attacker scarcity," the idea that sophisticated attacks require sophisticated attackers. The assumption no longer holds. Programs that rely on it (vulnerability triage that deprioritizes anything not on KEV, MFA selection that treats SMS as adequate, AppSec coverage that assumes attackers won't fuzz a particular surface) need an explicit refresh.

2. Indirect Prompt Injection Is the Attack That Matters

Haber draws a sharp distinction between direct and indirect prompt injection that maps directly onto how security teams should weight their concern:

"I can exfiltrate your entire corporate inbox in about three seconds while you are on vacation, sipping a mojito. You will not even notice that I did that through an indirect prompt injection. You will have no idea. The indirect ones are often invisible. They're not only hard to spot — but also after the fact, you wouldn't even know." — David Haber

The Check Point team demonstrated this with a now-canonical example: a Google Doc containing a malicious prompt, shared with a user who never opens it. The user's AI agent, connected to their Drive, reads the document, follows the injected instructions, and exfiltrates data. The victim is not in the interaction loop at any point.

This is the exact attack class Microsoft's Semantic Kernel research validates this week. The agent has tools. The tools have privileges. Any text the agent processes (including text it was asked to summarize, retrieve, or analyze) can become an instruction. The blast radius is determined entirely by what the agent is permitted to do.

What to do with this: Inventory every AI agent in your environment by what data it reads and what tools it can call. Any agent that ingests untrusted content (email, shared documents, web pages, MCP-connected drives, tickets) and also has write or execute privileges is a candidate for indirect prompt injection. Reduce one side of the equation or the other; most agents are over-permissioned on tools relative to what they actually need.

3. Guardrails Are Dead, and Why That Matters Now

This is the central thesis of the conversation, and Haber is unambiguous:

"Last year, the hot talk in town was guardrails. I believe guardrails are dead. With the autonomy and the complexity that agentic AI brings, we need to go away from what are essentially perimeter checks. Putting one guardrail after another — 'don't talk about weapons, no hate speech, don't bash the competitor, prompt injection defense' — we've been layering on these guardrails on top of AI. That's over. It doesn't scale. What we need to do now is we need to move from perimeter checks to contextual intelligence." — David Haber

Contextual intelligence, in Haber's framing, evaluates the agent's design intent, system instructions, traces from past behavior, and user analytics in real time against the action the agent is currently taking. It is reasoning about whether the agent is being manipulated, not a static rule about what it can and cannot say.

The structural critique applies just as cleanly to traditional cloud security tooling. Barbosa surfaces the WAF analogue:

"How do you detect the prompt injection through a WAF? It's impossible. So if that's the access modality — that's one of the first places that we chose to make the integration with Lakera and the runtime security — to augment the WAF. Otherwise it's a request and there's no existing method to try to detect it." — Paul Barbosa

The point is not that WAFs are obsolete. It is that the layer in your stack designed to inspect text-shaped requests has no native concept of "is this text trying to manipulate a downstream model?" Adding that capability is an architectural change, not a rule update.

What to do with this: If your current AI security strategy is a list of prompt filters or content guardrails bolted to model APIs, treat that as a starting baseline and not the end state. The investments that actually scale are agent-level behavioral instrumentation, tool-call auditing, and runtime evaluation of agent actions against declared intent. These are heavier engineering lifts than guardrails, and they need to start now.

4. Identity for Agents Is Not a Solved Problem

When asked whether non-human identity controls can carry the weight that guardrails no longer can, Haber's answer is direct. His position, paraphrased from the transcript (where one word appears garbled and is preserved as such below):

"I don't think the identity prompt [transcript reads "prompt"; almost certainly "problem"] for agents has been solved. At all... There are certain important questions around how we want to treat agents... One of the big areas people are looking into is self-replicating agents. So you've got teams that are replicating themselves to maybe do other tasks. How do identities evolve with that? I don't think that's clear at all. Many claim they've solved it. I've not seen anything that convinces me that we have a good handle on that." — David Haber [VERIFY exact word — possible transcription error]

Barbosa reinforces the point. Least privilege for NHIs is necessary but not sufficient, because the space is moving too fast for any static control to be a stopping point:

"It's never gonna be enough. The space is evolving too fast for any static control to say, okay, I understand I have non-human identity and I'm gonna apply least privilege. That's just table stakes." — Paul Barbosa

This connects directly to the Mini Shai-Hulud worm and the Semantic Kernel CVEs. The worm exfiltrates exactly the credentials agents and automation use (AWS IAM keys, GitHub PATs, Vault tokens) and uses them to expand. The Semantic Kernel research shows that the agent's own service identity is the blast radius. Least privilege bounds the damage; it does not prevent the path.

What to do with this: Treat NHI governance as a year-long program, not a project. The minimum tactical baseline: every AI agent in production has its own service identity (not a shared one), the identity is scoped to the specific tools and data the agent needs, and there is logging that tells you when the identity is used outside its expected pattern. Beyond that, plan for the harder problems Haber names: identity for self-replicating agents, identity that travels across environments, distinguishing "Ashish acting via an agent" from "an agent acting on Ashish's behalf."

5. The Same Action, Catastrophic by Context

Barbosa's framing of why context-aware defense matters is the cleanest articulation of the agentic security problem:

"The same action that an agent could take could be okay — or it could be catastrophic, just depending on the conditions. The constraint on AI is never gonna be security, unfortunately. The constraint is gonna be productivity — and productivity by its very nature is always to be more helpful, is gonna ask for more and more access, more and more authorization. And I think as humans we're gonna gladly grant that. That same action taken by an attacker could be catastrophic." — Paul Barbosa

This is the exact dynamic in the Semantic Kernel SessionsPython case: a file-transfer helper is benign in the workflow it was written for, and an arbitrary host write primitive in the hands of an injected prompt. The function did not change. The context did.

What to do with this: When evaluating agent deployments, the question is not "does this tool seem dangerous?" but "what is the worst action this tool enables if the agent is being manipulated by content it just ingested?" Most production agents have not been audited against that question. Start with the agents that touch customer data or cloud control planes.

6. AppSec, Network, Data — It's All One Problem Now

The conversation closes on an organizational point that maps directly onto how this week's news has to be triaged. Ashish presses on whether AI security is an AppSec problem or a data security problem. Haber's answer:

"Now it's everything." — David Haber

Barbosa expands on what that means operationally:

"It used to be like they own the tool — they're the network security team, they got the firewall, we'll get a ServiceNow ticket, it'll go to them. Now I think everyone more than ever, it's everyone's problem. If I'm a CISO, I'm going to every domain that I have a tool set and saying — how are you solving for this? Because it can render itself through your control, your tool set, or the applications that you're protecting." — Paul Barbosa

The Mini Shai-Hulud worm illustrates the point. The story is simultaneously a CI/CD problem (poisoned GitHub Actions), an identity problem (OIDC token theft), a secrets problem (Vault and IAM exfiltration), an endpoint problem (persistence into Claude Code and VS Code config), and a SaaS problem (npm and PyPI as the distribution channel). No single domain owner can fully respond to it.

What to do with this: This week is a forcing function to ask, across every security domain in your organization, the same question Barbosa describes: "how are you solving for this?" If the answer is "we're not, that's another team," find the gap and own it.

7. The Defense Window Is Open, But It Is Closing

Haber's closing observation is the one worth carrying into next week's planning:

"We are actually at a very unique time, I believe right now, where we still have a chance for defense to catch up. I see both offensive security and defense on an exponential curve. But I think the question is — what's the exponent? How fast are we actually moving?" — David Haber

The Google-disrupted exploit was caught because GTIG was looking; the next one may not be. Mini Shai-Hulud broke an attestation primitive (SLSA) that defenders were starting to trust. Microsoft framed the Semantic Kernel research as a class problem, not a one-off.

What to do with this: Pick one of the harder problems — agent behavioral monitoring, NHI lifecycle management, CI/CD supply chain attestation that survives runner compromise — and make actual progress on it this quarter.

🧠 Mental Model — Language Is the New Executable

If language is executable, then every place an agent reads untrusted data is a place an attacker can run code.

Guardrails were the AV scanner of the LLM era: pattern-matching on a target that mutates faster than the patterns. The successor is not a better filter. It is runtime context — what was this agent told to do, what is it doing now, and does the second match the first?

Cloud security teams that build that telemetry layer in 2026 will be the ones positioned to defend in 2027. Teams that keep adding guardrails will be running an antivirus strategy against an autonomous adversary.

📚 RELATED RESOURCES 🎧

• Check Point AI Security research — AI security threat research and Lakera-related publications

• Gandalf by Lakera — gandalf.lakera.ai — AI red-team game, educational tool for prompt injection patterns

• CISA Known Exploited Vulnerabilities Catalog

• Google Cloud Threat Intelligence — AI Threat Tracker (May 2026)

• Microsoft Security Blog — Semantic Kernel research disclosure

• Unit 42 — PAN-OS CVE-2026-0300 Threat Brief

• Wiz / Snyk — Mini Shai-Hulud analyses

Podcast Episode

• Full Episode with David Haber and Paul Barbosa (Check Point) — Complete transcript and audio for this week's featured conversation

Question for you? (Reply to this email)

🤔 If guardrails are dead, what is the first thing you take out of your AI security stack — and what do you put in its place?

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: Why CVSS Alone Won't Survive 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

If the past week had a thesis, it's this: the gap between vulnerability disclosed and vulnerability weaponized is no longer measured in months. It's measured in days, sometimes hours, and the underlying cause isn't a single tool or actor — it's the AI-assisted offensive workflow that's now table stakes for advanced adversaries.

The news brief reflects it everywhere. Palo Alto Networks disclosed CVE-2026-0300 with state-sponsored exploitation already underway. Microsoft documented a three-day AiTM campaign that quietly stole post-MFA tokens from 13,000 organizations. Cyera's Bleeding Llama disclosure showed how default-permissive AI infrastructure is leaking the most sensitive secrets in the building. And Cisco put $400 million on the table to lock down non-human identities — the credential layer AI agents now use to act inside enterprises.

Against that backdrop, this week's conversation is with Brad Hibbert, COO and Chief Strategy Officer at Brinqa, hosted by Ashish Rajan of Cloud Security Podcast. The discussion is about Claude Mythos — Anthropic's frontier model now being tested in private programs against vulnerability discovery — and what it means for every existing vulnerability management program. Brad's framing is sharp: "Heartbleed was a storm. Mythos is climate change." [Listen to the episode]

⚡ TL;DR for Busy Readers

This week’s attacks didn’t break systems — they used them


🔥 PAN-OS CVE-2026-0300 is being actively exploited by a likely state-sponsored cluster — restrict Captive Portal to internal IPs now; patches start May 13.

🪪 Microsoft AiTM campaign stole post-MFA tokens from 35K users — non-phishing-resistant MFA is over; move M365 admins to FIDO2/passkeys this quarter.

🦙 Bleeding Llama (CVE-2026-7482) leaks heap memory from 300K Ollama servers, including API keys and prompts — inventory, upgrade to 0.17.1, rotate exposed secrets.

🤖 Cisco's $400M Astrix acquisition validates non-human identity as a top-tier security category — start your NHI inventory this month.

⏱️ Brad Hibbert's core argument: Stop measuring patch SLAs. Start measuring the exposure window — how long a vulnerability was actually exploitable in your environment..

📰 THIS WEEK'S TOP SECURITY HEADLINES

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

1. PAN-OS zero-day: state actors are already inside

Palo Alto Networks disclosed CVE-2026-0300 on May 6 — unauthenticated RCE on PA-Series and VM-Series firewalls. Unit 42 is tracking active exploitation by CL-STA-1132, a likely state-sponsored cluster. The pattern: RCE → log destruction → AD enumeration via firewall service account credentials.

CISA added it to KEV on May 6. Patches roll out May 13. Until then: restrict the User-ID Authentication Portal to internal IPs only.

The attackers had RCE for days before disclosure. Any defender measuring success by patch SLA had a green dashboard while their AD was being mapped, a textbook example of why "exposure window" matters more than "patch window."

→ Read the Unit 42 brief

2. 35,000 users. MFA didn't help.

Microsoft Defender Research disclosed a 3-day adversary-in-the-middle campaign (April 14-16) that hit 35,000+ users across 13,000 organizations. Healthcare and finance led the target list. The attackers proxied the legitimate Microsoft login flow in real time, capturing post-authentication session tokens — sidestepping passwords and SMS/app-based MFA entirely.

If you're still on non-phishing-resistant MFA for M365 admins, this is your wake-up call. FIDO2 or passkeys this quarter, not next.

→ Read Microsoft's analysis

3. Your AI inference servers are leaking secrets

Cyera's "Bleeding Llama" disclosure (CVE-2026-7482, CVSS 9.1) is the AI infrastructure story most cloud teams aren't tracking. Three unauthenticated API calls leak the entire Ollama process memory — including the API keys, database creds, and cloud secrets sitting in environment variables on your inference hosts.

300,000 servers exposed. Patched silently in 0.17.1, but the patch notes never flagged it as a security update — so most operators never upgraded.

The pattern: AI infrastructure deployed with localhost-tool defaults running as production servers, with the most sensitive credentials in the building sitting in 0.0.0.0-bound process memory.

→ Read Cyera's writeup

4. Cisco bets $400M that non-human identity is the new perimeter

Cisco announced its intent to acquire Israeli identity-security startup Astrix Security for ~$400M on May 4. Astrix discovers and governs non-human identities (NHIs) — API keys, service accounts, OAuth tokens, machine credentials — across their lifecycle. Cisco will fold it into Identity Intelligence, Duo, Secure Access, and Splunk.

This is the first nine-figure security M&A explicitly framed around securing AI agents at the credential layer. Machine identities outnumber humans 10-to-1 in most enterprises, and they're the path of least resistance for AI-agent compromise and supply chain attacks.

Expect rapid consolidation across Okta, CyberArk, SailPoint, Wiz, and Palo Alto. Inventory NHIs now if you haven't.

→ Read SecurityWeek's coverage

🎯 Cloud Security Topic of the Week:

From Patch Windows to Exposure Windows — Why CVSS Alone Won't Survive the AI Era

The shift Brad Hibbert describes is structural, not tactical. For two decades, vulnerability management has run on a clear contract: a vendor publishes a CVSS score, your scanner picks it up, you classify by severity, and you remediate within an SLA — typically 30/60/90 days driven by PCI or another compliance regime. Patch SLA performance became the metric that boards and auditors rallied around.

That contract assumed two things that no longer hold: (1) attackers needed time and skill to weaponize disclosed vulnerabilities, and (2) the volume of meaningful CVEs would scale linearly. AI-assisted vulnerability discovery breaks both assumptions simultaneously. Brad describes the Mythos shift bluntly: "It's a persistent elevation of capability that the threat actors have, which is that they can discover vulnerabilities at machine speeds now."

The implication for cloud security leaders is that the yardstick itself has to change. The new metric is the exposure window how long a given vulnerability was actually exploitable inside your environment, taking into account business context, mitigating controls, network reachability, identity blast radius, and attack-chain composition. Patching faster doesn't get you there; some of the most consequential issues this week (PAN-OS, Bleeding Llama) were exploitable for weeks before patches existed.

That reframing forces a series of architectural and operating-model changes and it's the central thread running through this week's news as well as the conversation below.

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:

• Claude Mythos: Anthropic's frontier model currently in private testing for security and intelligence applications, including AI-assisted vulnerability discovery at scale. Brad describes it as a "climate change" shift versus prior temporal events like Heartbleed and Log4Shell.

• Exposure Window: The duration a vulnerability is actually exploitable in your environment — distinct from the patch window. Driven by reachability, mitigating controls, and identity blast radius, not just CVSS severity.

• CTEM (Continuous Threat Exposure Management): Gartner-defined program model that emphasizes continuous discovery, validation, prioritization, and mobilization. Brad argues the Mythos compression effectively forces every program toward CTEM-style operations on a compressed timeline.

• EPSS (Exploit Prediction Scoring System): Probability score for whether a CVE will be exploited in the wild within 30 days. Useful as a complement to CVSS, but Brad's caveat lands: "if everything is exploited and everything's kind of ranked the same, how do you provide better guidance to your team?"

• Attack Chain Analysis: The practice of evaluating multiple low/medium-severity findings together as a path-to-impact, rather than node-by-node. Mythos demonstrated chained privilege escalation across three medium CVEs to achieve root.

• Non-Human Identity (NHI): Service accounts, API keys, OAuth tokens, machine credentials, and AI-agent identities — typically outnumbering human identities 10-to-1 in modern enterprises.

This week's issue is sponsored by Orca Security

Orca Security is hosting Cloud Security LIVE, a half-day virtual summit on Tuesday, May 12th. Join CISOs, security co-founders, and practitioners for unfiltered insight real stories and strategies from people securing the world's most complex cloud environments.

Sessions include:

• The new standard for resilience: zero-breach to zero-impact

• AI on both sides: securing models and APIs while using AI to defend your cloud

• Mastering 3rd-party and supply chain risk

• Security leadership panel on AI, risk, and driving change

  
  Join for a chance to win* a 64GB Beelink AI PC. *US-based attendees only.

Register Today

💡Our Insights from this Practitioner 🔍

1. Heartbleed was a storm. Mythos is climate change.

Brad opens the conversation with a frame that's worth sitting with. Past high-profile vulnerabilities Heartbleed, Log4Shell were temporal. They caused intense activity, then closed out. The exploit cycle had a beginning, a middle, and an end.

"It's not just a temporal thing — it's a persistent elevation of capability that the threat actors have... your months went down to weeks, and in some cases down to seconds before these things can be exploited." — Brad Hibbert

What this changes for cloud security leaders is the planning horizon of the program itself. A program designed to handle 12 Heartbleed-class events per year fails when the underlying capability shift is permanent. The PAN-OS exploitation pattern this week successful RCE within a week of first attempts, log destruction inside the same operation is the normal tempo now, not the anomaly.

What to do with this: Audit your program's design assumptions. If your SLAs, change-control windows, and remediation handoff cadence were built when "manual vulnerability research at machine scale" was a contradiction in terms, those assumptions need an explicit refresh. Brad's framing for the board: "It's not about closing off your criticals in 30 days to meet PCI compliance. It's about how exploitable, what's that exposure window, and how am I showing that go down?"

2. The threat model isn't dead — but the assumptions inside it are

When Ashish asks whether existing threat models are still valid, Brad's answer is nuanced: the structure holds, but the embedded assumptions don't.

"The assumptions that sophisticated attacks required sophisticated attackers has kind of gone away." — Brad Hibbert

Three specific assumptions Brad calls out:

1. Attacker scarcity. The cost of mounting a sophisticated attack has collapsed. The Mexican government breach earlier this year — where a single actor used Claude to steal 150GB across nine agencies validated this empirically.

2. Time between discovery and remediation. PCI's 30-day window for criticals is an artifact of an era when 30 days was a reasonable gap before exploitation. It isn't anymore.

3. CVSS as primary prioritization. Brad's point: when 40,000 highs become 80,000 highs and EPSS marks most of them as likely-exploited, prioritization based on severity scores degenerates into noise.

Practitioner translation: Run a tabletop exercise this quarter where the trigger is "a new CVE-2026-0300-class vulnerability is disclosed at 9am with public PoC by noon, mass exploitation by midnight." Where does your program fail? That's your investment list.

3. The new yardstick is exploitability and the exposure window

This is the core argument of the conversation, and the through-line back to the news.

"The biggest thing today is the biggest short-term thing that CISOs need to do is they need to focus on exploitability and explainability... what we've been talking about with a lot of companies right now is you have to get down to exploitability." — Brad Hibbert

Exploitability, in Brad's framing, isn't just "is there a public PoC?" It's the intersection of the vulnerability with your environment: reachability, mitigating controls (EDR, segmentation, identity guardrails), business context, and the existence of attack paths that chain it with other findings.

The exposure window is the operational consequence: how long was the vulnerability actually exploitable in your environment, end-to-end, until you reduced or eliminated that exploitability — whether by patching, segmenting, killing reachability, or applying a compensating control. Brad's distinction is critical: you don't always need to patch to close the exposure window. You need to make the path inactive.

That distinction maps directly to several stories this week. Bleeding Llama: the patch existed but wasn't flagged as security; the real fix for most enterprises was putting an auth proxy in front and binding Ollama to localhost. PAN-OS: patches don't ship until May 13 but restricting User-ID portal access to internal IPs collapses the exposure window today.

4. Stop ignoring the lows. Start mapping attack chains.

One of the sharpest moments in the conversation comes when Ashish acknowledges what most security teams have been quietly doing for years:

"90% of the time, a lot of the lows were just simply ignored because like, 'Hey, it's a low.' I don't know how many organizations have done this ever." — Ashish Rajan

Brad's response confirms the gap:

"Three medium vulnerabilities, leveraging privilege escalation, could give them root access to a machine versus one standalone critical CVE... you've got to back up and take a look at it not from a node lens, but from a network path lens and attack chain lens." — Brad Hibbert

This is what AI-assisted attackers do natively. Mythos demonstrated the ability to chain three medium CVEs into a privilege escalation that would not have triggered any individual high/critical SLA. Defenders running CVSS-only prioritization will keep missing these because the analytical lens is wrong; they're evaluating findings node-by-node when the attacker is reasoning over graphs.

Practical implication: This is one of the strongest arguments for the kind of unified exposure data plane Brad describes. You cannot compose attack chains across silos. If your CSPM, EDR, vulnerability scanner, and identity tools all run independent AI-driven prioritization, you get siloed AI decisions which are structurally weaker than what an integrated attacker is doing.

5. Remediation has been the forever-problem because the objective was misaligned

Ashish's question "why have we never solved remediation?" opens the most operationally useful section of the conversation. Brad's answer is that the security and remediation teams have been measured on different things:

"If you have two teams that are measured differently — one team's measured on how quickly they can identify and prioritize, the other team's measured on how quick a patch gets released — they're two different measurements. If you focus on the same outcome as a shared objective, which is to reduce the exploitability window, out of that will follow a bunch of other decisions." — Brad Hibbert

This is the kind of strategic-architectural insight senior cloud security leaders can act on without buying anything new. The fix is the operating model, not tooling: rewrite the shared OKR for security + cloud ops + dev so both sides are measured on reduction of exposure window rather than time-to-patch and time-to-detect respectively.

Brad also flags the friction layer that bottoms most programs out — the manual handoff:

"They wanna know why is A ahead of B? Why is B ahead of C? When you pass that information, if you have a shared objective and a shared understanding for how the security team is prioritizing, and an agreed upon approach... you have less of this 'let me export that to Excel, let me compare that to my scanner.'" — Brad Hibbert

Building shared explainability as to why a finding was prioritized, in language remediation teams trust  is the trust-building work that lets you eventually automate decisions. Without it, every prioritization becomes a negotiation.

6. Trust is a muscle. Automate incrementally, but start.

When Ashish presses on whether AI-suggested remediation can be trusted enough to automate, Brad's answer is staged but firm:

"You can automate things that are simple, that have very minimal impact, that are reversible. That's great. But if it's not reversible and can have an impact, then you start to get a little queasy in your stomach... they have to build up trust as they start to automate these processes through reasoning and through AI. They will start taking that 5% that they automate today, the 6%, the 10%, the 20%." — Brad Hibbert

The pattern he describes is small, reversible, low-blast-radius first, building toward more consequential decisions with explainability and audit trails throughout — matches what mature platform-engineering teams already do for production change management. The application of the same pattern to security remediation is the bridge that's been missing.

Cloud-security takeaway: Pick one cloud-native control where automation is reversible (e.g., revoking an over-privileged IAM role, blocking egress from a workload, rotating a service-account secret) and instrument it end-to-end with audit logging and rollback. That's your wedge for trust-building. Once the muscle exists, extending to less reversible actions becomes a policy conversation, not a technical one.

7. Don't boil the ocean pick one high-stakes asset and prove the model

When asked about quick wins, Brad is pragmatic:

"If you're gonna build on the top of the pyramid, don't try to do everything across the whole asset stack. Focus on a high-profile application that could have significant impact to the business, and maybe focus on your external attack surface first. Pick your poison... work the kinks out, work on that shared responsibility, kind of what the shared measurements are gonna be. Show the model working and then expand from there." — Brad Hibbert

This is the most actionable 30-60 day playbook from the conversation:

1. Pick one high-business-impact application or one critical external attack surface segment.

2. Define a shared exposure-window OKR across security and the relevant remediation team.

3. Instrument the full lifecycle — discovery, enrichment, exploitability assessment, prescriptive remediation guidance, two-way ticketing integration, post-remediation verification.

4. Measure exposure-window reduction, not patch volume.

5. Use the working model as the proof case to expand scope.

8. The convergence problem: siloed AI is going to fail

Brad's closing observation is one cloud security leaders should plan for now:

"I think a lot of security vendors are gonna say, 'We have the solution, it's AI.' But then what you're gonna do is you have these siloed security products making siloed AI decisions. What organizations need is to bring all this information into a global exposure repository so they can understand everything from a global perspective." — Brad Hibbert

The Cisco/Astrix deal in this week's news is, in part, a bet on this convergence pulling NHI, identity intelligence, secure access, and SIEM (via Splunk) into a single context-aware control plane. Expect more consolidation along the same line over the next 18 months. For practitioners building their own roadmap, the design principle is to invest in data integration and unified context before adding more siloed AI features.

📚 RELATED RESOURCES 🎧

• Brinqa — Resources on Mythos and Exposure Management

• CISA Known Exploited Vulnerabilities Catalog

• CISA CI Fortify Initiative — guidance for critical infrastructure operators on isolation and recovery

• Unit 42 PAN-OS Threat Brief (CVE-2026-0300)

• Microsoft Security Blog — AiTM Code-of-Conduct Campaign Analysis

• Cyera Research — Bleeding Llama Disclosure

• Gartner CTEM Framework Overview — for teams building toward continuous threat exposure management

Podcast Episode

• Cloud Security Podcast -Full Episode with Brad Hibbert- Complete transcript and audio for this week's featured conversation

Question for you? (Reply to this email)

🤔  If you measured your program on exposure window reduction instead of patch SLA next quarter, which OKR breaks first — and what does that tell you?

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: What's Missing From Most AI Security Programs (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

Two stories defined this week, and both expose the same gap. On the AI side, the LiteLLM SQL injection (CVE-2026-42208) was exploited in the wild within 36 hours of disclosure, the AI gateway turned out to be a credential vault holding OpenAI, Anthropic, and AWS Bedrock keys in a single PostgreSQL row. On the platform side, Wiz disclosed a GitHub RCE (CVE-2026-3854) reachable via a single git push, with cross-tenant blast radius on shared storage. Different bug classes, same underlying signal: the security perimeter for cloud workloads has moved up the stack into AI gateways, agent identities, and the platforms between developers and production, and most enterprise AI security programs were scoped before any of this was on the map.

To unpack the gap and what to do about it, we sat down with Shawn Hays, Product Marketing Manager for Microsoft Applications and AI Security Solutions at Varonis. Shawn spent six years configuring CMMC environments for defense industrial base customers, three years inside Microsoft on the Purview/Defender/Sentinel go-to-market, and is now driving Varonis's AI security platform, Atlas. His central argument, that we've entered a "multi-AI era" analogous to the multi-cloud explosion of fifteen years ago, and that the market has over-pivoted on AISPM while leaving guardrails, pen-testing, and runtime enforcement underbuilt, is the lens this newsletter uses to read the news. [Listen to the episode]

⚡ TL;DR for Busy Readers

This week’s attacks didn’t break systems — they used them


🔑 AI gateways are Tier-0 secrets stores. LiteLLM's litellm_credentials table holds enterprise cloud provider keys, treat every AI proxy as you would your IAM root, and rotate now if you ran a vulnerable build.  

🧬 "Agent identity" just became a procurement category. Google Cloud Next '26 introduced Agent Identity, Agent Gateway, and Model Armor primitives, IAM roadmaps without scoped non-human identity will fall behind in 2026.  

🏗️ AISPM alone is not an AI security program. Shawn Hays argues the market has over-pivoted on posture and visibility while leaving guardrails, pen-testing, and runtime monitoring underbuilt, close the gap before regulators do.  

🔗 Vendor-environment access is the breach pattern of the quarter. Anthropic Mythos, Citizens/Frost, and the Anthropic contractor incident all share the same root cause, third-party identity hygiene that doesn't match the sensitivity of what those vendors can reach. 

🛠️ Edge persistence outlasts patching. FIRESTARTER on Cisco firewalls and the April 24 KEV additions (SimpleHelp, Samsung MagicINFO, D-Link) prove that "we patched, so we're clean" is no longer a defensible posture for hybrid cloud environments.

📰 THIS WEEK'S TOP SECURITY HEADLINES

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

1. LiteLLM SQL Injection (CVE-2026-42208) Exploited Within 36 Hours: AI Gateway Becomes Cloud-Account-Class Risk

What Happened. A pre-authentication SQL injection in BerriAI's LiteLLM (CVSS 9.3) was indexed in the GitHub Advisory Database on April 24 and saw its first observed exploitation attempt on April 26 at 16:17 UTC, roughly 36 hours later. The flaw concatenates the Authorization Bearer value into a query without parameterization, letting unauthenticated attackers run arbitrary SQL against the PostgreSQL backend. Sysdig observed targeted UNION-based payloads from German-hosted IPs (AS200373) hitting precisely the three highest-value tables: LiteLLM_VerificationToken (virtual API keys + master key), litellm_credentials (stored OpenAI/Anthropic/Bedrock provider credentials), and litellm_config (environment variables). Affected versions: 1.81.16 through 1.83.6. Fixed in 1.83.7-stable.

Why It Matters. LiteLLM has 45,000+ GitHub stars and is widely deployed as the AI gateway in front of multi-provider LLM architectures. A single litellm_credentials row can hold an OpenAI org key with five-figure monthly spend, an Anthropic console key with workspace admin rights, and an AWS Bedrock IAM credential, meaning the blast radius is closer to a cloud account compromise than a typical web SQLi. Three takeaways: (1) inventory every AI gateway, proxy, and middleware tier and treat them as Tier-0 secrets stores, not developer convenience tooling; (2) any internet-facing LiteLLM instance running a vulnerable version during the exposure window should be assumed compromised; rotate every key and audit upstream provider billing; (3) the operator-grade exploitation (Prisma schema awareness, schema-aware column-count enumeration) means GHSA-only critical advisories now warrant KEV-level urgency.

🔎 Sources: Sysdig analysis

2. GitHub RCE via Single Git Push (CVE-2026-3854): Wiz Discloses Cross-Tenant Risk

What Happened. On April 28, GitHub and Wiz coordinated disclosure on CVE-2026-3854, a CVSS 8.7 command injection in GitHub's internal git push pipeline. By chaining three injections through unsanitized push option values, an authenticated user with push access could override the rails environment, redirect the custom hooks directory, and trigger path traversal via repo_pre_receive_hooks to execute arbitrary commands as the git user (with cross-tenant blast radius on shared storage). GitHub.com was patched within two hours of Wiz's report; per CISO Alexis Wales, ~88% of GHES instances were vulnerable at disclosure. The bug was discovered using AI-assisted reverse engineering (IDA MCP).

Why It Matters. Two threads to track. Operationally, any GitHub Enterprise Server instance must be on 3.19.3 or later. Wiz called the exploit "remarkably easy." Architecturally, the lesson is that when multiple services in different languages pass data through a shared internal protocol, the assumptions each service makes about that data become a critical attack surface. It's the same pattern that has haunted ingress-nginx and other shared-data systems. This is also the third notable GitHub incident in a single week (alongside the merge queue regression of April 22–23 and an April 27 search outage), which is putting platform-dependency assumptions under stress for compliance teams.

🔎 Sources: Wiz Research

3. Google Cloud Next '26: Wiz Integration Goes Deep, Agentic Defense Lands

What Happened. Google Cloud Next '26 ran April 22 in Las Vegas with a security agenda that, post-Wiz acquisition, finally looked unified. Headline announcements: three new Google Security Operations agents (Threat Hunting, Detection Engineering, Third-Party Context); Wiz Defend detections natively forwarded to Google SecOps and Mandiant Threat Defense; expanded Wiz coverage to Databricks, AWS AgentCore, Azure Copilot Studio, Salesforce Agentforce, Cloudflare AI Security for Apps, and Vercel; agent-governance primitives (Agent Identity, Agent Gateway, Model Armor integration); reCAPTCHA reborn as Google Cloud Fraud Defense; and KMS Quantum Safe Key Imports in preview. Google's M-Trends 2026 data claims initial-access-to-handoff time has collapsed from 8 hours three years ago to 22 seconds today.

Why It Matters. Two structural takeaways. First, "agent identity" has moved from concept to procurement category: Agent Identity, Agent Gateway, and Model Armor sketch the primitives every enterprise will need as autonomous agents proliferate inside production. Second, the Wiz/Google SecOps integration is meaningful but more incremental than secondary coverage suggests. Google's own language is careful ("updated how we integrate") rather than fully native. Custom parsing, normalization, and SOAR content sitting between Wiz and Chronicle UDM today is not automatically obsolete. CISOs should ask vendors specifically what changes versus what's marketing gloss. Third, the SCC Standard tier now bundles posture, compliance, and vulnerability management; worth a hard look for teams paying separately today.

🔎 Sources: Google Cloud Blog

4. ServiceNow Closes $7.75B Armis Acquisition, Reshaping Asset-Centric Security

What Happened. ServiceNow completed its all-cash $7.75 billion acquisition of cyber exposure management vendor Armis on April 20, six months ahead of the originally guided H2 2026 close. Together with the pending Veza identity acquisition, ServiceNow says the combination will more than triple its addressable market for security and risk solutions, embedding real-time asset discovery across IT, OT, IoT, medical devices, "physical AI," and cloud directly into the ServiceNow platform.

Why It Matters. This is a structural bet that the next decade of enterprise security runs through asset-and-identity context, not more detection. For cloud security leaders: (1) ITSM-native CMDBs are about to absorb cyber asset intelligence, which will pressure standalone CAASM tooling and reshape how exposures get prioritized; (2) the OT/IoT/medical visibility coming with Armis pulls non-IT assets into the same pane of glass as cloud workloads (meaningful for healthcare, manufacturing, and CNI buyers running hybrid estates); (3) for CISOs running ServiceNow as the system of record, the integration roadmap is now the ceiling on how fast you can collapse asset, vulnerability, and exposure tools. Plan for a 12–18 month integration window before depth catches up to the marketing.

🔎 Sources: ServiceNow Newsroom

5. Anthropic Investigates Unauthorized Access to "Mythos" Cyber Model via Vendor Environment

What Happened. Bloomberg reported on April 21 that a small Discord group of AI enthusiasts gained unauthorized access to Anthropic's Claude Mythos Preview, the vulnerability-discovery model restricted to Project Glasswing partners (Apple, Microsoft, Cisco, Amazon, Mozilla, several major banks, and reportedly the NSA). The group leveraged credentials from a third-party Anthropic contractor and guessed the model's endpoint URL based on naming-convention knowledge, gaining access on April 7, the same day Glasswing was publicly announced. Anthropic confirmed the investigation and characterized the access as scoped to a third-party vendor environment.

Why It Matters. Strip away the AI framing and this is a textbook contractor-credential-meets-predictable-naming-convention failure. Lessons: (1) third-party vendor environments holding access to your most sensitive systems need the same identity rigor as your own production: scoped credentials, short-lived tokens, no shared environments; (2) predictable naming conventions for staging, preview, and unreleased resources are an under-appreciated reconnaissance surface; (3) controlled-distribution governance for dual-use AI capability will keep failing in similar ways unless the access control layer matches the model's sensitivity. With OpenAI's GPT-5.4-Cyber and Google's Big Sleep operating in similar territory, expect more of these incidents, and expect frontier-AI access controls to become a board-level question for any organization participating in these partner programs.

🔎 Sources: TechCrunch

6. CISA & NCSC: FIRESTARTER Implant Survives Patches on Cisco Firewalls

What Happened. On April 23, CISA and the UK NCSC published a joint malware analysis report on FIRESTARTER, a custom Linux ELF backdoor found on a U.S. federal civilian agency's Cisco Firepower device running ASA software. Tracked to UAT-4356 (the same cluster behind ArcaneDoor), the implant was deployed in September 2025 via CVE-2025-20333 and CVE-2025-20362, and crucially persisted through the patches the agency later applied. CISA updated Emergency Directive 25-03 the same day, requiring federal agencies to collect device core dumps. Cisco recommends full reimaging; only a hard power cycle clears the persistence mechanism.

Why It Matters. "We patched, so we're clean" no longer holds for any organization that ran an internet-exposed ASA between September 2025 and patching. FIRESTARTER hooks into LINA, modifies the boot file, and re-launches itself on signal. For hybrid cloud architects specifically, these devices typically terminate site-to-site VPNs into AWS/Azure/GCP and house the credentials, certificates, and routing trust that connect on-prem to cloud workloads. A compromised firewall is also a compromised cloud egress path. Concrete actions: (1) treat any device exposed during the September 2025 window as compromised regardless of patch state; (2) plan reimaging, not patching, and rotate every credential, certificate, and key that touched the box, including cloud-side IAM roles or service account credentials accessible from those tunnels.

🔎 Sources: CISA AR26-113A

🎯 Cloud Security Topic of the Week:

What's Missing From Most AI Security Programs

The dominant question Shawn Hays hears at RSA from CISOs is some version of "I bought one AI security tool, why doesn't it cover my whole estate?" His answer is uncomfortable: most enterprises are already in the multi-AI era, and most AI security purchases were made for a single-vendor world that no longer exists. Copilot was the beta. Then Copilot Studio agents. Then Atlassian shipped Jira agents. Then Salesforce Agentforce. Then a business unit picked Bedrock for a specific use case, another picked Foundry for another, and somewhere a developer wired in an MCP server pointing at a Hugging Face model. Now the AISPM tool that scopes only to Microsoft prompts and responses sees a fraction of the surface.

Shawn frames this as a direct parallel to the multi-cloud transition fifteen years ago: every booth at RSA 2010 was selling multi-cloud security because organizations had lifted-and-shifted to "this place and that place and that place" without knowing how to protect it. We are now living the same pattern with AI, and the program design that worked for a single-stack AI strategy is not going to carry forward. But the bigger gap, in Shawn's view, is not breadth. It's depth. Most programs have visibility and posture management, and almost nothing else. The rest of this newsletter walks through the eight pillars he uses to frame an enterprise-grade AI security program, and why AISPM and visibility alone are the wrong place to stop.

Featured Experts This Week 🎤

• Shawn Hays ex-Product Marketing Manager for Microsoft Applications & AI Security Solutions at Varonis.

• 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:

• AISPM (AI Security Posture Management). Continuous discovery, posture assessment, and risk prioritization across AI components such as models, agents, MCP servers, code repos, and datasets. Analogous to CSPM but for AI estates.

• DSPM (Data Security Posture Management). Continuous discovery and risk assessment of sensitive data across cloud and SaaS, including who has access and how it's classified.

• ITDR (Identity Threat Detection and Response). Behavioral monitoring of identities (both human and non-human) for compromise indicators like privilege escalation, anomalous logins, and lateral movement.

• CIEM (Cloud Infrastructure Entitlement Management). Visibility and right-sizing of permissions for identities accessing cloud resources.

• AI Bill of Materials (AI BoM). A manifest of components inside an AI system (models, datasets, MCP servers, prompts, tools, dependencies). Analogous to SBOM for software supply chain.

• MCP (Model Context Protocol). The emerging standard for how agents call external tools and data sources. An MCP server exposes capabilities (e.g., "read this database," "call this API") that an agent can invoke at runtime.

• RAG AI (Retrieval-Augmented Generation). AI systems like Copilot that ground responses in data the prompting user already has access to, via token-exchange checks at query time. Permissions are inherited from the user.

• Guardrails. Runtime controls that block an agent from taking specific actions or producing specific outputs. Input guardrails (e.g., "reject prompt-injection attempts"), output guardrails (e.g., "never emit PHI").

This week's issue is sponsored by Orca Security

Orca Security is hosting Cloud Security LIVE, a half-day virtual summit on Tuesday, May 12th. Join CISOs, security co-founders, and practitioners for unfiltered insight real stories and strategies from people securing the world's most complex cloud environments.

Sessions include:

• The new standard for resilience: zero-breach to zero-impact

• AI on both sides: securing models and APIs while using AI to defend your cloud

• Mastering 3rd-party and supply chain risk

• Security leadership panel on AI, risk, and driving change

  
  Join for a chance to win* a 64GB Beelink AI PC. *US-based attendees only.

Register Today

💡Our Insights from this Practitioner 🔍

1. The "Multi-AI Era": Why It Changes Program Design

Shawn opens with a frame that anyone who lived through 2010-era multi-cloud chaos will recognize immediately:

"I think we are now entering this multi-AI era where no longer is an organization, an enterprise, sophisticated organization, just using copilot. They're using all these different pieces." Shawn Hays, Varonis

The implication for security architecture is direct. A program that scopes only to Microsoft Copilot's prompts and responses will not see Jira agents, Agentforce, Bedrock pro-code agents, or MCP servers pulling in third-party models. Shawn describes a recurring conversation with enterprises who bought a single-vendor AI security tool early, and then discovered, as they matured, that "the entirety of the AI that they have, or maybe the AI they're going to have" exceeds what one tool can cover. This is the AISPM equivalent of early CSPM tools that only saw AWS: useful, but incomplete the moment a second cloud showed up.

What to do about it. When evaluating an AI security platform, Shawn's recommended buyer's question is: "Can it protect all the AI I've built today, all the AI I plan to build tomorrow, and all the AI I don't even know about?" If the answer scopes to a single hyperscaler or a single AI vendor, the tool is solving a 2024 problem.

2. The Eight Pillars: AISPM Is Necessary, Not Sufficient

Shawn argues the market has over-pivoted on AISPM and visibility. It's the same pattern Varonis saw in DSPM five years ago, where customers bought posture tools and then realized they had no enforcement layer. The full program he describes covers eight areas; the pillars he emphasizes most:

1. Inventory and observability across every layer of the AI stack, models, MCP servers, agents, services, code repos, even Jupyter Notebooks (where he's seen developers stash secrets for convenience). Continuous, not point-in-time.

2. AISPM, misconfigurations, vulnerabilities, posture drift across that inventory.

3. AI Bill of Materials for both internal-built systems and third-party AI services. If a model has a CVE in NIST's NVD, you need to know it's in your stack, and you need to know it's in Grammarly's stack too.

4. Pen-testing of agents before they go live. As Shawn puts it, you "need to put it through the ringer… both from a jailbreaking, poisoning [perspective] but also very run-of-the-mill interactions to see how it's gonna behave."

5. Runtime guardrails that block specific behaviors, input guardrails for prompt injection, output guardrails for sensitive-data emission.

6. Compliance monitoring mapped to frameworks like NIST AI RMF that re-evaluate as the agent changes.

7. Third-party AI risk management including AI BoM ingestion from vendors.

8. Continuous monitoring across the full lifecycle, not just deployment.

The strategic insight underneath this list:

"They have great visibility, they have inventory, they know every piece of their AI system, but they really have no way of preventing that agent or AI system from going off the rails." - Shawn Hays, Varonis

This is the most actionable critique in the conversation. Many enterprises in 2026 will pass an internal audit of their AI security program, they have the dashboards, they have the inventory, they have CVE alerting on models, and still have nothing in front of an agent that would stop it from doing something stupid in production. The pen-testing-and-guardrails layer is where most programs are thinnest.

3. Identity Is Woven Through Everything: Why Native Tools Won't Carry You

Shawn is precise about how identity sprawls across an agentic estate:

"You've got identities for the folks that can access data in the cloud store… you have the identity of the agent, you have identity of the builders, like the people making these agents… if they're using some sort of Bitbucket, GitHub, you have identities for those that can have access to the code repos. It's like there's an identity layer woven throughout." - Shawn Hays, Varonis

Each of those identity surfaces needs ITDR coverage. Not just the cloud architect (with normal CIEM/ITDR for elevated privileges and lateral movement), but the agent identity itself, alerting on agents that suddenly gain entitlements, access resources they typically don't, or "feverishly" light up after a period of dormancy.

Ashish pushes on the obvious counter, "I have an E5 license, the native services cover this, right?", and Shawn's response is the most quotable piece of practical guidance in the episode:

"Native tools are really good about solving some of the native challenges. But then once you start broadening the scope and the aperture, that's when it gets a little tough." - Shawn Hays, Varonis

The example he uses is HIPAA. Microsoft Purview will do an excellent job preventing PHI exfiltration via labeled data and DLP policies, inside the Microsoft tenant. The moment an AWS Bedrock agent calls an EHR system through an MCP server, that protection envelope ends, but the regulator's expectation does not. For CISOs in regulated industries, this is the architectural argument for a cross-stack AI security platform regardless of how aligned your primary cloud is.

4. The Connector Ecosystem Is Quiet Third-Party Risk

The connector ecosystem is the part of the AI security problem most enterprises haven't budgeted for. Shawn's example: turning on the Salesforce connector in Microsoft 365 Copilot doesn't require deploying a "highly configured, sophisticated pro-code AI solution." It's a checkbox. But the moment that connector is on, Copilot is grounded in Salesforce data via the same can-access model, and any data permission misconfiguration in Salesforce now flows into Copilot output.

This is why DSPM and AI security are intertwined, not adjacent. RAG AI inherits user permissions; if those permissions are over-permissive, the AI is over-permissive. Shawn's guidance for Copilot governance specifically (and it transfers to any RAG-based AI tool in your estate):

1. Understand what data Copilot can access.

2. Test whether existing classification and labeling actually works.

3. Define how new data will be classified and labeled going forward.

4. Apply zero trust at runtime: monitor how Copilot interacts with data even after permissions are right-sized.

5. Zero Trust Applied to the Whole Chain, Not Just the User

The strongest architectural insight in the conversation is Shawn's reframing of zero trust as applied to every actor in an agentic transaction simultaneously:

"I need to not trust that agent. I need to even not trust the user prompting… I need to also not trust the cloud architect that's over that maybe data SQL database that's sitting in Azure. I wanna apply zero trust to that entire chain, and the reason being [is] data." - Shawn Hays, Varonis

In a healthcare patient-facing agent example, this means: don't trust the prompt (it might contain a jailbreak embedded inside legitimately-ingested PHI), don't trust the agent's downstream actions (it might write PHI to the wrong table), don't trust the Azure architect's identity (it might be compromised), and don't trust the cloud configuration (misconfig could leak data via SQL). Each link is a separate enforcement point with separate controls.

This is also the lens that makes this week's news cohere. The Anthropic Mythos incident violated trust at the contractor link. FIRESTARTER violated trust at the network appliance link. LiteLLM violated trust at the AI gateway link. None of these were AI-specific in the bug-class sense. They were identity-and-access failures dressed up in different costumes.

The "Ron Burgundy" Analogy: Why Data and Identity Will Outlast Every AI Architecture

When Ashish asks what controls will stand the test of time as 2027 and 2028 AI architectures arrive, Shawn lands on an analogy worth keeping:

"At least the AI we have now, and maybe for the next five years… AI is Ron Burgundy. It's only gonna read what's on the teleprompter. So if we're looking at identity solutions and data security… it's like, how are we gonna make sure that the right data shows up on the teleprompter?" - Shawn Hays, Varonis

The point is durable: whatever the next-generation agent architecture looks like, it will still be reading from a context window, and that context window is still being populated by data systems and identity decisions that you control. Right-size data access, instrument identity at every layer, and apply zero trust to the chain. Do that, and you'll be in a defensible position regardless of what AI architecture wins next.

Ashish's Frame: The Horse Has Left the Barn

Ashish makes the operational counterpoint that should sit with every CISO reading this:

"With AI, that horse has left the barn." - Ashish Rajan, Cloud Security Podcast

Data classification programs that "never had the rubber hit the road" (Ashish's words from his own CISO experience) are no longer a deferrable problem. The assumption that confidential data stays inside organizational boundaries is broken the moment an agent reaches into Salesforce, Jira, or a third-party MCP server. The teams that get ahead in 2026 are the ones treating data classification, identity hygiene, and access right-sizing as the AI security work, because, per Shawn's argument, that is the AI security work for the dominant RAG-based AI patterns.

Practical Application: A 30–60 Minute Action List

Drawing from Shawn's eight pillars and this week's news, the immediate work for cloud security teams:

• Inventory every AI gateway, proxy, and middleware in your estate (LiteLLM, Portkey, custom OpenAI proxies, etc.) and treat their secrets stores as Tier-0. If you ran a vulnerable LiteLLM build, rotate now.

• Map your full multi-AI footprint (Copilot, Copilot Studio, Foundry, Bedrock, Agentforce, Jira agents, custom agents, MCP servers, and any third-party SaaS using AI as a feature). Score each for AI BoM availability.

• Apply ITDR to non-human identities (agents and service principals), not just to humans. Anomalous agent behavior should page the SOC the same way anomalous human behavior does.

• Audit your connector ecosystem. Every cross-product connector (Copilot ↔ Salesforce, etc.) inherits permissions. Run a DSPM/AISPM pass on the data side of each connector.

• Add pen-testing and guardrails to your agent SDLC. If your AI program documentation only describes posture and inventory, it's incomplete.

📚 RELATED RESOURCES 🎧

• Varonis Atlas overview: Varonis's AI security platform

• Varonis blog: Applying Zero Trust to MCP Servers: Shawn's recent write-up referenced in the conversation

• Sysdig: CVE-2026-42208 LiteLLM Analysis: exploitation timeline and detection guidance

• Wiz Research: GitHub CVE-2026-3854: full technical disclosure

• CISA Emergency Directive 25-03 (FIRESTARTER): federal guidance applicable to all enterprises running ASA/FTD

• NIST AI Risk Management Framework (AI RMF): compliance reference for AI security programs

• Microsoft Purview + Copilot governance documentation: native controls baseline for the Microsoft stack

• Google Cloud Next '26 security keynote recap: Agent Identity, Agent Gateway, Model Armor announcements

Podcast Episode

• Cloud Security Podcast -Full Episode with Shawn Hays- Complete transcript and audio for this week's featured conversation

Question for you? (Reply to this email)

🤔 If you had to pick one (AISPM, runtime guardrails, or AI-aware ITDR), which is the biggest gap in your program right now?

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: Agentic Cloud Security: Why the CNAPP Must Evolve Before Your Adversaries Do (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’s uncomfortable truth:

Attackers are no longer breaking into your systems.
They are operating inside them using your tools, your APIs, and your trust relationships.

• APT41 is stealing IAM credentials using cloud metadata APIs

• Vercel was breached without a vulnerability - just OAuth trust abuse

• Microsoft Teams is being used to impersonate IT helpdesks

• Cisco ISE can now be taken over with read-only credentials

And according to Palo Alto Networks Research: It’s taking ~25 minutes from breach to data exfiltration. [Listen to the episode]

⚡ TL;DR for Busy Readers

This week’s attacks didn’t break systems — they used them


🔴 APT41 cloud credential theft: 
Winnti backdoor harvesting AWS/Azure/GCP tokens via SMTP (zero detections). Block outbound SMTP from non-mail workloads NOW  

🔑 SaaS tokens = your weakest link: 
Vercel breached via over-permissioned OAuth — API keys, GitHub & NPM tokens exposed. Audit third-party OAuth access TODAY  

⚠️ Identity isn’t safe: 
Cisco ISE CVSS 9.9 flaws exploitable with read-only credentials. Patch manually — Cisco can’t do this for you  

📦 Third Party Breach risk is live ( 1yr later): 
A 2025 Salesforce compromise is still exposing new victims — including 13.5M user records and SSNs — nearly a year later.  

🤖 CNAPP model is breaking: 
25-minute breach-to-exfiltration window confirmed — human-speed response is no longer viable   

📰 THIS WEEK'S TOP SECURITY HEADLINES

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

 🚨 1. Microsoft Teams Used for Helpdesk Impersonation Attacks

What’s happening

Microsoft has documented a nine-stage attack chain where Attackers are spinning up fake Microsoft tenants and impersonating internal IT via Teams → convincing employees to start remote sessions → then moving laterally and exfiltrating data.

Why this matters

No malware. No exploit.
Just trusted tools used against you.

Your EDR sees normal activity.
Your users see “IT support”.

This is a living-off-the-land attack that requires no malware, no CVEs, and no phishing emails. It exploits the trust users have placed in a familiar collaboration platform. Because the attacker operates from a Microsoft-issued tenant using Microsoft-sanctioned tools, most endpoint detection stacks will see Zoom-like remote access activity with no signal that anything is wrong. The cross-tenant access feature is enabled by default in most Microsoft 365 deployments and has almost certainly never been reviewed in your environment.

👉 What to do

▶     Audit Teams external access policy immediately.  Most organizations have never restricted cross-tenant chat. Limit it to approved domains, or disable it if not operationally required.

▶     Establish out-of-band helpdesk verification.  Create a verbal authentication phrase that all IT staff use before initiating remote sessions. Include this in your security awareness training.

▶     Hunt for Rclone in your environment.  Rclone has no legitimate enterprise use in most organizations. Its presence on an endpoint is an incident indicator.

▶     Create a detection rule for Quick Assist sessions from external tenants.  This pattern is unusual enough that a well-scoped rule should have near-zero false positives.

Sources:    BleepingComputer  |  CSO Online

🚨 2.  Salesforce Breach Surfaces Downstream: McGraw-Hill 13.5M, OneDigital 28K SSNs

What happened:

A 2025 Salesforce compromise is still exposing new victims — including 13.5M user records and SSNs — nearly a year later. OneDigital confirmed approximately 28,414 individuals had names and SSNs exposed. McGraw-Hill disclosed that ShinyHunters stole and publicly leaked 13.5 million user accounts via the same underlying Salesforce breach. The gap between the original compromise and these disclosures is approaching twelve months for some affected individuals.

Why it matters:

The Salesforce breach itself is not the primary lesson here. The lesson is the blast radius and the disclosure lag

👉 What to do

▶     Treat CRM as tier-1 cloud infrastructure.  Apply the same access controls, anomaly detection, and logging posture to Salesforce that you apply to your data warehouse.

▶     Renegotiate SaaS breach notification SLAs.  If your contracts do not specify a notification timeline for platform-level incidents, you have no contractual floor.

▶     Backdate your investigation window.  When a downstream notification arrives, treat the compromise date   not the notification date as your start point.

Sources: BleepingComputer | Palo Alto Unit 42 | Cybersecurity Dive | Rapid7

☁️ 3. ⚡ APT41 Deploys Zero-Detection Cloud Credential Backdoor to Harvest Credentials Across AWS, Azure, GCP

What happened:

APT41 is harvesting credentials from AWS, Azure, and GCP using metadata APIs and hiding traffic in SMTP.

Zero detections at time of discovery.

Why it matters:
This is the most cloud-native credential theft operation we have seen from a state-sponsored actor. The backdoor does not exploit a vulnerability in your cloud environment it queries the same metadata APIs your applications use legitimately. 

On AWS it hits the IMDS endpoint at 169.254.169.254 for IAM role credentials. On Azure it pulls managed identity tokens. On GCP it requests service account tokens. It also sends periodic UDP broadcast beacons on port 6006 for peer-to-peer lateral coordination between compromised hosts, meaning the C2 infrastructure can go dark while the campaign continues to propagate internally.

This attack:

• Uses legitimate APIs

• Avoids HTTP/DNS monitoring

• Blends into normal cloud behaviour

This bypasses:

• EDR

• Signature detection

• Traditional network monitoring

This is a cloud-native attack on your control plane

👉 What to do

▶     Block or alert on outbound SMTP (port 25) from non-mail workloads.  This is anomalous in cloud compute environments and should have very low false positives.

▶     Alert on unusual reads of cloud credential files  from non-SDK processes: ~/.aws/credentials, ~/.azure/ profile directories, GCP application default credential paths.

▶     Enforce IMDSv2 on AWS and equivalent IMDS hardening on Azure/GCP.  This limits the blast radius of a compromised instance by requiring session-oriented token requests.

▶     Hunt for stripped, statically linked ELF binaries in /tmp and /var/tmp.  These are not characteristic of legitimate cloud workloads.

▶     Alert on UDP broadcast traffic to port 6006 from compute instances.  This is the lateral movement beacon used by this implant.

Sources: Dark Reading  |  SC Media  |  CybersecurityNews

🏥 4. Cisco Patches Four Critical Flaws in Webex and ISE - Including Unauthenticated SSO Impersonation

What happened:

Cisco released patches for 15 vulnerabilities including four critical-severity flaws in Webex Services and Identity Services Engine.

CVE-2026-20184 (CVSS 9.8) in Webex allows an unauthenticated remote attacker to impersonate any user by exploiting improper certificate validation in the SSO integration with Control Hub. Three critical ISE flaws (CVE-2026-20147, CVE-2026-20180, CVE-2026-20186, all CVSS 9.9) enable remote code execution on the underlying OS   critically, CVE-2026-20180 and CVE-2026-20186 are exploitable with nothing more than read-only administrative credentials. No active exploitation has been confirmed at time of disclosure.

Why it matters:
The Webex SSO flaw has a manual remediation step that Cisco cannot complete on your behalf: admins must upload a new IdP SAML certificate to Webex Control Hub. In enterprises where Webex administration is delegated or outsourced, this step is highly likely to be missed. The ISE vulnerabilities carry a more severe operational implication: ISE underpins 802.1X authentication, NAC, and device trust for many large enterprises. An attacker with a compromised read-only monitoring account   a very common post-breach scenario   can achieve root code execution on your network access control infrastructure. CrowdStrike’s 2026 Global Threat Report notes that valid account abuse accounted for 35% of cloud incidents last year. These flaws make that even more dangerous.a

👉 What to do

▶     Upload the new IdP SAML certificate to Webex Control Hub NOW  if SSO is in use. This is your action item, not Cisco’s.

▶     Patch ISE to fixed releases:  3.1 P11 · 3.2 P10 · 3.3 P11 · 3.4 P6 · 3.5 P3. There are no workarounds.

▶     Audit read-only admin account activity in ISE.  Any anomalous activity on these accounts should be treated as a high-priority incident given the low privilege bar for exploitation.

Sources: SecurityWeek  |  CSO Online  |  Cisco Security Advisories

5 — Vercel Breach via OAuth Supply Chain Attack

What happened:

On April 19, Vercel disclosed a security breach that began in February 2026 when a Context.ai employee’s machine was infected with Lumma Stealer malware after downloading a Roblox game exploit. The malware harvested Google Workspace credentials and OAuth tokens, which the attacker used to pivot through Context.ai’s AWS environment into a Vercel employee’s Google Workspace account   gaining access to Vercel’s internal systems and non-sensitive environment variables. A threat actor claiming ShinyHunters affiliation listed the stolen data for $2M on BreachForums, claiming the haul includes API keys, NPM tokens, GitHub tokens, and 580 employee records. Vercel confirmed the incident, published IOCs, and advised all customers to rotate environment variable credentials.

Why it matters:
This breach chain required zero direct vulnerabilities in Vercel’s own code. The attack path was: infostealer → OAuth token theft → SaaS lateral movement → PaaS credential exposure. Every step exploited legitimate trust relationships between sanctioned enterprise applications. The structural problem is that a single developer using a third-party AI tool with overly permissive Google Workspace OAuth grants became the entry point for an incident that potentially affects hundreds of organizations.

👉 What to do

▶     Audit all third-party OAuth authorizations in Google Workspace and Microsoft 365.  Remove any app granted broad read/write access that is not formally inventoried and approved.

▶     Add PaaS deployment platforms to your SBOM and TPRM register.  Vercel, Netlify, Railway, Render   these are tier-1 supply chain dependencies, not external services.

▶     Rotate all Vercel environment variables not marked as ‘sensitive’.  Even without a direct notification, the exposure window spans February–April 2026.

▶     Block or alert on ‘Allow All’ OAuth grants  during enterprise onboarding of AI tools. This single permission pattern is the root cause of this incident.

Sources: TechCrunch  |  BleepingComputer  |  Help Net Security  |  Trend Micro Research  |  Vercel Security Bulletin

🎯 Cloud Security Topic of the Week:

Agentic Cloud Security: Why the CNAPP Must Evolve Before Your Adversaries Do

 For most of the past decade, the cloud security conversation was structured around posture. Know your misconfigurations. Remediate your public S3 buckets. Track your IAM sprawl. The CSPM era gave security teams visibility, and visibility was genuinely the right place to start. But a posture score does not stop an APT41 backdoor that is already running on your Linux workload and querying your metadata API. And a misconfiguration dashboard does not help you when an attacker goes from initial access to data exfiltration in 25 minutes.

 Elad Koren’s framing in this week’s episode is the clearest articulation of this shift we’ve heard: cloud security has moved from “manage your hygiene” to “protect in real time while maintaining hygiene.” The CNAPP of 2026 is not just a visibility platform. It is an autonomous response layer that can make and execute decisions faster than any human analyst can triage a ticket.

 The three structural changes Koren identified as driving this shift are worth examining individually, because each one has a direct implication for how you build or upgrade your cloud security program:

• AI is available to adversaries. Attacks that previously required days of reconnaissance and manual exploitation can now be generated and launched with a prompt. Palo Alto’s telemetry shows a 25-minute window from initial access to data exfiltration in active incidents. You cannot staff a human response team capable of operating inside that window.

• Vibe coding has removed the development friction that security relied on. When the cycle from “ideation to production” collapses to three days   including testing   the traditional shift-left security model breaks. There is no left to shift to. Security must be embedded as a continuous automated layer across the entire pipeline, not a review gate before deployment.

• AI workloads in cloud represent a posture gap most teams cannot close manually. Organizations are deploying experimental AI applications faster than their security teams can inventory, analyze, and control them. The incident Koren described   an internal AI workload accidentally exposed to the internet because the developer had no security context   is not an edge case. It is a pattern.

  ---

  Featured Experts This Week 🎤

• Elad Koren - VP, Product Management, Cortex Cloud, Palo Alto Networks

• 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:

• CNAPP (Cloud-Native Application Protection Platform)

  A unified security platform that combines CSPM (posture), CWPP (workload protection), CIEM (entitlements and identity), and increasingly runtime protection and AI workload security into a single data-integrated platform. Elad Koren’s argument is that the CNAPP of 2026 must move beyond posture management into active agentic defense   where AI agents can automatically remediate tier-one issues while surfacing complex attack paths for human analysts.

• Vibe Coding

  A term describing the practice of using AI coding assistants to generate, iterate, and deploy code at dramatically accelerated speeds   often with minimal formal review, design documentation, or security scrutiny. The term captures the intuitive, flow-state nature of AI-assisted development. Its security implication, as Koren described, is that inception-to-production cycles that previously took weeks now take days, collapsing the time window available for security review.

This week's issue is sponsored by Orca Security

Orca Security is hosting Cloud Security LIVE, a half-day virtual summit on Tuesday, May 12th. Join CISOs, security co-founders, and practitioners for unfiltered insight real stories and strategies from people securing the world's most complex cloud environments.

Sessions include:

• The new standard for resilience: zero-breach to zero-impact

• AI on both sides: securing models and APIs while using AI to defend your cloud

• Mastering 3rd-party and supply chain risk

• Security leadership panel on AI, risk, and driving change

  
  Join for a chance to win* a 64GB Beelink AI PC. *US-based attendees only.

Register Today

💡Our Insights from this Practitioner 🔍

1. The 25-Minute Window Has Broken the Traditional Security Model

The most operationally significant data point from Elad Koren’s conversation is also the most alarming: Palo Alto’s telemetry shows that once an organization is susceptible to a particular attack pattern, a threat actor can go from initial access to data exfiltration in 25 minutes. This is not a worst-case scenario. It is a measured median.

"It can be seconds. Our latest report shows that within 25 minutes an organization can have data exfiltrated. You cannot wait for the practitioners to fix the gap."    Elad Koren

The practical implication for cloud security architecture is that any control requiring human decision-making in the response chain   triage ticket, analyst review, change approval   cannot be the first line of defense for high-confidence threat signals. The most experienced analyst in your SOC cannot triage, escalate, approve, and contain an incident in 25 minutes when they are also managing a queue of other alerts. The response to known-pattern attacks must be automated.

2. Three Forces Have Changed the Threat Model Permanently

Elad laid out a clear framework for why the security model that worked three years ago is structurally inadequate today, and it is worth internalizing for board-level conversations:

"There are three fundamental things that changed in the model. AI is there for the adversaries   they can move much faster. Developers are pushing code much faster with vibe coding. And we are seeing more and more AI applications running in cloud that not many organizations know how to analyze the posture of."    Elad Koren

Each of these forces has a distinct security implication that compounds the others. AI-accelerated attacks mean your detection and response must operate at machine speed. Vibe-coded applications mean your code review pipeline will always be behind the deployment pipeline without automation. AI workloads in cloud mean your CSPM and CWPP coverage has gaps in resource types that simply did not exist 18 months ago. Combine all three, and Elad’s conclusion is apt: “combine all three and you have a time bomb basically.”

3. Agentic Cloud Security Is Not a Product Pitch   It Is an Architectural Requirement

The framing of “agentic CNAPP” can sound like vendor positioning, but Elad’s description of what it actually means is grounded in operational reality. The core argument is not that AI agents replace your security team. It is that tier-one triage the routine fixes, the known patterns, the high-confidence remediations   should be handled autonomously, so that your analysts can focus on the cases that genuinely require human judgment.

"A good solution prioritizes making sure that your tier-one analysts   you can take 85, 90% of the things they would do, the regular fixes, automatically. You’ll have AI agents working for you. Because then you’re fighting machines with machines."    Elad Koren

Ashish Rajan’s framing of the shift is equally direct: the agentic security era means the CNAPP must have API-level understanding of how AI agents communicate with cloud platforms, not just posture snapshots of static configurations. 

"It’s no longer enough that you have a CNAPP. Having an understanding of the pathway, API capabilities, and how you can have AI agents communicate with that as a platform will become the more important thing as we move into 2026 and beyond."    Ashish Rajan

4. Visibility and Identity Are the Two Non-Negotiable Foundations

When Elad was asked directly what organizations should focus on for a durable cloud security uplift program, his answer was grounded in a specific real-world example: an experimental AI workload deployed for internal use that was accidentally exposed to the internet because the developer had no security awareness of the infrastructure it was running on.

"That AI workload was open to the world without any need of authentication. The person creating that had little to almost no knowledge or awareness for security. Somebody was able to access it   he was able to exfiltrate data. Inception to production in less than three days, including testing, including everything."    Elad Koren

His prescription: visibility into where your AI workloads run, identity controls with least-privilege and minimal access for anything that touches those workloads, and securing the infrastructure   not just the application. This is not new advice in the abstract, but the AI workload context makes it urgent in a new way. Most organizations’ AI workload inventory is incomplete by definition   developers are spinning up new AI-powered services faster than any centralized inventory process can track them.

5. The “Messy Middle” Is Where We Are   And That Is a Strategic Opportunity

Elad’s most useful framing for security leaders planning multi-year programs is what he calls the “messy middle”: the transition period between where most organizations are today (siloed, posture-focused, human-speed) and where the industry is going (platformized, agentic, machine-speed). This period is messy because no one knows exactly what the equilibrium looks like. But the direction is clear.

The prescription for this period is not to wait for clarity. It is to build the foundations that will matter regardless of how the technology evolves: unified data platforms that eliminate tool silos, trust in AI-driven automation built through experimentation, and upskilling security practitioners to become orchestrators rather than ticket-processors.

"If organizations continue to build things in silos and look at security as siloed different tasks by different practitioners   adversaries will prevail. They’re like water. They’ll just find a path in. You close the door, they look at the window. You close the window, they look at the tunnel. If they don’t have a tunnel, they’ll dig a tunnel."    Elad Koren

📚 RELATED RESOURCES 🎧

• Palo Alto Networks Cortex Cloud   Platform Overview

  The platform Elad Koren describes in this episode. Relevant for teams evaluating agentic CNAPP capabilities.

Podcast Episode

• Cloud Security Podcast -Full Episode with Elad Koren - Complete transcript and audio for this week's featured conversation

Question for you? (Reply to this email)

🤔   Is your AI workload inventory complete enough that you could answer ‘where does our AI run and who can reach it’ in under an hour?

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 Behavioral Blind Spot: Why Your Security Stack Can't See What Users Actually Do With AI (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 week of April 8–13 delivered a signal that the security industry has been anticipating with dread: autonomous AI vulnerability discovery at scale. Anthropic's disclosure of Claude Mythos Preview, a model that independently found thousands of high- and critical-severity zero-days across every major operating system and browser is not a research curiosity. It is a forcing function for every security program that still operates on human-speed threat models.

At the same time, attackers remained methodical and thoroughly mundane. ShinyHunters did not need a novel exploit to pivot from Anodot's SaaS platform into over a dozen Snowflake customer environments, they walked in with stolen integration tokens. TeamPCP did not compromise a zero-day; they compromised a maintainer's credentials and waited for CI/CD pipelines to distribute the payload automatically.

Threading these stories together this week is Brandon Dixon, Co-founder of Ent.ai and one of the architects of Microsoft Defender Threat Intelligence and Microsoft Security Copilot. Brandon joined Cloud Security Podcast host Ashish Rajan to discuss why the control surfaces enterprises have built EDR, DLP, UEBA, SSPM are structurally blind to the behavioral signals that matter most: what a user actually intends to do, across every application, in real time. [Listen to the episode]

⚡ TL;DR for Busy Readers

• 🔴 Patch NOW: SharePoint (active exploit), Ivanti EPMM (KEV), Adobe Reader (5 months undetected), Windows IKE RCE (CVSS 9.8, wormable)

• 🔑 SaaS tokens = your weakest link: ShinyHunters breached Snowflake customers without a single vulnerability — just stolen integration tokens

• 📦 Your security tools can betray you: TeamPCP compromised Trivy, KICS, Axios, LiteLLM — 10,000+ cloud creds stolen via CI/CD

• 🤖 AI offense just scaled: Anthropic’s Claude Mythos found thousands of zero-days autonomously

• 👁️ EDR blind spot is real: It sees processes, not intent — and attackers are now operating in that gap

👉 WHAT TO DO THIS WEEK

• Patch internet-facing systems immediately (SharePoint, Ivanti, Windows services)

• Rotate ALL third-party SaaS tokens (especially Snowflake integrations)

• Audit CI/CD pipelines → lock dependencies + enforce signed artifacts

• Review AI usage inside sanctioned apps (Teams, Slack, WhatsApp, etc.) 

📰 THIS WEEK'S TOP 8 SECURITY HEADLINES

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

 🚨 1. Microsoft Patch Tuesday (167 CVEs, Active Exploits)

What happened:

• 167 vulnerabilities patched (largest of 2026)

• Active SharePoint zero-day (CVE-2026-32201)

• Wormable Windows IKE RCE (CVSS 9.8)

• Adobe Reader zero-day active for 5 months

Why it matters:
This is Exploit Wednesday territory. Attackers are already reverse-engineering patches.

👉 Priority order:

1. SharePoint (active exploitation)

2. Ivanti EPMM (KEV)

3. Windows IKE / TCP-IP RCE

4. Adobe Reader

Sources:  BleepingComputer | Security Affairs | Zero Day Initiative

🚨 2.  Ivanti EPMM Zero-Day (KEV, 4,400+ Exposed)

What happened:

• Third critical zero-day in Ivanti platform

• Active exploitation confirmed

• 4,400+ internet-exposed instances

Why it matters:
This is no longer a vulnerability issue — it’s a vendor risk signal.

👉 Treat as:

• Emergency patch

• Potential breach (assume compromise mindset)

Sources: BleepingComputer | Palo Alto Unit 42 | Cybersecurity Dive | Rapid7

☁️ 3. ⚡ Adobe Zero-Day (5 Months Undetected)

What happened:

• Silent exploitation via PDF for ~5 months

• No user interaction required beyond opening

• Targeting energy sector

Why it matters:
Your telemetry likely showed:
👉 “Acrobat.exe is running” — nothing else.

This is exactly the detection gap modern attacks exploit.

Sources: OpenVPN Blog | Zero Day Initiative

🏥 4. ShinyHunters: SaaS Token Breach → Snowflake Customers

Beginning April 4, ShinyHunters compromised Anodot — an AI-powered cloud cost monitoring 

What happened:

• Anodot breached → integration tokens stolen

• Attackers accessed multiple Snowflake environments

• 78.6M records leaked

Why it matters:
No vulnerability. No exploit.

👉 Just trusted SaaS tokens doing their job

This mirrors the 2025 OAuth attacks — and most orgs still haven’t fixed it.

Action:

• Rotate ALL SaaS tokens

• Enforce short-lived credentials

• Audit vendor integrations post-acquisition

Sources: TechCrunch | BleepingComputer | The Record

5 — TeamPCP Supply Chain Attack (10,000+ Orgs Impacted)

What happened:

• Trivy, KICS, Axios, LiteLLM compromised

• Malicious packages exfiltrated cloud credentials

• Spread via CI/CD pipelines

Why it matters:
Your security scanners are now part of the attack surface.

👉 If your pipeline auto-pulls latest:
You’re running unverified code in production by design

Action:

• Lock dependency versions

• Use signed artifacts

• Add release cooldown windows 

Sources: SANS Institute | Zscaler ThreatLabz | The Register | InfoQ

6 — Anthropic's Claude Mythos Preview Autonomously Discovers Thousands of Zero-Days Across Every Major OS and Browser; Project Glasswing Launched

What happened:

• Claude Mythos discovered thousands of vulnerabilities

• 72% success rate in exploit development

• Posted exploits autonomously in testing

Why it matters:
This is a category shift.

👉 Threat model is now:

• Faster than human response

• Cheaper to execute

• Scalable by design

Implication:
Detection-led security will fail.

👉 You need:

• Automated containment

• Identity-aware segmentation

• Sub-30 min response capability

Sources: Anthropic Red Team | Help Net Security | The Register | CSA Briefing via Help Net Security

7 — Microsoft Defender for Cloud → AI Model Scanning

What happened:

• Scans models for malware, secrets, unsafe formats

• Supports .pkl, .onnx, .pt, etc.

• Integrated into CI/CD

Why it matters:
AI models = new software supply chain

👉 Pickle files = built-in RCE risk

Action:

• Scan all models before deployment

• Prefer SafeTensors over Pickle

Sources: Microsoft Learn — AI Model Security | Microsoft Tech Community Blog | Defender for Cloud Release Notes

8 — Databricks Enters SIEM Market with "Lakewatch" via Dual Acquisition of Antimatter and SiftD.ai

What happened:

• Acquires Antimatter + SiftD.ai

• Launches AI-native SIEM

Why it matters:
Security is merging with data platforms.

👉 This creates a new problem:
Who owns detection security or data teams?

Sources: SecurityWeek — Cybersecurity M&A Roundup March 2026

🎯 Cloud Security Topic of the Week:

The Behavioral Blind Spot: Why Your Security Stack Can't See What Users Actually Do With AI

Every major security incident discussed in this week's news brief shares a common thread: attackers and risky insiders are operating inside the legitimate workflows of sanctioned enterprise tools. ShinyHunters looked like a trusted SaaS integration. The Adobe PDF exploit ran inside a fully patched Reader process. TeamPCP's malicious Axios release ran through the same npm dependency resolution your developers use daily. The Zoom remote-control exfiltration path is invisible to EDR because EDR sees the process, not the intent.

Brandon Dixon's work at Ent.ai addresses the fundamental question this creates for enterprise security programs: if adversaries and risky insiders have moved into the behavioral layer — into the clicks, clipboard operations, drag-and-drop file transfers, and AI prompt submissions that happen inside sanctioned applications — what does your detection surface actually cover?

The answer, increasingly, is less than you think. This is the topic that binds together AI security governance, insider risk, supply chain compromise, and the post-EDR detection problem. And it is the lens through which senior cloud security leaders should be evaluating both their current tooling and the programs they are building for the AI era.

Featured Experts This Week 🎤

• Brandon Dixon Co-founder & CTO , Ent.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:

• Behavioral Layer / Endpoint Behavioral Intelligence A detection approach that sits above the operating system process level and observes what users and agents actually do within and across applications — clicks, clipboard operations, file drags, AI prompt submissions, cross-app data movement — rather than simply which processes are running. This is distinct from EDR (which monitors file system and process activity) and UEBA (which typically analyzes aggregated log-derived signals).

• Living Off the Land (LotL) An attack technique in which threat actors use legitimate, pre-installed enterprise software (PowerShell, WMI, Zoom remote control, etc.) to conduct malicious activity, making detection harder because the tools themselves are not inherently suspicious. TeamPCP's use of compromised legitimate package releases is a supply-chain variant of this technique.

• CVE / CVSS / KEV CVE (Common Vulnerabilities and Exposures): the standardized identifier for a specific vulnerability. CVSS (Common Vulnerability Scoring System): a 0–10 severity score; 9.0+ is Critical. KEV (CISA's Known Exploited Vulnerabilities catalog): a list of vulnerabilities confirmed to be actively exploited in the wild, with mandatory patch deadlines for federal agencies under Binding Operational Directive 22-01.

This week's issue is sponsored by Tines

Move Past AI Hype to Build Secure Scalable Workflows

Hear how leaders at HubSpot, Asana, Jamf, ASOS and Riot Games are scaling AI and automation in real security and operations workflows. AI’s real impact doesn’t happen in isolation. It comes from experimentation and learning from teams already leading the way.

Join Workflow, Tines’ flagship virtual event streaming live from New York on May 6. Discover how teams are moving beyond AI paralysis, scaling automation responsibly, and building workflows that eliminate busywork.

Discover how teams are moving beyond AI paralysis, scaling automation responsibly, and reducing manual security and operational work.

Save your Spot

💡Our Insights from this Practitioner 🔍

1. The EDR Gap Is Structural, Not a Configuration Problem

One of the most practically useful points Brandon makes — and one that directly informs how you should interpret the attack patterns in this week's news — is that EDR's visibility gap is not a tuning problem or a missed rule. It is architectural. EDR was designed in an era when malware manipulated the file system. That design decision shapes what EDR can and cannot see:

"The adversary is now using the same software as the enterprise, and they're trying to look like an employee specifically, so they don't get detected. All we know is that Zoom's running. We don't understand why they gave remote control over and what they did after that happened." — Brandon Dixon, Co-founder, Ent.ai

This is not a theoretical gap. Brandon's incident response colleagues can confirm that Zoom remote control was activated — they know from SaaS logs — but they have no way to determine whether the resulting session was malicious or a legitimate help-desk handoff. That ambiguity is operationally disabling: you cannot act on an alert you cannot classify.

For cloud security architects, the practical implication is that any detection program that relies exclusively on process-level telemetry (EDR) and network-level telemetry (CASB/proxy) is structurally blind to the behavioral middle layer where the most consequential decisions are made. That middle layer — drag-and-drop, clipboard contents, UI interaction within an application, cross-app data movement — is precisely where AI adoption is creating new risk vectors.

2. Unsanctioned AI Inside Sanctioned Applications Is Your Next Undetectable HIPAA Violation

The WhatsApp/Meta AI example Brandon describes from a Fortune 500 deployment illustrates three converging risk trends simultaneously:

• AI is being embedded directly into sanctioned communication tools — WhatsApp, Zoom, Slack, Teams — without requiring a separate application install or any deliberate opt-in by the enterprise.

• Users are not being malicious. The HR employee who pasted patient records into Meta AI to get a summary was trying to do their job efficiently. The violation was unintentional — but it was still a HIPAA violation.

• Traditional DLP cannot catch it. As Brandon notes, DLP runs pattern-matching against content it can observe. If you drag a file rather than copy-paste, if the pattern doesn't match a defined regex, if the AI feature is embedded within encrypted application traffic — DLP misses it.

For CISOs currently building AI governance programs, this creates a classification problem that is not solvable through policy alone. You can enumerate the authorized AI tools in your AUP. You cannot enumerate every AI feature that will be silently added to every SaaS application your users rely on. WhatsApp embedded Meta AI. Microsoft embedded Copilot into Teams and Word. Google embedded Gemini into Workspace. The AI surface within sanctioned applications is growing faster than any policy review cycle can track.

3. Context-Aware Anomaly Detection: The Lessons of Failed UEBA Programs

Many senior security professionals carry institutional scar tissue from UEBA deployments that generated high false-positive rates and were eventually deprioritized or abandoned. Brandon's analysis of why those programs struggled is directly relevant to evaluating the next generation of behavioral detection platforms:

"Where those [UEBA systems] struggled is they simply tried to model independent variables or anomalies. Working late at night is potentially not a big deal, but working late at night and giving remote control of your system to someone else outside the business — well, you know, that's kind of odd. That context has historically been missing." — Brandon Dixon, Co-founder, Ent.ai

The distinction Brandon draws is between modeling independent behavioral variables (login time, geo-location, process list) versus modeling behavioral context — understanding what a user was doing immediately before, during, and after an action in order to evaluate whether the combination of behaviors constitutes risk. This is a fundamentally different technical approach from statistical anomaly detection, and it requires a different data source: behavioral telemetry captured at the endpoint in real time, not reconstructed from logs after the fact.

4. Endpoint Behavior as the Foundation for AI Agent Oversight

For cloud security leaders currently building AI governance frameworks, Brandon introduces a detection surface that most programs have not yet addressed: AI agents running locally on endpoints. As local model inference becomes more practical on modern hardware, AI agents that perform autonomous tasks — file access, web browsing, application control, code execution — are increasingly running at the endpoint level rather than exclusively in the cloud.

Brandon's approach at Ent.ai is to proxy that agent traffic at the endpoint layer, enabling visibility into the handoff between human instruction, AI execution, and the resulting system actions. This creates a detection capability that cloud-only monitoring misses entirely: you can observe what instruction the user gave the agent, what the agent did with it, and whether the resulting system interaction (file writes, process spawns, network calls) is consistent with the stated instruction and role-appropriate behavior.

For DevSecOps teams deploying AI coding assistants (GitHub Copilot, Cursor, Claude Code) and enterprise AI workflow tools, this framing suggests a near-term requirement: you need observability not just into which AI tools are authorized, but into what those tools do on the endpoint when they execute.

5. What to Actually Build First: Brandon's Program Guidance

When Ashish pressed Brandon on what a security leader should actually do before investing in behavioral detection tooling, his answer reframes the question in a way that is immediately actionable for senior practitioners:

"Do you actually understand who your risky users are? And more importantly, why are they risky? Because most people can't answer the question: what's actually happening in their business. They have these draconian policies that they draft... and it's only as good as its ability to enforce it at a control point. And the problem is, those policies are overly broad and the control points are not sufficiently deep, and they miss context." — Brandon Dixon, Co-founder, Ent.ai

The practical starting point this suggests for programs at different maturity levels:

• Foundational (no behavioral layer yet): Start by mapping your highest-risk user populations — finance, HR, legal, engineering with production access — and documenting what "normal" looks like for each role. This baseline work is necessary regardless of what tooling you adopt.

• Intermediate (EDR + CASB deployed): Identify the behavioral gaps between what your current stack can observe and what a risky action in each high-risk role actually looks like. The WhatsApp/Meta AI example is a useful test case — can your current stack catch it? If not, you have a documented gap to drive tooling requirements.

Advanced (evaluating next-generation behavioral detection): Evaluate platforms that provide real-time behavioral context at the endpoint — not just process telemetry or SaaS logs — with AI agent traffic visibility and cross-application behavioral correlation. Brandon's framing is that without the actual behavioral layer, even a data lake plus AI cannot reconstruct sufficient context to make informed decisions at the speed attacks now move.

📚 RELATED RESOURCES 🎧

• Ent.ai — Brandon Dixon's endpoint behavioral intelligence platform

•  CISA KEV Catalog  Known Exploited Vulnerabilities list including CVE-2026-1340 → CISA KEV Catalog

Podcast Episode

• Cloud Security Podcast -Full Episode with Brandon Dixon- Complete transcript and audio for this week's featured conversation

Question for you? (Reply to this email)

🤔   Can your current stack tell the difference between a user legitimately using an AI assistant and one leaking sensitive data through it — and if not, what's your first step to close that gap?

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: Identity Is the Only Scalable Control Plane (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 has spent the past 18 months debating shadow AI as a data governance problem. This week, that framing gets a hard reset.

Between Microsoft declaring that human-only defense is "no longer viable," a publicly disclosed Docker zero-day that AI coding agents can autonomously discover and exploit, and a Cisco breach traced to a compromised CI/CD pipeline the threat is no longer theoretical. The attack surface has fundamentally shifted to wherever your agents, workloads, and non-human identities operate.

To make sense of it, we spoke with Jasson Casey, Co-founder and CEO of Beyond Identity, one of the clearest thinkers on where identity security intersects with agentic AI risk. His argument, built from first principles, is that identity is not just one layer of your defense, it is the only control plane capable of managing the agentic threat model systematically. [Listen to the episode]

⚡ TL;DR for Busy Readers

• AI agents can now discover + exploit Docker container escapes autonomously (Docker CVE-2026-34040)

• Cisco was breached via a trusted CI/CD tool GitHub Actions (not direct attack)

• Microsoft confirms attack hand-off = 22 seconds → humans can’t keep up

• The real gap isn’t shadow AI — it’s uncontrolled non-human identity

• CrowdStrike's $1.16B bet on Identity + Browsers

📰 THIS WEEK'S TOP 4 SECURITY HEADLINES

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

 🚨 1. 🧬 AI Agents Can Exploit Docker - Autonomously

What Happened

Cyera Research Labs disclosed CVE-2026-34040 (CVSS 8.8)an incomplete fix for the 2024 perfect-10 vulnerability CVE-2024-41110. When an API request body exceeds 1 MB, Docker's middleware silently drops it before the AuthZ plugin inspects it, while the daemon processes the full payload and creates the requested container potentially with privileged access to the host filesystem. The attack requires one crafted HTTP request, no credentials, and no special tooling. Fixed in Docker Engine 29.3.1 (released March 25).

What elevates this beyond a standard container escape: Cyera demonstrated that AI coding agents running inside Docker-based sandboxes can be tricked into exploiting it via prompt injection hidden in a GitHub repository and, more alarmingly, can independently discover and construct the exploit themselves while attempting legitimate debugging tasks.

Why it matters: This is the first publicly documented case where an AI coding agent autonomously discovers and executes a container escape as a side-effect of a legitimate developer task. The blast radius extends from full host compromise to cloud credential theft, Kubernetes cluster takeover, and SSH access to production servers.

Immediate actions:

• Patch to Docker Engine 29.3.1: verify with docker version --format '{{.Server.Version}}'

• Check whether AuthZ plugins are in use: docker info --format '{{.Plugins.Authorization}}'

• Scope Docker API access aggressively; enforce rootless mode where possible

• Treat AI agent access to the Docker socket as a privileged identity requiring governance, not a developer convenience

Sources: Cyera Research | The Hacker News | eSecurity Planet

🚨 2. 💣 Cisco Breached via CI/CD Supply Chain

What Happened

Attackers exploited a compromised GitHub Action linked to the Trivy vulnerability scanner, stealing CI/CD credentials and breaching Cisco's internal development environment. Over 300 repositories and AWS keys were accessed.

Why it matters: This is a textbook example of transitive trust failure in the CI/CD pipeline and it is becoming the dominant pattern for cloud infrastructure compromise. The attacker did not breach Cisco directly; they breached a tool that Cisco trusted. For cloud security leaders, this reinforces three non-negotiable controls: enforce short-lived credentials and workload identity (no static keys, ever); implement artifact integrity validation using SLSA and Sigstore; and extend your monitoring posture to detect pipeline-level anomalies, not just runtime threats. The Cisco breach also illustrates why Jasson Casey's point about identity as the systematic answer resonates if every workload, tool, and pipeline step had device-bound, attributable identity, the blast radius of a compromised GitHub Action would be dramatically contained.

Sources: Dark Reading | BleepingComputer

☁️ 3. ⚡ Microsoft: Human-Only Defense Is Dead

What Happened

Microsoft's Security Blog, published April 2 from RSAC 2026, reveals that AI is no longer just a tool for attackers it now accelerates every phase of the kill chain from reconnaissance to persistence. Microsoft's Threat Intelligence team introduced the "agentic threat model" as the new defensive paradigm, citing Tycoon2FA (linked to Storm-1747), which generated tens of millions of phishing emails monthly and compromised roughly 100,000 organizations. Mandiant's M-Trends 2026 report documented attacker hand-off time collapsing to just 22 seconds. Microsoft declared human-only defense is no longer viable.

Why it matters: This isn't a vendor positioning statement, it's a structural shift in the threat model that should directly inform SOC staffing strategy, tool investment, and AI security governance. The 22-second hand-off figure means that detection-to-containment workflows built around human review cycles are architecturally insufficient. Security leaders building 2026 roadmaps need to factor agentic playbooks and AI-assisted response into their operating model, not as aspirational initiatives, but as baseline requirements. This directly reinforces the conversation with Jasson Casey this week about why security teams not adopting agentic workflows are already behind.

Sources: Microsoft Security Blog | Mandiant M-Trends 2026 | SiliconANGLE

🏥 4. 🧠 CrowdStrike Bets $1.16B on Identity + Browser

What Happened

CrowdStrike's two Q1 mega-dealsSGNL ($740M, continuous identity authorization) and Seraphic Security ($420M, enterprise browser protection)closed this month, representing $1.16B in combined spend and the platform's most significant capability expansion since the Humio acquisition. SGNL replaces static RBAC with real-time, context-aware authorization decisions for every API call, SaaS session, and AI workload. Seraphic adds a browser-native agent to Falcon, targeting the exploding threat surface created by browser-based SaaS access and AI coding assistants.

Why it matters: For enterprise buyers already on Falcon, this is a consolidation forcing function. SGNL's continuous authorization capability directly addresses AI non-human identity risk gap that most identity programs currently leave wide open. Seraphic's approach of instrumenting the browser runtime (rather than deploying a proxy) produces richer telemetry and lower latency, which matters for high-frequency SaaS and developer workflows. Expect Palo Alto, Microsoft, and SentinelOne to respond with counter-positioning. Security architects should revisit their CrowdStrike roadmap conversations now, but with realistic expectations: integration lags are real, and buying into a new module 6–9 months post-close carries meaningful integration risk. This acquisition also validates exactly what Jasson Casey describes this week that continuous, data-plane identity enforcement is becoming the core of the modern security stack.

Sources: BankInfoSecurity | CSO Online | GlobeNewswire

🛠️ WHAT YOU SHOULD DO THIS WEEK

Immediate actions:

• Patch Docker → 29.3.1

• Treat AI agents as privileged identities (not tools)

• Kill static credentials in CI/CD → move to workload identity

• Add runtime visibility for tool execution

• Audit which tools your agents can call

🎯 Cloud Security Topic of the Week:

Why Identity Is the Only Systematic Answer to the Agentic Threat Model

The conversation this week with Jasson Casey surfaces a problem that most enterprise security programs have not yet structurally addressed: AI agents are not users, not services, and not endpoints in the traditional sense but they behave like all three simultaneously. That gap is precisely where adversaries are beginning to operate.

The agentic threat model is not a future concern. It is happening in your developer workflows right now, on managed machines, unmanaged machines, and contractor devices alike. And the controls that most organizations have network controls, DLP, SIEM, EDR were not designed with this operating model in mind. The question is no longer whether you have an AI security gap. It is whether you have a systematic way to close it.

Featured Experts This Week 🎤

• Jasson Casey - Co-founder & CEO, Beyond Identity

• 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:

• Non-Human Identity (NHI): Machine identities associated with workloads, agents, scripts, and services rather than human users. AI coding agents create a new and particularly complex category of NHI because they operate autonomously, call tools, access credentials, and make decisions without direct human supervision at the moment of action.

• Device-Bound Identity: An authentication credential cryptographically tied to the physical device hardware, making it non-exportable and non-phishable. Unlike session tokens or API keys, device-bound credentials cannot be stolen and replayed from a different machine.

• Prompt Injection: An attack technique where malicious instructions are embedded in content that an AI agent will process through tool outputs, file contents, web pages, or API responses causing the agent to take actions that were not intended by the user or operator. Jasson Casey notes that prompt injection does not have to happen all at once; it can be staged across multiple tool calls, leveraging how transformers associate related context.

• Living Off the Land (LoTL): An attack technique where adversaries use legitimate system tools and processes already present on a target to conduct malicious activity, avoiding the need to introduce new malware. Casey draws a direct parallel between this and AI agent tool execution, every tool call is a potential LoTL vector.

This week's issue is sponsored by Tines

Move Past AI Hype to Build Secure Scalable Workflows

Hear how leaders at HubSpot, Asana, Jamf, ASOS and Riot Games are scaling AI and automation in real security and operations workflows. AI’s real impact doesn’t happen in isolation. It comes from experimentation and learning from teams already leading the way.

Join Workflow, Tines’ flagship virtual event streaming live from New York on May 6. Discover how teams are moving beyond AI paralysis, scaling automation responsibly, and building workflows that eliminate busywork.

Discover how teams are moving beyond AI paralysis, scaling automation responsibly, and reducing manual security and operational work.

Save your Spot

💡Our Insights from this Practitioner 🔍

The Shadow AI Framing Is Costing You Time You Don't Have

Organizations are spending enormous cycles trying to enumerate and govern unauthorized AI tool usage shadow AI discovery products are already advertising in airport terminals, as Casey noted. But shadow AI governance is, at best, a starting point. It answers the "what do we have" question. It does not answer the "how do we systematically secure it" question.

As Casey put it: "Shadow AI is kind of the way of getting the conversation started. A lot of organizations are kind of thinking about, well, let's just number one figure out what we have. And that's a great way to start because again, like without identify, you can't really run the other CSF functions. But I would argue it is just the tip of the iceberg."

The real problem is not that employees are using AI tools without permission. The real problem is that those AI tools, code assistants, agents, browser plugins are running on machines with access to your intellectual property, your credentials, and your production infrastructure, with no systematic visibility into what they are doing at the tool execution level.

Every Tool Call Is a Security Event

This is the conceptual shift that most security programs have not yet made. When a developer runs Claude Code or Cursor on their laptop, the AI model is not the risk surface the tools the model calls are. Every tool execution is a potential data exfiltration event. Every tool result is a potential prompt injection vector. And because modern agents have memory and can compact context across sessions, a prompt injection can be staged across multiple tool calls over an extended period functioning, as Casey describes, like malware persistence.

"Every time your agent executes a tool, it's a chance for proprietary information to basically be exfil. It's a chance for maybe that tool, if it's not actually authorized or maybe even malicious, to send C2 commands back to the agent. And the agent, just like Ron Burgundy, will happily do whatever's on the teleprompter."

The Docker CVE-2026-34040 disclosure this week makes this concrete: an AI coding agent, pursuing a legitimate debugging task, can now autonomously discover and execute a container escape. This is not a hypothetical. It is a documented proof of concept.

Control Plane Identity Is Not EnoughYou Need Data Plane Enforcement

Most enterprise identity programs operate at the control plane: IAM, SSO, MFA, user lifecycle management. These controls answer the question "who is this user?" at the moment of authentication. They do not answer the question "what is this workload doing right now, and should it be allowed to continue?"

Casey's argument is direct: "It's not enough to only be in the control plane. You have to also be in the data plane. Otherwise you cannot be a point of enforcement. And we think code assistant agents, specifically AI agents in general, are kind of the forcing function for that."

The practical implication for enterprise security architects is significant. The security stack you have todaySIEM, EDR, IAMwas designed around a human-centric, session-based model of access. AI agents operate continuously, autonomously, and across multiple systems simultaneously. Retrofitting human-oriented identity controls onto agentic workloads is not a solution; it is a temporary mitigation at best.

What the new model requires is device-bound identity for every workload including the AI agent itself so that every tool call, every API interaction, and every data access is attributable to a specific, verified identity. This gives you the chain of provenance needed to detect anomalies, respond to incidents, and reason about blast radius.

The Systematic Answer: Identity as the Security Architecture Core

Rather than choosing between blocking all AI usage and accepting all AI risk the "barbell" that both Casey and Ashish Rajan observe across their customer baseCasey's framework offers a third path: a lightweight, identity-anchored security context that wraps the agent at launch, monitors its behavior continuously, and kills the session when risk thresholds are crossed.

This approach addresses multiple problems simultaneously:

Credential theft and session hijacking are eliminated when agent credentials are device-bound and non-exportable. The Reddit story Casey references an $80,000 Anthropic API bill after a key was compromised becomes structurally impossible when keys cannot be stolen and replayed.

Prompt injection management becomes tractable when every tool and every agent has an attributed identity, creating a chain of provenance across the entire interaction. You may not be able to prevent every prompt injection attempt, but you can detect when an agent's behavior deviates from expected patterns and terminate the session.

Discovery the first function of the NIST CSF becomes automated rather than manual, because the identity system that launches the agent also inventories the tools, MCP connections, plugins, sub-agents, and local permissions it has access to.

Agentic Security Playbooks Are Not Optional

For SOC teams and detection engineers, Casey's message is direct: if your security team is not building agentic playbooks now, you are already behind. The model he describes is not simply "use AI in your SOC." It is a specific architectural pattern: decompose your security workflows into probabilistic nodes (where LLM judgment is appropriate) and deterministic nodes (where a script executes with perfect fidelity). Connect them deliberately.

"If your security teams aren't building this out already number one, they're getting behind. Number two, you can use that for controls verification, controls research, detection playbooks, actual detection. It's actually really, really good at prototyping."

Casey's own team demonstrated this in practice: in four hours, using open-source models from Hugging Face, they built a real-time audio impersonation capability capable of producing convincing voicemails from just seven seconds of audio sampling with zero-shot training and no fine-tuning. The point is not that this specific capability is the threat. The point is that your adversaries have access to the same tools, the same models, and the same four-hour build timeline. The security teams who have internalized this reality are building defenses that match it. The ones who haven't are waiting to be surprised.

Architecture Is the Forcing Function

One of the most practically useful frames from Casey's conversation is the question he poses about enterprise architecture: if you were starting your business today, what would you actually need? GitHub for code. Claude Code or Codex for AI-native development. Email. What else is genuinely necessary, versus a legacy of tools acquired when those were the only options available?

This is not an argument for reckless consolidation. It is an argument for honest architectural review specifically, for identifying which elements of your current security stack were designed for a human-centric, session-based threat model and which can genuinely extend to cover agentic workloads. Casey's view is that the simplifying architecture for the new stack places identity at the core, with SIEM and EDR retaining their value for behavioral analytics and data collection, but many workflow-centric SaaS products becoming candidates for replacement by AI-native alternatives.

For security leaders building 2026 roadmaps, this conversation is a prompt to ask: what in my current architecture assumes a human is making every decision? And what happens to those assumptions when the answer is increasingly no?

📚 RELATED RESOURCES 🎧

• Beyond Identity Ceros Product (Free Trial) - The product Jasson Casey references for AI agent identity and secure context management

• NIST AI Risk Management Framework (AI RMF) - Foundational framework for governing AI systems in enterprise environments

• CISA Guidance on AI-Enabled Threats - Federal guidance on securing AI systems and defending against AI-enhanced attacks

• SigstoreSoftware Supply Chain Signing - Open-source tooling for artifact integrity, directly relevant to CI/CD pipeline defense

• SLSA Framework - Supply chain integrity levels for software artifacts

• Microsoft Security BlogRSAC 2026 Coverage - Primary source for the agentic threat model and Mandiant M-Trends 2026 data

• Cyera Research CVE-2026-34040 Disclosure - Technical details on the Docker AuthZ bypass and AI agent exploitation proof of concept

Podcast Episode

• Cloud Security Podcast -Full Episode with Jasson Casey - Complete transcript and audio for this week's featured conversation

Question for you? (Reply to this email)

🤔   If your AI agents had identities today, what’s the first behavior you’d monitor?

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: AppSec in the AI Era: Why Your 2026 Program Is Already Broken and What to Build Instead (continue reading) 

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 week of March 25–31, 2026 will be remembered as a watershed moment for cloud-native supply chain security. In the span of nine days, a single threat actor group weaponized four of the most trusted tools in the DevSecOps ecosystem turning a security scanner, an AI proxy, a telephony SDK, and a ubiquitous JavaScript HTTP client into credential harvesting machines targeting the AWS IAM keys, GCP service accounts, and Kubernetes secrets of thousands of enterprise pipelines worldwide.

What makes this week's news especially instructive is its timing: it arrives just as two of the most experienced voices in enterprise security, Joe Sullivan, former CSO of Cloudflare, Facebook, and Uber, and Scott Gerlach, co-founder and CSO of StackHawk, sat down to share their unfiltered views on how Application Security must fundamentally reinvent itself for the AI era.

Their conversation cuts to the heart of why this week's attacks succeeded: security teams that are reactive, tool-dependent without context, and not embedded in the engineering loop are now structurally exposed. The fix is neither simple nor quick, but the blueprint is clearer than it has ever been. [Listen to the episode]

⚡ TL;DR for Busy Readers

• The TeamPCP supply chain campaign compromised Trivy, LiteLLM, Telnyx, and 100M+ download Axios to rotate all CI/CD secrets from March 19–31 now.

• Citrix NetScaler CVE-2026-3055 (CVSS 9.3) is actively exploited to patch SAML IDP-configured appliances before your next maintenance window.

• Google Vertex AI agents inherit dangerously broad IAM permissions by default and adopt BYOSA architecture for every agentic workload immediately.

• AI is 10x-ing code velocity and vulnerability volume simultaneouslyAppSec must embed in the engineering loop, not review from the outside.

• The CISO role is expanding to own AI transformation, curiosity, adaptability, and business enablement are now core job requirements.

📰 THIS WEEK'S TOP 5 SECURITY HEADLINES

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

 🚨 1. TeamPCP's Cascading Supply Chain Campaign Pivots to Ransomware After Breaching Five Ecosystems

What Happened

Between March 19–27, the financially motivated threat group TeamPCP (also tracked as PCPcat, ShellForce, and CipherForce) executed a cascading software supply chain attack across five developer ecosystems: GitHub Actions, Docker Hub, npm, PyPI, and OpenVSX. The attack chain opened with the group force-pushing malicious code to 76 of 77 version tags of Aqua Security's Trivy container scanner exploiting an unsanitized GitHub Actions workflow to harvest credentials from thousands of CI/CD pipelines. Using those stolen credentials, TeamPCP sequentially compromised Checkmarx KICS IDE extensions, the LiteLLM AI proxy package (~480M PyPI downloads), and the Telnyx Python SDK. A credential-stealing payload tracked as CVE-2026-33634 (CVSS 9.4) was purpose-built to exfiltrate AWS IAM keys, GCP service account credentials, Azure environment variables, and Kubernetes secrets. As of March 30, TeamPCP has paused new supply chain compromises and announced a ransomware partnership with the new Vect RaaS operation with at least one confirmed Vect ransomware deployment using TeamPCP-harvested credentials.

Why It Matters

This is the most consequential DevSecOps supply chain attack since XZ Utils, and it carries a threat profile specific to cloud and AI infrastructure teams. Three aspects demand immediate attention.

First, the attack deliberately weaponized security tooling. Trivy and Checkmarx KICS are not peripheral dependencies they are tools granted elevated pipeline access by design. Any organization that ran these tools between March 19–27 without pinning to verify commit SHAs should treat its CI/CD credentials as fully compromised. Microsoft Defender for Cloud confirmed the core attack chain harvested AWS IAM, GCP, and Azure environment variables alongside Kubernetes secret enumeration across affected runners.

Second, the LiteLLM compromise represents a novel AI infrastructure attack vector. LiteLLM functions as a unified gateway to over 100 LLM APIsOpenAI, Anthropic, AWS Bedrock, Vertex AI meaning a single compromised instance exposes every AI provider credential the organization holds.

Third, the pivot to ransomware monetization signals the attack is far from over. TeamPCP is estimated to hold a 300GB trove of harvested credentials. Breach disclosures and extortion attempts are expected to increase through Q2 2026.

Recommended Actions: Immediately rotate all secrets accessible to pipeline runners that executed Trivy, Checkmarx KICS, or LiteLLM between March 19–27. Pin all GitHub Actions to full commit SHAs. Audit runner logs for outbound connections to checkmarx[.]zone, models.litellm[.]cloud, or tpcp.tar.gz archives. Treat low-impact credential alerts from this period as high-priority indicators of impending secondary intrusion.

Sources: SANS Institute | Datadog Security Labs | Akamai | Infosecurity Magazine

🚨 2. Axios npm Hijack: North Korean-Attributed RAT Hits 100M+ Weekly Downloads

What Happened

An unknown attacker compromised the GitHub and npm accounts of the main developer of Axios, a widely used HTTP client library, and published npm packages backdoored with a malicious dependency that triggered the installation of droppers and remote access trojans. The attack was pre-staged approximately 18 hours before detonation. The malicious versions (axios@1.14.1 and axios@0.30.4) were live for roughly three hours before removal on March 31. On April 1, 2026, Google Threat Intelligence Group publicly attributed the compromise to UNC1069, a North Korea-nexus, financially motivated threat actor, based on infrastructure overlaps and the use of WAVESHAPER.V2an updated backdoor linked to the group's earlier activity. Although the malicious versions were removed within hours, Axios's presence in roughly 80% of cloud and code environments enabled rapid exposure, with observed execution in 3% of affected environments according to Wiz researchers.

Why It Matters

This is arguably the highest blast-radius npm compromise on record. The attack surface is your vendor's vendor's vendor and this is what that looks like in practice. Organizations that had lockfiles pinning Axios to a specific version, or CI/CD policies that suppress automatic install scripts, were protected. Organizations that did not have a window of exposure measured in hours, with consequences that may take weeks to fully assess. The North Korean attribution connects this to a broader pattern of DPRK-linked actors targeting developer supply chains to harvest credentials and establish persistent access in cloud environments. The convergence with TeamPCP activity itself linked to LAPSUS$ extortion suggests a coordinated effort to stockpile access across enterprise environments.

Immediate Actions: Downgrade to axios@1.14.0 (or @0.30.3 for legacy users). Rotate all cloud keys, repository tokens, and API credentials exposed in affected environments. Check for outbound connections to sfrclak.com:8000. Inspect CI/CD pipeline logs for the exposure window: 00:21–03:15 UTC, March 31, 2026.

Sources: The Hacker News | StepSecurity | Huntress | SANS Institute

☁️ 3. Google Vertex AI "Double Agent" Flaw: AI Platform Permissions Create Cloud-Wide Exposure

What Happened

Palo Alto Networks Unit 42 disclosed a structural "blind spot" in Google Cloud's Vertex AI platform: the Per-Project, Per-Product Service Agent (P4SA) associated with AI agents deployed via the Agent Development Kit (ADK) carries dangerously broad permissions by default. An attacker can craft a malicious AI agent as a serialized Python pickle file, deploy it on Vertex AI's Reasoning Engine, query Google's metadata service to extract P4SA credentials, then break out of the isolated agent environment and operate as a highly privileged service account gaining unrestricted read access to all GCS buckets and restricted Artifact Registry repositories in the project. Google has addressed the issue by revising its documentation and now strongly recommends a Bring Your Own Service Account (BYOSA) architecture for all Vertex AI deployments.

Why It Matters

This research surfaces a structural risk that will only grow as enterprises accelerate agentic AI deployments. AI agents are service identities with real permissions; they must be governed through your existing IAM framework, not treated as "just an app." The attack chain requires no zero-day: it abuses default configuration. Every organization running Vertex AI Agent Engine workloads should immediately audit P4SA permission scopes, move to BYOSA architectures, and apply IAM least-privilege review cycles before any agentic workload reaches production. The broader principle surfaced directly in this week's guest conversation is that non-deterministic AI code operating with overprivileged identities is the defining runtime security risk of 2026.

Sources: The Hacker News | Unit 42 / Palo Alto Networks | SecurityWeek

🏥 4. LAPSUS$ Claims AstraZeneca Breach: Cloud Configs, Source Code, and CI/CD Secrets for Sale

What Happened

LAPSUS$ claimed responsibility for an alleged breach of AstraZeneca, posting on their Tor-based leak site and dark web forums. The group asserts they exfiltrated approximately 3GB of internal data including source code (Java, Angular, Python), cloud infrastructure configurations (AWS, Azure, Terraform), employee records, and access credentials including private RSA keys, vault data, and GitHub Enterprise tokens. On March 27, LAPSUS$ released sample data and added health data company Virta Health to their target list. AstraZeneca has not issued a public statement. Attribution in cybercrime forums is inherently unverified.

Why It Matters

The healthcare and life sciences sector has become a primary target for data extortion, and this incident illustrates why cloud infrastructure configurationsnot source codeare the true crown jewel. If verified, the inclusion of Terraform files, AWS/Azure configs, and CI/CD secrets gives adversaries a complete blueprint of the cloud environment and the keys to access it. LAPSUS$ is evolving from public-shame extortion toward quiet data brokerage offering full datasets to vetted buyers rather than dumping them publicly. This shift demands more proactive dark-web monitoring and rapid takedown incident-response playbooks for situations where IaC configs and secrets appear for sale.

Sources: Cybernews | SecurityWeek | SOCRadar

🛡️ 5. Google Workspace Deploys AI-Powered Ransomware Detection at GAEnabled by Default

What Happened

Google moved its ransomware detection and file restoration features for Google Drive into General Availability on March 31, 2026. The updated AI model detects 14× more infections than the beta version, automatically pauses Drive file syncing upon detection, sends real-time alerts to users and admins via the Admin console Security Center, and enables bulk file restoration to pre-infection versions. Both features are enabled by default across Business, Enterprise, Education, and Frontline plans. Drive for Desktop v114 or later is required for full alert functionality on endpoints.

Why It Matters

This is a meaningful defensive capability at SaaS scale: automatic detection, sync interruption, and bulk file restoration without requiring a SIEM alert or analyst intervention. The operational priority is immediate: validate Drive for Desktop v114+ deployment coverage across your endpoint estate via MDM, verify admin alerting is configured in the Admin console Security Center, and confirm which OUs have the feature enabled. This is now table-stakes capability alongside Microsoft OneDrive's equivalent ransomware protection for Microsoft 365 subscribers.

Sources: Google Workspace Updates Blog | BleepingComputer

🎯 Cloud Security Topic of the Week:

AppSec in the AI Era: Why Your 2026 Program Is Already Broken and What to Build Instead

If there is a single thread connecting every story in this week's news brief and the most important insight from Joe Sullivan and Scott Gerlach's conversation is this: the security practices that felt adequate eighteen months ago are structurally insufficient for the speed and scale at which code is now being produced.

The TeamPCP and Axios supply chain attacks did not succeed because of exotic zero-days. They succeeded because developer tooling runs with elevated privileges in CI/CD pipelines, those pipelines assume everything upstream is trusted, and security teams have historically reviewed artifacts after the fact rather than validating the supply chain in motion. The attacks exploited the gap between how fast modern development moves and how slowly security has adapted to that velocity.

Joe Sullivan and Scott Gerlach spent a significant portion of their conversation mapping exactly this gap and what it will take to close it.

Featured Experts This Week 🎤

• Joe Sullivan - Security Consultant & CEO of Ukraine Friends | Former CSO of Cloudflare, Uber, and Facebook | Former Federal Cybercrime Prosecutor, US Department of Justice

• Scott Gerlach - Co-founder & Chief Security Officer, StackHawk | Former CSO at Stride 

• 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:

• DAST (Dynamic Application Security Testing): Security testing of running applications testing behavior, not just source code. Unlike SAST (Static Analysis), DAST reflects how the application actually behaves under attack conditions, dramatically reducing false positives.

• Legacy DAST vs. Modern DAST: Legacy DAST tests known, publicly facing production assets on a quarterly or annual cadence generating high false positive rates due to WAFs, CDNs, and incomplete coverage. Modern DAST tests every microservice, every PR/MR, 5–10 times per day in the pre-production environment, with near-zero false positives and developer-attributed findings.

• BYOSA (Bring Your Own Service Account): Google's recommended architecture for Vertex AI deployments, in which each AI agent is assigned a customer-managed service account with scoped, least-privilege permissions rather than inheriting the default P4SA with its dangerously broad default access.

• P4SA (Per-Project, Per-Product Service Agent): The default privileged identity automatically assigned to AI agents deployed on Google Cloud's Vertex AI platform. Unit 42 demonstrated that P4SA credentials can be extracted and abused to gain unrestricted access to GCS buckets, Artifact Registry, and Google Workspace data.

• Supply Chain Attack: A cyberattack that compromises software, tooling, or dependencies upstream of the target reaching downstream victims automatically when they install or update the poisoned component.

This week's issue is sponsored by Varonis

AI Security Requires More Than Visibility. It Requires Control. 

Security leaders are under pressure to enable AI innovation while managing a rapidly expanding attack surface across cloud, identity, and data layers. AI agents and copilots can introduce new access paths, automated high-impact actions, and accelerate threat timelines. 

Varonis Atlas helps organizations secure AI end-to-end - from understanding usage and enforcing guardrails to detecting suspicious activity and reducing risk dynamically. Join our upcoming webinar to learn how Varonis Atlas can help security teams operationalize AI security at scale. 

💡Our Insights from this Practitioner 🔍

The AI Development Tidal Wave Has Outpaced Every AppSec Program Built Before 2026

Scott Gerlach opens the conversation with a statement that every security leader should internalize: "Before, I would say even the end of last year, the AppSec programs were really still kind of reactive and just trying to keep up as best they could. And then AI gets down and everyone's like, wow, we're way behind now."Scott Gerlach

This is not a theoretical concern, it is the structural reality that allowed the TeamPCP campaign to succeed. Developers using AI-assisted coding tools are generating code at a pace that far outstrips the traditional security review cadence. When a security team is still triaging tickets from the last sprint while this sprint's code has already shipped, they are not operating a security program, they are operating an audit log.

The 10x Vulnerability Problem and Why Tickets Are the Wrong Unit of Work

Joe Sullivan adds precision to Gerlach's observation with a point that should reframe how every AppSec team measures its own effectiveness: "The volume of code that they're sending over to security is 10 Xing. And unfortunately, the vulnerability volume is 10 Xing as well. And so if we're not careful, we're gonna be pushing back at them 10 x the volume of issues. And we were already in trouble for pushing back too much at them."Joe Sullivan

Gerlach's framing of the ticket-centric model as the telltale sign of an immature program cuts to the same point: "If you're making tickets, it's probably not mature enough."Scott Gerlach

Tickets are a batched, asynchronous communication channel. Supply chain attacks, exploited zero-days, and AI-generated vulnerabilities operate on a real-time, continuous basis. The mismatch is not recoverable through better ticket prioritization it requires a fundamentally different testing architecture.

Legacy DAST vs. Modern DAST: The Architecture Decision That Determines Your Blast Radius

Gerlach's distinction between legacy and modern DAST is one of the most practically actionable frameworks in this week's conversation and it maps directly onto the supply chain risk profile of TeamPCP.

Legacy DAST tests known, public-facing production applications from outside the network perimeter, through WAFs and CDNs that generate false signals. The result: 90% false positive rates, sparse coverage, and findings that arrive too late. Modern DAST runs 5–10 times per day, tests every micro service and API as it moves through the CI/CD pipeline, runs inside the development environment, and delivers findings directly to the developer who introduced the change at the moment they can actually fix it. "We just talked to a customer the other day who was talking about their DAST program. They're switching out they had like a 90% false positive rate. And when they test with Stack Hawk able to test closer to the thing you're testing, have more of a white box, gray box it's 90% true positive rate versus 90% false positive rate."Scott Gerlach

The operational implication is direct: organizations with security testing embedded inside their CI/CD pipelines have detection opportunities for compromised tooling that legacy scanning from outside production simply cannot provide.

AI Agents in the Development Loop: Opportunity, Risk, and the Identity Model Problem

Gerlach describes the ideal agentic state: Claude Code or Cursor, having written a new feature, automatically triggers a DAST scan against the running application, consumes the findings, and fixes them all within the same agent loop, before a human even reviews the PR. "When Claude Code is done writing its feature that you ask it to write and it goesI see a hook for, I should run the app, run StackHawk against the app, and then consume the findings from that and fix them as part of the Claude Code loop. Now you're actually getting real security work into that and not burdening the developer with what is this ticket, where does this live."Scott Gerlach

But Sullivan immediately surfaces the counterweight and it maps precisely onto the Vertex AI "Double Agent" vulnerability disclosed this week: "A year from now, companies are gonna say, all right, we let you all run AI for a year, and you burn hundreds of thousands, if not millions of dollars on tokens. Can we get back to some deterministic software solution?"Joe Sullivan

Gerlach captures the identity model risk that connects both threads: "When you're rolling those things out, thinking about the identity model and the security model that it inherits from you and you're like, wait a second, I don't want it to have this much access. How can I limit that access? And then what does that do for the enterprise? What does that scale?"Scott Gerlach

The CISO's Expanding Mandate: From Security Gatekeeper to AI Transformation Lead

"In 2026, the CEO is turning to IT and saying, I want you to lead the AI transformation for the company. And that person is the security leader too. So we have more responsibility and we have more interaction with the CEO. And that's not gonna go backwards."Joe Sullivan

For cloud security professionals, the implication is not abstract: if your CEO is asking the head of security to be the AI governance and transformation lead, the skills you invested in securing cloud-native infrastructure need to extend to governing non-deterministic, agentic systems that, as the Vertex AI research demonstrates, can become inside threats when misconfigured.

What the Next-Generation Security Team Looks Like

Gerlach names the anti-pattern explicitly: "The people that have to have well-defined procedures and they wanna stay in the box, that's probably the anti-pattern for the next-gen security team."Scott Gerlach

Sullivan's prescription is equally directcuriosity is now a core security competency: "If you're not excited about AI and digging in and playing around with the new things, how are you going to keep up with the product and engineering teams? We can't fall for that sunk cost fallacy. We can't be resistant to change at this time. We have to be in discovery mode."Joe Sullivan

Security teams that embed themselves in engineering conversations about AI tooling adoptionnot auditing from outside after the fact will be in a structurally better position six months from now.

Practical Takeaways for Cloud Security Leaders

• Embed AppSec in the engineering loop not after it. If your team is still receiving code and generating tickets, you are operating legacy AppSec. Start conversations with engineering about where security testing can run inside the CI/CD pipeline itself.

• Shift from false positive tolerance to true positive precision. A 90% false positive rate is a testing architecture problem, not a signal problem. Test inside the development environment to eliminate WAF and CDN interference.

• Treat AI agents as service identities, not applications. Apply your IAM governance framework to every agentic workload before production deployment. Default permissions are almost always too broad. BYOSA on Vertex AI; scoped service accounts everywhere else.

• Audit your CI/CD supply chain assumptions today. Pin GitHub Actions to full commit SHAs, not floating tags. Assume any runner that executed Trivy, LiteLLM, Telnyx, or Axios between March 19–31 is compromised until proven otherwise.

Position security as a business enabler for AI transformation. CISOs who approach AI as purely a risk management exercise will be sidelined. Those who help engineering teams ship AI features securely and at speed will own one of the most important mandates in their organization.

📚 RELATED RESOURCES 🎧

AppSec & DevSecOps Guidance

• StackHawk: Modern DAST for DevSecOps Teams

• OWASP: Software Component Verification Standard (SCVS) for Supply Chain Security

• CISA: Known Exploited Vulnerabilities Catalog

• StepSecurity: Harden-RunnerFree CI/CD Pipeline Security Tool

Podcast Episode

• Cloud Security Podcast   Episode with Scott & Joe

Question for you? (Reply to this email)

🤔   Is your AppSec team embedded inside the engineering AI loop or are they still reviewing tickets after the code ships?

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: Governing AI Agents as Federated Developers: The New Identity and Access Frontier (continue reading) 

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 velocity of change inside AI-first engineering organizations is no longer a competitive talking point; it is a security crisis hiding in plain sight. When a single developer can generate and deploy more code in a day than an entire team could in a week, every assumption your AppSec program was built on needs to be re-examined.

This week we sit down with Igor Andriushchenko, Head of Security at Lovable, one of Europe's fastest-growing AI-native companies (the platform that lets anyone build fully functional web apps without writing a line of code). Igor joined when Lovable had 40 employees; six months later it had grown to 150+. He brings a rare vantage point: operating security at the bleeding edge of the agentic AI revolution, at a company where developers are not just using AI tools, they are building AI-native products at scale. Hosted by Ashish Rajan of the Cloud Security Podcast and AI Security Podcast, this conversation maps exactly what enterprise security leaders need to rethink now before the volume of AI-driven change overwhelms their existing controls.

We also cover the week's most critical news, including the Stryker cyberattack, a claimed 100GB breach at Crunchyroll, Mandiant's M-Trends 2026 cloud findings, and the AI-powered supply chain threat campaigns that are directly relevant to every organization adopting agentic developer tooling. [Listen to the episode]

⚡ TL;DR for Busy Readers

• AI-generated code is producing 100× the change velocity your SAST, DAST, and SCA pipelines are already load-failing; retool now.

• Treat AI agents like federated developers: they inherit every credential and permission their human operator holds, apply PAM, least privilege, and human-in-the-loop escalation for privileged actions.

• AI hallucinated supply chain risk is real: LLMs recommend abandoned or phantom packages; layer AI-native SCA with dependency pinning and registry controls.

• Mandiant M-Trends 2026: voice phishing (23%) and SaaS token theft are your top cloud initial-access vectors not exploits (only 6%). Rethink your detection priorities.

• The winning AI adoption play is not top-down mandate; it is building the internal skills, MCP server ecosystem, and data connections that make AI genuinely useful to security teams in their actual daily work.

📰 THIS WEEK'S TOP 4 SECURITY HEADLINES

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

1. Healthcare Giant Stryker Hit by Cyberattack

📰 What Happened: Medical technology leader Stryker confirmed it suffered a cyberattack, with containment measures underway and external forensic incident response firms engaged. Investigations are ongoing and the full scope has not yet been disclosed.

🔍 Why It Matters: Healthcare remains the highest-value target in critical infrastructure, not only for ransomware groups but for nation-state actors interested in supply chain leverage. Stryker's sprawling ecosystem of connected medical devices, SaaS platforms, and vendor integrations exemplifies the modern enterprise attack surface, one where a compromise upstream can cascade into clinical environments. This incident is a sharp reminder that IT/OT convergence risk is no longer theoretical: segmentation gaps between cloud workloads, operational technology, and SaaS-connected clinical systems are actively being exploited.

✅ Key Actions:

• Validate third-party access controls enforce ZTNA and least-privilege for all vendor and partner integrations.

• Harden segmentation between IT, OT, and cloud workloads; assume lateral movement paths exist until tested.

• Exercise your ransomware response playbook across hybrid environments, including cloud failover and clinical backup systems.

🔗 Source: BleepingComputer / Stryker Incident Coverage 

2. $120M Funding Round for Agentic Access Management Signals the NHI Security Era Has Arrived

What Happened: On March 19, 2026, Oasis Security announced $120 million in Series B funding led by Craft Ventures, with participation from Sequoia Capital and Accel, bringing total funding to $195 million. The round reflects the rise of AI agents becoming embedded across enterprise infrastructure.Over the past year, Oasis has seen new ARR growing 5x year over year, with a majority of its client base coming from the Fortune 500.

Why It Matters: Machine identities now outnumber humans 82:1. The systems designed to govern access were built for people, not autonomous systems. The Oasis round is venture capital confirming what CISOs are already experiencing: AI agents with cloud permissions are the fastest-growing and least-governed identity class in enterprise environments today.

The Trivy supply chain attack this week — where stolen CI/CD secrets included AWS IAM keys, GCP service accounts, and Kubernetes tokens — illustrates exactly the problem Oasis is solving. Every AI agent and automation workflow introduced into cloud environments creates non-human identities that require lifecycle management, least-privilege enforcement, and real-time access governance. One survey found 79% of IT professionals feel ill-equipped to handle attacks tied to non-human identities, even as adoption of AI agents continues to climb. 

Sources: SecurityWeek | Bloomberg | Morningstar 

3. RSA 2026: The AI-Powered Security Tooling Surge and the Governance Gap

📰 What Happened: At RSA Conference 2026, CrowdStrike, Palo Alto Networks, Cisco, and dozens of emerging vendors unveiled new AI-driven security capabilities spanning autonomous detection, accelerated incident response, and agentic SOC workflows. The announcements signal an arms race between attackers and defenders in which AI is the primary lever.

🔍 Why It Matters: The RSA announcements confirm what Igor articulated clearly in this week's transcript: AI is now being deployed on both sides of every security encounter. The risk for enterprise security leaders is not falling behind on AI adoption it is the governance gap that opens when AI tooling is deployed without the data connections, tuned models, and human oversight structures needed to make it reliable. Hallucinations in security tooling are not just embarrassing they generate alert fatigue, erode analyst trust, and create the dangerous illusion of coverage. The organizations that will win are those that integrate AI into existing SecOps workflows thoughtfully, not those that deploy the most tools.

✅ Key Actions:

• Prioritize AI-assisted triage over full autonomy human review of AI-surfaced findings remains essential at this stage of maturity.

• Validate model outputs rigorously; establish guardrails against hallucinated findings before operationalizing any AI detection capability.

• Integrate AI tooling into your existing SecOps stack; parallel tool sprawl increases noise and management burden.

🔗 Source: RSA Conference 2026 Coverage

4. AI + Supply Chain Attacks Target Developer Ecosystems and Cloud Pipelines

📰 What Happened: Recent threat intelligence documents active campaigns abusing developer tooling ecosystems including malicious VS Code extensions, poisoned GitHub repositories, and AI-themed lure packages to deliver infostealers and backdoors directly into enterprise cloud environments.

🔍 Why It Matters: The developer is the new perimeter. Malicious packages mimicking legitimate AI coding tools are being published to npm, PyPI, and similar registries, targeting the exact toolchain that engineering teams are actively expanding as part of their AI adoption push. Igor raised precisely this risk in discussing AI-recommended abandoned packages and dependency confusion attacks: AI coding assistants can introduce compromised or phantom dependencies at a rate no human reviewer can track without automated controls. Cloud credentials harvested from a developer's environment translate directly into cloud infrastructure access.

✅ Key Actions:

• Enforce secure SDLC controls: mandatory SCA scanning on every PR, with AI-native tooling that understands business logic, not just CVE signature matching.

• Restrict use of unverified IDE extensions, MCP servers, and AI skill packages build an internal approved registry.

• Monitor developer credential usage patterns in cloud environments; flag anomalous API activity from developer identity paths.

🔗 Source: Threat Intelligence on Developer Supply Chain

5. TeamPCP/Trivy Supply Chain Attack — 1,000+ SaaS Environments Hit, Lapsus$ Joins Extortion Wave

What Happened

On March 19, 2026, threat actor TeamPCP compromised Aqua Security's Trivy vulnerability scanner, injecting a credential-stealing payload into CI/CD pipelines across thousands of repositories by force-pushing 75 version tags in aquasecurity/trivy-action to malicious commits. The attack exploited credentials retained from an incomplete remediation of a prior breach.

The campaign has since escalated significantly. Mandiant CTO Charles Carmakal confirmed 1,000+ enterprise SaaS environments are actively compromised, with projections of "another 10,000" downstream victims as fallout continues. TeamPCP is now confirmed to be channeling stolen access to Lapsus$, converting a credential theft operation into an active extortion campaign. Attackers also pivoted into LiteLLM — a widely used AI middleware library — using stolen Trivy credentials, and deployed CanisterWorm to backdoor 29+ npm packages. Notably, the LiteLLM attack was deliberately timed to coincide with the RSA Conference, while defenders were distracted. Cached malicious Trivy Docker images (0.69.4–0.69.6) continue to circulate via mirror.gcr.io despite takedowns.

Why It Matters

The payload targeted the full cloud credential stack — AWS IAM keys, GCP service account tokens, Azure service principals, Kubernetes tokens, SSH keys, and Docker registry credentials. The Lapsus$ involvement means stolen credentials are already distributed and monetized; the remediation window has passed for affected environments. The LiteLLM pivot signals that AI/ML pipeline infrastructure is now a direct lateral movement target. Three structural lessons: tag-based GitHub Actions provide no integrity guarantee; incomplete credential rotation turns one breach into a campaign; and runtime detection outperformed every static control deployed.

Immediate Actions

• Audit GitHub Actions logs for trivy-action or setup-trivy runs between 17:00–23:13 UTC on March 19; search for tpcp-docs repos in your GitHub org

• Treat all CI/CD secrets as compromised if affected Actions ran — rotate immediately

• Pin all GitHub Actions to full commit SHAs, not version tags

• Audit LiteLLM deployments and associated credentials in AI/ML pipelines

• Verify npm and PyPI dependency integrity against Socket's CanisterWorm IOCs

• Do not assume takedowns ended exposure — check mirror.gcr.io and other caches

• Block domain scan.aquasecurtiy[.]org and IP 45.148.10.212

Sources: Sysdig TRT | Wiz Blog | Microsoft Security Blog | The Hacker News | GitGuardian

🎯 Cloud Security Topic of the Week:

Governing AI Agents as Federated Developers: The New Identity and Access Frontier

The most consequential security architecture challenge of 2026 is not a new vulnerability class it is the identity question posed by AI agents operating autonomously inside enterprise environments. When a developer runs ten AI coding agents overnight, each agent is not just generating code. It is operating with that developer's credentials, accessing that developer's permitted systems, and taking actions that the organization's existing IAM, PAM, and audit frameworks were never designed to capture or govern.

Igor Andriushchenko frames this with unusual clarity: the mental model shift required is from thinking of AI agents as tools to recognizing them as delegated principals  agents that inherit the permissions, credentials, and organizational trust of the human who invoked them. That reframing has immediate, practical implications for how cloud security architects design access controls, audit trails, and escalation paths in an agentic world.

This week, we go deep on what that actually looks like in practice from PAM-enforced human-in-the-loop escalation for privileged actions, to deny-list prompting strategies, to the skills and MCP server ecosystem that makes AI genuinely useful to security teams rather than just a mandate to fulfill.

Featured Experts This Week 🎤

• Igor Andriushchenko Head of Security, Lovable

• 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 Agents AI systems that do not just respond to prompts but autonomously take multi-step actions writing code, calling APIs, browsing the web, running commands on behalf of a user. The key security distinction: agents act, not just advise. When agents run with real credentials and real system access, the blast radius of a compromise or error scales accordingly.

• MCP Server (Model Context Protocol) An emerging open standard that allows AI agents to connect to external tools, data sources, and APIs in a structured way. MCP servers define what capabilities an agent can invoke. Analogous to API integrations in traditional software, but with the critical difference that AI agents can discover and chain MCP capabilities dynamically. Supply chain attacks targeting MCP marketplaces are already documented.

• PAM (Privileged Access Management) A security discipline and tooling category focused on controlling, monitoring, and auditing access to privileged accounts and credentials. In the context of AI agents, PAM provides the mechanism for requiring human escalation before an agent can access production secrets, high-privilege API keys, or sensitive system operations creating the "healthy friction" Igor describes.

• SCA (Software Composition Analysis) Automated tooling that identifies open-source and third-party components in a codebase, mapping them against known vulnerabilities (CVEs), license issues, and increasingly supply chain risk signals. In the AI coding era, SCA is under new pressure: LLMs can recommend abandoned, fictional, or malicious packages, and the volume of dependencies introduced per day has multiplied dramatically.

• SAST / DAST Static Application Security Testing (SAST) analyzes source code for security issues without executing it. Dynamic Application Security Testing (DAST) tests a running application by simulating attacks. Both categories are being disrupted by AI-native alternatives that build semantic models of application business logic rather than relying on pattern matching to find high-signal, low-noise findings like broken access control and business logic flaws.

• Dependency Confusion Attack An attack technique in which a threat actor publishes a malicious package to a public registry (npm, PyPI, etc.) with a name that matches or closely resembles a private internal package name. AI coding assistants that recommend package names without verifying their provenance or freshness can be manipulated into recommending the malicious public package over the intended private one.

• OAuth Token Harvesting The theft of OAuth access tokens  short-lived credentials used by SaaS applications to authorize access to impersonate legitimate users or service accounts. Per M-Trends 2026, this is a primary technique in cloud initial-access campaigns, particularly when tokens are embedded in SaaS vendor environments with broad downstream permissions.

• Voice Phishing (Vishing) Social engineering attacks conducted via telephone or voice-over-IP, often combined with AI voice synthesis to impersonate executives, IT help desks, or vendors. M-Trends 2026 identifies vishing as responsible for 23% of cloud intrusions frequently used to convince targets to approve MFA push notifications or surrender credentials verbally.

• Prompt Injection An attack against AI systems in which malicious instructions are embedded in content that the AI processes (documents, web pages, API responses), causing the AI agent to take unintended actions. In the context of AI coding agents with cloud access, successful prompt injection can result in credential exfiltration, data destruction, or unauthorized API calls.

• ASBOM (AI Software Bill of Materials) An emerging practice of documenting the AI models, datasets, and AI-dependent components within a software product analogous to a traditional SBOM for open-source dependencies. Igor describes using ASBOM in enterprise sales contexts, where banks are beginning to require vulnerability disclosure and reachability analysis for AI-dependent components before procurement approval.

This week's issue is sponsored by Varonis

AI Security Requires More Than Visibility. It Requires Control. 

Security leaders are under pressure to enable AI innovation while managing a rapidly expanding attack surface across cloud, identity, and data layers. AI agents and copilots can introduce new access paths, automated high-impact actions, and accelerate threat timelines. 

Varonis Atlas helps organizations secure AI end-to-end - from understanding usage and enforcing guardrails to detecting suspicious activity and reducing risk dynamically. Join our upcoming webinar to learn how Varonis Atlas can help security teams operationalize AI security at scale. 

💡Our Insights from this Practitioner 🔍

The CI/CD Pipeline Is Being Load-Tested to Failure

Igor's opening framing is the most important thing any security leader can hear right now: the infrastructure that enterprise security programs were built on the code review gates, the SAST scan cadences, the human-in-the-loop approval workflows is failing not because it was badly designed, but because it is being subjected to a load it was never engineered to handle."These old rails that CI/CDs run on, they are just getting load tested and reaching its limits in every organization." Igor, Lovable

A developer running ten AI coding agents in parallel overnight can produce more PRs in eight hours than a traditional team produced in a month. Each of those PRs represents state change in the system. Each state change is a potential security regression. And the tooling that security teams depend on to catch those regressions SAST scanners, human reviewers, manual threat models cannot keep pace with the throughput.

The practical implication for enterprise security architects is urgent: the right question is not "how do we improve our existing SAST pipeline?" It is "what does a security program look like that was designed for 1,000 commits per day?" That requires AI-native tooling with semantic code understanding, not pattern matching; autonomous triage agents that can investigate findings without waiting for analyst bandwidth; and a risk acceptance framework that explicitly acknowledges the speed-security tradeoff rather than pretending it does not exist.

🔑 Action: Conduct a throughput stress-test of your existing security tooling: how many PRs per day can your current SAST, SCA, and code review process handle before coverage degrades? That number is your current security ceiling and AI adoption is almost certainly pushing your organization toward it.

AI Agents Are Federated Developers Govern Them Accordingly

The most architecturally important insight from the conversation is Igor's framing of AI agents as delegated principals. When a developer invokes a coding agent, they are not just using a smart autocomplete tool they are federating their credentials, their access scope, and their organizational trust to an autonomous system that will act on their behalf without human review of each individual action. "Developer federates its access, its credentials, its knowledge to the AI. So you should almost see it as like another developer, essentially." Igor, Lovable

This reframing has immediate, practical consequences. If your IAM architecture allows a developer to access production secrets on-demand, then an AI agent running as that developer can also access production secrets on-demand and can do so thousands of times per day, silently, without any of the human judgment that (sometimes) catches misuse. The solution Igor implements at Lovable is elegant: PAM-enforced escalation for privileged actions. Developers can freely use AI agents for development-scoped work, but anything requiring production credential access requires a human to explicitly perform an escalation step that the agent cannot complete autonomously.

This is not a new concept, it is the principle of least privilege applied to a new class of principal. But its implementation requires deliberate architectural decisions: which actions should require human escalation? Where does the PAM boundary sit? How do you enforce it when AI agents are being invoked from developer machines, CI/CD pipelines, and SaaS platforms simultaneously?

🔑 Action: Map your current developer access entitlements and identify which of those entitlements an AI agent inheriting that access could abuse autonomously. For each high-risk entitlement, evaluate whether PAM-enforced human escalation is technically feasible and operationally acceptable given your speed-security tradeoff.

The Deny-List Paradox: Why Standard Security Prompting Logic Fails for Agents

One of the most counterintuitive insights from the conversation addresses a subtle but consequential difference between how security professionals think about access control and how AI agents process instructions. Security practitioners are trained to prefer allow-lists over deny-lists to define what is permitted and block everything else. Igor explains why this logic inverts AI agents. "For the agents, it's reversed. Because if you do an allow list, it'll always focus against that.The real world has so many more paths, but it will always choose the paths that you say you are allowed to do this." Igor, Lovable

When you give an AI agent a list of permitted actions, the agent optimizes toward executing those actions treating the allow-list as a set of objectives rather than a boundary. The agent will find paths to those permitted actions that you did not anticipate and did not sanction.The more effective approach, Igor argues, is to explicitly instruct agents on what not to do providing a security context document (embedded in the agent's system prompt or knowledge file) that defines the threat model, the sensitive components, and the prohibited actions.This is analogous to a new-hire security briefing: rather than listing every permitted workflow, you explain the business, what needs protecting, and what constitutes a security incident.

🔑 Action: For every AI coding agent or security agent your team deploys, create a security context document a structured summary of your threat model, sensitive components, and prohibited actions and embed it in the agent's knowledge file or system prompt. Treat it as a living document that security updates as the codebase and threat landscape evolve.

AI-Native SCA: The Overlooked Surface That LLMs Are Actively Expanding

Igor raises a specific, concrete risk that deserves standalone attention: AI coding assistants are actively introducing supply chain vulnerabilities that existing SCA tooling is not equipped to catch. The mechanism is hallucination LLMs confidently recommending libraries that do not exist at the specified version, have not been maintained in years, or share names with malicious packages published by attackers. "I asked AI about what is a good library for PII sanitization in Go, and it gave me a library and said it's actively maintained and the last commit was eight years ago." Igor, Lovable

This is not an edge case. Research presented at Black Hat has demonstrated methods for generating package names that, in some percentage of LLM invocations, cause the model to recommend a malicious attacker-controlled package over the intended legitimate one. As AI-generated code becomes the majority of enterprise commits, the aggregate risk from hallucinated or manipulated package recommendations becomes a meaningful supply chain vector, one that bypasses traditional SCA scanners that only check for known-bad CVEs against packages that are correctly installed.

The defensive architecture requires layering: AI-native SCA tools that understand the semantic context of dependency introduction (not just CVE signature matching), registry-level controls that restrict installation to approved package sources, and dependency pinning policies that prevent silent version drift. Critically, the AI agent's code generation pipeline itself must be instrumented not just the final PR.

🔑 Action: Audit your current SCA tooling against the AI-hallucination threat model: does it flag packages that are minimally maintained, have suspicious commit histories, or share names with known internal packages? If not, evaluate AI-native SCA vendors that surface these signals.

Building the Skills Ecosystem: The Unsexy Work That Determines AI Security ROI

A recurring theme in the conversation is the gap between announcing an "AI adoption strategy" and actually making AI useful to security teams in their day-to-day work. Igor's experience at Lovable building an incident responder skill that allows analysts to trigger autonomous investigation of suspicious alerts with a single command illustrates what genuine AI value looks like versus performative tooling deployment. "The overlooked part is that non-sexy work building skills, making connections, building MCP servers. Organizations usually just put Copilot into everyone's environment. But then what? What is it connected to? What can it do?" Igor, Lovable

The insight here is structural. The value of an AI agent in a security context is almost entirely determined by the quality of the data connections and skills it has access to the MCP servers that connect it to your SIEM, your cloud audit trails, your vulnerability management platform, your ticketing system. An AI agent without those connections is a sophisticated chat interface. An AI agent with them is a force multiplier.

Ashish reinforces this from a practitioner standpoint: the path to genuine AI security capability is iterative start with a single, high-value connection (e.g., "query AWS CloudTrail for this suspicious IP"), validate the output, add the next connection, and gradually build toward multi-step autonomous workflows that would previously have required hours of analyst time.

🔑 Action: Identify the three highest-friction, highest-repetition tasks your security team performs (e.g., alert triage, vulnerability verification, IOC lookups across multiple platforms). For each, map the data connections required and evaluate whether an MCP server or skills-based agent could automate the retrieval and initial analysis steps.

The Crawl-Walk-Run Model for AI Security Adoption

Both Igor and Ashish push back firmly against the organizational tendency to jump from zero AI usage to fully autonomous agentic workflows, a pattern that consistently produces failed implementations and organizational backlash. Igor's "air pocket" metaphor is instructive: within any organization, there are specific, bounded use cases where AI can be deployed safely and generate clear value without requiring a complete overhaul of security architecture.

For a large bank with significant regulatory exposure and risk aversion, the air pocket might be internal tooling prototyping with no production data involved. For a fast-moving scale-up, it might be PR-creation by non-developers with mandatory human review before merge. For a security team overwhelmed by SAST findings, it might be an AI agent that fetches the relevant code context and performs initial triage reducing analyst time-to-decision from thirty minutes to three.

The principle generalizes: find the smallest, highest-value problem that AI can solve today, solve it well, generate internal credibility, and use that credibility to expand the scope of AI deployment incrementally. Organizations that attempt to solve the entire class of problems simultaneously deploying fully autonomous security operations without the foundational skills, data connections, and governance frameworks are the ones that end up publicly reversing their AI strategy.

📚 RELATED RESOURCES 🎧

Threat Intelligence & Research

• Google Cloud / Mandiant M-Trends 2026 Report https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026

• OWASP Top 10 for LLM Applications (2025) https://owasp.org/www-project-top-10-for-large-language-model-applications/

• NIST AI Risk Management Framework (AI RMF) https://www.nist.gov/system/files/documents/2023/01/26/AI%20RMF%201.0.pdf

Cloud-Native Guidance & Tools

• AWS IAM Best Practices for Least Privilege https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html

• Model Context Protocol (MCP) Specification https://modelcontextprotocol.io

• Socket Security AI-Native SCA https://socket.dev

• OpenSSF Scorecard https://securityscorecards.dev

Podcast Episode

• Cloud Security Podcast   Episode with Igor Andriushchenko

Question for you? (Reply to this email)

🤔  Has your organization mapped which developer entitlements an AI agent could inherit and defined the PAM boundary that requires a human 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: Why AI May Finally Let CISOs Simplify Their Security Stack (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 accelerated again this week, and the numbers tell the story bluntly: what once took five months from a public vulnerability disclosure to confirmed in  the  wild exploitation now closes in under two days in 2026. That compression isn't theoretical. It's documented at ZeroDayClock.com, and it showed up in real time this week when a Chrome renderer flaw and a new ransomware initial access chain both arrived simultaneously, demanding immediate enterprise response.

Against that backdrop, this week's newsletter brings together three breaking security stories and a frank, unfiltered conversation with Caleb Sima veteran CISO, investor, and co  host of the AI Security Podcast   recorded live ahead of RSAC 2026. Caleb and Ashish Rajan (Cloud Security Podcast) cut through the conference noise to address something most vendors won't talk about: the case for radical vendor consolidation powered by internal AI teams, and why the current wave of "AI agent security" products largely can't back up their claims. [Listen to the episode]

⚡ TL;DR for Busy Readers

• Google closes $32B Wiz acquisition
  Expect tighter CNAPP + threat intelligence integration and potential licensing shifts.

• Patch Chrome now CVE 2026 3909 and CVE  2026  3910 are actively exploited zero days in Skia and V8; CISA KEV deadline is March 27. All Chromium based enterprise browsers are in scope.

• LeakNet ditches broker access New ClickFix + Deno in memory loader chain leaves minimal forensic artifacts; flag Deno.exe in non developer endpoints and tune PsExec detection rules.

• Vendor consolidation thesis gains momentum episode where Ashish Rajan & Caleb Sima argue the AI era enables CISOs to go all  in on 2–3 platform vendors and use internal AI teams to close the capability gap.

📰 THIS WEEK'S TOP 4 SECURITY HEADLINES

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

1. 🛡️ March Patch Tuesday: Azure MCP Server SSRF, Copilot Zero-Click Exfiltration Bug, & Two Public Zero-Days

What Happened

Microsoft's March 2026 Patch Tuesday addresses 79 security vulnerabilities, including two publicly disclosed zero-days. The most urgent concern is CVE-2026-26144, a critical information disclosure vulnerability in Microsoft Excel that can cause Copilot Agent mode to silently exfiltrate data with no user interaction requiredSeparately, CVE-2026-26118 is an elevation of privilege vulnerability in Azure MCP Server Tools (CVSS 8.8). An attacker could exploit this by sending a crafted input to a vulnerable Azure MCP Server that accepts user-provided parameters. The MCP Server then sends an outbound request to an attacker-controlled URL, potentially including its managed identity token, allowing the attacker to capture that token and inherit the permissions associated with the MCP Server's managed identity. 

Why It Matters

Two distinct cloud-AI attack vectors are in play here. First, CVE-2026-26144 represents a new class of threat: an attacker can deliver a malicious Excel file and if Microsoft 365 Copilot is enabled, trigger automatic, zero-click data exfiltration through the AI agent itself. No macro, no user action. Second, CVE-2026-26118 strikes at the emerging MCP ecosystem directly. MCP was designed to give AI agents safe, structured access to tools and data. CVE-2026-26118 shows that the protocol infrastructure itself can become an attack vector and that AI agent infrastructure expands the privilege escalation surface. For M365 Copilot deployments: patch immediately and audit Copilot Agent mode permissions. For Azure MCP implementations: update Azure MCP Server Tools and review managed identity scopes to enforce least privilege.

Sources: Talos Intelligence · Tenable · The Hacker News · SecurityWeek Zecurit Awesome Agents

2. 🚨 Google Patches Two Actively Exploited Chrome Zero Days CISA Adds Both to KEV (CVE  2026  3909 & CVE  2026  3910)

What Happened

Google issued emergency out  of  band patches for two high  severity Chrome vulnerabilities confirmed as exploited in the wild: an out  of  bounds write in the Skia graphics library (CVE  2026  3909) and an inappropriate implementation flaw in the V8 JavaScript and WebAssembly engine (CVE  2026  3910). CISA added both to its Known Exploited Vulnerabilities catalogue with a federal remediation deadline of March 27, 2026. Chrome's third zero  day pair of 2026. Technical exploitation details are restricted pending broad patch deployment.

Why It Matters

This is a patch now CVE. Skia and V8 are core rendering and execution components present across all Chromium  based browsers Chrome, Edge, Brave, Opera, and any Electron based enterprise applications. The V8 flaw carries implicit RCE risk within the browser sandbox and is a historically favoured APT initial access surface. Key actions:

• Verify the patched version is deployed fleet  wide   enterprise Chrome auto  update is frequently delayed or disabled in managed environments.

• Flag Electron  based internal tooling (Slack, VS Code, internal apps) and track vendor patch timelines for each.

• Review browser isolation and RBI policies for high  risk user populations (finance, exec, privileged users).

• Treat the March 27 KEV deadline as your internal SLA if you operate in regulated sectors or hold federal contracts.

This story also illustrates the zero day clock compression that Caleb Sima references in this week's expert interview: browser  level disclosures are now exploited within days, not weeks. Detection and patch velocity must match that pace.

Sources: CISA KEV Catalogue | The Hacker News | ZeroDayClock.com

3. 🔍 📦 LeakNet Ransomware Adopts ClickFix Social Engineering and Deno InMemory Loader drops Reliance on Access Brokers

What Happened

ReliaQuest threat intelligence published on March 17 identifies LeakNet ransomware operators adopting a previously unreported initial access chain: ClickFix lures delivered through compromised legitimate websites, paired with a Deno JavaScript runtime loader that executes a Base64  encoded payload almost entirely in memory, fingerprints the victim machine, and establishes C2. This marks a deliberate departure from initial access brokers (IABs) giving LeakNet direct, lower  cost access at greater scale. Every confirmed LeakNet incident shares a deterministic post  exploitation chain: jli.dll sideloading into Java within the USOShared directory → PsExec lateral movement → S3 bucket payload staging and exfiltration.

Why It Matters

The Deno loader is the standout technical detail. Rather than deploying custom malware, attackers install the legitimate Deno executable and use it to run malicious code via VBS and PowerShell scripts named with Romeo/Juliet naming patterns. The activity presents as normal developer tooling. Minimal forensic artifacts remain. Three strategic implications:

• Dark web IAB monitoring is no longer sufficient: LeakNet's shift to self  directed ClickFix campaigns removes the IAB dependency that previously provided early  warning telemetry for threat intelligence teams.

• Detection engineering updates required: Flag Deno.exe executing in non  developer contexts. Create detection rules for VBS/PowerShell scripts with Romeo*/Juliet* naming. Alert on jli.dll sideloading events and anomalous PsExec usage at scale.

• Use the deterministic kill chain as a containment trigger: Automated host isolation on confirmed jli.dll sideloads and anomalous PsExec activity can compress mean  time  to  contain from hours to minutes.

Sources: ReliaQuest   LeakNet Threat Spotlight | The Hacker News | BleepingComputer

4. ⚠️ Google Closes $32B Wiz Acquisition — Biggest Deal in Cloud Security History

What Happened

On March 11, 2026, Google announced the completion of its acquisition of Wiz, a leading cloud and AI security platform headquartered in New York. The deal received antitrust approval from U.S. regulators in November 2025 and from the European Commission in February 2026. Wiz will maintain its brand and continue providing cybersecurity solutions for all major cloud platforms, including AWS, Azure, and Oracle Cloud.

Why It Matters

This is the defining consolidation event in cloud security for the decade. For enterprise teams, the immediate implication is not product disruption Wiz has been explicit about multi-cloud continuity but strategic positioning. By integrating Wiz's advanced cloud security capabilities with Google's security operations platform, the company aims to provide organizations with a comprehensive defense platform designed for modern cloud and AI-driven infrastructures. The long-term question for CISOs: does a Google-owned CNAPP still serve as a neutral arbiter across your AWS, Azure, and GCP estate, or does procurement pressure shift? Wiz's $1B+ ARR base means your peer organizations are paying close attention. Evaluate your CNAPP and multi-cloud security stack posture now before renewal cycles hit during integration.

Sources: Google Press Release · TechCrunch · SecurityWeek 

🎯 Cloud Security Topic of the Week:

The Vendor Consolidation Thesis:
Why AI May Finally Let CISOs Simplify Their Security Stack

At RSAC 2026, the vendor floor will be louder, more crowded, and harder to navigate than ever. Vibe coding and AI tooling have spawned what Caleb Sima estimates to be a thousand new cybersecurity startups   all with the same marketing, the same branding, and the same AI agent claims. But beneath the noise, a structural shift is underway that smart CISOs are already moving on: the possibility of radical stack consolidation, powered by internal AI capability teams.

This week's expert conversation with Caleb and Ashish tackles the question most vendors don't want practitioners asking: what if the best  of  breed era is ending, and good  enough  plus  AI is the winning architecture?

Featured Experts This Week 🎤

• Caleb Sima -  CSO | CEO | Founder WhiteRabbit Ventures | 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:

• MCP: (Model Context Protocol)   An emerging standard for exposing tool and data APIs to AI agents. Mentioned in the transcript as a potential interoperability layer for security vendor integration, though its implementation depth varies widely.

• Zero Day Clock:  A project tracking time  to  exploitation metrics across disclosed vulnerabilities. In 2026, the median window from public disclosure to confirmed exploitation has compressed to approximately 1.5 days.

• Vibe Coding: Colloquial term for AI assisted, low  friction software development using LLMs (e.g., Claude Code, GitHub Copilot). Referenced by Caleb Sima as a driver of rapid cybersecurity startup proliferation.

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 🔍

1. The RSA Noise Problem Is Structural And It's Getting Worse

Caleb Sima doesn't sugarcoat the RSAC experience for practitioners. With AI tooling and vibe coding lowering the barrier to startup creation, this year's show floor may have genuinely doubled in density from 2025. The challenge isn't finding good vendors, it's that all the signal  to  noise filters have failed. "I cannot tell the difference, man. I personally, who have been in this industry since its inception, cannot tell the difference because all the marketing is the same, all the branding is the same. The only thing that stands out is what gorilla marketing tactic you have decided to use at RSA." Caleb Sima

For practitioners walking the floor this year, both speakers converge on a pragmatic filter: stop evaluating vendors on their marketing pitch and start evaluating their API surface. Ashish Rajan frames it cleanly. The minimum viable question for any vendor in 2026 is whether their product is API  accessible and AI  ready. Not whether they have an AI agent story, but whether your internal AI can query, orchestrate, and automate against their platform..

2. The AI Enabled Vendor Consolidation Thesis

The most provocative idea in this week's transcript is Caleb's consolidation hypothesis   and it has teeth. The traditional argument for best  of  breed security tooling is that attackers move faster than platform vendors, so you need specialised point solutions at each layer. But that argument breaks down when AI can close the capability gap between a mediocre platform native tool and a category leading specialist. "What if I were a CISO and said, I'm done with this. I'm done with the 500 vendors that I'm dealing with. I'm going to pick one or two that solve 95% of it. I'm gonna be all in on Palo Alto. I'm gonna clear everything out. And where I'll make up the difference, I'll use AI." Caleb Sima

The logic: consolidate onto two or three major platform vendors to gain deep hooks into your data plane, drive pricing leverage through committed spend, and reduce integration overhead. Then invest in an internal AI platform team  modelled on how cloud platform teams were built in the early 2010s to build vertical automation layers on top of that standardised infrastructure.

Ashish Rajan notes this isn't purely theoretical: publicly listed security companies are already acquiring toward this vision. The key CISO  level question Caleb poses is whether the gap between a platform vendor's mediocre native capability and a best  of  breed specialist is large enough that AI cannot close it. For a growing number of security functions, his answer is: no, it isn't.

Caleb's two  part test for any product pitch at RSAC:

• Is the API accessible and cost  reasonable at agent  scale usage? Security vendors price for human  triggered queries   not 24/7 AI automation loops. Probe for usage  based pricing cliffs.

• Does AI usage of their product give me personalisation and customisation that I couldn't achieve with the platform vendor's native tool? If not, consolidate.

3. Building the Internal AI Security Platform Team

Before there was a cloud team, every business unit bought its own infrastructure. The formation of centralised cloud platform teams with governance, standardisation, and cost management was the architectural move that made cloud scale possible. Caleb argues security is at exactly that inflection point with AI. "Everyone, at least so far, is similar to an enterprise company; they're all independently working on things that help them automate. Detection response has AI in the SOC, the vuln management team has AI in scanning, red teaming has AI. They're all separate. There needs to be a centralised function that looks across all of these and finds ways of pulling these things together."   Caleb Sima

The centralised AI security platform team's mandate would span: cross team AI abstraction and cost management; identification of capability gaps that no single vertical owns (executive reporting, cross  domain risk correlation); and providing the internal "glue" that connects enterprise search (Glean, Databricks, Atlassian), security tooling APIs, and AI orchestration layers.

Ashish adds an important accessibility dimension: this function doesn't require every team member to be a terminal  level engineer. Enterprise search APIs, MCP connectors, and AI coding agents can enable security professionals with moderate technical fluency to build meaningful automation without deep programming backgrounds.

4. AI Agent Security: Still an Open Book

For practitioners evaluating the wave of AI agent security vendors at RSAC, both speakers deliver a clear  eyed verdict: the category is real, the tooling is largely not ready, and the vendor claims rarely survive first contact with hard questions.

"I ask them first: can you define to me what an agent is? And I think 70% of the people can't answer that. So then clearly you can't track it if you don't even know what an agent is or how to define an agent."   Caleb Sima

The three specific capability gaps where no vendor has a credible answer today:

• Agent observability and intent: Distinguishing a security  relevant AI action from an operational or legitimate action requires organisational context that no third  party vendor currently holds. Continuous eval loops are the only current mechanism, and they don't scale.

• Identity chain  of  custody across agent hops: In multi  agent architectures, an identity traverses five or six system hops. No current tooling provides a reliable, tamper  evident audit trail for this traversal.

• Good decision vs. bad decision detection: Full end  to  end visibility of an agent's actions does not equate to knowing whether those actions are benign or malicious. Context  aware decision classification is still unsolved at production scale.

The actionable implication: when a vendor at RSAC claims full AI agent security coverage, ask them Caleb's questions. If they can't define what an agent is in your specific deployment context (workforce laptop vs. Kubernetes production vs. MCP  connected SaaS), they cannot protect it. Treat AI agent controls as incomplete and layer in: retrieval controls, output filtering, tool use restrictions, egress monitoring, and separation of sensitive data from model context.

4. The Zero Day Clock and Why Vendor Response Time Is Now Your Problem

One of the most operationally concrete data points in this week's conversation is Caleb's reference to ZeroDayClock.com  a project tracking time  to  exploitation metrics across disclosed vulnerabilities.

The trend line is unambiguous: in 2023, the median window from vulnerability disclosure to confirmed exploitation was approximately five months. In 2026, it is approximately 1.5 days. Caleb's own example from the week: a security researcher published a blog post about a prompt injection vulnerability in a GitHub AI triage bot. Within two days, an attacker had exploited the same company using the exact technique from that post   prompt injecting the bot via the GitHub issue title, downloading open  source tooling as a payload, and establishing C2 entirely through the publicly documented chain.

This timeline compression means that patch SLAs built around 30  day or even 7  day cycles are architecturally obsolete for high  severity vulnerabilities with public PoC. The practical response is building automated patch pipeline capabilities within the security team that can identify a disclosure, assess organisational exposure, and begin deployment or compensating control activation without waiting for weekly change windows.

🧠  MENTAL MODEL OF THE WEEK

The Trust Chain Model

Developer Workstation  →  SaaS Platform  →  CI/CD Pipeline  →  Cloud IAM Role

Cloud compromises rarely start with infrastructure exploitation. They begin by breaking the weakest trust relationship in the identity chain. The attacker only needs one weak link to inherit the privileges of the entire chain. Map every trust relationship in your developer ecosystem  not just your cloud environment.

📚 RELATED RESOURCES 🎧

• ZeroDayClock.com   Track real  time time  to  exploitation metrics across disclosed CVEs

• Microsoft Sentinel UEBA Behaviors Workbook   Official deployment guide and workbook

• CISA Known Exploited Vulnerabilities Catalogue   Current KEV list including CVE  2026  3909/3910

• ReliaQuest: LeakNet Threat Spotlight (ClickFix + Deno)   Full TTP breakdown with detection guidance

• OWASP Top 10 for LLM Applications   Framework for AI/LLM risk in enterprise deployments

• Unit 42: Prompt Guardrail Evasion Research   March 2026 research on prompt fuzzing evasion rates

Podcast Episode

• AI Security Podcast   RSAC 2026 Special  - Full Episode featuring Caleb Sima and Ashish Rajan

• Cloud Security Podcast   Weekly cloud security practitioner insights from Ashish Rajan

Question for you? (Reply to this email)

🤔 Does your security team have explicit ownership of browser-based identity threats  or is the browser still a gap between IT, SOC, and identity?

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: When AI Plays Both Sides: Rethinking SOC Architecture in the Era of 29-Minute Breakouts (continue reading) 

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 you had to pick one thread connecting every major enterprise breach of the last 18 months, it wouldn't be a zero-day or a misconfigured S3 bucket. It would be identity  compromised through the browser.

This week's edition comes at a pivotal moment. Google's $32 billion Wiz acquisition, the largest cybersecurity deal in history, is closed. A coalition of identity-focused threat actors is now operating under a single banner (Scattered Lapsis Hunters), having already compromised MGM, Okta, Marks & Spencer, and Salesforce. And the attack vector enabling all of it? The browser is a surface that most enterprise security programs still treat as someone else's problem.

To make sense of this shift, we spoke with Adam Bateman, co-founder of Push Security and former elite red teamer at MWR  whose simulations were so convincing they were mistaken for real nation-state attacks and appeared in public threat intelligence reports. Adam brings a decade of offensive security research to the question of why identity controls are failing and what defenders actually need to do about it.  [Listen to the episode]

⚡  ONE STAT THAT MATTERS

72 hours

The time it took threat actor UNC6426 to escalate from a stolen developer token to full AWS administrative control — without exploiting a single infrastructure vulnerability. Identity trust chains are now the primary blast radius multiplier in cloud breaches.

⚡ TL;DR for Busy Readers

• Google closes $32B Wiz acquisition
  Expect tighter CNAPP + threat intelligence integration and potential licensing shifts.

• Scattered Lapsis Hunters coalition emerges
  Identity-focused actors combining tactics from Scattered Spider, Lapsus$, and ShinyHunters.

• Supply chain breach → AWS admin in 72 hours
  GitHub OIDC trust abuse enabled full environment takeover.

• Audit your GitHub-to-AWS OIDC trust policies today

• Identity providers ≠ security boundaries
  40%+ of SaaS apps remain invisible to most conditional access policies.

• Browser security becomes the new EDR frontier
  Modern phishing now executes entirely inside the browser.

📰 THIS WEEK'S TOP 6 SECURITY HEADLINES

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

1. 🚨 MAJOR M&A  Google Closes $32B Wiz Acquisition

What Happened: Google completed its $32 billion all-cash acquisition of Wiz. The deal passed U.S. antitrust review in November 2025 and received unconditional EU approval in February 2026. The combined platform merges Google's Threat Intelligence and Security Operations with Wiz's CNAPP/CSPM. Critically, Wiz remains available across AWS, Azure, and Oracle Cloud.

Why It Matters: The consolidation of Mandiant (IR + threat intel) with Wiz (CNAPP/CSPM) creates a formidable platform  and immediate pressure on Palo Alto Networks and Microsoft Defender for Cloud. For teams currently on Wiz: integration roadmap, commercial terms, and Gemini AI integration pace deserve scrutiny over the next 12 months.

Sources: Google Cloud Blog | SecurityWeek | TechCrunch | Wiz Blog

2. 🚨 SUPPLY CHAIN  Stolen npm Token Gives Attacker Full AWS Admin in 72 Hours

What Happened: Threat actor UNC6426 leveraged a developer's GitHub token  stolen via the nx npm package supply chain compromise  to achieve full cloud environment takeover in under 72 hours. The attacker abused the GitHub-to-AWS OIDC trust relationship to create a new administrator role, exfiltrated Amazon S3 data, performed production data destruction, and publicly renamed all internal GitHub repositories.

Why It Matters: Any IAM role whose trust policy references token.actions.githubusercontent.com without a StringEquals condition on the sub claim is exploitable today. Audit GitHub-to-AWS OIDC trust configurations immediately and treat overly permissive IAM roles as critical misconfigurations  not policy aspirations.

Sources: The Hacker News | CSA Research Brief

3. 🔍 CLOUD VULN  "LeakyLooker": Nine Cross-Tenant Flaws in Google Looker Studio

What Happened: Tenable Research disclosed nine cross-tenant vulnerabilities in Google Looker Studio enabling arbitrary SQL queries against BigQuery, Google Sheets, Spanner, PostgreSQL, MySQL, and Cloud Storage. A key flaw: duplicated reports retained stored database credentials, letting the new report owner run custom SQL without knowing the password. Google has patched all issues.

Why It Matters: Analytics and BI platforms connected to sensitive cloud databases are a seriously underappreciated attack surface. The credential-inheritance flaw illustrates how feature convenience ("copy this report") becomes a security liability at scale. Review access controls on shared Looker Studio reports and audit who can duplicate data-connected dashboards.

Sources: Tenable Research | The Hacker News | Infosecurity Magazine

4. 🚨 EMERGING VECTOR  Malicious Rust Crates and AI-Powered CI/CD Bots Target Developer Secrets

What Happened: Researchers discovered five malicious Rust crates on crates.io (late February – early March 2026) disguised as time utilities, covertly exfiltrating .env file data. Simultaneously, an AI-powered bot named "hackerbot-claw" scanned public repositories for exploitable GitHub Actions workflows, targeting secrets at Microsoft, Datadog, and Aqua Security. In the Aqua incident, attackers pushed malicious Trivy VS Code extensions and used local AI coding agents to exfiltrate data.

Why It Matters: .env files frequently contain cloud provider API keys, database credentials, and GitHub tokens. Mandate cargo-audit and cargo-deny in all Rust-based CI pipelines. Audit GitHub Actions workflows for pull_request_target exposure. Treat AI coding agents on developer machines as a monitored security boundary.

Sources: The Hacker News | Socket Research

5. ⚠️ AI SECURITY  OpenAI Acquires Promptfoo, Bringing AI Red-Teaming into the Core Platform

What Happened: OpenAI announced plans to acquire Promptfoo, an AI security platform for identifying and remediating vulnerabilities in AI systems. The technology integrates into OpenAI Frontier for enterprise AI agent security testing and monitoring. The open-source project continues.

Why It Matters: Agent security testing  red-teaming, indirect prompt injection, safety evals  is moving from niche AppSec work into core platform capability. Deploying AI agents without built-in red-teaming infrastructure will become a compliance gap, not just a best-practice shortfall.

Sources: OpenAI and Promptfoo official announcements

6. ⚠️ SAAS RISK  Salesforce Warns of Active Data-Harvesting Against Experience Cloud Sites

What Happened: Salesforce disclosed a threat actor mass-scanning public-facing Experience Cloud sites using a modified version of Mandiant's AuraInspector to exploit overly permissive guest-user settings. ShinyHunters  part of the Scattered Lapsis Hunters coalition  has publicly claimed responsibility.

Why It Matters: SaaS risk most often sits in authorization design, not software defects. Immediate actions: review guest-user profiles, set external access defaults to private, disable unauthenticated public API access, and inspect Aura event logs for unusual query patterns.

Sources: Salesforce guidance and follow-on reporting.

🎯 Cloud Security Topic of the Week:

The Browser Is Your New Network Perimeter

For most of security's history, the network was the thing you defended. EDR extended that logic to the endpoint. But there is now a third layer  one that most enterprise security programs have left almost entirely unprotected: the browser.

The architectural shift is already complete. Employees work inside browsers, not applications. They talk to cloud services, not internal networks. Identity  not network access  is the control plane. And yet almost no organisation has deployed the equivalent of EDR for the browser. That gap is exactly what groups like Scattered Lapsis Hunters are exploiting  and it's why every major enterprise breach of the past 18 months started not with a firewall bypass, but with an identity compromise that detonated entirely inside the browser.

This week, Adam Bateman of Push Security walked through exactly how this shift has happened, what attack patterns are dominating, and why the existing stack  IDPs, MFA, SWGs, even EDR  has a structural blind spot that only browser-native visibility can close.

Featured Experts This Week 🎤

• Adam Bateman - Co-Founder & CEO | Push 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:

• IDP (Identity Provider): A centralised platform (e.g., Okta, Entra ID) that manages authentication across applications. Adam's key point: IDPs function more like domain controllers than firewalls  they provide a management layer, but attackers bypass them by targeting local accounts or SaaS apps users access outside SSO flows.

• OIDC (OpenID Connect): An authentication protocol built on OAuth 2.0. The GitHub-to-AWS OIDC trust is a common CI/CD pattern  but without a StringEquals condition on the sub claim, any attacker with a GitHub token can assume privileged IAM roles.

• Click Fix Attack: A social engineering technique that injects a malicious command into the user's clipboard via JavaScript. The user is prompted to paste and execute via Windows Run  downloading malware. EDR often misses it because the command runs as a direct user action, not a suspicious process chain.

• Consent Fix Attack: Push Security's newly named variant combining Click Fix with OAuth consent phishing, attributed to Midnight Blizzard. The user is tricked into performing actions granting an attacker full Azure control  entirely inside the browser, with zero code executed on the endpoint.

• Consent Phishing : An attack tricking users into granting OAuth permissions to a malicious application. The attacker then controls it via API, accessing email and files and performing password resets  bypassing MFA entirely by using a legitimate token rather than logging in.

• Omni-channel Phishing : The evolution of credential phishing beyond email. Attackers now deliver phishing links through LinkedIn DMs, SMS, social media comments, Google Ads sponsored results, and personal email inboxes  all detonating inside the browser.

• Scattered Lapsis Hunters: The newly-formed coalition of Scattered Spider, Lapsus$, and ShinyHunters  collectively responsible for breaches at MGM, Okta, Microsoft, JLR, Marks & Spencer, and Salesforce. Their MO is purely identity-first; none of their major breaches started on the network.

• Secure Web Gateway (SWG): A proxy-based solution for monitoring web traffic via SSL interception. Adam's analysis: modern JavaScript-heavy SaaS apps stage their payloads client-side  meaning the SWG never sees the full application. Browser-native tools have the full runtime context the SWG never will.

• CNAPP: Cloud-Native Application Protection Platform  an integrated platform combining CSPM, workload protection, network security, and IaC scanning. Wiz is the defining product in this category, now integrated with Google's Mandiant threat intelligence and Security Operations.

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 🔍

1. The IDP Is Not a Firewall  And Attackers Know It

The central misconception Adam targets is the assumption that deploying Okta or Entra ID creates a security perimeter analogous to a firewall. It doesn't. It creates a management layer  and like every management layer, it can be bypassed.

"People take their IDP, whether it be Okta, Entra, whatever it might be, and they say: yeah, it's this with a hundred SaaS applications behind it and everything's got MFA on it. When you actually dig into it... it's not a firewall, it's an overarching management layer. If you gained access to Okta, you could compromise everything beneath it  but you can also get into those underlying apps in lots of other ways as well."

 The practical mechanism: when users encounter an application login page, they often bypass SSO entirely by clicking "Sign in with Google" or creating a local account outside the IDP. Adam's data shows this happening across thousands of applications, including services like Zapier that can be weaponised to send internal Slack messages once compromised.

What this means for your architecture:

• Your IDP policy is only as effective as your enforcement coverage. 40%+ of SaaS apps in most organisations are shadow IT, invisible to your IDP.

• Credential stuffing attacks bypass IDP entirely. Attackers don't need to defeat MFA if they can log in with a local credential that was never federated.

• OAuth and consent-phishing attacks bypass MFA regardless of strength  including hardware keys and passkeys.

2. The Architectural Shift Most Security Teams Haven't Accounted For

The shift Adam describes is structural, not incremental. In the legacy model, the attack surface was open ports. In the modern model, applications live in the cloud; identity is the only path to them. And identity lives in the browser.

"We used to work on our laptops with applications talking to the network. And now we work inside our browsers with our browsers talking to the cloud. The laptop to the network was bound together with ports and protocols. The browser to cloud is bound together with identity. So the modern attacks are now: how do I get access to this identity in a creative way to get access to the cloud services where all the critical data is?" - Adam Bateman

This is why groups like Scattered Lapsis Hunters are so effective. They're not finding novel exploits, they're applying sound offensive logic to an architecture most defenders are still protecting with the wrong tools. Even organisations that are 50% on-premise have a cloud and SaaS footprint that represents an uncovered attack surface. It's not a transition problem, it's a permanent gap without browser-level visibility.

3. Phishing Has Outgrown the Inbox

Two distinct evolutions of phishing that bypass both traditional email security and endpoint detection entirely:

Omni-channel Phishing

Push Security has documented campaigns where attackers compromised LinkedIn accounts and used them to DM phishing links to high-profile CEOs  from a known, trusted contact. The corporate email gateway saw nothing. Adam's team has also observed delivery via SMS, social media comments, and legitimate SaaS apps including DocuSign documents with embedded phishing links and Google Ads-distributed phishing via sponsored results.

Legitimate SaaS as a Phishing Vehicle

Traditional email security works by identifying illegitimate sending domains. Attackers have neutralised that control by sending phishing from legitimate SaaS platforms. A $20 DocuSign account, a real-looking court order with a large signing button  and the email arrives from docusign.com, which is legitimate. The phish happens when the user opens the browser to sign.

Click Fix & Consent Fix: Browser-Native Payload Chains

Click Fix (clipboard injection → user pastes and executes) is now prolific. The Consent Fix variant  attributed to Midnight Blizzard  is the most technically significant development: a user hits a watering-hole site, performs browser actions, and the result is a full Azure compromise. No PowerShell. No endpoint execution. No EDR alert.

"Email is no longer the target anymore. Phishing has evolved to a lot more things happening inside the browser." - Ashish

4. What Browser Security Actually Looks Like  And Who Owns It

The ownership question for browser security is unresolved in most enterprises. IT owns browser deployment. But browser security  detection and response for identity compromise, phishing, malicious extensions, session hijacking  belongs to no one.

Push Security positions itself as detection and response tooling bought by the same team that runs EDR. The mechanism: a browser extension that observes logins across all SaaS applications  including shadow IT, inspects the DOM, profiles login pages, and detects cloned phishing pages. Because it covers every identity event across every app (not just IDP-managed ones), it closes the gap SSPM tools can't reach via API alone.

The longer-term category play: the displacement of Secure Web Gateways. The same evolutionary logic that transformed AV → EDR is now playing out with SWG → Browser Security.

Practical steps for security architects:

• Map your SaaS footprint honestly  including shadow IT. 40%+ of SaaS apps are unmanaged. You cannot secure what you cannot see.

• Audit your IDP coverage. Identify every application where users can log in without SSO and either enforce federated identity or accept and monitor the risk.

• Review OAuth app permissions across M365 and Google Workspace for apps with Mail.Read, Mail.Send, or Files.ReadWrite granted by individual users.

• Add browser security to your stack evaluation  Push Security, enterprise browser tooling, or managed browser solutions.

• Assign ownership. SOC, identity team, or cloud security  someone needs to own this explicitly, or it will remain unowned.

✅ WHAT SECURITY LEADERS SHOULD DO THIS WEEK

1. Audit GitHub-to-AWS OIDC roles for missing sub claim restrictions  the misconfiguration that enabled the 72-hour AWS takeover.

2. Review SaaS analytics access controls for dashboards connected to production databases, particularly duplication and sharing permissions.

3. Add dependency-scanning to Rust pipelines using cargo-audit and cargo-deny to detect malicious crates.

4. Audit Salesforce Experience Cloud guest user profiles to ensure anonymous users cannot access internal objects or APIs.

Map your full SaaS footprint  including shadow IT  and assign explicit ownership of browser-based identity threat detection.

🧠  MENTAL MODEL OF THE WEEK

The Trust Chain Model

Developer Workstation  →  SaaS Platform  →  CI/CD Pipeline  →  Cloud IAM Role

Cloud compromises rarely start with infrastructure exploitation. They begin by breaking the weakest trust relationship in the identity chain. The attacker only needs one weak link to inherit the privileges of the entire chain. Map every trust relationship in your developer ecosystem  not just your cloud environment.

📚 RELATED RESOURCES 🎧

• Push Security Research Blog — Click Fix, Consent Fix, and Omnichannel Phishing

• Google Cloud Threat Horizons Report H1 2026 — Supply chain and OIDC trust analysis

• Tenable LeakyLooker Research — Cross-tenant flaws in cloud analytics platforms

• CISA GitHub Actions Security Hardening Guide

• OWASP OAuth Security Cheatsheet — Consent phishing and OAuth app risks

• Socket Research — Malicious Rust crates and supply chain detection

Cloud Security Podcast

• Cloud Security Podcast Episode with Adam Bateman

Question for you? (Reply to this email)

🤔 Does your security team have explicit ownership of browser-based identity threats  or is the browser still a gap between IT, SOC, and identity?

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: 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