The Adversarial Testing of AIIM

AIIM should not be trusted merely because its designers believe it is fair, secure, or resistant to manipulation. It should be tested by people who are actively trying to make it fail.

For this reason, we propose a five-month public red-team experiment for AIIM after we obtain $1300 for the experiment. Participants will attempt to identify weaknesses in the system’s AI-based evaluation, ranking, moderation, and funding mechanisms. Successful participants may receive money when they demonstrate a valid vulnerability under the published rules.

What Is AIIM Red Teaming?

Red teaming is the deliberate testing of a system by people who adopt an adversarial perspective. Instead of asking whether AIIM works under normal conditions, the red team asks questions such as:

• Can a participant manipulate AIIM’s evaluation criteria?
• Can misleading wording produce an unfairly high score?
• Can coordinated users distort funding decisions?
• Can an attacker bypass a restriction without violating infrastructure security?
• Can legitimate-looking content conceal manipulation?
• Can the system be induced to reward low-value or fraudulent work?

The purpose is not sabotage. The purpose is to discover weaknesses before they can cause serious harm.

A Five-Month Open Challenge

The proposed AIIM Red Team challenge is intended to run for five months after its funding target is met. This page describes the planned experiment; it does not announce that the challenge has started. Participation is subject to the scope and rules below.

The proposed funding target is $1,300: $200 per month for five months for the recipient-payment budget ($1,000 total), plus $300 for AI, hosting, and related operating costs.

Participants may attempt to obtain rewards by demonstrating weaknesses in AIIM’s authorized testing environment. A participant must not simply claim that an exploit exists. The participant must explain the method in enough detail for the AIIM team or governance process to reproduce and evaluate it.

What Counts as an Authorized AIIM Breach?

Only vulnerabilities involving AIIM’s decision-making mechanisms are within scope.

Examples may include:

• prompt manipulation;
• evaluation gaming;
• deceptive submissions;
• score inflation;
• identity or reputation manipulation within the permitted test environment;
• coordinated attempts to influence AI-based ranking;
• exploitation of inconsistencies between AI evaluation and community voting;
• methods that cause AIIM to allocate funds contrary to its stated rules.

A reported method should also pass the applicable quorum-based governance or ban-voting process. The quorum mechanism is implemented in the software. In extraordinary cases, an administrator may intervene as a fallback. The process must determine whether the technique represents a genuine vulnerability, normal permitted behavior, or conduct that falls outside the experiment.

What Is Prohibited?

The red-team program does not authorize attacks against infrastructure or property.

The following actions remain prohibited:

• obtaining or attempting to obtain private keys;
• stealing credentials;
• compromising wallets;
• exploiting server vulnerabilities;
• introducing malware;
• impersonating real people without authorization;
• attacking third-party services;
• accessing private user data;
• violating applicable law.

A vulnerability is not automatically authorized merely because it affects AIIM. Participants must remain within the published scope and testing environment.

Disclosure Is Mandatory

A participant who demonstrates a vulnerability must provide a clear explanation of:

1. what weakness was discovered;
2. how the attack works;
3. what conditions are required;
4. what effect it has on AIIM;
5. how the result can be reproduced;
6. how the vulnerability might be mitigated.

A participant who extracts a reward but refuses to disclose the method should not qualify for payment under the program, but is considered as an illegal breaker. The reward is offered for useful security knowledge, not merely for defeating the system.

Reports may initially be submitted privately if immediate publication would put the system or users at risk. After mitigation, the findings should normally be published in an anonymized or technically appropriate form so that the wider community can learn from them.

Rewarding Useful Attacks

The reward is the amount of money the red team member succeeded to take

Why Open Participation Matters

An internal team is unlikely to anticipate every form of manipulation. Researchers, developers, prompt engineers, economists, governance specialists, and ordinary users may notice different classes of failure.

Open participation also tests whether AIIM’s rules are understandable. If many good-faith participants misunderstand the permitted scope, that is itself evidence that the rules or interface need improvement.

Adversarial Testing as Part of AIIM Governance

Red teaming should not be treated as a one-time publicity event. It should become a recurring part of AIIM governance.

Each testing round can produce:

• a public vulnerability report;
• updated evaluation criteria;
• new automated checks;
• revised governance rules;
• examples of prohibited manipulation;
• evidence about which defenses worked and which failed.

This creates a feedback loop: attackers reveal weaknesses, governance evaluates them, developers improve the system, and later red teams test the improvements.

The Principle

AIIM should be designed under the assumption that every scoring rule, prompt, voting mechanism, and funding criterion will eventually be tested by intelligent adversaries.

A trustworthy funding system is not one that has never been attacked. It is one that invites controlled attacks, learns from them, rewards honest disclosure, and becomes harder to manipulate over time.

Research Preregistration

In accordance with best science policies, the research is preregistered at OSF.io to avoid both intentional and non-intentional manipulations with probabilities in the future.