In partnership with

WEEK 49 AI 3X3 BRIEF

Welcome to Week 50's AI Security 3x3 Brief.

TL;DR: A new report confirms most organizations have no visibility into how AI handles their data, Cisco research shows open-weight models collapse under conversational pressure, and a new vulnerability class called "IDEsaster" just exposed every major AI coding assistant to remote code execution.

🚨 DEVELOPMENT 1

The AI Governance Gap Just Got Quantified

The 3 Key Points:

1. What Happened: The 2025 State of AI Data Security Report, produced by Cybersecurity Insiders with research support from Cyera Research Labs, surveyed 921 cybersecurity and IT professionals and found a stark disconnect: 83% of organizations already use AI in daily operations, but only 13% have strong visibility into how these systems handle sensitive data. Two-thirds have caught AI tools over-accessing sensitive information. And 23% admit they have no controls for prompts or outputs whatsoever.

2. Why It Matters: The report introduces a concept worth internalizing: AI as an "ungoverned identity." Unlike human users who work within defined access policies, AI systems read faster, access more, and operate continuously—often with permissions inherited from whoever deployed them. Most organizations still apply human-centric identity models to machine-speed processes. That mismatch is the blind spot attackers will exploit.

3. What You Need to Know: This isn't a maturity problem—it's a visibility problem. You can't govern what you can't see. If your organization is in the 87% without strong AI visibility, the question isn't whether you have risk exposure. It's how much.

For Enterprises: Treat AI as a distinct identity class. Map what data each AI system can access, audit prompt and output flows, and implement AI-specific access policies separate from user permissions.

For SMBs: Before adopting any new AI tool, understand its data handling policies. At minimum, implement basic access controls and maintain an inventory of which AI tools touch which data.

FROM OUR PARTNERS

AI that works like a teammate, not a chatbot

Most “AI tools” talk... a lot. Lindy actually does the work.

It builds AI agents that handle sales, marketing, support, and more.

Describe what you need, and Lindy builds it:

“Qualify sales leads”
“Summarize customer calls”
“Draft weekly reports”

The result: agents that do the busywork while your team focuses on growth.

🔐 DEVELOPMENT 2

Multi-Turn Attacks Flip AI Defenses from 87% to 8%

The 3 Key Points:

1. What Happened: Cisco AI Defense researchers published findings showing that open-weight AI models block 87% of single malicious prompts—but when attackers persist across multiple conversational turns, success rates for the attacker climb to 92%. That's not a typo. The models that pass single-turn safety benchmarks fail catastrophically under sustained conversational pressure. The research tested eight popular open-weight models from Meta, Mistral, Alibaba, and Google.

2. Why It Matters: The vulnerability is systemic, not model-specific. Techniques like "Crescendo" (gradually escalating requests), "Role-Play" (establishing fictional contexts), and "Contextual Ambiguity" (confusing safety classifiers) achieved success rates exceeding 90% against multiple models. Mistral Large-2 hit 95% jailbreak success with information decomposition attacks. The pattern is clear: capability-first development produces capability-first security gaps. Meta's Llama showed a 70% security gap between single and multi-turn attacks. Alibaba's Qwen posted 73%.

3. What You Need to Know: If you're deploying open-weight models for customer-facing chatbots, internal copilots, or autonomous agents, single-turn safety benchmarks are misleading. Your models may pass evaluation while failing in production.

For Enterprises: Implement context-aware guardrails that monitor entire conversations, not individual prompts. Conduct continuous red-teaming that includes multi-turn attack scenarios. Harden system prompts and limit model integrations with automated external services.

For SMBs: Favor AI tools from vendors that prioritize safety alignment over raw capability. Ask vendors specifically about multi-turn attack resilience. Be wary of tools allowing extensive customization without corresponding security controls.

⚠️ DEVELOPMENT 3

"IDEsaster" Proves Your Coding Assistant Is an Attack Surface

The 3 Key Points:

1. What Happened: Security researcher Ari Marzouk disclosed over 30 vulnerabilities affecting every major AI coding assistant tested—GitHub Copilot, Cursor, Windsurf, Claude Code, Gemini CLI, Kiro.dev, Zed.dev, Roo Code, JetBrains Junie, and Cline. The vulnerability class, dubbed "IDEsaster," combines prompt injection with legitimate IDE features to achieve data exfiltration and remote code execution. Twenty-four CVEs have been assigned. AWS issued security advisory AWS-2025-019. Microsoft patched CVE-2025-64671 (GitHub Copilot for JetBrains) in this week's Patch Tuesday.

2. Why It Matters: IDEsaster isn't about buggy AI tools—it's about how AI agents interact with IDE features that were never designed for autonomous components. Attackers can hide instructions in README files, documentation pages, or code comments that humans skip but AI parses. The AI then triggers legitimate IDE functionality (like editing configuration files or fetching remote JSON schemas) to execute malicious actions. One attack chain: inject a prompt that makes the AI edit .vscode/settings.json to point php.validate.executablePath to an attacker-controlled script. When PHP validation runs, you've got code execution.

3. What You Need to Know: 100% of tested AI IDEs were vulnerable. The fundamental issue: AI agents operating with developer permissions in environments designed before autonomous code-writing existed. Traditional security tools won't catch this because the payload is natural language, not malware.

For Enterprises: Treat AI coding assistants as privileged integrations requiring the same scrutiny as any tool with file system and network access. Disable auto-approval for AI tool actions. Run AI assistants in containerized, network-restricted environments. Audit which repositories and projects AI tools can access.

For SMBs: Only use AI coding assistants with trusted projects and files. Connect only to trusted MCP servers and monitor them for changes. Manually review sources you add (URLs, documentation) for hidden instructions—comments in HTML, CSS-hidden text, and invisible Unicode characters can all carry prompt injections.

🎯 ACTION PLAN

Your Key Action This Week:

Inventory your AI exposure across three dimensions:

  1. Which AI tools have access to sensitive data and what governance exists?

  2. Which customer-facing or internal AI applications use open-weight models, and have you tested multi-turn attack resilience?

  3. Which developers use AI coding assistants, and what permissions do those tools have? If you can't answer all three, you've identified your first priority.

💡 FINAL THOUGHTS

Your Key Takeaway:

his week's developments share a through-line: AI systems are creating ungoverned spaces faster than security teams can map them. The governance gap means most organizations can't see what their AI accesses. The multi-turn vulnerability means models that appear safe aren't. And IDEsaster proves that even developer tools—the infrastructure security teams rely on—have become attack surfaces.

The organizations that treat AI as both a capability and a threat vector will adapt. The ones that don't will learn why "ungoverned identity" became a term security teams use in incident reports.

How helpful was this week's email?

Login or Subscribe to participate

We are out of tokens for this week's security brief.

Keep reading and learning and, LEAD the AI Revolution 💪

Hashi & The Context Window Team!

Follow the author:

Keep Reading

No posts found