Notifications
Clear all
Topic starter
02/08/2026 11:56 am
TL;DR: More than 70% of collected open-source applications were not usable as training environments, with only 25% fully functional out of the box and the rest failing at build, startup, setup, or runtime verification, according to Novee. The finding shows that deterministic environments, not model size, are the hidden dependency in reinforcement learning for security AI, where broken infrastructure produces broken signals.
NHIMG editorial — based on content published by Novee: The Hardest Part of Training Security AI Isn’t the Model. It’s the Environment
By the numbers:
- More than 70% of the open-source applications we collected for training didn’t actually work out of the box.
- Only 25% of the applications were fully functional out of the box.
- Current coverage: more than 80% of collected apps reach verified state.
Questions worth separating out
Q: What breaks when AI training environments are not deterministic?
A: Training breaks because the model cannot distinguish real behavioural signals from noise caused by changing setup, dependency drift, or incomplete initialization.
Q: Why do broken environments matter for AI and identity governance?
A: They matter because the environment is part of the trust boundary.
Q: How do security teams know whether a training environment is actually usable?
A: They know by proving that it starts from scratch, initializes data correctly, returns real application content, and survives a full verification cycle without hidden manual intervention.
Practitioner guidance
- Make environment verification part of model readiness checks Require clean rebuilds, service-specific health validation, and content checks before any training run or red-team simulation is accepted as valid.
- Remove hidden human steps from automated training estates Scan for setup wizards, manual migrations, and first-run configuration steps that assume an operator will finish deployment.
- Treat self-reporting AI success as untrusted output Use a separate deterministic verifier to confirm that the environment works after any AI-driven repair or adjustment.
What's in the full article
Novee's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how the Fixer converts broken open-source apps into fully functional containers
- Detailed verification logic for database, HTTP, and teardown checks across multiple frameworks
- Implementation patterns for handling setup wizards, CAPTCHA, and silent startup failures
- Examples of the specific build and entrypoint changes used to make environments deterministic
👉 Read Novee's analysis of why deterministic training environments matter for security AI →
AI training environments for attack models: where do controls break down?
Explore further
02/08/2026 1:04 pm
Environment integrity is now a security control for AI systems. When a model learns from unstable or partially initialised systems, the resulting behaviour is not just lower quality, it is governance failure. Security teams should treat reproducible environment state as part of the trust boundary for AI training, testing, and agent validation.
A question worth separating out:
Q: What should teams do when AI systems claim they have fixed a broken environment?
A: They should validate the result with an independent deterministic rebuild, full-stack startup checks, and content verification before accepting the fix. Any self-reported success from the same system that made the change must be treated as provisional until a separate check confirms the environment is truly working.
👉 Read our full editorial: Verified training environments are the real bottleneck for AI attackers
