AI security in 2026: red teaming, jailbreaks, and the dual-use problem that never gets easier

The attack surface of a production AI system

A production AI system has a different attack surface from traditional software. Traditional software has defined inputs and outputs with explicit security boundaries. An AI system's core function is to interpret natural language instructions and act on them, which means the boundary between legitimate instruction and malicious manipulation is inherently fuzzy.

The main attack categories that security researchers were documenting in early 2026 fell into four broad groups. Each had distinct characteristics, risks, and mitigation approaches.

Red teaming: what it is and what it is not

Red teaming is the practice of deliberately attempting to find vulnerabilities or failure modes in an AI system before deployment. AI labs had been doing internal red teaming since at least 2022, and by 2026 most frontier labs had formal red team operations with dedicated staff.

The limitation of internal red teaming is structural. A team inside a company is incentivised to find problems that are fixable on the current release timeline. External red teamers, whether independent researchers or adversarial parties, have different incentives and often find different things. The US AI Safety Institute and its UK counterpart had been developing frameworks for independent pre-deployment evaluation, but in early 2026 these were still largely voluntary.

The challenge with red teaming AI systems is that you cannot test every possible input. A traditional software security audit can, in principle, review all code paths. An AI system with billions of possible inputs and emergent behaviours requires a different approach, one that is statistical and heuristic rather than exhaustive.

The dual-use problem

The dual-use problem is not new to technology, but AI presents it in a particularly acute form. An AI system capable of answering complex chemistry questions is also capable of answering questions that could facilitate harm. A model that can write persuasive text is also capable of generating misinformation. A model that can help debug code is also capable of helping an attacker write exploits.

The standard response from AI labs has been to train models to decline certain categories of request. This works reasonably well for the most direct forms of harmful requests. It works less well for indirect requests, for legitimate-sounding queries with harmful intent, and for adversarial users who invest time in finding approaches that work. The more capable the model, the more useful it is to legitimate users and the more useful it is to adversarial users simultaneously.

This is not a problem that better alignment training fully solves, because the capabilities and the risks are the same capabilities. A model that cannot help with any query that could theoretically be misused would not be useful for anything.

What the responsible disclosure of the Claude zero-day showed

The February zero-day disclosure was a positive data point for the industry. The researcher used Anthropic's bug bounty programme, received a payment, and the vulnerability was patched quickly. The disclosure was coordinated and professional.

What it also showed is that AI APIs have security vulnerabilities of the same type as traditional software. System prompt extraction is a real attack, not a hypothetical. The analogy to database injection attacks is not perfect but is instructive: when user input and trusted instructions share the same channel, clever manipulation can blur the boundary between them.

The certification question

By March 2026, a serious conversation was underway about whether AI systems deployed in high-stakes contexts should be required to meet a security certification standard analogous to Common Criteria for traditional software. The argument for is that enterprises deploying AI in financial, medical, or infrastructure contexts deserve assurance that the system has been evaluated against known attack categories.

The argument against is that AI systems evolve too quickly for traditional certification cycles, and that certifying a model at a point in time may provide false assurance as the model is fine-tuned, updated, or exposed to adversarial inputs post-certification. Both arguments have merit. The practical resolution is probably a framework that requires continuous monitoring rather than point-in-time certification, analogous to SOC 2 Type II rather than an ISO certification.