# FortWin-Autoimmune Whitepaper ## 1. Abstract FortWin-Autoimmune is a split-brain autonomous defense platform that separates artifact generation from endpoint enforcement. The Forge Plane produces bounded candidate artifacts and strategy packages. The Enforcement Plane admits only signed artifacts, activates them through a deterministic lifecycle, monitors effect, and rolls back when safety constraints are violated. This whitepaper is the canonical architecture document for the FortWin platform. It now distinguishes between: - implemented single-node behavior in this repository - target-state platform direction beyond the current repo Current implemented loop: `register -> ingest -> generate -> validate -> submit -> approve/stage/canary/promote -> feed export/publish -> enforcer verify/apply -> attestation` ## 1.1 Current Implementation Status (as built) Implemented now in this repository: - `FortWin.ControlPlane` - command handling - promotion readiness evaluation - blocker persistence - lane selection - safety-budget and emergency-override gating - incident reconstruction by `trace_id` - runtime artifact archive/retention - `FortWin.Forge` - pipeline APIs: `ingest -> generate -> validate -> submit` - `ForgeManager` - bounded attack-summary, retrieval, repair-intent, compile, and scoring stages - `FortWin.ForgeGpu` - remote ONNX inference service for: - interpretation - pattern reranking - candidate ranking - DirectML-first startup with CPU fallback - `FortWin.Feed` - publish/list/get/pull/verify feed endpoints - `FortWin.Enforcer` - verify/admit/stage/canary/activate or rollback/attest loop - deterministic adapter-backed apply path - `FortWin.Dashboard` - overview - promotion throughput - forges - events - history/archive - incidents - commands - promoted artifact export - append-only JSONL event store with cross-process append locking - paged read paths for runtime artifacts, archive entries, and recent events - Ed25519 feed signing and verification with local key ring - trained local surrogate ONNX models for: - interpret - rerank - ranker Current verification: - the single-node loop is runnable through: - `scripts/start-forge-dashboard-enforcer.ps1` - release verification scripts cover: - control-plane paging - dashboard paging - forge neural readiness - GPU service readiness - single-node production loop ## 1.2 Current Limits Not yet implemented as full production reality: - replay-backed exploit lab validation - symbolic execution - exploit mutation fuzzing - independent deployed multi-forge workers - native host enforcement backends such as real firewall/eBPF/service configuration adapters - incident-trained production ONNX models - fleet/federation distribution beyond the single-node model Those remain target-state work, not current app behavior. ## 2. Problem Statement Conventional security systems are heavy on detection and light on bounded repair: - high alert volume - slow human triage - inconsistent containment - weak rollback discipline - fragmented remediation lineage - poor operational explainability FortWin-Autoimmune addresses this by turning defensive response into signed, versioned, inspectable security artifacts and enforcing them through deterministic lifecycle controls. ## 3. Split-Brain Autonomous Defense Architecture FortWin-Autoimmune enforces strict role separation: - Forge Plane - interprets attack context - proposes candidates - validates and submits them - Control Plane - owns authoritative promotion state - applies readiness, blocker, and budget logic - signs and exports feeds - Enforcement Plane - verifies - stages - canaries - activates - rolls back - attests - Dashboard - provides operator visibility and command ingress ```mermaid flowchart LR subgraph FP["Forge Plane"] D["Detect + Causality"] C["Candidate / Strategy Generation"] V["Bounded Validation"] U["Submit to Control Plane"] D --> C --> V --> U end subgraph CP["Control Plane"] R["Readiness + Lane Selection"] K["Council Verdict / Promotion State"] S["Sign + Export Feed"] U --> R --> K --> S end subgraph AF["Security Artifact Feed"] F[("Signed Feed Envelope")] end subgraph EP["Enforcement Plane"] P["Pull / Load Feed"] X["Verify Signature + Policy"] G["Stage / Canary / Activate"] M["Measure KPIs"] B["Rollback or Remain Active"] T["Emit Attestation"] P --> X --> G --> M --> B --> T end S --> F --> P ``` ### 3.1 As-Built Plane Mapping Current repository services: - Forge Plane: `src/FortWin.Forge` - Control Plane: `src/FortWin.ControlPlane` - Feed Plane: `src/FortWin.Feed` - Enforcement Plane: `src/FortWin.Enforcer` - Dashboard: `src/FortWin.Dashboard` - Remote inference boundary: `src/FortWin.ForgeGpu` ## 4. Security Artifact Model Artifacts are the executable contract between generation and enforcement. ### 4.1 First-Class Artifact Kinds - `NetworkContainment` - `ServiceHardening` - `BehaviorGuard` - `AutomatedRepair` ### 4.2 Canonical Objects The codebase locks these schema-level objects: - `SecurityArtifact` - `SecurityArtifactAction` - `ArtifactCouncilVerdict` - `DefenseStrategyPackage` - `SecurityArtifactFeed` - `CommandEnvelope` - `AttestationRecord` Representative shape: #### SecurityArtifact ```json { "artifact_id": "art-20260314-0042", "kind": "NetworkContainment", "version": "1.0.0", "target_surface": "host_runtime", "risk_score": 0.18, "requires_operator_approval": false, "expiry_utc": "2026-04-10T00:00:00Z", "actions": [], "capabilities": [], "rollback": { "mode": "restore_previous", "snapshot_id": "snap-art-20260314-0042" }, "metadata": { "trace_id": "trace-771", "issuer": "forge" }, "rollback_reference": "previous-artifact-id" } ``` #### SecurityArtifactFeed ```json { "schema_version": 1, "key_id": "fwk-20260312035907-6b8fd9c7e84641a5857c0df88bc973d3", "signature_algorithm": "ed25519", "feed_id": "feed-20260314-120001", "issuer_node_id": "forge-node-01", "timestamp_utc": "2026-03-14T12:00:01Z", "signature": "signature-hex", "trust_metadata": { "issuer": "trusted", "scope": "single-node-v1" }, "artifacts": [] } ``` #### CommandEnvelope ```json { "command_id": "cmd-20260314-2001", "command_type": "Approve", "issued_by": "operator", "trace_id": "trace-771", "target_id": "art-20260314-0042", "payload": {} } ``` #### AttestationRecord ```json { "attestation_id": "att-20260314-9001", "trace_id": "trace-enforcer-771", "node_id": "node-01", "artifact_id": "art-20260314-0042", "status": "applied", "reason": "applied", "latency_delta_ms": 0.7, "drop_rate_delta_percent": 0.03, "rollback_pressure": 0.0, "timestamp_utc": "2026-03-14T12:02:10Z" } ``` ## 5. Forge System FortWin’s long-term design is a multi-forge ecosystem. The current codebase implements the first production-real slice of that idea. ### 5.1 Target-State Multi-Forge Direction Target-state forge families: - Neural Forge - Deterministic Forge - Replay Forge - Hardening Forge In the target architecture, these forges compete or collaborate to produce candidate artifacts and strategy packages. No forge deploys directly. ### 5.2 Current As-Built Forge Reality Current repo behavior is: - one deployed Forge service - one `ForgeManager` - multiple internal candidate profiles: - `Conservative` - `Balanced` - `Aggressive` - `Phased` - one remote inference service boundary for ONNX work That means the current app already has candidate diversity, but it does not yet run separate independently deployed forge worker services. ```mermaid flowchart TD T["Threat / Trace / AttackGraph"] --> M["ForgeManager"] M --> H["TraceUnderstandingEngine"] H --> G["AttackStateModeler"] G --> R["EventOutcomeRetriever"] R --> I["RepairHypothesisGenerator"] I --> C["ConstrainedArtifactCompiler"] C --> S["ForgeCandidateScorer"] S --> P["Pre-Council Candidate Set"] P --> K["Strategy Council (Control Plane)"] subgraph GPU["Remote GPU Inference Boundary"] GI["Interpret"] GR["Rerank"] GN["Rank"] end H -. optional .-> GI R -. optional .-> GR S -. optional .-> GN ``` ### 5.3 ONNX Model Status The repository now contains trained local surrogate ONNX models for: - interpretation - pattern reranking - candidate ranking These are real trained models used to make the GPU boundary operational and testable. They are not yet incident-trained production models. ### 5.4 Dual-Network Forge Upgrade The next contract-locked Forge step is a dual-network architecture: - `Repair Synthesis Network` - generates `RepairIntent` - generates `RepairCandidate` - emits conservative, balanced, aggressive, and phased variants - `Promotion Assurance Network` - evaluates promotion readiness - critiques rollback weakness and policy mismatch - recommends revisions before council This is now formalized in the repo spec and shared contracts through: - `PromotionAssessment` - `PromotionCritique` - `CrossForgeLearningRecord` Current as-built reality: - the repo does not yet run two separately deployed neural services for these roles - the role separation is now locked at the contract/spec layer so runtime implementation can follow without redefining objects later ## 6. Attack Graph and Strategy Engine FortWin has moved beyond artifact-only handling toward strategy-aware defense planning. ### 6.1 Attack Graph Modeling Current attack graph inputs: - nodes for hosts, services, identities, and related entities - weighted edges - inferred attack phase - predicted next steps Current outputs: - `TraceSummary` - `AttackTransition[]` - graph fingerprint and phase context ### 6.2 Defense Graph Generation Current forge compilation produces: - bounded artifacts - `DefenseGraph` - ordered defense actions per candidate ### 6.3 Defense Strategy Packages Current control-plane council materializes: - `DefenseStrategyPackage` - `ArtifactCouncilVerdict` The package includes: - `strategy_id` - `trace_id` - `attack_fingerprint` - `phase` - `defense_graph` - `artifacts` - `activation_plan` - `safety_constraints` - `rollback_reference` ### 6.4 Validation Reality The current system performs real bounded validation, but not full research-grade exploit replay validation. Implemented now: - intent validation - action allowlist validation - rollback contract validation - risk/performance heuristic checks - hard-gate filtering - strategy dependency checks in council evaluation Not implemented now: - symbolic validation - replay sandboxing - exploit mutation replay - full differential behavior harness That distinction matters. The current app is operational, but its validation stack is still heuristic rather than laboratory-grade. ## 7. Artifact Council The whitepaper concept is “Artifact Council.” The current repository implements this primarily as `StrategyCouncilService`. ### 7.1 Current Council Behavior Current council input: - `StrategyCandidate[]` - per-candidate validation state Current council behavior: - validates hard-gate conditions - checks defense-graph dependencies - checks rollback feasibility - scores survivors deterministically - emits: - `ArtifactCouncilVerdict` - `DefenseStrategyPackage` Current scoring blends: - efficacy - performance - phase fit - rollback readiness ### 7.2 Doctrine Council policy remains: 1. hard gates first 2. weighted survivor scoring second Current implementation follows that doctrine, even though the present council is strategy-centric rather than split into separate artifact-only and strategy-only services. ### 7.3 Promotion Assurance Role The new target-state learned assurance layer sits between deterministic validation and council selection: `Generator -> Compiler/Validation -> PromotionAssessment -> Council` Rules: - Promotion Assurance does not replace hard gates - Promotion Assurance does not sign or activate artifacts - Promotion Assurance provides structured critique, not only freeform commentary - Council remains the deterministic promotion authority ## 8. Validation Pipeline and Lifecycle ### 8.1 Lifecycle States Implemented lifecycle states: - `Candidate` - `ShadowPending` - `ShadowComplete` - `VerificationPass` - `PromotionEligible` - `ArtifactBuildPending` - `Staged` - `CanaryActive` - `LocallyActive` - `FederationAdvertised` - `FleetEligible` - `VerificationFailed` - `PromotionBlocked` - `CanaryFailed` - `RolledBack` - `Retired` - `Suppressed` ### 8.2 Current Blocker Reasons Implemented blocker reasons include: - `AutonomyRestricted` - `OperatorApprovalRequired` - `SafetyBudgetExceeded` - `NoEnforcementSurface` - `ArtifactBuildFailed` - `PolicyConflict` - `CanaryCapacityUnavailable` - `InsufficientConfidence` - `SimilarityMismatch` - `RuntimeHealthDegraded` - `MissingTrustContext` ### 8.3 Current Transition Rules Key current rules: - `Approve` always evaluates readiness - readiness persists: - `lane` - `primary_blocker` - `secondary_blockers` - `required_next_step` - repair lane may enter `ArtifactBuildPending` - `Stage`, `Canary`, and `Promote` are blocked by emergency override - safety budget blocks unsafe transitions ```mermaid stateDiagram-v2 [*] --> Candidate Candidate --> VerificationPass VerificationPass --> PromotionEligible: readiness pass VerificationPass --> PromotionBlocked: readiness fail PromotionEligible --> ArtifactBuildPending ArtifactBuildPending --> Staged Staged --> CanaryActive CanaryActive --> LocallyActive: healthy CanaryActive --> CanaryFailed: unhealthy CanaryFailed --> RolledBack LocallyActive --> FederationAdvertised FederationAdvertised --> FleetEligible LocallyActive --> RolledBack: safety breach LocallyActive --> Retired: retention / policy retire PromotionBlocked --> Suppressed ``` ## 9. Endpoint Enforcer Lifecycle The Enforcer is a runtime artifact lifecycle engine, but today it is adapter-backed rather than host-native. Current responsibilities: - load feed file - verify signature and trust - apply admission policy - stage - canary - activate - rollback on failure - emit attestation and summary files Current deterministic statuses: - `applied` - `deferred` - `rejected` - `rolled_back` Current implementation detail: - per-artifact-kind adapter state is written to `data/runtime/adapters/*.json` - operations are currently: - `simulate` - `upsert` - `delete` This is enough to make the end-to-end loop real, but it is not yet equivalent to a native endpoint security agent with direct OS or kernel control surfaces. ## 10. Trust, Signing, and Admission Rules Current signing implementation: - Ed25519 - NSec-based key handling - local key ring persisted under `data/runtime/keys` Current admission doctrine: - trust signed feed envelopes - verify key identity and signature - reject expired artifacts - reject disallowed capabilities - reject artifact kinds whose action sets violate kind policy Important implementation note: - the signer class is still named `HmacArtifactSigner` - the implementation is asymmetric Ed25519, not HMAC ## 11. Dashboard and Operator Model The dashboard is now part of the implemented product, not a future note. Current dashboard capabilities: - service health - forge and GPU readiness - inference telemetry visibility - promotion throughput - event feed - runtime archive/history inspection - incident lookup by `trace_id` - command dispatch - promoted artifact export Current payload design: - `/api/dashboard/overview` is intentionally trimmed - heavy collections are paged through dedicated endpoints: - runtime artifacts - runtime archive - recent events - pipelines This keeps the dashboard usable under heavier state volume. ## 12. SaaS Platform Positioning FortWin-Autoimmune remains a security artifact subscription architecture: - Enforcer = installed runtime engine - Forge ecosystem = artifact creation and evaluation system - Feed = signed distribution channel This remains a strong commercial and operational model even at the current single-node stage. ## 13. Feedback Learning Loop Current feedback loop inputs: - event history - strategy verdicts - enforcer processed-artifact outcomes - attestation records - runtime archive and rollback history Current loop usage: - retrieved patterns influence forge priors - rerank/rank models influence ordering - dashboard exposes inference telemetry and outcome summaries Target-state next: - use real incident corpora and attestation outcomes to train stronger production ONNX models - train Generator and Promotion Assurance roles against shared outcome records - persist dual-network learning via `CrossForgeLearningRecord` ### 13.1 Dual-Network Learning Signals The Generator should learn from: - compile success - validation pass rate - canary survival - rollback rate - critique-guided revision success The Promotion Assurance role should learn from: - prediction accuracy against real canary/apply outcomes - false-safe approvals - false-negative over-rejections - usefulness of structured critiques Both roles should consume: - council outcomes - rollback events - attestation records - operator suppressions ## 14. Public Interfaces / Types to Lock ### Commands - `Approve` - `Stage` - `Canary` - `Promote` - `Rollback` - `Suppress` - `SetAutonomyLevel` - `SetEmergencyOverride` ### Council Interface Current input: - `StrategyEvaluationRequest` - `StrategyCandidate[]` Current output: - `StrategyEvaluationResult` - `ArtifactCouncilVerdict` - optional `DefenseStrategyPackage` Next locked assurance objects: - `PromotionAssessment` - `PromotionCritique` - `CrossForgeLearningRecord` ### Feed Interface Current signed feed envelope: - `schema_version` - `key_id` - `signature_algorithm` - `feed_id` - `issuer_node_id` - `timestamp_utc` - `signature` - `trust_metadata` - `artifacts` ### Enforcer Interface Current result model: - status: - `applied` - `deferred` - `rejected` - `rolled_back` - typed `failure_reason` - lifecycle `state` - `ArtifactHealth` ## 15. Implementation Roadmap Status ### Phase 1: Shared contracts + event store + command handling Status: implemented - shared contracts are in place - append-only eventing is in place - authoritative command handling is in place ### Phase 2: Forge plane Status: implemented for the current single-forge service, partial for target-state multi-forge deployment - bounded forge stack exists - `ForgeManager` exists - GPU inference boundary exists - separate deployed deterministic/replay/hardening forge services do not yet exist ### Phase 3: Feed plane Status: implemented - signed feed envelopes - publish/list/get/pull/verify endpoints - control-plane export/build path ### Phase 4: Enforcer plane Status: implemented for adapter-backed single-node enforcement - verify/admit/stage/canary/activate/rollback/attest is real - native host enforcement backends remain future work ### Phase 5: Dashboard/API read models and operator controls Status: implemented for the current dashboard - current repo includes the dashboard executable - operator controls are mapped to real commands - archive/history inspection is implemented - paged read models are implemented ### Phase 6: Soak and reliability hardening Status: partial - integrated loop scripts and verification scripts exist - more long-run soak automation and broader failure injection remain future work ## 16. Test Plan ### 16.1 Spec Integrity - every command type must reach authoritative mutation paths - every artifact kind must declare bounded actions and rollback semantics ### 16.2 Service Integration - single-node end-to-end loop must pass - signed feed verification must pass - emergency override and safety budget must block unsafe transitions - dashboard paging endpoints must stay operational ### 16.3 Council Behavior - unsafe candidates fail hard gates - scoring remains deterministic for identical inputs - rollback-infeasible strategies are rejected ### 16.4 Operational Reliability - incident reconstruction by `trace_id` remains available - no silent terminal outcomes - GPU service must either: - attach preferred provider - or fall back cleanly while staying truthful in status/telemetry ## 17. Assumptions and Defaults - primary stack: `.NET 9` - current scope: single-node production reality first - whitepaper diagrams remain source-of-truth architecture visuals - promotion remains bounded by hard gates, readiness, council logic, and safety budgets - federation and fleet-scale orchestration remain future extensions beyond the current repo