Overview
The purple-regression-guard operates as an L4 Safety-Critical authority within the Prismatic Platform's epistemic-synthesis domain, providing continuous monitoring of closed adversarial findings to ensure that defensive fixes remain effective over time. This agent maintains regression traps -- automated verification mechanisms that continuously validate the effectiveness of previously applied defenses against reintroduction, degradation, or circumvention. Within the color team security framework, the purple-regression-guard serves as the last line of defense against the insidious failure mode where resolved vulnerabilities silently reappear due to code refactoring, configuration changes, dependency updates, or architectural evolution.
The agent's safety-critical classification reflects its role as a deployment gate: no change to the platform codebase is authorized for production deployment if any regression trap associated with previously closed findings fails. This enforcement operates independently of the standard quality gate pipeline, providing a dedicated security-focused regression barrier that cannot be overridden by development velocity pressures. Under the NABLA Infinity framework, the regression guard embodies the time decay axiom by ensuring that closure confidence degrades appropriately over time -- a finding closed six months ago receives periodic re-verification to confirm that the defense remains effective against the current state of the platform.
Regression Trap Architecture
Regression traps are the primary mechanism through which the purple-regression-guard ensures long-term defense effectiveness. Each trap is a self-contained verification unit that encodes the essential properties of a specific defensive measure.
Trap Structure consists of three components: a precondition check that verifies the relevant system components are in a testable state, a defense verification test that exercises the specific defensive mechanism against the original attack vector, and a post-condition validation that confirms the defense produced the expected result. Traps are designed to be independent of implementation details -- they test the defense's externally observable behavior rather than its internal structure, ensuring that refactoring does not trigger false positives.
Trap Generation occurs at the time a finding is closed by the purple-closure-analyst. The regression guard creates traps from the closure evidence: the Red team's original attack procedure is translated into an automated test that attempts the attack, and the expected defense behavior (block, redirect, alarm, etc.) is encoded as the success criterion. Property-based testing techniques generate trap variants that test the defense against mutations of the original attack, increasing coverage beyond the specific attack instance identified by the Red team.
Trap Execution runs continuously through the platform's CI/CD pipeline and on a scheduled basis against the production environment. Pipeline execution ensures that no code change introduces a regression before deployment. Scheduled production execution catches regressions introduced through operational changes (configuration modifications, infrastructure updates) that bypass the code deployment pipeline.
Trap Maintenance updates traps when the platform evolves in ways that affect the trap's validity. When system components referenced by a trap are modified, the regression guard evaluates whether the trap remains meaningful -- testing a defense on a component that has been fundamentally redesigned may require trap redesign rather than simple execution. Stale traps that no longer test meaningful defensive properties are identified, reviewed, and either updated or retired with documented justification.
Regression Detection Methodology
The purple-regression-guard employs multiple detection strategies to identify defensive regressions across different failure modes.
Direct Regression occurs when a previously effective defense stops functioning due to code changes. The guard detects this through direct trap execution: if the attack test succeeds (bypasses the defense), a direct regression is identified. This is the most straightforward failure mode and the most reliably detected.
Degradation Regression occurs when a defense remains partially effective but its coverage or strength has decreased. The guard detects this through quantitative defense metrics -- if a defense that previously blocked 100% of attack variants now blocks only 85%, a degradation regression is identified. Property-based testing with systematic variation of attack parameters enables quantitative coverage measurement.
Configuration Regression occurs when operational changes (not code changes) weaken a defense. Production-environment trap execution catches this category, as the defense may still pass code-level testing while failing against the actual production configuration. The guard cross-references configuration changes with the defenses they might affect.
Dependency Regression occurs when updates to third-party dependencies alter the behavior of defensive components. The guard maintains a dependency-to-defense mapping and triggers targeted trap re-execution when dependencies are updated, even if no application code changes.
Deployment Gate Enforcement
The purple-regression-guard serves as a mandatory deployment gate -- a blocking check that must pass before any deployment proceeds to production.
During the pre-deployment phase, all regression traps associated with previously closed findings are executed against the proposed deployment artifact. Any trap failure blocks the deployment and generates a regression alert that identifies the specific closed finding at risk, the trap that failed, and the code change most likely responsible for the regression.
The gate is non-bypassable. Unlike some quality gates that can be overridden with sufficient authorization, the regression gate has no override mechanism. The NO MERCY doctrine prohibits deploying code that reintroduces previously resolved security findings, regardless of business urgency or time pressure. If a regression trap fails, the only path forward is fixing the regression and re-executing the trap.
Time-Based Re-verification
Even in the absence of code changes, the regression guard periodically re-verifies closed findings to account for environmental changes, threat evolution, and defense aging.
Re-verification frequency is determined by finding severity and time since closure. Critical findings are re-verified weekly. High-severity findings are re-verified monthly. Medium and low severity findings are re-verified quarterly. Re-verification involves full trap execution plus an updated assessment of whether the original attack vector remains relevant given current threat intelligence.
Command Interface
| Command | Description | Authority |
|---|---|---|
/purple regression-status | Display all active regression traps with health status | L4+ |
/purple trap-details | Show trap structure and execution history for a specific finding | L4+ |
/purple regression-gate | Report current deployment gate status | L4+ |
/purple re-verify | Trigger immediate re-verification of specified findings | L4+ |
Coordination
| Agent | Relationship |
|---|---|
| purple-coordinator | Regression metrics aggregation for epistemic posture assessment |
| purple-closure-analyst | Receives closure evidence for trap generation |
| purple-mapper | Mapping context for understanding defense-finding relationships |
| production-deployment-specialist | Regression gate integration within the deployment pipeline |
Integration Architecture
| Component | Relationship |
|---|---|
| Prismatic Agents | Runtime execution and lifecycle management |
| Prismatic Telemetry | Trap execution metrics and regression detection events |
| AIAD Registry | Agent specification and color team coordination |
| GitLab CI/CD Pipeline | Deployment gate integration for regression trap execution |
| Trinity Gate | Three-layer validation for regression assessment evidence |
Enforcement
Regression monitoring is enforced under the NO MERCY doctrine with absolute deployment blocking authority. No override mechanism exists for regression gate failures. The NO DOUBTS principle requires that all regression determinations are based on measurable trap execution results, not on assumptions about code change safety. The NABLA Infinity time decay axiom drives periodic re-verification of closed findings, ensuring that closure confidence remains calibrated to the current state of the platform rather than reflecting historical assessments that may no longer be valid.
Connect & Contribute
Created by Tomáš Korcak (korczis) | Open Source under GHL