🚨 GitHub Breach Caps TeamPCP's 5-Compromise Run - Sergej Epp on Why Defense Has No Verifiers

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) 

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