KATOYING STING
Reproduce one weakness inside the declared local or synthetic boundary.
BLUE TEAM · HIVE AEGIS
KTY-R001 · BLUE HONEY
BLUE HONEY
A safe wound enters. Evidence leaves. The ecosystem remembers.
The Blue Team reproduces one weakness in an owned sandbox, applies a reversible defense, replays the same challenge, and keeps only what the evidence proves. That reusable memory is Blue Honey.
owned local / synthetic only
10 / 10 guard assertions
24 / 24runtime tests
10 / 10deterministic assertions
48model calls
14 / 34accepted / quarantined
0external or executed
The Blue Team
Security is a living role, not a wall.
Yokai can sense, search, probe, build, verify, carry, learn or guard. The Blue Team gives risky experiments a safe place to fail, learn and return stronger. HIVE AEGIS is its bounded mechanism; it does not turn the whole ecology into a security system.
Meet the full YOKAI ecology ↗Security loop
How does Blue Honey protect the ecosystem?
AEGIS runs blue-team self-play inside an owned local or synthetic sandbox. A model may suggest a move, but the harness measures the result. Nothing becomes shared memory until the same challenge has been replayed and the defense can be removed cleanly.
WAX
Wrap it in a minimal reversible defense without changing the target.
RE_STING
Replay the same challenge, inputs and success condition against the protected state.
SEAL
Keep Blue Honey only when before/after evidence and rollback both hold.
Current bench
What survives becomes memory. What fails stays visible.
The current run exercises three registered synthetic fixture families. Model outputs stay advisory: deterministic guards decide what survives, and no candidate text is compiled or executed.
Observed
Bounded evidence
- 24 of 24 runtime tests passed.
- 10 of 10 deterministic guard assertions passed.
- 14 model digests were accepted; 34 were quarantined.
- Zero external call and zero candidate action executed.
Boundary
No invented generalization
- Only three named fixture families are registered.
- All three remain PARTIAL_BENCHED.
- Some SEAL proposals were rejected by the guards.
- This is not a general cybersecurity effectiveness claim.
Three registered storms
Different failures need different proof.
Each fixture isolates one common failure pattern. The names are playful; the rejection rules are deterministic.
MIRAGE_BLEU
Agreement is not evidence. A defense cannot pass until a physical result exists outside the model consensus.
POLLEN_FANTOME
A system cannot certify itself. Independent review and already-existing evidence are required.
ATOM_STORM
Malformed events are isolated while the valid event survives. Quarantine does not erase useful signal.
Next threshold
The physical proof contract.
The next run must happen in a disposable, owned local sandbox with a known weakness and a scripted control. The status changes only when the measurements below exist.
Baseline
The scripted attack succeeds repeatedly against the clean sandbox snapshot.
Same attack
RE_STING uses the same script, input, target snapshot lineage and success predicate as STING.
Defense effect
The attack no longer reaches its success predicate after WAX, while unrelated control behavior still works.
Reversibility
Removing the guard restores the baseline outcome without rebuilding the sandbox by hand.
Boundary
Zero external target, zero persisted secret, zero daemon and zero destructive action outside the disposable fixture.
Reject when
The attack changes between runs, manual intervention decides the result, controls regress, or the sandbox boundary cannot be demonstrated.
Claim boundary
A partial bench is useful when it stays partial.
Version 0.1.0+codex.20260716225832. The published result says only this: registered deterministic guards ran against owned synthetic fixtures, model prose stayed advisory, and the measured boundaries held. A new family needs a new guard and a new bench.
Open machine-readable status ↗Reference layer
Sources used.
These references shape the testing vocabulary and evidence discipline. They do not endorse Katoying, HIVE or the current result.
- NIST SP 800-115 · Technical Guide to Information Security Testing and Assessment Planning, conducting and documenting controlled security tests.
- OWASP Web Security Testing Guide v4.2 Repeatable test structure and web security verification vocabulary.
- MITRE D3FEND A public knowledge graph for defensive cybersecurity countermeasures.
- MITRE ATT&CK Resources A shared reference for describing adversarial behavior without inventing private labels.