Happy Monday!

Before we dive into the data, we want to take a moment to hope that you, your families, and your teams are staying safe. The current geopolitical landscape is heavy, and as is often the case in 2026, physical tensions are translating directly into digital ones. We are seeing a significant surge in cyber activity across the board—making it more critical than ever to stay vigilant and grounded.

Every Week, I break down the AI threat stories that matter:

This week's issue covers four stories that together paint a clear picture of where AI threats are heading in 2026: attacks are getting faster, the supply chain is the new perimeter, and the infrastructure running your AI workloads is largely invisible to your defenses.

Let's get into it.

LEAD THREAT

Here's a sentence that should be on every CISO's radar right now: an autonomous AI agent, with no credentials and no human assistance, broke into one of the world's most powerful consulting firms and gained full read-write access to its internal AI platform in two hours flat.

This is not a hypothetical. It happened in February 2026.

Red-team startup CodeWall pointed its autonomous offensive AI agent at McKinsey's internal chatbot, Lilli — a platform used by over 40,000 employees processing more than 500,000 prompts per month. The agent selected the target itself, researched it autonomously, identified the attack surface, and executed the full chain without a human typing a single prompt.

The entry point was surprisingly mundane: 22 publicly exposed API endpoints that required no authentication. One of them accepted user search queries and concatenated JSON keys directly into SQL — a textbook injection flaw. The agent spotted something that standard scanning tools missed: JSON keys being reflected verbatim in database error messages, signaling a SQL injection opportunity. From there it moved fast. Within two hours it had accessed 46.5 million chat messages covering client strategy, M&A discussions, and confidential engagements — all in plaintext — along with 728,000 client files and 57,000 user accounts.

The most alarming part: Lilli's system prompts were stored in the same database, and they were writable. A malicious actor could have silently rewritten the instructions controlling how the chatbot behaves for all 40,000 consultants — poisoning its answers, removing guardrails, and manipulating how it cites sources. No code deployment needed. Just one SQL UPDATE statement.

McKinsey patched everything within 24 hours of disclosure. No client data was confirmed accessed. But the patch is not the story.

The era of AI-vs-AI attacks has arrived, and it changes the threat calculus in three important ways.

First, speed. A human attacker doing this manually would have taken days or weeks to chain together reconnaissance, vulnerability identification, exploitation, and data access. An AI agent did it in two hours — and that gap will only widen as agents improve.

Second, scale. CodeWall's agent selected its own target. It didn't need a human to point it at McKinsey. Threat actors deploying the same technology can run hundreds of these agents simultaneously, scanning and attacking targets indiscriminately at machine speed.

Third, the vector was not exotic. This wasn't a zero-day. It was unauthenticated API endpoints and SQL injection — vulnerabilities that have existed for decades. The AI didn't find a novel attack. It found an old one faster than any human would. Your AI platform may have the same problems right now and you wouldn't know it.

Three immediate actions that apply directly to any team running an internal AI platform:

Audit every API endpoint your AI system exposes. Unauthenticated endpoints are the entry point here — run a full inventory this week and verify authentication is enforced on every single one. If you don't know how many endpoints your AI platform exposes publicly, that's your answer.

Isolate your AI's system prompts. They should never live in the same database as user-queryable data. Treat system prompts like configuration secrets — separate storage, strict access controls, read-only from the AI's perspective.

Assume your AI platform will be red-teamed by an autonomous agent. Not by a human typing clever prompts — by an AI running thousands of probes per hour. Test accordingly. Tools like Garak and PyRIT can simulate this. If you haven't run them against your own systems, someone else will.

THREAT ROUNDUP

OpenAI launched Codex Security, an AI-powered vulnerability scanner now in research preview and free for the next month for ChatGPT Pro, Enterprise, Business, and Edu customers. The tool analyzes entire code repositories, builds a threat model based on the system's architecture and exposures, identifies vulnerabilities ranked by real-world impact, and proposes patches. OpenAI claims it found nearly 800 critical vulnerabilities and over 10,000 high-severity issues across 1.2 million commits in the past 30 days alone — in widely used projects including Chromium, OpenSSL, and PHP. The launch follows Anthropic's Claude Code Security announcement just days earlier, which was significant enough to send cybersecurity company stocks tumbling.

Two of the biggest AI labs on the planet entered the vulnerability scanning market within days of each other. That is not a coincidence — it is a signal that AI-powered security tooling is becoming a core battleground for the major AI players. For security teams, the immediate implication is practical: you now have access to a free, enterprise-grade AI vulnerability scanner for the next month. The bigger question is what happens to traditional SAST and vulnerability management vendors when OpenAI, Anthropic, and Google are all offering this capability bundled into tools developers already use every day.

If your organization is on ChatGPT Enterprise or Pro, run Codex Security against your most critical repositories this month while it's free — treat it as a free red team engagement and see what it surfaces that your existing tools missed. Do not replace your current vulnerability management process with it yet. Use it as an additional layer and validate findings before acting. Procurement conversations with traditional SAST vendors are worth revisiting in Q3.

Researchers at Noma Security discovered a critical vulnerability in Context7 — one of the most widely used MCP servers on GitHub, with 50,000 stars and over 8 million downloads. Context7 sits inside developer IDEs and feeds AI coding assistants like Cursor, Claude Code, and Windsurf with up-to-date library documentation. The problem: anyone with a GitHub account could register a library on Context7 and set "Custom Rules" — AI instructions that were delivered verbatim, unsanitized, directly into a developer's AI agent. No filtering. No distinction from legitimate documentation. The attacker publishes once, Context7 delivers the payload, the AI agent inside the IDE executes it. Researchers demonstrated the full attack chain: stolen environment files, credentials exfiltrated to an attacker-controlled GitHub repo, and local project folders silently deleted — all triggered by a developer simply asking their AI assistant for help with a library. The vulnerability was patched within two days of disclosure. No evidence of exploitation in the wild was found.

This is an MCP supply chain attack and it signals something every security team needs to internalize: your AI coding assistant trusts whatever comes through its MCP servers. It has no way to distinguish between legitimate documentation and attacker-controlled instructions when they arrive through the same channel. Popularity is not safety — the researchers also demonstrated that Context7's "trending" and "top 4%" badges could be gamed by self-interaction alone, manufacturing false credibility for a poisoned library. Every MCP server in your developers' IDEs right now is a potential delivery channel for this exact attack pattern.

Run an immediate inventory of every MCP server installed across your development team's IDEs — most teams have no visibility into this. Treat MCP servers as you would any third-party dependency: review what they connect to, what content they serve, and whether that content is sanitized before reaching your AI agent's context. Flag any MCP server that aggregates user-generated or third-party content. Consider restricting MCP server installations to an approved list until your team has conducted that review.

Check Point Research disclosed VoidLink, a malware framework purpose-built for cloud and container environments — not adapted from Windows tools, but designed from the ground up for Kubernetes. It detects which cloud provider it's running on, determines whether it's inside a Docker container or Kubernetes pod, harvests API credentials, Git tokens, and cloud metadata, and adapts its behavior based on how well-monitored the environment is — slowing down in defended environments, running freely in unmonitored ones. Cisco Talos confirmed it has already been used in real campaigns targeting technology and financial organizations. The part that makes this a watershed moment: researchers believe AI was used to build it in under a week.

VoidLink exposes the blind spot most security teams don't want to admit exists. Years of investment in EDR, identity, and cloud monitoring have left Kubernetes — where AI models train, inference runs, and agents operate — almost entirely invisible to defenders. VoidLink is specifically designed to operate in the layer where traditional security agents live, meaning by the time your EDR looks for a signature, the malware has already encrypted itself and moved on. This isn't a gap at the edge of your infrastructure. It's a gap at the center of it. Nearly 90% of organizations experienced at least one Kubernetes security incident last year. Most had no idea.

Find out right now whether your security team has runtime visibility into your Kubernetes environments — not just configuration scanning, but real-time process and syscall monitoring. If the answer is no or unclear, that is your most urgent gap. Audit what credentials and secrets are accessible from inside your containers — VoidLink specifically targets API keys, Git tokens, and cloud metadata endpoints, all of which are commonly over-permissioned in Kubernetes workloads. If your organization runs AI workloads on Kubernetes, treat those clusters as crown jewel infrastructure with the same security investment you'd give your identity layer. The attackers already do.

DEFENDER'S CORNER

Look at all four stories in this issue and you'll notice a pattern: every single attack succeeded because something trusted something it shouldn't have. McKinsey's database trusted unauthenticated API requests. Developer IDEs trusted MCP server output without inspecting it. Kubernetes clusters trusted container workloads with excessive permissions. VoidLink trusted that defenders couldn't see into the kernel — and it was right.

The common thread is a misconfigured or absent least-privilege policy. This week's defender action is simple but high-impact: conduct a privilege audit across your AI stack.

Start with three questions. First — what can your AI platform's API endpoints do without authentication? If the answer is anything beyond returning a public landing page, you have exposed attack surface that needs to close this week. Second — what permissions do your Kubernetes workloads run with? Pull a list of any pod running with privileged: true or with hostPID, hostNetwork, or hostIPC enabled. These are VoidLink's preferred footholds and they are almost never necessary in production. Third — what can your AI coding assistant's MCP servers actually do on a developer's machine? If nobody on your team has reviewed the permissions of installed MCP servers in the last 30 days, assume you have unreviewed execution access sitting in every developer's IDE.

None of this requires new tooling. It requires 90 minutes and the willingness to look.

TOOL OF THE WEEK

trivy.dev | github.com/aquasecurity/trivy

If you run containers, Kubernetes, or any kind of cloud infrastructure and you're not using Trivy, fix that today. Trivy is an open-source vulnerability and misconfiguration scanner from Aqua Security that covers container images, Kubernetes clusters, infrastructure-as-code files, Git repositories, and cloud configurations — all in a single tool.

What makes it directly relevant to this week's issue: Trivy scans for the exact misconfigurations VoidLink exploits — privileged containers, over-permissioned service accounts, exposed secrets in environment variables, and Kubernetes RBAC misconfigurations. It also scans container images for known vulnerabilities before they reach production, closing the supply chain gap that the Context7 attack exploited at the IDE layer.

Run it against your Kubernetes cluster in three commands:

brew install trivy (or via apt/binary) trivy k8s --report summary cluster trivy image your-ai-workload-image:latest

The cluster scan alone will surface misconfigurations most teams have never seen in their own environments. It's free, actively maintained, and takes under five minutes to run your first scan. No excuse not to.

SOURCES

CodeWall original research: codewall.ai/blog/how-we-hacked-mckinseys-ai-platform Via: theregister.com/2026/03/09/mckinsey_ai_chatbot_hacked

Noma Security original research: noma.security/blog/moltbot-the-agentic-trojan-horse

OpenAI announcement: openai.com/index/codex-security-now-in-research-preview Via: securityweek.com

Check Point Research original disclosure: research.checkpoint.com/2026/voidlink-the-cloud-native-malware-framework

Cisco Talos active exploitation report: blog.talosintelligence.com/voidlink

Isovalent technical analysis: isovalent.com/blog/post/voidlink-cloud-malware-detection