other changes

docs/secret-strategy.md

@@ -31,7 +31,7 @@ For solo personal projects, a complex CI/CD security pipeline is usually overkil
 
 ---
 
-### The Chosen Solution: Dual-Layer Approach
+### The Chosen Solution: Dual-Layer Approach + Infisical Runtime Injection
 
 #### Layer 1: Gitleaks (The Local Guard)
 *   **Where:** Local developer machine (Pre-commit Hook).
@@ -41,6 +41,10 @@ For solo personal projects, a complex CI/CD security pipeline is usually overkil
 *   **Where:** GitHub Actions / CI Pipeline (Post-commit).
 *   **Why:** Uses active verification. If a secret slips past (via an AI agent pushing directly or a bypassed local hook), TruffleHog actively calls out to external APIs to verify if the key is live. By using the `--only-verified` flag, it guarantees zero false positives and only fails the pipeline if it proves a key is an active threat.
 
+#### Layer 3: Infisical Operator (Pipeline Runtime Injection)
+*   **Where:** Inside the Kubernetes Cluster (via `InfisicalSecret` CRD).
+*   **Why:** The security pipeline itself requires numerous highly-privileged secrets (DefectDojo API tokens, AWS S3 keys, Pulumi access tokens, Socket.dev keys) to execute the scans and upload reports. We do not store these in GitOps. Instead, the Helm chart deploys an `InfisicalSecret` resource. The Infisical Kubernetes Operator authenticates with the central vault, pulls the secrets dynamically, and syncs them into a native Kubernetes `Secret` (`amp-security-pipeline-secrets`). The Argo Workflow containers then consume these safely at runtime as environment variables.
+
 ---
 
 ### Tradeoffs & Accepted Risks