// Cyber Missions
The environment is real. So is the standard it is held to.
Every mission comes out of the XORCISE mission simulation engine. Each one is a contained operating environment (real hosts, real services, real limits) authored alongside the rubric it will be graded on and the terrain the agent has to work through. The agent gets freedom of action inside it; the network fence holds by construction rather than by trust.
And arriving is not the same as succeeding. The rubric weighs method, the checks weigh restraint, and the terrain records how much of the ground the agent ever understood, because an agent is trusted on how it worked, not only on where it finished.
// Catalogue
A public library, kept current.
The XORCISE library is Apache-2.0, the same licence as the engine, not a free tier of something else. It is added to periodically: new missions appear in the catalogue without you upgrading anything, because the catalogue is read from the remote server rather than baked into your install.
Missions are authored by Fifth Domain, not contributed, and they are distributed as prebuilt images rather than as a build tree you compile yourself. What you get under Apache-2.0 is the manifest, the rubric, the checks and the terrain, all readable on your machine before the first run, and the right to use, modify and redistribute what was shipped. What you do not get is our authoring pipeline. If you want a mission we have not written, the engine takes one you build yourself and grades it identically.
- Across the specialtiesVulnerability assessment, penetration, network defence, detection, forensics, software engineering and more.
- Graded by proficiencyBeginner through expert, so an agent can be stretched rather than merely passed.
- Pull what you needThe catalogue lists the whole library; installing downloads only the missions you choose.

// Declared up front
The standard ships with the mission.
Pulling a mission installs its full manifest, not just an image. Objective, rubric, deterministic checks, skills, technologies and terrain all sit on your machine before the first run: readable, versioned, and identical for every agent that attempts it. Nothing about how a run will be judged is decided after the fact. Pick a field to read what actually ships.
It is a local file, so you can read it yourself: every installed mission keeps its manifest under ~/.xorcise/missions/<id>/, and the same record backs the grading you see in the console.
manifest.metadata · the brief handed to every agent, unchanged between runs.
// Terrain
A map, and the path actually taken.
Each mission is authored as a graph: the hosts and services that exist, how they connect, and which node carries the objective. That is the terrain: the ground truth of what was there to be found.
During a run, the agent's actions are attributed back onto it. Nodes move from unknown to discovered to enumerated; edges light up as they are probed. What you get afterwards is not just whether the agent finished, but how much of the environment it ever understood, and which route it took to get there.
An agent that reaches the objective without enumerating the path to it scores differently from one that worked the terrain.

// What it measures
A flag is a proxy.
The public beta ships a CTF-derived library: missions authored by people, each built around a single recoverable objective and verified in part by a flag-correct check alongside the rubric. That is worth stating plainly, because it is a limit. A flag records that an agent arrived. It records nothing about how, and our own published benchmark found flag capture ordering models wrongly: the model that captured more of them still finished last once method was scored. The write-up →
It is also why the rubric carries half the score today rather than sitting alongside a pass mark. The direction is to drop the flag entirely: scenario missions scored on serials, an ordered chain of actions each tied to a training need and each proven by observables the run has to leave behind. The question stops being whether a token was submitted and becomes whether the action was performed, and evidenced. What an operator declines to do counts the same way: a decoy left alone is a result.
Scenario missions · in development
Pulled from us. Run by you.
The catalogue lives on our server; the mission does not. Pulling one downloads its image to your machine, and every run after that is local: your containers, your network, your evidence. Nothing about a run needs us to be reachable.
Missions are deliberately vulnerable by design: the library includes an Apache 2.4.49 host carrying CVE-2021-41773, and others like it. Images are not yet signed and ship no SBOM. Run them on a host you are willing to treat as untrusted, not one with routes into a network you care about; the per-run fence confines the agent, not the container image you chose to pull. How the fence is built →
Bring your own.
Add a mission from a local bundle and the engine builds its image alongside the library ones. It runs, grades and records identically. Importable mission packs, so a whole set can be shared as one artefact, are coming.
Mission packs · coming soon
Prove it on your own agent.
pip install xorciseApache-2.0 · Python 3.12+ · runs locally · no phone-home.