AID-R-004: Fleet Remediation Propagation & Technical Recurrence Prevention

Version 1.20261015 · Actionable technique

Propagate an incident-proven technical remediation across the complete affected fleet, read the resulting effective state back from every target through a separate read-only path, and institutionalize the fix in build, deployment, or configuration baselines so the same technical weakness does not recur.

Pillars: data, infra, model, app

Lifecycle: improvement

Scope boundary

Owns fleet-wide propagation and institutionalization of an already proven technical remediation. It excludes post-incident review facilitation, customer communication, ticket administration, and enterprise risk-scoring updates.

AID-R-006: AID-R-004 propagates an incident-proven fix across the affected fleet and future baselines; AID-R-006 orchestrates dependency-ordered recovery of one multi-component system. A clean-room cutover can complete without proving organization-wide propagation, while fleet remediation does not replace dependency-aware assembly and cutover of the recovered system.

Implementation guidance

AID-R-004-G001

Perform targeted regression validation of fixes using AI-specific security testing and archive the results as evidence.
Purpose and boundary

Use this reusable incident-regression validation module to verify that the exact fixed release was independently tested against the complete signed incident exploit-path and benign-control population and met the organization-approved release criteria. A test process exit code, empty hit log, or upstream fix receipt alone is not proof.

Sign target, cases, harness, and policy

The security validation authority signs the incident and target system/release/model/prompt/tool/policy digests, isolated endpoint and credential reference, exploit, variant, benign and functionality case IDs, inputs and expected assertions, seeds/repetitions, harness/adapter/container digests, raw-output schema, metric algorithms, organization-approved thresholds, exclusions, and evidence freshness. Secrets remain in the CI secret store and are referenced, never archived.

# File: validation/contracts/incident-regression-manifest.yaml
schema_version: aidefend.r004.incident-regression.v1
required_bindings:
  - incident_id
  - target_release_digest
  - target_component_manifest_digest
  - case_manifest_digest
  - expected_case_id_manifest_digest
  - harness_release_digest
  - adapter_config_digest
  - execution_image_digest
  - metric_and_threshold_policy_digest
  - credential_reference
result_required_fields:
  - expected_case_count
  - executed_case_count
  - exploit_case_count
  - benign_case_count
  - errored_case_count
  - excluded_case_ids
  - per_case_result_digest
  - failed_case_ids
  - raw_output_manifest_digest
  - result
Execute and preserve evidence

An evaluator independent of the fix author and deployer verifies every signature/digest, confirms the isolated target identity, and runs every case with the pinned harness and adapter. It rejects missing, duplicate, extra, silently skipped, or unsupported cases and preserves all prompts/inputs according to data policy, responses, tool traces, detector outputs, timings, errors and per-case assertions. Sign the canonical verdict and retain the manifest, sanitized adapter config, raw output, logs, container attestation, receipt, and signature.

Independent replay

A second assurance identity fetches the exact target and evidence, rechecks case completeness and assertion calculations, replays the policy-required population or independently approved full replica run, and compares raw/per-case/verdict digests. Dependencies are the signed case and threshold policies, exact isolated target, harness/adapters, credential service, trusted time, complete raw output, and retention store. Fix deployment or prior test success is only eligible input.

Action: block release/closure unless the exact signed case population and raw evidence independently reproduce the verdict.

AID-R-004-G002

Institutionalize the mitigation in shared security libraries and reusable runtime policy baselines so future services inherit the fixed control by default.
Purpose and boundary

Use this shared-security-artifact release reference architecture to verify that the incident mitigation was packaged as an immutable, signed, regression-backed reusable library or runtime policy artifact with complete provenance. It does not prove consumer adoption; AID-R-004-G003 owns that population.

Define the signed package manifest

The security-platform owner signs the incident/control mapping, source commit, build workflow and image digests, package identity/version/digest, dependency lock and SBOM digests, provenance/signing policy, supported runtime/API matrix, configuration schema, security and compatibility test manifests, registry target, and deprecation policy. Version numbers and minimum consumer versions are release-policy inputs.

# File: security_artifacts/contracts/mitigation-package.yaml
schema_version: aidefend.r004.mitigation-package.v1
required_bindings:
  - incident_id
  - mapped_aidefend_control_ids
  - source_commit_digest
  - build_workflow_digest
  - build_image_digest
  - package_name
  - package_version
  - package_digest
  - dependency_lock_digest
  - sbom_digest
  - provenance_digest
  - signing_policy_digest
  - configuration_schema_digest
  - security_test_manifest_digest
  - compatibility_test_manifest_digest
release_receipt_required_fields:
  - built_artifact_digest
  - registry_immutable_locator
  - signer_identity
  - executed_test_count
  - failed_test_ids
  - independent_registry_readback_digest
  - result
Build, sign, and retain evidence

Build from the signed source/lock in a hermetic, network-restricted pipeline, generate SBOM and provenance, run every security and compatibility test, sign the immutable artifact digest with the protected release identity, and publish by digest to the approved registry. Preserve build attestations, dependency resolution, tests, SBOM, provenance, signature and registry receipts; never publish on an unpinned dependency, mutable tag-only reference, or self-reported test status.

Independent verification

A verifier outside the build/release trust domain fetches by immutable registry locator, recomputes artifact/SBOM/provenance digests, verifies signer and source/build bindings, installs in every policy-required runtime from the supported matrix, and replays signed incident and compatibility tests. Dependencies are approved mitigation design, signed source/lock/build/test policies, protected signer, immutable registry, supported runtimes, trusted time, and evidence storage. Regression PASS is only an input.

Action: publish and reference only the independently verified immutable artifact digest; a source merge or package name/version alone is not institutionalization.

AID-R-004-G003

Enforce organization-wide adoption of the institutionalized mitigation through IaC baselines and CI/CD policy gates.
Purpose and boundary

Use this organization-wide adoption-enforcement reference architecture to verify that every applicable service/release in the signed population is prevented from build or deployment unless it uses the exact institutionalized mitigation required by policy, and effective runtime state is independently reconciled. Artifact publication is only a dependency.

Bind population, requirement, and exceptions

The platform authority signs the complete service/environment/release population from authoritative inventory, applicability rules, required mitigation artifact/policy digests and version constraints, IaC baseline and CI/admission policy digests, enforcement-adapter releases, positive/negative tests, exception schema/approvers/expiry, and freshness. Rollout targets and deadlines come only from versioned organizational policy.

# File: security_artifacts/contracts/mitigation-adoption-policy.yaml
schema_version: aidefend.r004.mitigation-adoption.v1
required_bindings:
  - incident_id
  - service_release_population_digest
  - applicability_policy_digest
  - required_mitigation_digest
  - version_constraint_policy_digest
  - iac_baseline_digest
  - ci_policy_digest
  - admission_policy_digest
  - enforcement_adapter_digests
  - exception_policy_digest
verification_required_fields:
  - expected_service_count
  - applicable_service_count
  - observed_service_count
  - compliant_effective_release_count
  - valid_exception_ids
  - noncompliant_release_ids
  - unmeasured_service_ids
  - negative_test_result_digest
  - result
Enforce and preserve evidence

Make the required digest/version constraint part of reusable IaC modules, build policy and deployment/admission evaluation; reject missing, mutable, unverified or exception-free alternatives before promotion. At runtime expose the effective library/policy digest through an authenticated inventory/readback path. The platform owner signs per-release gate decisions, effective digests, exception decisions, rejects, counts and errors and retains raw CI/admission/runtime exports.

Independent readback

A verifier outside platform administration re-enumerates applicable services from the signed inventory, inspects effective build/deployment/runtime digests, validates every exception signature/scope/expiry, and submits policy-required negative variants through CI and admission paths. It reconciles exact expected/applicable/observed populations. Dependencies are the verified shared mitigation artifact, signed adoption/exception policies, complete inventory, enforceable adapters, effective-state telemetry, trusted time, and evidence retention. Dependency PASS never becomes adoption PASS.

Action: close adoption only when exact effective-state population and bypass tests independently verify enforcement; a baseline PR or green build alone is not proof.

Open-source tools

Commercial / hosted tools

Threat mappings

MITRE ATLAS

MAESTRO

OWASP LLM Top 10 2026

OWASP ML Top 10 2023

OWASP Top 10 for Agentic Applications 2026

NIST Adversarial Machine Learning 2025

Cisco Integrated AI Security and Safety Framework

Google Secure AI Framework 2.0 - Risks

Databricks AI Security Framework 3.0

AID-R-004: Fleet Remediation Propagation & Technical Recurrence Prevention | AIDEFEND

Loading interactive view…

AIDEFEND™

A Practical Knowledge Base for AI Security Defenses

Version

GitHub MCP Service