Building a "Fail-Closed" Zero-Trust CI/CD Protocol: A Personal Open-Source Experiment

maquina-anjo — Wed, 09 Sep 2026 05:12:25 +0000

Hello, Dev community! 👋 I am Anjo Machina (安城巻那), a QA engineer based in Japan.

I want to share an open-source project I have been building. It is a solitary experiment aimed at exploring structural sovereignty and safety in deployment pipelines. I would be deeply grateful for any architectural feedback or critique from the experienced engineers here.

The Challenge in the GenAI Era

I have been trying to rethink how we handle Quality Assurance. Relying on passive testing frameworks that simply run scripts and report failures feels increasingly risky, especially when code is generated by AI faster than humans can thoroughly verify.

To address this, I built Anjo-Core, a fully autonomous, fail-closed Zero-Trust governance protocol that runs directly inside GitHub Actions.

GitHub Repository: anjo-da-maquina/Anjo-Core

The Philosophy of Ataraxia

In classical philosophy, Ataraxia means a state of serene calmness. In Anjo-Core, it translates to operational stillness. The protocol does not merely "test" code; it actively governs the environment to maintain this stillness, ensuring only cryptographically verified and structurally sound code can enter the main branch.

The Core Architecture

Instead of passive tests, Anjo-Core operates through an agentic swarm of 37 specialized cryptographic agents, each with a single, isolated responsibility (e.g., Semantic Drift Detector, Canary Data Watchdog).

Here is how the system handles the DevSecOps workflow:

1. Automated GenAI Parsing (MCP)

Instead of manually writing tests, Anjo-Core uses the Model Context Protocol (MCP). Multiple LLMs read functional requirements (Excel/YAML) and use a consensus mechanism to dynamically generate highly restrictive test suites, preventing AI hallucinations.

2. Cryptographic Enclaves & Auditing

All critical validations occur within simulated Trusted Execution Environments (TEE) to prevent memory tampering. The system generates a cryptographic proof (ZKP) and tamper-proof JUnit XML logs, ensuring absolute compliance and integrity.

3. The Samson Option (Fail-Closed Circuit)

If a critical structural anomaly is detected (e.g., a memory leak pattern or unauthorized network call), the protocol triggers The Samson Option. This emergency kill-switch instantly isolates the runtime environment, purges all tainted state, and forcefully terminates the pipeline before any merge can occur.

Let's Discuss

Does a fail-closed, autonomous architecture like this make sense in a practical DevSecOps environment? How would you bypass these agents or compromise the system's integrity?

I am constantly learning, and this project is very much a work in progress. I welcome your insights, pull requests, or critiques on how I can improve this architecture.

Thank you for reading!

DEV Community: maquina-anjo