THE DEFENDER IS A MACHINE.
MAKE IT BETRAY THE BANK.
You attack the AI Defence agent, not the applications. Instruction injection through telemetry, evasion, budget exhaustion, and inducing it to act against legitimate users. An autonomous attacking agent needs a declared containment design and a kill switch before it is allowed into the range at all. That is why AI Red submits a proposal.
Three attackers.
For every defender.
Attack the defence agent itself: instruction injection through telemetry, evasion, budget exhaustion, and inducing it to act against legitimate users.
A Red Team without an approved proposal does not receive range credentials.
What the defender
was told to do.
The agent you attack was built to this brief. Every sentence is a surface.
Consume the enterprise's full telemetry stream.
INSTRUCTION INJECTIONCombine deterministic analytics with model-based reasoning: prompt-in, verdict-out is not sufficient and scores poorly on technical complexity.
EVASIONMap detections to MITRE ATT&CK and state the coverage gap honestly.
EVASIONCorrelate across cells so that one incident is recognised as one incident rather than five alerts.
INSTRUCTION INJECTIONPublish an action policy binding severity and confidence to alert, recommend or act.
BUDGET EXHAUSTIONAct only through the JengaSec Action API, with a hard blast-radius cap, per-window action budgets, a reversal path for every action, and a kill switch that halts autonomy without halting detection.
BUDGET EXHAUSTIONTreat every telemetry field as attacker-controlled text.
INSTRUCTION INJECTIONKeep false positives low: blocking a legitimate customer is scored as damage.
INDUCED ACTION AGAINST LEGITIMATE USERSEmit a decision log for every alert, recommendation and action, complete enough for a judge to reconstruct the reasoning after the fact.
EVASIONTreat every telemetry field as attacker-controlled text. Your agent is the target of the AI Red track.
Your agent is a system.
It needs safety design.
An autonomous attacking agent is itself a system that needs safety design. These sections are a condition of being permitted to run one in the range at all.
- Agent architecture: what the agent perceives, how it plans, what tools it may call, and what it does when it is uncertain.
- Autonomy boundary: which actions the agent takes without a human, and which require a team member to confirm.
- Containment design: how the agent is prevented from acting outside the assigned cell: the technical control that enforces it, not the intention that guides it.
- Kill switch: how a team member or an organiser halts the agent within seconds, and what state it leaves behind.
- Action and resource budget: the ceiling on requests, model calls and duration, and how it is enforced.
- Attack taxonomy: which attack classes the agent will attempt, and how each will be evidenced.
- Attribution: how every action the agent takes is traceable to this team, so that its activity can be separated from the other Red Team attacking the same cell.
- Rollback: what the team will do if the agent causes unintended disruption to a Blue cell's availability.
Fifteen sections.
Eight more for the agent.
HEADINGS ARE NOT OPTIONAL :: Use the section numbers and titles below as your document headings, in order, exactly as written, for example 08 Reconnaissance Plan. 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.
Scored on preparation and professionalism rather than on results. It doubles as the record that the team understood and accepted the rules of engagement before being given access.
The target cell, the team's approach in one page, and what a successful engagement would demonstrate.
What the assigned cell is for, its role in the enterprise, its published interface, and what the team assesses to be its most valuable assets.
Everything in scope, restated in the team's own words, and everything out of scope. Errors here are the most common cause of rule breaches.
Explicit, itemised acceptance of the rules of engagement, signed by every member.
The adversary being simulated: external unauthenticated, authenticated customer, malicious insider, compromised partner: and the capability and motivation assumed.
Six to ten specific, testable hypotheses about where the cell is likely to be weak, derived from its domain and its published interface.
The phases of the engagement, the standard being followed (PTES, OWASP WSTG, OSSTMM or equivalent), and the mapping to MITRE ATT&CK tactics.
What will be enumerated in the recon window, with what tooling, at what rate.
At least three chains from initial access to objective, each with the expected evidence and the expected impact.
Every tool to be used, with versions. Any custom tooling described, with its intended behaviour and its safety limits.
How the team will avoid data destruction, uncontrolled disruption and scope escape, including the rate limits it imposes on itself.
How evidence will be captured, timestamped, stored, redacted and destroyed.
Who does what in which window, and how the activity log will be maintained.
The structure of the final report, the severity model to be used with the CVSS version stated, and how remediation advice will be developed.
Signed statement on lawful conduct, confidentiality of anything discovered, and the obligation to report real-world risk immediately.
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, 8 to 14 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 attack methodology or safety design without team authorship, unread citations, or undeclared use is not permitted.
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.