A handful of engineering teams now sit at the center of a strange paradox: they're constructing the very defenses organizations will rely on against tomorrow's sophisticated AI-driven attacks, while simultaneously assembling the tools that attackers will use to launch them.

This April, Anthropic extended invitations to over 50 organizations to join Project Glasswing, an early-access program for Claude Mythos — a model the company positioned as its most capable cybersecurity-focused AI to date. OpenAI wasn't far behind, launching its own preview effort called Daybreak to give select organizations hands-on access to GPT 5.5.

In the months since, penetration testers acting as red teams have turned these models loose on their own organizations' infrastructure, probing for weaknesses, while opposing blue teams have raced to spot and neutralize the resulting exploits. Caught between both sides are the engineers themselves — simultaneously designing safeguards against the models' most dangerous capabilities and building the very frameworks needed to harness their power.

This dual role has a name in security circles: "yellow" teaming, a concept that emerged from a Black Hat 2017 talk advocating for developers to be woven directly into security testing workflows. Today, it's these yellow teams who are quietly setting the trajectory for cybersecurity's next era.

Inside the Rooms Where Yellow Teams Operates

Sam Curry, CISO at Zscaler and a Project Glasswing partner, describes the yellow team's role as essentially product development for security: they ask red teamers what tools would make their attacks more effective, functioning as though they were the R&D division of a sophisticated adversary. At the same time, they ask blue teams what protective capabilities are missing from what current vendors offer.

Yellow Teams Step Into New Territory

Traditionally, yellow teams haven't spent much energy building tools for red teams. That's changing, though, as programs like Project Glasswing push companies to figure out how to actually put Mythos to work. Netskope's CISO, James Robinson, found the learning curve steeper than expected. The model wasn't something you could simply point at a target and walk away from — it hedged conclusions and flagged issues without the situational awareness a human tester would have. In one instance, it flagged an internal endpoint as insecure simply because it lacked authentication, missing the fact that the endpoint was never internet-facing to begin with — a detail that would have been obvious to a person conducting the same review.

This pattern shows up again and again: security teams expect to hand the AI free rein, then quickly discover it needs guardrails and context humans take for granted. Robinson's team had already learned this lesson, though — Netskope had gone through OpenAI's Daybreak program before joining Glasswing, standing up a small internal group called Project Red Horizon specifically to build a working harness around GPT-5.5.

Wrapping Mythos and GPT-5.5 in Structure

Think of a harness as a containment layer wrapped around an AI model — it dictates exactly what the model is permitted to do, what access it holds, and which rules and safety boundaries it must operate within. That might sound restrictive, but the opposite is true. For both attackers and defenders alike, getting the harness right is arguably the single most important step in making AI-powered vulnerability discovery actually work.

The Hard Part: Making Mythos and GPT-5.5 Useful

Constructing a harness that actually performs well is far from simple. Robinson recalled that Netskope's early attempts to contain GPT-5.5 produced an overwhelming volume of results — not because the model was thorough, but because the surrounding context hadn't been properly configured, leaving the team to sift through a flood of false positives.

Getting an AI model to focus its capabilities productively takes real engineering effort. Cisco, another Glasswing participant, chose to open-source its own solution: the Foundry Security Spec. The framework governs model behavior through a detailed set of guiding principles — its "constitution" — and organizes the work across 13 distinct agent roles (from orchestration to detection, triage, and reporting), collectively responsible for roughly 130 individual sub-requirements. Microsoft took a similar but distinct path with MDASH, deploying over 100 specialized agents that hunt for bugs independently across a five-stage process. Cloudflare's approach, meanwhile, structures its vulnerability-discovery harness around an eight-step workflow.

Harnesses Alone Aren't Enough

A well-built harness is only part of the equation — organizations also need a deliberate strategy for how to actually use it. Omar Santos, a distinguished engineer on Cisco's AI Security Engineering team, breaks his team's approach into three tiers of complexity. At the simplest level, red teamers feed the harnessed model outputs from earlier static analysis and direct it to craft exploits against live systems. A step up in sophistication, the team incorporates product documentation, historical bug reports from past advisories, and years of accumulated offensive-security knowledge, allowing the model to link multiple vulnerabilities together and carry out post-exploitation analysis. At the most advanced tier, the team works directly with binary files, simulating an attack in an environment stripped of any actual software.

Preparing for What Comes Next

Organizations that have successfully harnessed Mythos and GPT-5.5 are uncovering vulnerabilities by the thousand — including flaws that have persisted for decades in foundational technologies, along with intricate exploit chains. That surge in discovered risk has pushed blue teams to lean on yellow teams for help making sense of what these models are finding.

Levi Bolourie, Zscaler's corporate CISO, warns that blue teams risk being buried in signals and alerts if they don't bring AI into their analysis process — and as that volume keeps climbing, he expects the line between blue and yellow teams to blur considerably. That shift is already visible at Netskope, where engineers now find themselves woven into the patching workflow in ways they weren't before. Robinson describes a new dynamic where red and blue team members actively bring yellow team engineers up to speed — flagging a discovery from Mythos and pushing to get it patched quickly — giving those engineers a front-row seat to problems they'd never previously had visibility into.

But Bolourie stresses that one-time fixes miss the point. The real goal for yellow teams is embedding these AI models and their output directly into the software development lifecycle itself, using what's learned to change practices upstream and stop the same categories of vulnerabilities from resurfacing. Cisco has largely automated this feedback loop by pairing its Foundry Security Spec with CodeGuard, its companion open-source framework for secure AI-assisted coding — the defensive system feeds its knowledge to the offensive one, and whatever new issues the offensive side uncovers flow back into defense. Netskope runs a similar loop, but through people rather than pure automation. Robinson recalls that the Daybreak program gave rise to a daily scrum ritual, where yellow and red team members compared notes on how they were using the models, what they'd discovered overnight, and logged those findings for the record.