MAX Authorization Challenge — Rules and Authorization Scope

Version 1.0 — September 6, 2026

1. Authorized Environment

The only environment expressly authorized for offensive security activities is the local challenge sandbox downloaded by the participant and run on systems controlled by the participant.

All analysis, testing, modification, reverse engineering, and bypass attempts must take place within that local environment.

The mere accessibility of a hostname, IP address, subdomain, service, or infrastructure does not constitute authorization to test it.

2. Use of AI, AI Agents, and Automated Tools

Within their own local sandbox, participants may freely use:

• local or cloud AI models;
• autonomous AI Agents;
• multi-agent systems;
• agent frameworks;
• debuggers;
• fuzzers;
• scripts;
• reverse-engineering tools;
• static analysis;
• dynamic analysis;
• automation;
• custom tooling;
• any other lawful technical method applied exclusively to the local sandbox.

Participants may also delegate the entire local analysis process to one or more autonomous AI Agents.

3. Challenge Objective

The sandbox exposes three actions:

• STATUS
• PING
• READ_SECRET

The active valid manifest authorizes STATUS and PING.

READ_SECRET is not authorized.

The challenge is solved only if the participant succeeds in obtaining the exact hosted secret while READ_SECRET remains unauthorized by the active valid manifest.

4. What Does Not Constitute a Valid Solution

The following do not constitute a valid solution:

• obtaining an output merely different from DENY;
• causing HTTP 400 errors;
• causing HTTP 500 errors;
• causing crashes;
• causing timeouts;
• causing denial of service or resource exhaustion;
• executing STATUS;
• executing PING;
• obtaining results only in the participant’s local sandbox without demonstrating the bypass through the remote verifier;
• compromising systems, services, or infrastructure other than the local sandbox.

The hosted secret is the proof of a successful solution.

After obtaining the hosted secret through a valid bypass, the participant must submit it through the challenge’s standard CTFd submission system.

5. Role of the Remote Verifier

The remote service associated with the challenge is not an authorized target for offensive security activities.

It exists exclusively to verify a specific bypass technique that has already been developed and validated against the local sandbox.

The remote verifier is available exclusively to participants who are registered for the MAX Authorization Challenge and authenticated through the official challenge platform.

The verifier endpoint provided through the private challenge area must not be disclosed, published, forwarded, or otherwise shared with unregistered third parties.

Possession or knowledge of the verifier endpoint does not, by itself, constitute authorization to use the service. Any person who obtains it from another participant, through accidental disclosure, or by any other unauthorized means is not authorized to access, use, or test the verifier.

Use of the remote verifier by unregistered persons is outside the authorized scope of the challenge.

Interaction with the remote verifier must be:

• manual;
• limited to requests reasonably necessary for verification;
• exclusively intended to verify a technique already developed locally.

The remote verifier must not be used for general exploration, scanning, fuzzing, brute force, enumeration, autonomous probing, denial-of-service testing, resource exhaustion, or any other offensive remote activity.

6. Automation Prohibited Against Remote Systems

The following may not be used against CTFd, the remote verifier, or any other remote infrastructure:

• autonomous AI Agents;
• bots;
• crawlers;
• scanners;
• remote fuzzers;
• automated attack scripts;
• multi-agent systems;
• automated exploitation frameworks;
• enumeration automation;
• brute-force tools;
• autonomous probing systems.

Automation is authorized only against the local sandbox.

7. Out-of-Scope Systems

The following are expressly out of scope:

• CTFd;
• hosting infrastructure;
• the network provider;
• proxies, load balancers, and infrastructure services;
• accounts and credentials;
• other participants;
• other users;
• other challenges;
• other containers;
• other tenants;
• max-russo.com, except for normal website browsing;
• domains, subdomains, hosts, or services not expressly identified as part of the local sandbox;
• any third-party system or data.

8. Prohibited Remote Activities

The following activities are prohibited against remote systems:

• port scanning;
• service enumeration;
• vulnerability scanning;
• remote fuzzing;
• brute force;
• credential stuffing;
• credential attacks;
• attempts to compromise CTFd;
• attempts to compromise the hosting provider;
• denial of service;
• DDoS;
• resource exhaustion;
• attempts to interfere with other users;
• attempts to access data belonging to other participants;
• attempts to escape or break out of the intended challenge environment;
• any activity not necessary for the manual verification of a bypass already developed locally.

9. Limits of Authorization

The authorization granted by the organizer applies exclusively to what is expressly stated in these rules.

The organizer does not authorize, and cannot authorize, activities against infrastructure, services, data, or systems belonging to third parties.

Participants must also comply with the applicable terms of use, policies, and laws governing any third-party services and tools they choose to use during the challenge.

Any activity not expressly authorized by these rules must be considered out of scope.

10. Technical Nature of the Sandbox

The sandbox is an environment created specifically for authorized security testing.

It does not represent a real production system and does not contain:

• operational credentials;
• operational private keys;
• real third-party data;
• real databases;
• real MAX infrastructure;
• real MAX IoT systems.

The challenge secret is a value created exclusively for the contest.

11. Interpretation of the Result

A valid bypass would demonstrate a real issue in the implementation tested by the challenge.

The challenge does not demonstrate the absolute security of:

• MAX;
• SPHINCS+;
• MAX IoT;
• the authorization model;
• AI Agent authorization in general.

If no participant demonstrates a valid bypass, the only correct conclusion is:

“No bypass was demonstrated within the scope and conditions tested.”

The absence of a solve does not constitute proof of absolute security.

12. Official Challenge Period

The challenge opens on:

September 13, 2026

and closes on:

September 29, 2026

Submissions made outside the official challenge period may not be considered valid for the leaderboard, official results, or any recognition.

13. Scope Violations

Participants must comply with the authorization scope defined in these rules.

The organizer reserves the right to exclude from the official results any participant who violates these rules or carries out unauthorized activities against remote systems, third-party infrastructure, or other participants.

14. Fundamental Rule

In summary:

The attack happens locally. The online service is only used to verify the result.

Participants may use any AI, AI Agent, or technical tool against their own local sandbox.

The remote service is not an attack target.