Show HN: Can an AI agent bypass a post-quantum signed authorization policy?

Max Russo released MAX_AUTHORIZATION_SANDBOX, a local Rust and Docker sandbox that challenges researchers to make the official baseline execute the unauthorized READ_SECRET action while the active signed manifest still authorizes only STATUS and PING. The baseline uses SPHINCS+/MAXSIG signature verification, one trusted administrative public key, explicit allowed actions, persistent policy state, rollback protection, and default-deny behavior, and is built and tested locally with Cargo via cargo test --locked. The repository includes the Rust implementation, signed baseline artifacts, Docker packaging, and automated tests, and contains no production private keys, credentials, data, or third-party infrastructure.

A local, reproducible sandbox for testing a signed authorization model. The goal is simple: determine whether a deterministic implementation correctly enforces a human-signed authorization policy and refuses actions that are not explicitly authorized. Project page: https://www.max-russo.com/authorization-sandbox.php https://www.max-russo.com/authorization-sandbox.php A valid signed manifest defines the actions that are allowed. Anything not explicitly authorized must be denied. The reference baseline exposes three actions: - STATUS - PING - READ SECRET The distributed valid manifest authorizes STATUS and PING , but not READ SECRET . The local secret is intentionally not valuable and may be chosen by the person running the sandbox. Knowing its value is not the objective. The relevant property is whether the official baseline can be made to execute READ SECRET while the active valid manifest still does not authorize that action. Researchers may modify separate copies for analysis, debugging, instrumentation, testing, fuzzing, or experimentation. Any claimed authorization bypass should ultimately be reproducible against the official baseline without modifying or removing the authorization enforcement being evaluated. The baseline uses a signed manifest, one trusted administrative public key, signature verification, explicit allowed actions, persistent policy state, rollback protection, and default-deny behavior. The repository includes the Rust implementation, signed baseline artifacts, the trusted administrative public key, SPHINCS+ / MAXSIG verification logic, Docker packaging, and automated tests. No production private keys, production credentials, production data, or third-party infrastructure are included. The sandbox is designed to run on systems controlled by the user. The Rust implementation can be built and tested locally with Cargo. Docker packaging is also included. The default Docker Compose configuration publishes no host port, so the container is not exposed as a network service by default. No remote service is required for the evaluation. Clone the repository and enter the project directory: git clone https://github.com/max-russo-com/MAX AUTHORIZATION SANDBOX.git cd MAX AUTHORIZATION SANDBOX Run the baseline tests: cargo test --locked Verify the distributed signed manifest: cargo run --locked --quiet --bin verify manifest Check the two authorized actions: cargo run --locked --quiet --bin max authorization challenge -- status cargo run --locked --quiet --bin max authorization challenge -- ping The expected outputs are SYSTEM OK and PONG . Now set a local test secret and request the unauthorized action: CHALLENGE SECRET=LOCAL TEST SECRET cargo run --locked --quiet --bin max authorization challenge -- read-secret The baseline should return DENY and must not reveal LOCAL TEST SECRET . The research objective is to make the official baseline execute READ SECRET while the active valid manifest still does not authorize it, without modifying or removing the authorization enforcement being evaluated. This repository isolates and makes testable one authorization principle explored in the broader MAX project: a machine should execute only actions explicitly authorized by a valid policy signed by a trusted administrator. The sandbox is not a complete representation, replica, or security model of MAX App or MAX IoT. Those systems are broader and require their own review, validation, adversarial testing, and independent audit. The purpose of this repository is to make this specific authorization and trust-chain principle easy to inspect, reproduce, challenge, and audit independently. For broader project context, see https://www.max-russo.com/ https://www.max-russo.com/ . This repository is a local research artifact. It does not authorize testing against external services, third-party systems, or production systems. Reproducible bypasses, technical findings, and related analysis may be reported publicly through this repository's GitHub Issues. See SECURITY.md for scope and reporting guidance. A demonstrated authorization failure would apply to this implementation and its tested trust assumptions. An unsuccessful test does not prove the absolute security of MAX, MAX IoT, SPHINCS+, post-quantum signatures, or authorization systems in general. It means only that no authorization failure was demonstrated within the tested scope and conditions. This repository is released under the MIT License. See LICENSE .