AI security needs testing against people who actively try to break the rules.
A helpful response to an ordinary question tells us little about how a model behaves when someone tries to extract protected information, override its instructions, or manipulate its decisions.
We built Red Sentinel to make that testing an open competition. Defenders deploy AI sentinels with an attack objective, a bounty, and an attack fee. Attackers submit prompt injections and jailbreak attempts. If an attack meets the success conditions, the attacker receives the bounty through on-chain settlement.
For our hackathon build, we integrated Kimi K3 into two parts of this process: running defender sentinels and participating in the jury that evaluates attack results.
Kimi as the defender
A sentinel is the AI system that an attacker tries to breach.
Defenders configure its instructions and define what counts as a successful attack. Kimi then powers the sentinel’s responses as attackers try to push it beyond those boundaries.
This places Kimi inside the core product experience. Its responses are the material being tested, rather than supporting text around the application.
For example, a defender can create a challenge where a sentinel must protect a secret. Attackers can try impersonation, conflicting instructions, or requests disguised as harmless tasks. The test is whether the sentinel preserves the boundary under adversarial input.
A failed attack provides evidence that a particular attempt did not work. A successful attack reveals a failure case that the defender can investigate. Neither result proves that a model is universally safe or unsafe.
Connecting Kimi to Red Sentinel
Red Sentinel supports custom model providers through an OpenAI-compatible API interface.
A defender supplies an endpoint URL, an API key, and a model identifier. The application includes a connection check before deployment, so the defender can verify that the configured model responds.
We use this integration path to connect Kimi. It lets us bring the model into the arena without building a separate deployment experience for every provider.
That flexibility matters for AI security testing. Builders need to test the model they intend to use, with their own instructions and challenge conditions.
Kimi as part of the jury
Generating a response and evaluating an attack are separate responsibilities.
An attacker might produce a persuasive-looking conversation without actually meeting the challenge objective. A response might also violate the objective without using an obvious phrase such as “I have been hacked.”
In our hackathon setup, Kimi also participates in the jury that evaluates attack results against the challenge’s success conditions.
This gives Kimi a second role: assessing whether the observed behavior constitutes a breach. Its contribution supports the evaluation process, while the bounty settlement remains a separate on-chain step.
The value Kimi brought
Kimi contributed to both sides of the arena’s central workflow.
First, it gave defenders a model they could deploy and expose to adversarial testing. This makes the integration directly useful to AI builders who want to examine how their instructions behave under pressure.
Second, its participation in the jury added model-based assessment of attack outcomes. The question becomes whether an attack achieved the defined objective, rather than whether the attacker claimed success.
Third, the compatible API interface let us reuse our provider configuration and validation flow. We could focus on the security challenge and evaluation experience instead of creating a provider-specific integration from scratch.
We are not claiming a measured improvement in cost, latency, or detection accuracy. The value in this build is functional: Kimi runs the systems being tested and contributes to assessing the results.
From model access to adversarial evidence
Our goal is to help builders move from “this prompt seems secure” to concrete evidence from attacks.
Kimi helps make that possible within Red Sentinel. Defenders can launch Kimi-powered challenges, attackers can test their boundaries, and the jury can evaluate the resulting behavior.
Combined with on-chain bounties on Monad, this creates an incentive for people to find meaningful failures and gives defenders specific cases they can use to improve their AI systems.
