The AI Security Letter: What It Gets Right and What It Skips

A letter started circulating this past week, initiated by OpenAI and signed by a long list of major tech companies, VerSprite included, after our own internal review. The premise: AI models, frontier-grade or otherwise, now automate enough of reconnaissance, data harvesting, and attack-surface fingerprinting that a proliferation of AI-driven cyberattacks should be expected in the near term. That’s not a new observation. What’s worth dissecting is what the letter actually asks organizations to do about it, and where that call to action holds up under scrutiny.

What the letter is asking for

Stripped down, the letter makes four asks:

1. Every organization should treat AI-era security as an immediate, non-negotiable priority.
2. Defenders should be empowered with AI-capable tooling to close the gap with attackers.
3. The industry needs a mobilized, collective response including partnerships with government and law enforcement.
4. Frontier AI companies need to provide responsible, governed model access.

None of these are wrong. The question is whether “AI is a big catalyst to cyber attacks” is actually news to anyone who’s been running a security program for the last decade, and whether bolting AI onto a security stack solves anything if the stack was never sound to begin with.

Fundamentals first, AI second

AI has been driving autonomous decision-making in production systems for well over a decade this isn’t a 2026 phenomenon. What has changed is how cheaply an attacker can now automate recon, subdomain enumeration, and attack-surface fingerprinting against a target. That’s a real shift. But status quo security the kind built around compliance checklists and vendor-recommended tooling rather than actual understanding of what’s running in an environment was already failing before AI entered the picture. AI just removes the lag time attackers used to need.

The uncomfortable finding here: most organizations still can’t answer basic attack-surface questions. Do you know what’s running in your environment? Is it legitimate? Can it be trusted? What permissions does it actually have? These aren’t new questions, and cybersecurity as a discipline has a poor track record answering them consistently. No amount of AI-powered defense tooling closes that gap if the underlying visibility isn’t there first.

There’s a version of “fight AI with AI” that’s true, and a version that’s marketing. The true version: you shouldn’t try to defend against AI-augmented attackers with zero AI-assisted visibility of your own. The marketing version: buying an AI security product substitutes for doing the harder, slower work of understanding what you’re actually implementing and why.

A useful gut check on threat modeling specifically if your threat model matches everyone else’s threat model, you don’t have a threat model. A model of threats that isn’t married to your own signals, your own systems, your own scar tissue isn’t telling you anything actionable. That’s the same critique that predates this letter by years and applies just as much to AI-specific threats as it did to any other category.

AI is a tool, not a hero or a villain

There’s a lot of noise right now board-level pressure to “address” one enterprise AI security tool or another as if adopting it is itself the security outcome. It isn’t. Using an enterprise AI tool for vulnerability discovery in your own environment is useful. Treating that adoption as the saving grace for security hygiene broadly is a category error.

The clearer framing: AI is a tool, not the enemy and not the hero. Attackers who are bad at their jobs don’t automatically become dangerous because they now have AI assistance the multiplier only applies to skill and intent that’s already there. And on the defensive side, 18 months of AI security tooling rollout has produced a lot of noise in engineering pipelines without a proportional increase in signal. Too much noise and not enough signal means there’s nothing tangible to actually act on which works directly against the point of this letter, not toward it.

Where AI-assisted automation is a genuine win

To be fair to the letter’s second point, there are real, unglamorous processes where AI-assisted automation helps immediately. Entitlement reviews are a good example traditionally done manually, infrequently (quarterly if you’re lucky, sometimes never, depending on the maturity of the industry). Local models can now baseline assigned users against identity stores like Entra, local AD, and Okta, and surface gaps far more often than a human-run quarterly review ever will. That’s the difference between DevSecOps and what’s increasingly becoming AI SecOps: security folded into the engineering lifecycle continuously rather than reviewed periodically. Engineering without security built in isn’t really engineering anymore that applies to requirements, design, development, testing, deployment, and maintenance alike.

The collective response is already how mature programs operate

The letter’s third ask mobilizing a collective response with government and law enforcement isn’t new territory for anyone who’s run a CISO program. Establishing relationships with local and federal authorities, sharing notes across jurisdictions, is standard practice for mature programs. Where it adds real value: threat actors are frequently operating under nation-state direction, and a detail that looks like a minor incident at the micro level can corroborate something a federal or international cybercrime unit is actively triaging at scale. That collective visibility spanning private industry and government also matters for identifying deepfake and executive-impersonation attacks, both of which are increasing.

Governance is a frontier-model problem, not just an enterprise one

The letter’s final point frontier AI companies providing responsible model access is arguably where the real onus sits. These companies occupy a position similar to Microsoft, IBM, and Apple during the dot-com era: new-era infrastructure providers with outsized responsibility for what they’re releasing into mass consumption. Enterprises can and should apply zero trust principles before ever sending sensitive data to a frontier model redaction and sanitization of financial data, IP, or data subject information before it leaves your own domain, regardless of vendor claims about private enclaves. But the leadership on governance and regulation ultimately needs to come from the frontier providers themselves, in partnership with government partly because they’re likely seeing signals in aggregate that individual enterprises can’t.

Where this leaves security teams

The letter is timely, and worth signing. But treating it as a mandate to bolt AI onto an existing security program misreads what it’s actually calling for. The starting line has moved not toward “buy an AI security tool,” but toward boards and executive committees having real visibility into their threat models, well past what compliance alone requires. The fundamentals it’s implicitly asking for attack surface management, non-generic threat modeling, zero trust, security embedded across the full development lifecycle are the same ones that were overdue a decade ago, when the shift to cloud-native architecture happened without shared responsibility models ever being properly enforced. AI didn’t create that gap. It just made the cost of ignoring it higher, and the timeline shorter.

Frequently Asked Questions