// TRACK_02 :: BLUE_SIDE

WATCH THE WHOLE BANK.
DECIDE. THEN ACT.

Your agent consumes every cell's telemetry, recognises one incident as one incident, and acts only through the JengaSec Action API with a hard blast-radius cap and a kill switch. Blocking a legitimate customer is scored as damage.

LIT PROPOSAL REQUIRED
// Your_Mission

Two to three agents.
Per enterprise.

Build an autonomous defence agent that reads the enterprise's telemetry, decides what is happening, and acts through a permitted-action gateway.

2 TO 3 DEFENCE CELLS PER ENTERPRISE
4 TO 6 TEAMS ADVANCE IN TOTAL
~3 RED TEAMS PER DEFENDER
// The_Defence_Brief

Prompt-in, verdict-out
is not enough.

01

Consume the enterprise's full telemetry stream.

02

Combine deterministic analytics with model-based reasoning: prompt-in, verdict-out is not sufficient and scores poorly on technical complexity.

03

Map detections to MITRE ATT&CK and state the coverage gap honestly.

04

Correlate across cells so that one incident is recognised as one incident rather than five alerts.

05

Publish an action policy binding severity and confidence to alert, recommend or act.

06

Act only through the JengaSec Action API, with a hard blast-radius cap, per-window action budgets, and a reversal path for every action.

07

A kill switch that halts autonomy without halting detection.

08

Treat every telemetry field as attacker-controlled text.

09

Keep false positives low: blocking a legitimate customer is scored as damage.

10

Emit a decision log for every alert, recommendation and action, complete enough for a judge to reconstruct the reasoning after the fact.

Treat every telemetry field as attacker-controlled text. Your agent is the target of the AI Red track.

// Every_Blue_Cell

Eight rules.
No exceptions.

One container image per service, built by the provided pipeline, running as a non-root user with no privileged mode and no host mounts.

A single HTTP port from the PORT environment variable, with GET /healthz, GET /readyz, and a machine-readable GET /openapi.json that matches the implementation.

Configuration from environment variables and mounted secrets. A credential in the repository is an automatic finding, whether or not a Red Team discovers it.

Stateless services: all persistent state in the provided database or bucket: with idempotent migrations applied on deploy.

Transport security everywhere. Authorisation evaluated server-side on every request against the acting principal, never inferred from a client-supplied role.

Input validated against an explicit schema at the boundary, with unknown fields rejected rather than ignored. Errors must not disclose stack traces, queries, versions or internal hostnames.

Dependencies pinned and scanned, free of known critical vulnerabilities at submission. Rate limiting on authentication, search, export and any expensive operation.

Telemetry in the common envelope, emitted within five seconds of the action. Missing telemetry is scored as a missing security control, not as a documentation gap.

// Your_Proposal

Twelve core sections.
Plus ten for this track.

HEADINGS ARE NOT OPTIONAL :: Use the section numbers and titles below as your document headings, in order, exactly as written, for example 08 Threat Model. The platform reads headings to locate each section before a judge opens the file. A section under a different title, or merged into another, can be read as missing and scored as missing.

01
Executive Summary FRAMING

One page. What the team is building, for which brief, why it matters, and what will exist at the end of the build phase.

02
Problem Statement 10%

The specific security problem this component exists to solve, in its enterprise context. Not "cyber attacks are increasing".

03
Objectives

Three to six objectives, each specific and verifiable. "Implement MFA with recovery" is an objective; "improve security" is not.

04
Proposed System 15%

What the service does, its main flows, and its boundaries: including what it deliberately does not do.

05
System Significance 15%

Why this component failing would matter to JengaBank, and what an attacker gains by compromising it.

06
Functional Requirements 15%

A numbered, testable list covering every mandatory capability in the brief, plus the team's own additions marked as such. Must include a compliance table mapping every mandatory capability and every mandatory endpoint to the requirement that covers it.

07
Non-functional Requirements 15%

Performance, availability, scalability, maintainability and operability targets, with numbers attached.

08
Threat Model 20%

Assets, trust boundaries, actors, attack surface, threats enumerated using a named method (STRIDE, attack trees or equivalent), and the risks accepted.

09
Security Objectives 20%

The controls that answer the threat model, each traced to the threat it mitigates and to a recognised framework reference.

10
Proposed Architecture Diagram 15%

At least one component diagram and one data-flow diagram with trust boundaries marked, embedded as legible images, each with a text description beneath it.

11
Technology Stack 15%

Languages, frameworks, libraries, data stores and any AI models, with a justification for each significant choice and a note on its security posture.

12
Development Timeline 10%

Week-by-week plan across the build window, with named owners, dependencies and milestones. Must include time for testing and documentation.

// Additional_For_This_Track

Agent architecture: the perceive, reason and act stages, what runs where, and what state the agent keeps between events.

Model choice and hosting, with the reason for the choice, where inference runs, and the fallback when the model is unavailable.

Detection design: the deterministic analytics, the model-based reasoning, and how the two combine into a verdict.

MITRE ATT&CK coverage map: the techniques the agent intends to detect, and an honest statement of what it will not cover.

Action policy: the table of severity and confidence bands against alert, recommend and act, with the reasoning for where the autonomy boundary sits.

Safety design: blast-radius cap, action budgets, reversal path for every action, kill switch, and the behaviour when the agent is uncertain.

Adversarial robustness: how attacker-controlled text in telemetry is prevented from becoming instruction, and how the agent behaves under flooding and poisoning.

False-positive management: the expected cost of a wrong action on each action type, and the design that keeps it low.

The decision-log schema the agent will emit, with a worked example entry.

Resource budget plan: expected model calls, tokens, compute and wall-clock per hour of engagement: and an evaluation plan stating how detection rate, false-positive rate and time to detect will be measured before the engagement, and on what data.

UPLOAD FORMAT :: Attach a cover page, declaration of originality, and AI use statement. Missing any of the three is returned as incomplete. PDF only, selectable text, 12 to 20 pages excluding cover, contents, references and appendices. A4, margins >= 2 cm, body >= 11 pt, spacing >= 1.15, max 25 MB, English, no password or encryption. Filename: JS26_<ENTERPRISE>_<CELL>_<TEAMID>_<TYPE>_v<N>.pdf.

AI USE :: Editing your own text, diagrams from your own content, and human-verified research assistance are permitted when declared. Generating the threat model or security design without team authorship, unread citations, or undeclared use is not permitted.

// Before_You_Register

Ready in thirty minutes.
Or losing days.

Full legal name of every member, exactly as on their identity document.
Identity document per member showing date of birth. PDF, JPG or PNG, under 5 MB, photographed in good light with the whole document in frame.
Email per member, institutional if you have one.
GitHub or GitLab handle per member.
If enrolled: student number, institution, programme and year of study.
Captain and one deputy: phone number in international format, for example +254712345678.
Team name, three to forty characters.
Ranked track preferences for your side.
Skills declaration, 100 to 1500 characters, honestly describing what the team has built before. Overstating it earns you a brief you cannot complete.
Open The Full Checklist
// Final_Word

Design the kill switch first.
Then the detection.

> ./register --track=ai-defence-blue --team=4