AegisFlow: Trust Beyond the Code

Tagline: AI agents propose. Deterministic gates decide.

Inspiration: What Happens After the AI Writes the Code?

The theme of this hackathon, Life After Code, made us think about a problem that is becoming harder to ignore.

AI can now write functions, refactor entire modules, and generate pull requests in seconds. But writing code is only one part of building reliable software. The real question is: How do we know the code is safe, correct, and ready to deploy?

Imagine an AI agent introduces a bug. Its tests fail, so it changes the tests instead of fixing the problem. Or it modifies a CI/CD configuration to skip a security check. The pipeline turns green, but the underlying issue is still there.

That is the gap we wanted to address.

While exploring agentic software development, we focused on four risks:

• AI grading its own work: An agent can produce an incorrect solution and still confidently claim that it works.
• Tests weakened to hide failures: Assertions can be removed, thresholds relaxed, or edge cases ignored to make a failing pipeline pass.
• Security checks bypassed: Changes to CI/CD configuration can accidentally or deliberately disable important verification steps.
• Unverified release artifacts: A successful Git commit does not automatically prove that the container image and its dependencies are the ones that were actually checked.

We wanted to build something that would not simply ask AI to be more careful. We wanted a system that could independently verify the evidence before allowing a release.

That idea became AegisFlow, a GitLab-native release assurance system designed for a world where AI agents are increasingly involved in writing production software.

Our guiding principle is simple:

Agents propose and explain. Deterministic gates decide.

An AI agent can help plan a change, write code, or explain a failure. However, it does not get the final say on whether a release passes. That decision belongs to automated tests, static analysis, security checks, cryptographic verification, and explicit release policies.

What We Built

AegisFlow is an automated verification and release governance layer built around the software development lifecycle. To demonstrate how it works in a practical, high-consequence setting, we built GridPulse, a power-grid resilience analytics service.

GridPulse draws inspiration from power-system reliability concepts, including frequency response and transmission contingency analysis. It gives us a concrete system to demonstrate why software verification matters when reliability is important.

AegisFlow connects code changes to verification evidence, release decisions, deployment, and recovery. Here is how its main components work.

1. Deterministic Verification and Test-Integrity Analysis

Every proposed change passes through a defined set of verification gates. These include unit tests, Ruff linting, Mypy type checking, dependency vulnerability scanning with pip-audit, and secret detection.

We also built an Abstract Syntax Tree (AST) analyzer that compares Python code and tests across Git revisions. Rather than relying only on text searches, it examines code structure to identify changes such as removed assertions or weakened comparison conditions.

The goal is to catch changes that make a pipeline appear healthy without actually improving the software.

If a required gate fails, the release is blocked. A successful explanation from an AI agent cannot override that result.

2. Cryptographic Change Passports

Passing tests is important, but a release also needs traceable evidence of what was checked.

For each verified change, AegisFlow generates a Change Passport, a canonical JSON record containing information about the Git commit, container image digest, CycloneDX Software Bill of Materials (SBOM), and verification results.

We use RFC 8785 JSON Canonicalization Scheme (JCS) rules to produce a consistent representation of the data, then calculate its SHA-256 digest.

This makes it possible to verify the integrity of the recorded release information and connect a decision to specific software artifacts and verification results.

If a required check fails, the release remains blocked rather than being allowed through on the strength of an AI-generated explanation.

3. An Append-Only, Tamper-Evident Decision Ledger

Release decisions should not disappear or change silently after the fact.

AegisFlow records its Change Passports in a linear hash chain. Each entry includes the hash of the previous entry:

H_i = SHA256(H_(i-1) || EntryData_i)

This creates a verifiable sequence of release decisions. If an earlier entry is modified, the subsequent chain verification can detect the inconsistency.

We also make the security boundary explicit: a hash chain is tamper-evident, not inherently tamper-proof. Protecting the ledger against an attacker who can rewrite the entire chain requires additional access controls and trusted external checkpoints.

We believe security tools should explain their limitations as clearly as they explain their protections.

4. A Live Failure-and-Recovery Sandbox

We wanted judges to experience the verification process rather than just watch a dashboard displaying green indicators.

AegisFlow includes an interactive sandbox that runs real Python test processes inside an isolated temporary workspace.

A judge can:

1. Introduce a controlled defect, such as changing a multiplier to 0.00.
2. Run the actual pytest subprocess and observe it fail with exit code 1.
3. Watch AegisFlow mark the release as RELEASE BLOCKED.
4. Inspect diagnostic evidence extracted from JUnit XML.
5. Apply a bounded repair and rerun the tests to verify whether the defect has been resolved.

The sandbox uses temporary workspaces so these experiments do not modify the host Git working tree.

This is one of the most important parts of our demonstration: the failure and recovery are driven by actual test execution, not simulated success and failure messages.

5. Cloud Run Deployment and Automated Rollback

Verification should continue to matter after the code passes CI.

AegisFlow integrates with GitLab CI/CD to deploy verified artifacts to Google Cloud Run. Authentication uses Google Cloud Workload Identity Federation (WIF), avoiding the need to store long-lived service account keys in the deployment pipeline.

After deployment, health probes monitor service status and latency. If two consecutive probes fail or exceed the configured latency budget of 1,500 milliseconds, the deployment logic can shift traffic back to the previous revision.

This connects verification to runtime behavior: a release must not only pass checks before deployment, but also meet defined health requirements afterward.

How We Built It

We built AegisFlow around the GitLab ecosystem, combining AI-assisted development with conventional, independently verifiable engineering controls.

GitLab Duo Custom Agents

We designed three distinct roles within .gitlab/duo/:

• Planner: Breaks down issues and proposes an implementation approach.
• Engineer: Works on scoped code changes.
• Admission Guard: Helps inspect changes and explain verification requirements.

We also defined permission boundaries in AGENTS.md to prohibit actions such as accessing CI secrets, force-merging changes, or modifying IAM roles. The agents can assist the workflow, but they are not intended to control the security boundaries themselves.

GitLab CI/CD

Our .gitlab-ci.yml pipeline organizes the workflow into verify, package, deploy, and govern stages, connecting verification results with packaging, deployment, and release records.

Backend

The backend uses Python 3.11 and FastAPI. It handles release decisions, sandbox execution, HMAC-based admission checks, AST analysis, ledger verification, and GridPulse calculations.

We built a suite of 293 backend tests to cover these components.

Frontend

The dashboard uses React 18 and Vite, with an Obsidian-inspired visual design, interactive grid topologies, and execution terminals. Vitest covers 39 frontend tests.

Software Supply Chain

We implemented a CycloneDX 1.5 SBOM generator for Python and npm dependencies. The generated inventory supports dependency visibility and vulnerability review.

Model Context Protocol (MCP)

We also implemented an MCP server exposing JSON-RPC 2.0 tools, including explain_release_decision, verify_change_passport, and audit_decision_ledger. This provides a standard interface through which compatible AI clients can query release decisions and verification evidence.

Together, these components make AegisFlow more than an AI coding assistant. It is a system for governing what happens after AI-assisted code is produced.

Challenges We Faced

Isolating Real Test Execution

One of our biggest challenges was running real pytest subprocesses through a live web backend without accidentally changing the main Git working tree.

We addressed this using temporary workspaces created with tempfile.mkdtemp, controlled execution, and mutex locks where needed. This allowed us to demonstrate failures and repairs while keeping the main repository separate from sandbox experiments.

Keeping Cryptographic Results Consistent

Canonical hashing sounds straightforward until different operating systems and JSON serializers produce different byte representations of the same logical data.

We addressed this by following RFC 8785 canonicalization rules before calculating SHA-256 digests. The objective was to produce consistent results across our Windows development environment, Linux CI runners, and Cloud Run containers.

Detecting Changes That Weaken Tests

A simple text search can miss meaningful changes to test logic. For example, changing a comparison operator may weaken an assertion without removing the test itself.

We therefore developed an AST comparison approach that examines Python syntax before and after a change, looking for structural differences involving assertions and comparison conditions.

This was a useful reminder that security checks must examine the behavior and structure of code, not just whether a file still exists.

What We Are Proud Of

• Real failure and recovery: The sandbox executes actual Python test processes, captures exit codes, and extracts JUnit XML evidence instead of relying on mocked test results.
• 332 automated tests: Our suite includes 293 backend tests and 39 frontend tests, which passed in our reported test run.
• Automated cloud deployment: GitLab CI/CD deploys to Google Cloud Run and Artifact Registry using Workload Identity Federation rather than long-lived service account keys.
• A verifiable release history: Change Passports and the hash-linked decision ledger provide a way to check recorded release evidence and detect inconsistent historical entries.
• Clear security boundaries: We explicitly distinguish between tamper-evident records and tamper-proof storage, and between implemented controls and protections that require further hardening.

Most importantly, we built a working demonstration in which judges can introduce a defect, observe a genuine test failure, and verify the result of a repair.

What We Learned

1. Verification should not depend on the same reasoning that produced the code.

AI agents are useful at generating and explaining solutions, but confidence is not proof. Independent tests and deterministic policies provide a stronger basis for release decisions.

2. Evidence is more valuable than a green badge.

A successful pipeline should be backed by inspectable results: test reports, process exit codes, dependency inventories, artifact digests, and recorded gate decisions.

3. Autonomy needs boundaries.

Separating planning, implementation, and admission responsibilities helps reduce the scope of mistakes. Explicit permissions and independently enforced gates make those boundaries more meaningful.

4. Security claims need to be precise.

A hash chain can expose changes to recorded history, but it does not automatically prevent an attacker from rewriting that history. Similarly, a clean dependency scan is evidence from a particular scan, not a guarantee that software is free of vulnerabilities.

Building AegisFlow reinforced an important lesson for us: reliable AI-assisted engineering is not about removing humans from every decision. It is about making automated decisions more observable, testable, and accountable.

What's Next?

AegisFlow is a foundation that we want to extend beyond our GridPulse demonstration.

Our next priorities are:

• Multi-repository onboarding: Make it easier for teams to connect their own GitLab or GitHub repositories and configure verification policies for their projects.
• Keyless artifact signing: Explore Sigstore and Cosign for stronger artifact signing and verifiable provenance, building on the current Change Passport and HMAC-based mechanisms.
• External audit checkpoints: Strengthen the decision ledger with independently protected checkpoints to improve detection of attempts to rewrite historical records.
• Compliance-oriented evidence: Develop configurable verification profiles and audit evidence packages for frameworks such as SOC 2 and ISO 27001, with careful attention to what the controls can actually demonstrate.
• Broader runtime assurance: Extend health monitoring and rollback policies to support more services and deployment scenarios.

Final Thoughts

The future of software development will include more AI-generated code, more autonomous agents, and faster release cycles. But speed alone does not make software reliable.

We built AegisFlow around a simple belief: AI should help us build software faster, while independent verification helps us decide whether that software deserves to ship.

With GitLab as the foundation, GridPulse as our demonstration system, and deterministic gates as the final authority, we are exploring a practical way to make AI-assisted software development more trustworthy.

For us, Life After Code is about more than what AI can create. It is about how we verify, govern, and take responsibility for what it creates.

Built With

• artificial-intelligence
• cybersecurity
• cyclonedx
• devsecops
• docker
• fastapi
• gitlab
• gitlab-ci
• gitlab-duo
• google-cloud-run
• in-toto
• json-rpc
• model-context-protocol
• mypy
• pip-audit
• pytest
• python
• react
• ruff
• sbom
• vite