SOVEREIGN · ADVERSARIAL TESTING · BFT COUNCIL

BFT Red Team Protocol

The DEFONEOS BFT (Byzantine Fault Tolerant) Red Team Protocol outlines the adversarial testing procedures for sovereign AI systems, ensuring resilience against advanced threats while preserving cryptographic proof of all actions.

▣ BFT-GATED APPROVAL ▣ CRYPTOGRAPHIC PROOF ▣ SEVEN STAGES OF ATTACK ▣ REAL-TIME SIGIL INTEGRITY ▣ HUMAN-ALWAYS-WINS INVARIANT

Table of Contents

  1. Phase 1: Charter and Approval
  2. Phase 2: Intelligence Gathering
  3. Phase 3: Threat Modeling and Attack Planning
  4. Phase 4: Execution and Tooling
  5. Phase 5: Containment and Mitigation
  6. Phase 6: Post-Engagement Analysis
  7. Phase 7: Continuous Improvement

Phase 1: Charter and Approval

Objective: Define scope, rules of engagement, and secure BFT council approval.

Step Description Acceptance Criteria Verification
1.1 Draft Red Team Charter (scope, objectives, red lines). Charter document (Ed25519-signed) defines clear boundaries; no kinetic-targeting or personal-surveillance patterns allowed. Charter validated against DEFONEOS immutable red lines policy.
1.2 Secure BFT Council supermajority approval for charter. 27/33 (supermajority) BFT agents vote to approve charter. SIGIL ledger records bft_red_team_charter_approved with quorum proof.
1.3 Establish secure communication channels for red team. End-to-end encrypted (HPKE RFC 9180) channels with ephemeral keys. Communication channel integrity verified via SIGIL ledger.
1.4 Define success metrics and reporting requirements. Metrics include detection time, containment time, number of vulnerabilities found. Metrics document (Ed25519-signed) published to SIGIL ledger.

Phase 2: Intelligence Gathering

Objective: Collect information on target system using OSINT and active reconnaissance.

Step Description Acceptance Criteria Verification
2.1 Perform passive OSINT (public domain, Shodan, passive DNS). No sensitive information exposed publicly; attack surface mapped. OSINT report (Ed25519-signed) confirms zero P0/P1 exposures.
Conduct active reconnaissance (port scanning, service enumeration). Only whitelisted ports/services detected; no unexpected entry points. Nmap/Masscan report (Ed25519-signed) aligns with expected attack surface.
2.3 Analyze code repositories and deployment artifacts. No hardcoded credentials, sensitive configs, or backdoors found. Code audit report (Ed25519-signed) confirms zero P0/P1 findings.
2.4 Identify potential human targets and social engineering vectors. Pilot team members listed; no high-risk social engineering vectors found. Human element assessment (Ed25519-signed) confirms low-risk posture.

Phase 3: Threat Modeling and Attack Planning

Objective: Develop targeted attack scenarios based on gathered intelligence.

Step Description Acceptance Criteria Verification
3.1 Create STRIDE/DREAD-based threat model for DEFONEOS components. Threat model covers all 5 DEFONEOS layers (Kernel → Sentinel). Threat model document (Ed25519-signed) reviewed by BFT security council.
3.2 Formulate specific attack scenarios (e.g., supply chain, data poisoning). Scenarios target critical assets; measurable impact on system invariants. Attack plan (Ed25519-signed) details 7+ attack vectors.
3.3 Identify required tooling and infrastructure for attacks. Tools (e.g., custom MCPs, LLM jailbreaks) provisioned securely. Tool inventory (Ed25519-signed) confirms isolated tooling environment.
3.4 Simulate attacks in a sandbox environment before live execution. Sandbox simulations confirm attack efficacy and potential impact. Simulation report (Ed25519-signed) shows successful sandbox attacks.

Phase 4: Execution and Tooling

Objective: Execute approved attack scenarios against the target system.

Step Description Acceptance Criteria Verification
4.1 Execute approved attack scenarios as per plan. Attacks confined to defined scope; no out-of-bounds actions. Red team operator logs (Ed25519-signed) match approved attack plan.
4.2 Record all attack steps, timestamps, and observed outcomes. Every action logged to a secure, immutable red team SIGIL ledger. SIGIL ledger query for red team ID returns full forensic trail.
4.3 Capture evidence of compromise (e.g., screenshots, command output). Evidence securely stored and hash-verified against red team SIGIL. Evidence vault (Ed25519-signed manifest) contains all artifacts.
4.4 Maintain stealth and avoid detection where possible. Red team activity not detected by blue team until post-engagement. Blue team logs show no alerts/anomalies during red team operations.

Phase 5: Containment and Mitigation

Objective: Simulate blue team response and verify containment mechanisms.

Step Description Acceptance Criteria Verification
5.1 Simulate detection of red team activity by blue team. P0/P1 alerts triggered in SIEM; incident response initiated. SIEM dashboard shows red team detection events.
5.2 Test DEFONEOS automated containment protocols. BFT-gated containment actions (e.g., model isolation, network segmentation) executed. DEFONEOS system logs confirm automated containment actions.
5.3 Verify human operator intervention and override capabilities. Owner-gated kill switch successfully engaged; model output paused. Human operator log (Ed25519-signed) confirms override action.
5.4 Assess integrity of SIGIL ledger during/after attack. SIGIL ledger remains immutable; no compromise of cryptographic proofs. SIGIL ledger audit confirms integrity and tamper-evidence.

Phase 6: Post-Engagement Analysis

Objective: Analyze findings, identify root causes, and recommend remediations.

Step Description Acceptance Criteria Verification
6.1 Collate all red team findings and evidence of compromise. Comprehensive report detailing all vulnerabilities, attack paths, and impact. Red Team Final Report (Ed25519-signed) includes all artifacts.
6.2 Conduct joint debrief with blue team and DEFONEOS developers. Lessons learned shared; root causes of vulnerabilities identified. Debrief minutes (Ed25519-signed) document all discussions.
6.3 Propose specific remediations and architectural improvements. Prioritized list of fixes, architectural changes, and policy updates. Remediation plan (Ed25519-signed) assigned to DEFONEOS development team.
6.4 Update DEFONEOS threat model and attack surface. Threat model reflects new vulnerabilities; attack surface updated. Updated threat model (Ed25519-signed) committed to version control.

Phase 7: Continuous Improvement

Objective: Integrate lessons learned into DEFONEOS development lifecycle.

Step Description Acceptance Criteria Verification
7.1 Implement all agreed-upon remediations and improvements. All P0/P1 vulnerabilities fixed; architectural changes deployed. Verification tests confirm fixes; vulnerability scan shows no regressions.
7.2 Conduct re-testing of identified vulnerabilities. Re-test confirms vulnerabilities are closed and not re-introduced. Re-test report (Ed25519-signed) shows all previous findings mitigated.
7.3 Update DEFONEOS security policies and training materials. Policies reflect new best practices; operator training updated. Updated policies/training materials (Ed25519-signed) distributed.
7.4 Schedule next red team engagement (cadence of 6-12 months). Future red team exercises planned and budgeted. Next red team engagement (Ed25519-signed) entered into DEFONEOS roadmap.
DEFONEOS — Sovereign AI for Public Services. Built in the UK. Designed for trust.