No. 07 · Technical

Red, Blue, Green, and Yellow Agents

Four review agents, bundled into the harness, that check every application for quality, consistency, and security before it ships.

Abstract. If AI writes and repairs the code, something has to check the AI. Four review agents ride inside the harness, each nicknamed for a colour. Green checks code quality and hygiene. Yellow checks how the writing reads. Red attacks the application the way an outsider would. Blue defends it, judging the code against an international security standard and turning the evidence into a verdict a decision-maker can act on. These agents are bundled into the harness as checks and balances: a piece of work cannot be called done until it passes. Security and quality stop being something we chase after the fact and become first-class concerns.
The earlier papers set out two halves of the same problem. We can now find what is wrong across the whole estate, from the rising cyber pressure to the health of every repository, and we have four ways to rebuild it. Both halves lean on AI doing the work. That raises the obvious question. If an AI writes or repairs the code, who checks the AI? Four review agents, each named for a colour, ride inside the harness and inspect every application for quality, consistency, and security. They are the checks and balances on everything the builders produce.


## §01 Who checks the AI

The colours come from security practice, where red is the attacker and blue is the defender. We added two more. Green covers code quality and hygiene. Yellow covers how the content reads. Each colour is a separate agent and looks at the work from an angle the others do not. A developer runs each agent throughout the development lifecycle process and at every milestone in the project.

The four are split on purpose between mechanical and judgment work. Green and Yellow are fully deterministic: give them the same code and they return the same findings every time. Red's reconnaissance is deterministic too, with one step that uses Claude to plan how an attack would go. Blue is mostly judgment, the kind a senior reviewer brings. Determinism is what lets an agent act as a gate that never drifts. Judgment is what catches the problem a checklist would miss. The harness uses each where it fits.


## §02 Green: quality and hygiene

Green is the foundation, and it runs first. It reads the code and reports the plain facts of its health. Which dependencies carry known vulnerabilities. Whether a password or key has been committed into the source. Whether dangerous patterns are present. How much of the code the tests actually cover. It works in two rounds: the first reads the code without running it, the second runs the existing tests and watches what happens, including which parts of the code the tests never touch.

Because Green is deterministic, the same code always produces the same findings. That is what makes it the evidence base every other agent builds on. It does not guess; it counts. When it flags a file with almost no test coverage, or a secret sitting in the source, that finding is a fact rather than an opinion, and it can be checked the same way twice.


## §03 Yellow: how the content reads

Yellow reads the application content. Government software carries a lot of prose: documentation, the copy inside the interface, release notes, the messages a citizen actually sees. When AI writes that prose it leaves tells, the turns of phrase that mark text as machine-made and quietly erode trust. These tells are often called 'AI smell'. Yellow walks twelve rules across every piece of writing in the project and flags each tell with the offending line, a plain rewrite, and a short note on why it reads as a machine wrote it.

These are the same rules that govern the papers you are reading now. An em dash, a stock cliché, a fawning opening, an "ensure" standing in for a real verb: each is caught and named. The point is simple. If the public is going to read it, it should read like a person wrote it. Yellow is the cheapest of the four to run, a matter of seconds, and it keeps the whole estate sounding human.


## §04 Red: the attacker

Red is the attacker. It looks at a finished application the way an outsider with bad intentions would, from the outside in. It maps the domain and its subdomains, scans for open ports, checks the encryption and the security headers, and works out which technologies are in use. That reconnaissance is ordinary, repeatable tooling, and it runs on any machine without special setup.

Then Red does the part that used to need a specialist. It reasons over everything it found and plans how it would break in, proposing concrete attack paths: slipping past a login, chaining a remote exploit, drawing data out a side door. In that planning step, Claude does the thinking, and it is the one part of Red that varies from run to run. Red only ever runs against systems the government owns and has authorized for testing. Its job is to find the hole before someone else does, and to hand the next agent a map of how an attack would actually unfold. It is the adversary that helps knock down your application long before it makes it out into the world.


## §05 Blue: the defender

Blue is the defender, and it runs last because it reads everything the others found. It builds a map of the application, classifies how sensitive each part is, and writes a threat model. Then it walks every requirement in the OWASP Application Security Verification Standard at Level 2, the international baseline for a serious web application, and records each one as pass, fail, or not applicable, with the evidence behind the call. It checks the same code against Alberta's cybersecurity architecture standard, folds Red's reconnaissance into a step-by-step picture of how an attack would unfold, and writes security tests that prove each fix holds.

Blue's last act is to write the report a decision-maker can act on. An executive summary. The findings ranked by severity. The standards met and missed. A remediation plan that points to the exact files. Where Green counts and Red probes, Blue judges, the way a senior security architect would, and turns a pile of evidence into a defensible verdict that an auditor can follow.


## §06 Four agents, one system of checks and balances

On their own, each agent is useful. Together they are a system of checks and balances. Green and Yellow run first and fast, side by side. Red attacks from the outside. Blue takes the deterministic evidence from Green and the attack picture from Red and renders the judgment. The deterministic agents give gates that never regress; Blue gives the expert read a checklist alone would miss. No single agent could do all jobs, so the work is divided four ways and recombined at the end.

What turns these reviews from advice into enforcement is that they are bundled into the harness as gates. The harness will not let a piece of work be called done if the security scan shows a critical finding, if the scan is stale, or if the review never ran. Every "must do" is backed by a check that fails loudly when it is skipped. The gates are mechanical, not aspirational.

Across sixteen categories, from authentication and session handling to cross-site request protection, input validation, and supply-chain hygiene. The estate gets a little safer with every pass, and the lesson is kept rather than relearned.

Security controls built into the template the agents check against ~95. The four agents check each application against this baseline on every pass.

"Security and quality stop being something we chase after the fact, and become a property of how the code is made." · Paper 7 · Red, Blue, Green, and Yellow Agents

The apps produced in concern with these four agents address the critical challenges raised within The Cyber Imperative. The build methods from The Four Approaches are safe to run at speed. The builders get their speed, and the public gets code that has been attacked, defended, and proof-read before it ever reaches them.


## §07 What it runs on: Claude, the Agent SDK, and Vertex

All of this runs on the Anthropic Claude platform. The deterministic agents, Green, Yellow, and Red's reconnaissance, are ordinary code that needs no model at all. The parts that call for judgment, Red's attack planner and Blue's whole assessment, are built with the Claude Agent SDK, the toolkit for running a model through many steps with a fixed set of tools and a budget of turns. The harness pins which model does which job and how hard it is allowed to work, so a review is repeatable and its cost is known before it starts.

Alberta runs these models through Claude on Google Vertex AI, now the Google Agent Platform. That keeps the work inside a governed Canadian cloud, with the model provider held behind a clean boundary so it can be changed as the field moves. The same boundary lets a local or open model be tested against the commercial one on identical work, which matters as the economics shift. The agents do not care which model answers, only that the answer meets the standard.


## §08 What this gives the builders

The four agents are how Alberta makes "the AI built it" a sentence a security reviewer can trust. They catch what a tired person would miss, they never skip a step, and they turn quality and security from a hope into a gate the code has to pass. The builders move faster because the safety net is automatic and always on, and because a found problem becomes a permanent rule rather than a recurring surprise.

With the harness and its review agents in place, the question turns to the factory that puts them to work on every build. The next papers open up that factory: where applications are designed and specified, where agents build and test them under these same controls, and where the work is tracked and measured.

Tags: security, agents, harness, red-team, quality

Open the interactive version