AI Security: The Gap Nobody Wants to Address

When Zvi Mowshowitz publishes something about governance, it's worth reading carefully. Not because he's always right, but because he tends to identify exactly the crack that industry consensus prefers to ignore. His latest Substack article, published this week, has a title that itself serves as a diagnosis: Cyber lack of security and AI governance. And the central argument is as uncomfortable as it is predictable: the AI industry moves faster than any reasonable security or accountability structure can accommodate.

The piece arrives at a moment when the debate over language model governance has shifted from academic forums to corporate boardrooms, yet without translating into concrete operational standards. The Hacker News thread has limited traction so far, which itself is telling: either the topic feels too abstract, or fatigue from AI risk discussions is starting to weigh heavily.

What the Article Says

Mowshowitz articulates a two-part thesis. First: conventional cybersecurity was already an unsolved problem before LLMs entered corporate workflows. Second: the arrival of AI agents capable of executing tools, accessing APIs, and operating with a degree of autonomy has substantially expanded the attack surface, without existing governance frameworks evolving at the same pace.

This isn't a new argument, but Mowshowitz develops it with more precision than most. He distinguishes between risks inherent to the models themselves (hallucinations, bias, misaligned behavior) and systemic risks that emerge when those models connect to real infrastructure. An agent that can read email, execute code, call external services, and write to databases isn't just a chatbot with more capabilities: it's an attack vector with credentials.

Why It Matters Now

In May 2026, this debate has a concrete technical context. Claude Code, Anthropic's official CLI, allows you to configure subagents, hooks that fire on session lifecycle events, and MCP servers that expose external tools to the model. The flexibility is real and useful. But each MCP server added to `claude_desktop_config.json` is also a new surface that can be compromised, misconfigured, or exploited through prompt injection.

Claude Code hooks, for example, execute shell commands on events like `PreToolUse` or `PostToolUse`. If an attacker manages to influence the input reaching the model at those moments, they can attempt to make the hook execute something other than what the developer intended. This isn't science fiction: it's basic systems engineering applied to a new environment.

The problem isn't that these tools exist. The problem, as Mowshowitz points out, is that most teams deploying them lack security protocols to match. Teams that would apply exhaustive review to a change in a payments API install third-party MCP servers with minimal checks.

Who This Affects

This discussion is especially relevant for three groups. First, engineering teams building on Claude Code or any other agent environment: they need to incorporate threat modeling from design, not as an afterthought patch. Second, corporate security leaders who have treated AI as just another productivity tool: the operational autonomy of current agents demands a different category of analysis. Third, those working in technology policy: AI governance cannot be reduced to debating whether models are "safe" in the abstract, without addressing how they integrate into real infrastructure.

Mowshowitz doesn't offer a ten-point plan or a regulatory roadmap. What he offers is a map of the gap between what exists and what would be needed. Sometimes, that's more useful.

---

From our perspective, we've spent months watching how the conversation about security in the Claude ecosystem stays at the model layer and rarely descends to the integration layer. Mowshowitz's article doesn't solve anything, but it frames the problem with enough rigor that ignoring it is now a conscious choice, not an accidental omission.