RED MANEUVERS

Red‑Teaming Autonomous Neuromorphic Military Command

by
Gerard King
www.gerardking.dev

First Edition · © 9/27/2025 Gerard King
All rights reserved. This work is deliberately non‑operational. It provides high‑level conceptual frameworks, governance, testing methodologies, and ethical analysis for red‑teaming and evaluating autonomous neuromorphic command systems — not instructions for building, weaponizing, or deploying such systems. Material that could meaningfully facilitate the construction or use of weapon systems has been omitted.

Independent Research 

FOCUSED TABLE OF CONTENTS

Preface — Purpose, audience, and safety constraints
Acknowledgements

Part I — Problem Framing

1. Why Red‑Team Neuromorphic Command? — Motivation and scope (pp. 1–8)
   
   

2. Definitions and Boundaries — Neuromorphic computing, autonomy, command authority (pp. 9–16)
   
   

3. Threat Model Taxonomy — Adversarial actors, failure modes, insider vs. external threats (pp. 17–28)
   
   

Part II — Conceptual Architecture (Non‑Operational)
4. High‑Level System Blocks — Sensing, representation, decision affordances, actuation interfaces (conceptual only) (pp. 29–40)
5. Human‑In‑the‑Loop vs. Human‑On‑the‑Loop — Decision authority design patterns (pp. 41–48)
6. Observability and Audit Trails — Telemetry, provenance, and explainability for neuromorphic systems (pp. 49–58)

Part III — Red‑Team Methodology for Neuromorphic Command
7. Red‑Team Objectives and Constraints — Safety‑first scoping (pp. 59–66)
8. Scenario Design — Political, operational, and environmental axes (tabletop vs. simulated) (pp. 67–78)
9. Adversarial Test Types — Robustness tests, distributional shift, adversarial inputs (conceptual, non‑exploitable) (pp. 79–92)
10. Behavioral and Cognitive Stress Tests — Surprise inputs, degraded sensors, contested communications (pp. 93–104)
11. Socio‑Technical Attacks — Human factors, misinformation, and chain‑of‑command manipulation (pp. 105–116)
12. Red Team Tools & Environments — Safe sandboxing, synthetic data, digital twins, and rule‑based emulators (pp. 117–128)

Part IV — Maneuvers (Playbooks at Policy Level)
13. Tabletop Maneuver: Loss of Communications — Decision authority reallocation and failover checks (exercise design and injects; non‑actionable) (pp. 129–140)
14. Tabletop Maneuver: Sensor Degradation & Conflicting Reports — Cross‑validation, uncertainty handling, and escalation triggers (pp. 141–152)
15. Tabletop Maneuver: Insider Compromise Hypothesis — Authentication, provenance checks, and human verification pathways (pp. 153–162)
16. Tabletop Maneuver: Adversarial Information Environment — Influence operations, false telemetry, and command resilience (pp. 163–174)
17. Simulation Maneuver: Distributional Shift — Testing generalization and graceful degradation (design principles; non‑exploitable) (pp. 175–186)
18. Combined Maneuver Series — Multi‑axis red team campaign templates for policymakers and auditors (pp. 187–198)

Part V — Metrics, Evaluation & Reporting
19. Safety and Compliance Metrics — Harm‑centric measures, human override latency, and audit fidelity (pp. 199–210)
20. Robustness Metrics — Confidence calibration, performance under stress, and graceful failure indicators (pp. 211–222)
21. Reporting Formats — Executive brief, technical appendix, and red team after‑action report templates (pp. 223–234)

Part VI — Governance, Ethics & Legal Considerations
22. Rules of Engagement for Red Teams — Ethics, legal review, and institutional approvals (pp. 235–244)
23. Accountability Mechanisms — Logs, immutable evidence, and independent verification (pp. 245–254)
24. Policy Remedies — Design constraints, certification schemes, and operational limits (pp. 255–266)
25. International and Domestic Norms — Confidence‑building, transparency, and export‑control implications (pp. 267–278)

Part VII — Organizational Implementation
26. Building a Responsible Red Team Unit — Mandate, skills, and cross‑disciplinary composition (pp. 279–288)
27. Training and Exercises — Curriculum, tabletop cadence, and white/grey/black box staging (pp. 289–300)
28. Integration into Acquisition and Lifecycle — Procurement checkpoints, acceptance testing, and post‑deployment monitoring (pp. 301–312)

Part VIII — Case Studies & Thought Experiments (Open Sources Only)
29. Historical Analogues — Command failures and lessons for autonomous systems (pp. 313–324)
30. Hypothetical Exercises — Non‑operational debriefs and sanitized red team findings (pp. 325–336)

Conclusions (pp. 337–342)
Appendices
A. Glossary (pp. 343–350)
B. Red Team Reporting Templates (safe, non‑operational) (pp. 351–360)
C. Sample Tabletop Injects (policy‑level, sanitized) (pp. 361–370)
D. Further Reading and Standards (open literature) (pp. 371–380)

Bibliography (pp. 381–396)
Index (pp. 397–412)

SELECTED INDEX (focused entries; conceptual page refs)

Adversarial inputs — conceptual tests, 79–92
Audit trail — provenance, 49–58; reporting, 223–234
Authority reallocation — failover patterns, 129–140; 41–48
Black/grey/white box testing — staging, 289–300; 117–128
Cognitive stress tests — 93–104
Distributional shift — simulation design, 175–186; robustness metrics, 211–222
Ethics — red team rules, 235–244; societal impacts, 267–278
Explainability / observability — 49–58; 199–210
Human factors — 105–116; training, 289–300
Insider compromise — 153–162
Metrics — safety, compliance, 199–210; robustness, 211–222
Red team unit — composition & skills, 279–288
Reporting — after‑action, 223–234; templates, 351–360
Sandboxing & digital twins — 117–128
Tabletop injects — sample (sanitized), 361–370
Transparency & verification — 245–254; 255–266

Preface

This book — Red‑Maneuvers: Red‑Teaming Autonomous Neuromorphic Military Command — was written to help fill a gap I kept seeing in conversations between technologists, defence practitioners, policymakers, and civil‑society actors. Neuromorphic architectures and other brain‑inspired approaches are being discussed in labs and white papers; autonomy is being debated in doctrine rooms and parliaments. Yet the practical work of testing, challenging, and assuring command systems that claim cognitive, adaptive, or neuromorphic properties remains poorly scoped, inconsistently governed, and often dangerously under‑specifed.

The central purpose of this book is narrow and deliberate: to provide a clear, ethics‑first, policy‑oriented playbook for red‑teaming — i.e., stress‑testing, probing, and evaluating — autonomous command systems that incorporate neuromorphic ideas at a conceptual level. That means the emphasis is on scenario design, organizational process, evaluation metrics, reporting, and governance. It does not mean recipe‑level instructions, exploit walkthroughs, or any operational guidance that could be used to build, weaponize, or meaningfully compromise real systems.

Who this is for
• Policymakers and parliamentary staff who must set boundaries, certification requirements, and oversight modalities for novel command systems.
• Military and defence acquisition officers responsible for acceptance testing, safety certification, and supplier‑facing red teams.
• Independent auditors, regulators, and compliance teams that will evaluate safety, provenance, and auditability.
• Ethicists, legal advisers, and civil‑society organizations seeking concrete frameworks to evaluate risk and propose mitigations.
• Interdisciplinary red‑team practitioners (human factors, systems engineers, legal, political‑military) charged with designing exercises and after‑action reporting.

What this book is not
• It is not a technical manual for designing or tuning neuromorphic hardware or software.
• It is not a how‑to guide for offensive cyber, kinetic operations, or exploitation of AI systems.
• It is not a normative endorsement of deploying autonomous lethal decision‑making. Where the technical and political landscapes permit, this book assumes conservative design constraints and prioritizes human oversight and legal compliance.

Safety constraints and editorial stance
Safety is the operating principle for every chapter. To make that explicit:

1. Non‑operational framing. Wherever technical topics appear (architectural overviews, stress‑test categories, simulation concepts) I intentionally present them at a high conceptual level. I avoid code, configuration parameters, specific attack vectors, or test payloads that could be misused.
   
   

2. Harm‑centric metrics. The book reframes evaluation success away from raw performance and toward indicators that matter for safety, accountability, and lawful behaviour: human override latency, provenance fidelity, graceful degradation, and audit completeness.
   
   

3. Institutional approvals and ethics. Every red team activity described in this book assumes formal pre‑approval by appropriate legal, ethical, and institutional bodies. Sample rules of engagement, approval checklists, and reporting templates are included so teams have a procedural blueprint for safe testing.
   
   

4. Openness about limits. Many neuromorphic concepts remain experimental and contested. The book marks uncertainty where it exists and recommends conservative operational postures where evidence is incomplete.
   
   

How to use this book
• Read Part III (Red‑Team Methodology) and Part IV (Maneuvers) first if you are looking to design an exercise.
• Use the reporting templates in Part V and Appendix B to structure findings for both technical and non‑technical audiences.
• Use the governance chapters to draft procurement clauses, certification checkpoints, and oversight rubrics.
• Adapt tabletop scenarios to institutional risk tolerance but always preserve the safety constraints and pre‑approval requirements included here.

On language and tone
I’ve tried to write for a mixed audience: precise enough for technologists to be useful; plain enough for policymakers and ethicists to act on. Key terms are defined in the glossary (Appendix A); legal and ethical anchors are called out with references to existing instruments and literature (open sources only).

A final note on intent and responsibility
The decisions that surround autonomous command systems will have far‑reaching humanitarian, political, and strategic consequences. Red teams — when properly constrained and empowered — are one of the most powerful tools institutions have to discover brittle failure modes before they cause real harm. This book is my contribution to making that practice safer, more transparent, and more accountable.

If you use the frameworks here, do so with humility, rigorous legal oversight, and a bias toward preserving meaningful human control. If you’d like, the next chapter gives a short, one‑page checklist to get a red‑team exercise from concept to authorized tabletop in a legally compliant way.

ACKNOWLEDGEMENTS

This manuscript is an initial draft conceptualizing autonomous neuromorphic military command red teaming maneuvers. The page numbers throughout are provisional and conceptual, anticipating formal publication with finalized pagination. This draft has not undergone third-party audit or institutional review and should be considered a foundational work for further expert validation and refinement.

I extend my deepest gratitude to OpenAI for developing the generative AI technologies that enabled much of the synthesis, drafting, and exploration of ideas presented here. Their innovations in natural language processing have been critical in shaping this work. See OpenAI at https://openai.com and ChatGPT at https://chat.openai.com.

Equally, I thank Google for providing the research infrastructure, tools, and cloud platforms that supported the iterative development of this project. See Google at https://www.google.com.

This work is offered from a civilian perspective, with the hope it can contribute to setting rigorous safety, accountability, and transparency standards for future autonomous command systems within Canadian Defence. It is not an operational manual but a policy-oriented framework intended to foster responsible innovation.

Selected GPTs and Web Properties by Gerard King

Throughout the research and drafting process, I utilized a variety of GPT-powered tools developed or curated under the gerardking.dev umbrella. Below is a curated list of notable GPTs and related web resources, with direct URLs for reference:

GPT / Web Property

Description

URL

Quantum Input Output Interface Architect (QIOIA)

Expert in integrating quantum computing with computer I/O systems

https://jarvis.cx/tools/gpts/quantum-input-output-interface-architect-qioia-85082

Know It All King III

A versatile GPT developed by Gerard King

https://chat-prompt.com/gpt-store/g-75cmrpIxI-know-it-all-king-iii

Aardvark Infinity Resurgence

Uses 2,322 GPTs created by gerardking.dev

https://medium.com/@aardvarkinfinity/my-gpts-032af20a11ff

Gerardking.dev, Quantum Central Bank Operator

GPT focused on financial innovation inspired by quantum principles

https://jarvis.cx/tools/gpts/*-gerardking-dev-quantum-central-bank-operator-65814

Pinterest Page

YouTube Shorts on AI, scripting, and cybersecurity by gerardking.dev

https://ca.pinterest.com/gerardkingdev/gpts-by-gerardkingdev/

Cybersecurity Engineering Insights Blog

Blog focused on cybersecurity authored by Gerard King

https://www.cei.gerardking.dev/

Medium Profile (Aardvark Infinity)

Articles on AI, cybersecurity, and automation

https://medium.com/@aardvarkinfinity/

These AI tools and web properties reflect the diversity and interdisciplinary scope of the research underpinning this work. They are included here for transparency and to provide readers with access to related resources created during the development of this draft.

Responsibility and Limitations

All remaining errors or omissions are my sole responsibility. The inclusion of third-party platforms and contributors does not imply their endorsement of this manuscript’s contents. Contributors reviewed only policy-level, non-operational materials. This work remains a preliminary draft and requires further third-party review before formal adoption or operational use.

If this book adds value, I encourage engagement in public consultations, ethical review processes, and independent audits to advance safer, more accountable autonomous command systems.

— Gerard King
www.gerardking.dev

Part I — Problem Framing

Chapter 1 — Why Red‑Team Neuromorphic Command?

Motivation and scope (pp. 1–8)

Overview (what this chapter does)

This chapter explains why institutions should invest in disciplined, safety‑first red‑teaming for command systems that incorporate neuromorphic or brain‑inspired claims. It sets the problem boundaries, articulates the policy and operational stakes, identifies the principal audiences and stakeholders, and defines a constrained scope for responsible red‑team activity. Throughout I keep the framing conceptual and policy‑oriented — deliberately avoiding technical recipes, exploit details, or any instruction that could aid misuse.

1.1 Why this problem matters now

Neuromorphic approaches — architectures that emphasise event‑driven sensing, spiking representations, low‑power adaptive dynamics, or other brain‑inspired motifs — are emerging in research labs and early prototype systems. When such architectures are proposed as components of command systems (systems that make, recommend, or facilitate orders affecting people, resources, or the use of force), the risks become strategic and humanitarian, not merely technical.

Key drivers that make red‑teaming urgent:

• Operational impact: Command systems affect mission intent, escalation, and lives. Failures here amplify harm.
• Novel failure modes: Neuromorphic designs (and other adaptive models) can exhibit brittle generalization, opaque internal dynamics, and stateful behaviours whose failure modes differ from classical deterministic software.
• Decision‑delegation trend: Militaries and agencies are experimenting with increasing levels of automation in decision loops; oversight must keep pace.
• Regulatory pressure and public scrutiny: Policymakers, courts, and publics demand evidence that systems respect law, ethics, and accountability. Red‑team outcomes feed those processes.
• Supply‑chain and insider risks: Autonomous command depends on diverse vendors, sensors, and human workflows; adversary influence or human error can have systemic effects.

1.2 The specific role of red‑teaming

Red‑teaming is not the only safeguard; it complements other assurance activities (formal verification where applicable, independent audits, certification testing, and operational doctrine). Its unique value:

• Probing assumptions — surface implicit design assumptions about intent, inputs, and operational context.
• Stress‑testing socio‑technical coupling — reveal how human operators, rules of engagement, and organizational incentives interact with system behaviours.
• Discovering policy gaps — identify where doctrine, procurement language, or oversight mechanisms are silent or inconsistent with system capabilities.
• Informing mitigations — generate actionable policy‑level recommendations (constraints, controls, monitoring) that reduce real‑world harm.

Importantly, red‑teams should not be framed as adversary playbooks. Safe red‑team practice focuses on exposing risk and remediating it — not on producing usable exploits.

1.3 Scope: what this book’s red‑teaming covers (and excludes)

Included (policy‑safe, non‑operational):
• Conceptual manoeuvres and tabletop exercises that simulate degraded conditions (loss of comms, sensor conflict, contested information environments) at a high level.
• Organizational, legal, and ethical stress tests (chain‑of‑command, rules of engagement, audit fidelity).
• Simulation design principles (sandboxing, digital twins, sanitized data) and staging guidance for safe environments.
• Metrics and reporting formats oriented to safety, accountability, and public oversight.
• Rules of engagement, approvals, and institutional governance for red teams.

Excluded (deliberately):
• Concrete methods, payloads, or inputs that would enable exploitation of neuromorphic hardware or software.
• Step‑by‑step offensive cyber or kinetic operation instructions.
• Low‑level tuning, architectures, or code snippets for building neuromorphic command capabilities.
• Any material that meaningfully lowers the bar for hostile actors to weaponize or subvert systems.

1.4 Principal audiences and stakeholders

This chapter frames who should read and act on red‑team outputs.

Primary audiences:
• Policy and legislative bodies — need evidence, plain‑language summaries, and policy prescriptions.
• Military leadership and acquisition authorities — need assurance criteria, procurement language, and operational constraints.
• Red‑team practitioners and auditors — need safe test designs, reporting templates, and governance guards.
• Legal and ethics advisors — need scenarios and findings expressed in terms amenable to legal evaluation.
• Civil society and oversight bodies — need transparent, sanitized summaries to inform public debate.

Secondary stakeholders: vendors, standards bodies, and international confidence‑building actors who may use sanitized red‑team outcomes to inform specifications and norms.

1.5 High‑level objectives for safe red‑teaming of neuromorphic command

Every red‑team engagement should map to a small set of safety‑centric objectives. Examples (conceptual):

1. Detect brittle behaviour — identify conditions under which the system’s outputs become untrustworthy or inconsistent with operator intent.
   
   

2. Verify oversight pathways — confirm humans can observe, intervene, and override within required timeframes and with verifiable audit trails.
   
   

3. Expose socio‑technical vulnerabilities — reveal how human error, miscommunication, or organizational incentives could lead to unsafe outcomes.
   
   

4. Validate provenance and traceability — ensure inputs, decisions, and overrides are recorded in a manner suitable for after‑action review.
   
   

5. Assess graceful degradation — confirm the system fails in non‑harmful ways when outside validated operating envelopes.
   
   

6. Produce policy‑actionable recommendations — provide mitigation options that are implementable at doctrine, procurement, or regulatory levels.
   
   

These objectives prioritize human safety, legal compliance, and institutional learnability over any single measure of system performance.

1.6 Typical red‑team question set (policy phrasing)

Red teams should begin with a short set of high‑level questions that avoid technical detail but focus the exercise:

• Under what conditions could the system issue a decision that materially diverges from stated mission intent?
• What human roles and approvals are required to transform system output into action, and are those roles realistic under operational stress?
• How observable are internal representations and uncertainty estimates to operators and auditors?
• How does the system behave under reasonable distributional shifts in sensing and environment? Does it fail safely?
• What traces exist to reconstruct a decision path during an incident review?
• What organizational or procurement incentives might encourage premature reliance on automated outputs?

These questions guide scenario design and reporting without touching technical exploits.

1.7 Risk taxonomy (high level)

For productive red‑team planning, use a simple four‑category risk taxonomy:

1. Technical risks — model brittleness, opaque internal state, calibration drift, sensor fusion inconsistencies (conceptual).
   
   

2. Operational risks — misaligned doctrine, poor human‑machine teaming, unrealistic operator training, or acceptance of opaque outputs.
   
   

3. Organizational risks — procurement pressures, vendor lock‑in, inadequate audit or rollback mechanisms.
   
   

4. Societal/legal risks — civilian harm, violations of law of armed conflict, loss of public trust, and export/transfer concerns.
   
   

Red‑team activities should aim to reveal cross‑cutting risks that span these categories.

1.8 Safety guardrails for red‑team design (procedural checklist)

Before any exercise begins, the following approvals and controls should be obtained and documented. These are procedural, non‑technical safeguards:

1. Legal review: independent legal counsel certifies the exercise plan is lawful and that results will be handled appropriately.
   
   

2. Ethics and institutional approval: an institutional review board or ethics panel authorizes the exercise scope and safeguards.
   
   

3. Defined non‑operational scope: explicit written constraints forbidding development of operational exploits or public release of operational detail.
   
   

4. Sanitization plan: rules for what findings are publishable in sanitized form for policy audiences.
   
   

5. Safety‑first rules of engagement: stop conditions, escalation channels, and human override requirements codified.
   
   

6. Data governance: use of synthetic or sanitized datasets where real data would pose privacy or security risks.
   
   

7. Independent observers: invite neutral auditors or legal observers to validate that the exercise adhered to constraints.
   
   

8. After‑action handling: a pre‑defined process for remediations, responsible disclosure to vendors, and reporting to oversight bodies.
   
   

These guardrails are essential to ensure the red team’s work reduces risk rather than creating it.

1.9 What success looks like (policy signals)

Success for a red‑team engagement is not “finding an exploit” but generating clear, implementable signals that decision‑makers can act on. Examples:

• A prioritized list of governance and procurement clauses that mandate audit trails, human‑in‑loop thresholds, and testable fail‑safe behaviours.
• An after‑action report that translates technical findings into legal, ethical, and operational implications with recommended mitigations.
• Concrete acceptance criteria and test checkpoints added to acquisition contracts or certification frameworks.
• Training requirements and scenario libraries integrated into operator curricula.
• Evidence packages (sanitized) suitable for public oversight and parliamentary review.

1.10 Limitations and ethical commitments

Red‑teaming is limited in scope and cannot replace robust safety engineering, formal verification where applicable, or democratic oversight. Ethical commitments this practice must uphold:

• Prioritize human life and legal compliance over technical performance.
• Avoid creating or publishing operationally useful exploit information.
• Ensure equitable access for oversight actors to sanitized results.
• Transparently document constraints, uncertainties, and residual risks.

1.11 Roadmap for the rest of the book (what to expect next)

Chapters that follow translate this framing into safe, usable practice: high‑level architectural concepts (Chapter 4), red‑team methodology and scenario design (Chapters 7–12), specific policy‑level maneuver playbooks (Chapters 13–18), and metrics/reporting templates for translating findings into governance action (Chapters 19–21). Appendices provide checklists and sanitized templates for approvals and reporting.

Closing (short)

Neuromorphic and adaptive approaches may promise efficiency or capability gains, but their incorporation into systems that influence command decisions raises distinct risks. Well‑scoped, ethically governed red‑teaming — focused on exposing socio‑technical brittleness and generating policy‑actionable mitigations — is a necessary part of responsible stewardship. This book offers a practical, safety‑focused path for institutions to do that work without inadvertently lowering the bar for misuse.

Part I — Problem Framing

Chapter 2 — Definitions and Boundaries

Neuromorphic computing, autonomy, command authority (pp. 9–16)

Overview (what this chapter does)

This chapter defines key terms and concepts critical for understanding the scope of red‑teaming autonomous neuromorphic command systems. It aims to establish clear, actionable distinctions between neuromorphic computing, autonomy, and command authority — all of which are central to the red‑team process described in this book. By drawing these boundaries, this chapter sets the stage for safe, non‑exploitative engagement with such systems, ensuring clarity around what red‑teams should test, how they should approach system behaviour, and where legal and ethical responsibilities lie.

2.1 Neuromorphic Computing: What it is and isn’t

Neuromorphic computing is an interdisciplinary field that seeks to build computing architectures inspired by the structure and function of the brain. These systems are often contrasted with traditional computing architectures, which tend to be designed around logic gates, sequential execution, and fixed pathways.

Key elements of neuromorphic systems:

• Spiking neural networks (SNNs): Unlike classical artificial neural networks (ANNs), which use continuous signals, neuromorphic systems rely on discrete, event‑based signals, mimicking how biological neurons "fire" in response to stimuli.
  
  

• Event‑driven processing: Neuromorphic systems process information when events occur, much like biological neural circuits, which only activate when specific sensory or internal events trigger them. This offers advantages in terms of power efficiency and adaptability.
  
  

• Low‑power design: Inspired by the brain’s energy efficiency, neuromorphic systems often focus on minimizing power consumption by activating processing elements only when necessary.
  
  

However, neuromorphic computing does not inherently mean autonomy. The term refers specifically to the architecture and processing method. While neuromorphic systems can be used in autonomous systems (e.g., for decision-making), not all neuromorphic systems are intended to be autonomous.

Relevance to command systems:
Neuromorphic systems, by virtue of their design, offer more flexible and adaptive processing compared to traditional computational models. This can make them appealing for military or strategic command systems where adaptive responses to dynamic environments are crucial. However, their non-deterministic behaviour (i.e., responses based on past stimuli rather than fixed rules) presents significant challenges for governance and oversight.

2.2 Autonomy: Degrees of autonomy and implications for military command

Autonomy, in the context of military and command systems, refers to the ability of a system to make decisions and perform tasks with varying levels of independence from human intervention. The degree of autonomy directly influences how much control is transferred from human operators to machine decision‑makers.

Degrees of autonomy (autonomy spectrum):

• Human‑in‑the‑loop (HITL): Humans actively supervise or intervene in decisions. This includes systems that generate suggestions, but final decisions remain with a human operator (e.g., target identification, route planning).
  
  

• Human‑on‑the‑loop (HOTL): The system operates autonomously but the human can intervene if necessary. For example, autonomous drones can carry out surveillance but humans can overrule commands if the context shifts.
  
  

• Full autonomy: Systems make decisions without human oversight. Autonomous weapons, for example, could select and engage targets based on predefined rules or machine learning models, with minimal or no human interaction.
  
  

Implications for command authority:

• Human control over lethal force: Full autonomy in decision-making, especially in military contexts, creates ethical, legal, and strategic questions about who controls the use of force. The most critical concern is that if a system is making lethal decisions, who is held accountable for those decisions?
  
  

• Adaptive decision-making: Neuromorphic systems’ event‑driven processing may allow autonomous systems to adapt in ways that conventional systems cannot. This increases the complexity of oversight, as a system’s actions may not always be predictable.
  
  

• Complexity of command authority: Command authority over autonomous systems must be clearly defined. For instance, who authorizes a neuromorphic system to take control of military assets? Is it the commander issuing a general directive, or is it the system that self‑determines its actions based on its interpretation of the environment?
  
  

2.3 Command Authority: The human‑machine interaction in autonomous systems

Command authority refers to the recognized and legal power to issue commands that direct actions, resources, or personnel. In the context of autonomous military systems, defining command authority becomes increasingly complex due to the involvement of machines that are capable of interpreting and executing commands with minimal human oversight.

Key aspects of command authority in autonomous systems:

• Authority delegation: In military settings, command authority is typically structured hierarchically, with senior commanders delegating authority to subordinate units or operators. With autonomous systems, this hierarchy must be clearly delineated, as machines cannot independently assume command unless legally authorized.
  
  

• Control mechanisms: In human‑machine systems, particularly those with autonomous capabilities, the control mechanisms that allow humans to influence or override the system’s actions are crucial. For example, can a human override a decision made by a neuromorphic system? Or are there predefined conditions under which the system operates independently?
  
  

• Ethical and legal frameworks: Legal and ethical boundaries must clearly define under which circumstances autonomous systems are authorized to make decisions, particularly when it involves lethal actions or other high‑stakes outcomes. Human commanders or operators remain legally responsible for the outcomes of any action taken by autonomous systems.
  
  

Challenges posed by neuromorphic command authority:

• Opacity and accountability: Neuromorphic systems, due to their event‑driven nature, may not provide clear explanations for decisions. If an autonomous system makes an adaptive decision that leads to unintended consequences, it may be difficult to trace the reasoning behind the action.
  
  

• Chain of command implications: The delegation of decision‑making power from humans to machines can muddy the chain of command. A machine that is capable of adaptive learning may not adhere strictly to predefined rules, but rather modify its decisions based on prior experience or environmental conditions. In military settings, this poses a risk to accountability.
  
  

• Ethical use of force: A critical aspect of command authority is the ethical use of force. Autonomous systems making decisions about the application of force must align with international law, particularly the laws of armed conflict, and respect principles such as distinction (targeting combatants vs. civilians), proportionality, and necessity.
  
  

2.4 Boundaries: What’s in scope for red-teaming and what’s not

Red-teaming neuromorphic command systems means testing systems for failure modes, vulnerabilities, and unexpected behaviours. However, red-teams need clear boundaries about what they can and cannot probe.

In scope:

• Human‑machine interaction: Red‑teams can evaluate how well human operators interact with autonomous systems and assess scenarios where human intervention may be needed. This includes testing the adequacy of overrides, escalation pathways, and auditability.
  
  

• Risk identification: Red‑teams focus on identifying risks that arise from autonomous decision-making, particularly in terms of unintended consequences, conflicts with human intent, or deviations from legal frameworks.
  
  

• Accountability structures: It is vital to ensure that there are clear accountability mechanisms for actions taken by autonomous systems. This includes auditing capabilities, decision logs, and chain‑of‑command clarifications.
  
  

• Operational contexts and degradation: Red‑teams must simulate various stress conditions (sensor failures, information manipulation, contested environments) and assess how neuromorphic systems handle operational shifts. They should probe the system’s ability to adapt and still operate within safety thresholds.
  
  

Out of scope:

• Designing or improving neuromorphic architectures: Red‑teams are not responsible for the underlying design or engineering of neuromorphic systems. Instead, they focus on how the system operates within the environment and according to its designed intent.
  
  

• Exploitation of vulnerabilities: The goal is to identify risks, not to exploit weaknesses for offensive purposes. Red‑teams must avoid creating or disseminating information that could be used for malicious purposes.
  
  

• Technical breakdowns of hardware: While a neuromorphic system’s internal workings (e.g., hardware, firmware) are important to understand, red‑teams should focus on how the system operates from an end-user perspective, not dive into hardware vulnerabilities.
  
  

2.5 Conclusion: Drawing the line for responsible red-teaming

Defining these terms — neuromorphic computing, autonomy, and command authority — provides the necessary framework to guide red‑team efforts safely. Neuromorphic systems are not inherently autonomous, but they may be used in command environments where autonomy is a key feature. As these systems grow in sophistication, red‑teams must operate within boundaries that prioritize human oversight, legal responsibility, and ethical accountability, while testing system robustness and human‑machine interaction in realistic conditions.

The next chapters will explore practical ways to approach red‑team testing, beginning with conceptual architectures for neuromorphic systems and how to design safe, realistic stress tests.

Part I — Problem Framing

Chapter 3 — Threat‑Model Taxonomy

Adversarial actors, failure modes, insider vs. external threats (pp. 17–28)

Overview (what this chapter does)

This chapter provides a structured, policy‑level taxonomy for threats relevant to autonomous neuromorphic command systems. It helps red teams and decision makers classify who or what can cause harm, how harm might arise, and where to prioritise detection, mitigation, and governance effort. Emphasis is explicitly non‑operational: examples are conceptual and intended to support safe exercise design, procurement language, and governance.

1. High‑level threat classes

Group threats into three broad classes to keep planning and responses tractable:

1. Adversarial actors — intentional malicious actors seeking to subvert, mislead, or weaponize the system.
   
   

2. Accidental / stochastic failures — non‑malicious technical faults, model misgeneralization, or environmental surprises.
   
   

3. Organizational / socio‑technical failures — governance, process, training, or incentive misalignments that permit unsafe outcomes.
   
   

Each class intersects with different capabilities and motives; red‑team designs should sample across them.

2. Adversarial actors (who and why)

Adversarial actors can be profiled by motive, capability, and access. This helps prioritise threat exercises and governance controls.

A. External strategic adversaries

• Motive: strategic advantage, denial/disruption, escalation control.
  
  

• Capabilities: state resources, sophisticated cyber/EM operations, intelligence.
  
  

• Risk focus: supply‑chain compromise, contested information environments, coordinated deception campaigns.
  
  

B. Non‑state violent groups / insurgents

• Motive: tactical advantage, propaganda, asymmetric effects.
  
  

• Capabilities: targeted cyberattacks, physical interference, information ops with local effect.
  
  

• Risk focus: localized deception or interference with sensors and human reporting chains.
  
  

C. Nation‑state espionage / sabotage actors

• Motive: intelligence collection, sabotage, long‑term subversion.
  
  

• Capabilities: insider recruitment, advanced persistent threats, covert supply‑chain insertion.
  
  

• Risk focus: stealthy persistence, subtle model poisoning, exfiltration of training or provenance data.
  
  

D. Criminal actors (profit‑driven)

• Motive: ransom, extortion, resale of sensitive data.
  
  

• Capabilities: cybercrime toolkits, social engineering, access to commoditised exploits.
  
  

• Risk focus: ransomware on logging/audit systems, theft of provenance trails, extortion of operators.
  
  

E. Opportunistic actors / hobbyists

• Motive: curiosity, notoriety.
  
  

• Capabilities: limited but escalating; may reveal zero‑day flaws accidentally.
  
  

• Risk focus: public disclosure of sanitized but sensitive findings; accidental public harm.
  
  

F. Insider adversaries

• Motive: ideology, coercion, financial gain, disgruntlement.
  
  

• Capabilities: privileged access to configurations, data, and human workflows.
  
  

• Risk focus: bypassing oversight, injecting false telemetry, manipulating provenance records.
  
  

3. Failure modes (what can go wrong — conceptual)

Classify failure modes to structure red‑team scenarios and acceptance criteria. Keep descriptions high‑level and non‑exploitative.

A. Perception & sensing failures

• Description: corrupted, spoofed, delayed, or missing sensor inputs lead to incorrect internal representations.
  
  

• Policy implication: require multi‑sensor provenance, cross‑validation, and conservative action envelopes.
  
  

B. Representation & state drift

• Description: the system’s internal state evolves away from validated priors (e.g., due to online learning or persistent miscalibration).
  
  

• Policy implication: bound online adaptation, require verifiable rollback points and explainable state snapshots.
  
  

C. Decision misalignment

• Description: outputs diverge from commander intent or legal constraints due to mis-specified objectives, reward misalignment, or emergent behaviours.
  
  

• Policy implication: insist on verifiable intent‑to‑action mappings and human‑confirmable decision criteria.
  
  

D. Performance degradation / graceful failure gap

• Description: system fails in a way that does not guarantee safety (silent degradation vs. safe‑stop).
  
  

• Policy implication: require explicit fail‑safe behaviours and testable degradation modes.
  
  

E. Audit/traceability loss

• Description: loss or corruption of logs, telemetry, or provenance prevents post‑incident reconstruction.
  
  

• Policy implication: mandate tamper‑evident logging, independent backups, and retention policies.
  
  

F. Adversarial manipulation (non‑technical)

• Description: information operations, social engineering, or doctrinal misuse cause harmful decisions.
  
  

• Policy implication: integrate human factor controls, doctrine reviews, and verification checkpoints.
  
  

G. Supply‑chain & configuration compromise

• Description: compromised components introduce unknown behaviours or backdoors.
  
  

• Policy implication: enforce supplier assurance, component provenance, and configuration attestation.
  
  

4. Insider vs External threats — contrasts & red‑team implications

Understanding differences shapes safe exercise design and governance prescriptions.

Insider threats (trusted access):

• Strengths: high privileges, contextual knowledge, ability to manipulate human workflows and logs.
  
  

• Weaknesses: fewer resources required, but greater risk of subtle, long‑duration damage.
  
  

• Red‑team focus: plausibility of privilege misuse, procedural gaps, separation of duties, audit gaps, and incentives.
  
  

External threats (untrusted access):

• Strengths: can be highly resourced and covert (state actors), or opportunistic and noisy (criminals).
  
  

• Weaknesses: may have limited time/physical access; rely on cyber, EM, or influence channels.
  
  

• Red‑team focus: perimeter defenses, supply‑chain resilience, detection latency, and recovery capabilities.
  
  

Hybrid threats: combinations (e.g., external actor recruits insider) should be modelled explicitly during campaign planning.

5. Threat prioritisation framework (policy‑oriented)

A one‑page prioritisation rubric helps institutions decide what to test first. Score each threat on three axes (1–5):

• Impact (human harm, strategic fallout)
  
  

• Likelihood (operational plausibility given context)
  
  

• Detectability/Recoverability (how quickly the institution can detect and recover)
  
  

Compute a simple risk score = Impact × Likelihood ÷ Detectability. Prioritise high scores for immediate red‑team focus and governance change.

Example (illustrative, non‑operational):

• Insider manipulation of audit trails: Impact 5 × Likelihood 3 ÷ Detectability 1 → High priority.
  
  

• Opportunistic public disclosure of sanitized logs: Impact 2 × Likelihood 4 ÷ Detectability 3 → Medium priority.
  
  

Use this rubric to allocate red‑team effort and remediation investment.

6. Socio‑technical vectors (how threats interact across system & people)

Threats rarely operate purely in the technical or human domain. Consider common vectors:

• Human interface failures: ambiguous displays, poor uncertainty communication, or alert fatigue lead humans to accept flawed recommendations.
  
  

• Organisational incentives: procurement that rewards performance metrics over safety increases acceptance pressure.
  
  

• Operational tempo mismatch: automation designed for peacetime data may fail under combat speeds and stress.
  
  

• Information environment manipulation: adversary‑driven false narratives or spoofed telemetry that exploit trust relationships.
  
  

Design red‑team scenarios that explicitly combine vectors (e.g., sensor ambiguity + stressed operator + incomplete audit logs) to surface emergent risks.

7. Detection, response & recovery — non‑technical controls

High‑level controls that reduce risk across threat classes. These are governance and planning levers rather than technical exploits.

A. Detection

• Multi‑layer monitoring (operational, human workflow, supply‑chain indicators).
  
  

• Independent observers and auditors during exercises.
  
  

• Defined thresholds for unusual state changes and mandatory reporting.
  
  

B. Response

• Clear human override protocols and command reversion procedures.
  
  

• Stop‑gap measures: system isolation, controlled rollback, and forensic preservation.
  
  

• Legal and ethical escalation pathways: notifying counsel, oversight committees, and appropriately redacted public briefings.
  
  

C. Recovery & learning

• Post‑incident forensic review with independent verification.
  
  

• Remediation loops into procurement and training.
  
  

• Transparent but sanitized reporting to oversight bodies and (where appropriate) the public.
  
  

8. Red‑team design implications (safe practice)

Translate the taxonomy into safe exercise design choices:

• Scope selection: include insider scenarios and hybrid attacks — they often reveal the largest governance gaps.
  
  

• Sanitization: never use real operational data in public exercises; synthetic or sandboxed telemetry is mandatory.
  
  

• Separation of duties: ensure red teams cannot unilaterally modify production audit trails; independent observers validate exercise constraints.
  
  

• Focus on detectability & recovery: design injects that test detection latency and ability to recover to a safe state rather than exploit capability.
  
  

• Metrics alignment: measure socio‑technical outcomes (time to detect, time to safe‑stop, percentage of auditable decisions) not exploit depth.
  
  

9. Checklist — Threat modelling for a red‑team campaign (policy checklist)

1. Identify primary adversary profiles relevant to your operational context.
   
   

2. Map plausible failure modes against those adversaries.
   
   

3. Score threats using the prioritisation rubric (Impact × Likelihood ÷ Detectability).
   
   

4. Select a balanced mix of insider, external, accidental, and hybrid scenarios.
   
   

5. Obtain legal/ethics approvals and define sanitization rules.
   
   

6. Define detection, response, and recovery playbooks to be exercised.
   
   

7. Include independent observers and ensure tamper‑proof logging for the exercise.
   
   

8. Pre‑define safe stop conditions and post‑exercise remediation responsibilities.
   
   

9. Produce a sanitized after‑action report format aligned to policy audiences.
   
   

10. Closing guidance (short)

Threat modelling for neuromorphic command systems must treat human, organisational, and technical risks as inseparable. Prioritise scenarios that reveal governance and human‑machine coupling failures — these are where the greatest harm and the clearest policy levers lie. Red teams should act as risk‑sensing organs for institutions: surface brittle assumptions, validate detectability and recovery, and translate findings into policy and procurement actions that preserve meaningful human control.

Part II — Conceptual Architecture (Non‑Operational)

Chapter 4 — High‑Level System Blocks

Sensing, Representation, Decision Affordances, Actuation Interfaces (conceptual only) (pp. 29–40)

Overview (what this chapter does)

This chapter describes a high‑level, non‑operational decomposition of an autonomous command system that incorporates neuromorphic or brain‑inspired claims. The intent is to give red‑teams, policymakers, auditors, and ethicists a common vocabulary for designing exercises, defining acceptance criteria, and assessing governance controls — not to provide engineering specifications, attack techniques, or tuning advice. Every block is described at the conceptual layer with explicit notes on red‑team considerations and governance guardrails.

4.1 Minimal block diagram (conceptual)

At the highest level, an autonomous command system can be thought of as four interacting conceptual blocks:

1. Sensing & Ingest — collects and preprocesses inputs from environment and human sources.
   
   

2. Representation & Memory — forms internal state, situational models, and short/longer‑term memory.
   
   

3. Decision Affordances (Reasoning Layer) — generates recommendations, intent interpretations, and action affordances.
   
   

4. Actuation Interfaces & Commanding — translates authorized decisions into commands, logs actions, and enforces human authority boundaries.
   
   

Between and around these blocks sit cross‑cutting services: Audit & Provenance, Human Interface & Oversight, Safety & Constraint Enforcement, and Supply‑Chain / Configuration Management. Red‑teams should treat cross‑cutting services as primary inspection points.

Note: This is an analytical decomposition for governance and testing. It avoids implementation detail (algorithms, code, hardware) by design.

4.2 Sensing & Ingest (conceptual role)

What it is (conceptually): the subsystem that collects inputs — sensor feeds, human reports, external databases, and telemetry. In neuromorphic‑inspired systems this may be described as event‑driven acquisition (conceptually: inputs arrive as events rather than constant polling).

Key policy considerations:

• Source provenance: every input should carry metadata about origin, timestamp, and handling.
  
  

• Sanitisation & minimisation: only authorised, privacy‑compliant data should be permitted into command decision pathways.
  
  

• Multi‑source cross‑validation: systems should be expected to validate conflicting inputs through institutional procedures (not opaque internal heuristics alone).
  
  

Red‑team focus (safe, non‑operational):

• Design injects that simulate conflicting reports, delayed inputs, or loss of a source and observe human‑machine handling.
  
  

• Evaluate how ingest rules and operator displays expose uncertainty and provenance.
  
  

• Test whether procedural controls prevent unauthorised sources from influencing decisions.
  
  

Governance guardrails: mandate minimum provenance metadata, require synthetic data for testing, specify acceptable data retention and redaction policies.

4.3 Representation & Memory (conceptual role)

What it is (conceptually): the internal state of the system — situational model, belief about the environment, and any longer‑term memory that affects future behaviour (e.g., learned priors, cached state). For neuromorphic descriptions this is often framed as stateful, event‑driven representations rather than stateless computations.

Key policy considerations:

• Snapshotability & explainability: operators and auditors must be able to request interpretable snapshots of state sufficient to explain (at a high level) why an output was produced.
  
  

• Bounded adaptation: if the system adapts over time, adaptation should be bounded, logged, and reversible under institutional control.
  
  

• State provenance: changes to internal state should be attributable to specific inputs, times, and authorized processes.
  
  

Red‑team focus (safe, non‑operational):

• Exercise scenarios where the system’s internal representation is intentionally ambiguous (e.g., partial sensor fusion) and observe operator decisions.
  
  

• Probe whether state snapshots are available, readable by humans, and usable in after‑action reviews.
  
  

• Validate rollback and state‑freeze procedures as part of response playbooks.
  
  

Governance guardrails: require versioned state snapshots, policies for bounding online adaptation, and retention of immutable audit records describing state transitions.

4.4 Decision Affordances (conceptual role)

What it is (conceptually): the reasoning layer that translates representations into actionable affordances — e.g., recommended courses of action, risk estimates, or intent interpretations. This is where claims about “cognition,” adaptation, or neuromorphic decision‑making are most often expressed.

Key policy considerations:

• Action taxonomy & human mapping: every recommendation must be classified by its operational weight (informational, recommendatory, pre‑authorized action) and mapped to the human role required to convert it into command.
  
  

• Uncertainty communication: outputs should include calibrated indicators of uncertainty, provenance, and the assumptions underlying recommendations.
  
  

• Constraint enforcement: legal, ethical, and rules‑of‑engagement constraints must be integrated at or above this layer so that recommendations outside permitted envelopes cannot be actioned without explicit human authorization.
  
  

Red‑team focus (safe, non‑operational):

• Create scenarios where recommendations conflict with clear commander intent to test escalation and override paths.
  
  

• Measure how uncertainty and provenance are displayed to operators and whether operators can reliably interpret them under stress.
  
  

• Evaluate whether the system has hard or procedural constraints preventing unsafe automatic actions.
  
  

Governance guardrails: require normative classification schemas for outputs, require explicit human authorization thresholds for higher‑consequence actions, and mandate auditable justification snapshots for recommendations.

4.5 Actuation Interfaces & Commanding (conceptual role)

What it is (conceptually): the interface layer through which authorized decisions are enacted — issuing orders, adjusting resource allocations, or triggering subordinate systems. It includes the control plane (who can command what) and the logging/confirmation plane (how an action is recorded and confirmed).

Key policy considerations:

• Authority mapping: precise mapping of human roles, digital authorizations, and command thresholds. Who can convert a recommendation into an order? Under what conditions?
  
  

• Fail‑safe pathways: explicit mechanisms and procedures for halting, isolating, or reverting actions in an emergency.
  
  

• Tamper‑evident logging: all commands and confirmations must be recorded in a manner resistant to undetectable modification.
  
  

Red‑team focus (safe, non‑operational):

• Test institutional procedures for authorizing actions (tabletop injects that require rapid authorization decisions).
  
  

• Observe how actuation confirmations are presented and whether operators can reliably trace an action to the originating recommendation and authorization.
  
  

• Validate stop conditions and whether operators understand the practical steps to implement them.
  
  

Governance guardrails: insist on separation of duties, multi‑party authorization for critical commands, and immutable audit trails fed to independent verification bodies.

4.6 Cross‑cutting services (brief conceptual notes)

These services operate across the four blocks and are priorities for governance and red‑team inspection:

• Audit & Provenance: end‑to‑end provenance for inputs, state changes, decisions, and actuation. Governance should require tamper‑evident, versioned logs with independent backups. Red‑teams should verify traceability through sanitized exercises.
  
  

• Human Interface & Oversight: operator displays, uncertainty visualisation, alerts, and workflows. Design for clarity under stress, and require operator training standards. Red‑teams should measure human understanding and error rates in representative exercises.
  
  

• Safety & Constraint Enforcement: policy engines and runtime guards that prevent prohibited actions. These should be institutionally auditable, configurable by authorized governance bodies, and tested via tabletop scenarios only.
  
  

• Configuration & Supply‑Chain Management: manifests, trusted components lists, and attestation services that ensure components are the versions intended by procurement. Red‑teams should probe governance around supplier attestations and change control, not vendors’ internal IP.
  
  

4.7 Safe red‑team checkpoints mapped to blocks (practical, non‑operational)

A compact checklist for red‑teams to use when designing an exercise (policy‑safe language):

Sensing & Ingest

• Are provenance metadata and source quality visible to operators?
  
  

• Can unauthorised sources be injected into decision pathways under current procedures?
  
  

Representation & Memory

• Are state snapshots available for review and export?
  
  

• Is there a documented policy limiting online adaptation and enabling rollback?
  
  

Decision Affordances

• Are outputs classified by operational weight and mapped to authorization roles?
  
  

• Do outputs include uncertainty and provenance indicators intelligible to operators?
  
  

Actuation Interfaces & Commanding

• Is there clear, auditable mapping from recommendation → authorization → action?
  
  

• Are multi‑party authorization and safe‑stop procedures practiced and enforceable?
  
  

Cross‑cutting

• Is logging tamper‑evident and independently backed up?
  
  

• Are independent observers able to validate that red‑team exercises adhered to approval constraints?
  
  

4.8 Metrics & acceptance signals (policy‑oriented)

High‑level, safety‑centric metrics suitable for procurement and red‑team reporting (avoid technical performance metrics):

• Time to human awareness: how long between a system‑level anomaly and a human operator being notified in operationally meaningful terms.
  
  

• Time to safe‑stop: procedural time required for human operators to halt a pending action from initial alert.
  
  

• Provenance completeness: percentage of decisions with full source and state metadata required for after‑action review.
  
  

• Override fidelity: percentage of overrides properly recorded and reconstructable in audit logs.
  
  

• Graceful degradation index: qualitative rating (e.g., Good / Adequate / Poor) describing whether system behaviour moves to safe‑default modes under stressed inputs.
  
  

These metrics are intentionally high level so they can be used across architectures and vendors without prescribing technical internals.

4.9 Governance & procurement language (short examples, non‑operational)

Sanitized, policy‑level clauses red teams and procurement officers can use to drive safer systems:

• “All decision‑relevant inputs must be accompanied by provenance metadata and marked for visibility in operator interfaces.”
  
  

• “Any capability that recommends or issues operational commands must require human authorization above X consequence level; thresholds and roles must be auditable.”
  
  

• “Systems claiming online adaptation must provide verifiable, versioned snapshots and rollback procedures; adaptation must be subject to institutional review.”
  
  

• “Audit logs shall be tamper‑evident, independently backed up, and preserved for N years under secure retention policies.”
  
  

(These are examples of the kind of clause language the book explores further; tailor thresholds and retention periods to legal/regulatory requirements in your jurisdiction.)

4.10 Closing guidance (short)

Thinking in blocks helps institutions ask the right red‑team and governance questions without getting lost in implementation detail. For safety‑first red‑teaming:

• Focus on observability, provenance, human‑influence pathways, and bounded adaptation.
  
  

• Design exercises to stress socio‑technical coupling (human workflows + system outputs) rather than to probe implementation vulnerabilities.
  
  

• Require legal/ethics approvals and independent observers before any exercise.
  
  

• Translate findings into procurement clauses and operational policies that preserve meaningful human control and auditable responsibility.
  
  

The next chapters will take these conceptual blocks and show how to build safe red‑team methodologies and scenario‑level maneuvers that exercise them without producing operationally useful exploits.

Part II — Conceptual Architecture (Non‑Operational)

Chapter 5 — Human‑In‑the‑Loop vs. Human‑On‑the‑Loop

Decision Authority Design Patterns (pp. 41–48)

Overview (what this chapter does)

This chapter examines the two primary human oversight architectures for autonomous systems: Human‑In‑the‑Loop (HITL) and Human‑On‑the‑Loop (HOTL). It analyzes their structural assumptions, governance implications, and red‑team testability. These patterns are not engineering blueprints but command authority frameworks: policy decisions about how autonomy interacts with command, legality, and responsibility.

The chapter provides:

• Conceptual definitions and differences between HITL and HOTL
  
  

• Practical affordances and constraints for military command systems
  
  

• Design pattern archetypes (conceptual, not technical)
  
  

• Governance and red‑team audit implications
  
  

• Guidelines for determining which pattern is appropriate in which context
  
  

5.1 Definitions — Core distinction

Pattern

Core Feature

Human Role

Decision Flow

Human‑In‑the‑Loop (HITL)

System waits for human input before acting

Approver or veto authority

System → Human → Action

Human‑On‑the‑Loop (HOTL)

System acts autonomously by default but allows human intervention

Supervisor or override authority

System → Action (→ Human monitors)

These are institutional patterns, not technical implementations. They define the authority model, not the specific interfaces or algorithms.

🔒 Red‑team implication: The chosen pattern determines where human judgment is expected, tested, and legally accountable. Every red‑team scenario must align with — and stress — these roles.

5.2 HITL Pattern — Overview

Use case: Systems where decisions must be explicitly approved by a human, especially in cases involving lethal force, escalation potential, or political sensitivity.

Characteristics:

• System produces recommendations, ranked options, or alerts, but does not act without human input.
  
  

• Operator must review and confirm before actuation.
  
  

• All command actions are logged with human authorization metadata.
  
  

Advantages:

• High assurance of legal and ethical oversight.
  
  

• Enables explicit human accountability per action.
  
  

• Easier to align with existing rules of engagement (ROE), especially in kinetic contexts.
  
  

Limitations:

• Slow decision tempo under stress or degraded comms.
  
  

• High operator cognitive load and fatigue.
  
  

• Susceptible to inattentional errors or “rubber‑stamping” under pressure.
  
  

Governance questions:

• Are humans meaningfully reviewing system suggestions, or just approving reflexively?
  
  

• What is the maximum response latency tolerable before safety or mission outcomes are impacted?
  
  

• Is operator training sufficient to understand system uncertainty and assumptions?
  
  

5.3 HOTL Pattern — Overview

Use case: High‑tempo or high‑volume operations where human intervention is only needed in edge cases or for override. Common in ISR, logistics, or automated surveillance.

Characteristics:

• System executes autonomous decisions by default, with humans monitoring and intervening only if needed.
  
  

• Human interaction is asynchronous and usually exception‑driven.
  
  

• Logs include system justifications and any human interventions or overrides.
  
  

Advantages:

• Faster decision cycles; scalable to multiple domains or assets.
  
  

• Reduced burden on human operators in low‑risk or routine settings.
  
  

• Allows proactive monitoring and intervention when anomalies occur.
  
  

Limitations:

• Risk of “automation drift” — humans become disengaged, miss anomalies, or delay overrides.
  
  

• System may make irreversible decisions before human comprehension catches up.
  
  

• Operator trust calibration becomes critical — both over‑trust and under‑trust are dangerous.
  
  

Governance questions:

• Are anomaly thresholds and intervention protocols clearly defined and rehearsed?
  
  

• Do operators have sufficient observability to detect unsafe behaviour in time?
  
  

• Is the audit trail strong enough to reconstruct what happened and why?
  
  

5.4 Hybrid & Adaptive Patterns (Emerging)

Real‑world command systems rarely fit cleanly into HITL or HOTL. Increasingly, hybrid authority designs blend elements from both, sometimes adaptively.

Examples:

• Tiered autonomy: HITL for force application; HOTL for navigation or surveillance.
  
  

• Escalation‑aware automation: System starts in HOTL mode but drops to HITL when legal thresholds are approached (e.g., cross‑domain effects, proximity to civilians).
  
  

• Confidence‑modulated control: Human review required when system confidence is low or decision complexity is high.
  
  

Design implication:

• These patterns require real‑time meta‑awareness — the system must know not only what it’s deciding, but how it’s allowed to decide based on context.
  
  

🧭 Governance challenge: Who defines these transitions? What oversight ensures the system remains in the correct mode?

5.5 Design Pattern Archetypes (Conceptual)

Archetype

Pattern

Description

"Command Gatekeeper"

HITL

System acts only when human grants explicit permission. Ideal for kinetic, irreversible, or politically sensitive operations.

"Autonomy Supervisor"

HOTL

System acts independently unless human intervenes. Common in high‑volume, low‑risk domains (e.g., fleet management).

"Escalation Aware Agent"

Hybrid

System shifts patterns based on mission phase or legal context. Requires self‑monitoring of authority thresholds.

"Decision Delegation Ladder"

Adaptive

Human can dynamically delegate authority levels based on mission tempo, trust in system, or fatigue. Requires traceability.

🎯 Red‑team note: Exercises should model not just failure of action, but failure of delegation — e.g., when the system acts under the wrong authority mode due to misinterpretation or oversight.

5.6 Red‑Team Considerations

Core evaluation questions:

1. Mode adherence: Can the system prove that it stayed within its designated decision authority pattern under stress?
   
   

2. Override latency: How quickly and reliably can human operators intervene in HOTL scenarios?
   
   

3. Understanding burden: Can humans interpret system reasoning in time to intervene meaningfully?
   
   

4. Delegation clarity: In hybrid models, can humans trace who or what authorized a shift in authority?
   
   

Safe inject examples (non‑operational):

• Simulate comms latency that delays HITL approval — observe fallback behaviour.
  
  

• Present ambiguous legal context (e.g., dual‑use targets) — does the system seek HITL or proceed HOTL?
  
  

• Create conflicting goals (e.g., minimize civilian harm vs. mission speed) — which authority pattern handles this better?
  
  

5.7 Governance & Audit Implications

Auditability requirements:

• Every action must include:
  
  
  

  • The decision authority mode in effect at time of action.
    
    

  • The human or process responsible for that authority level.
    
    

  • A verifiable timestamped trail from recommendation → authorization → actuation.
    
    

Policy anchors:

• Certain actions (e.g., lethal force) may legally require HITL regardless of operational context.
  
  

• Autonomy delegation must be revocable, auditable, and bounded by institutional norms.
  
  

• Operator authority cannot be bypassed through learning, adaptation, or emergent model behaviour.
  
  

5.8 Choosing the Right Pattern — Conceptual Matrix

Mission Feature

Preferred Pattern

Notes

Irreversible or lethal actions

HITL

Ensures human moral and legal accountability.

High-speed, non-lethal ops

HOTL

Efficiency with monitored override.

High uncertainty or dynamic legality

Hybrid / HITL

Better to slow down than make irreversible error.

Operator overload risk

HOTL with fail-safes

Watch for disengagement and override delays.

Political or ethical ambiguity

HITL with legal review

Reduces institutional exposure.

5.9 Closing Guidance

Red‑team mantra: It’s not just what the system did — it’s what authority it thought it had when it did it.

Safe autonomy requires more than model performance — it requires explicit institutional control over when autonomy is allowed, revoked, or reclassified. HITL and HOTL are not technical decisions — they are sovereignty design patterns. Choosing, enforcing, and auditing the correct pattern is a core governance responsibility.

In Part III, we will move into red‑team methodology: how to simulate failure of authority structures, probe assumptions about human–machine coupling, and surface command‑level risk before systems ever reach deployment.

Part II — Conceptual Architecture (Non‑Operational)

Chapter 6 — Observability and Audit Trails

Telemetry, Provenance, and Explainability for Neuromorphic Systems (pp. 49–58)

Overview (what this chapter does)

This chapter outlines the institutional and governance importance of observability in neuromorphic and autonomous military command systems. It frames telemetry, provenance, and explainability as not only engineering concerns but also strategic enablers of human control, after‑action accountability, and lawful deployment.

For red‑teamers, observability defines what can be tested. For commanders and auditors, it defines what can be proven. In neuromorphic systems — especially those claiming adaptive or self‑modifying behaviors — auditability is not optional: it is the minimum requirement for governance legitimacy.

6.1 What Is Observability? (Conceptual Definition)

Observability is the capacity to infer why a system behaved the way it did — during, before, or after an event — using information that is independently verifiable, institutionally meaningful, and procedurally accessible.

This includes:

• Telemetry — real‑time and recorded system states, events, and transitions
  
  

• Provenance — metadata tracing inputs, decisions, authorizations, and environmental context
  
  

• Explainability — mechanisms that allow humans to interpret system behavior in the context of mission, legality, and command intent
  
  

6.2 Why Neuromorphic Systems Pose New Audit Challenges

Characteristics of neuromorphic systems that raise observability concerns:

Feature

Audit Risk

Stateful, recurrent memory

Difficult to snapshot or reset cleanly; requires temporal traceability

Event‑driven processing

Continuous, non‑discrete decision flow can obscure clear action triggers

Adaptation over time

System behavior may change in ways that are hard to reconstruct post‑hoc

Non‑symbolic internal representations

Makes traditional logical explanations difficult or impossible

Emergent behavior under input stress

System behavior may not be repeatable or formally provable

Governance cannot accept “the system learned to do it” without evidence — observability is the means by which institutions retain posture, traceability, and control.

6.3 Telemetry — What Must Be Recorded?

Telemetry includes what the system saw, inferred, considered, rejected, and ultimately did.
Red‑teams must be able to replay and interrogate this data; auditors must be able to verify it was tamper‑free.

Minimum telemetry domains:

1. Input log
   
   
   

   • All raw and preprocessed inputs (sensor data, human inputs, external feeds)
     
     

   • Timestamped and source‑attributed
     
     

   • Redacted/sanitized for privacy and legal compliance
     
     

2. Internal state snapshots
   
   
   

   • Periodic dumps of internal representations or embeddings
     
     

   • Marked with system confidence and relevant decision checkpoints
     
     

   • Cryptographically signed to prevent post‑hoc manipulation
     
     

3. Decision path metadata
   
   
   

   • Which outputs were generated, how ranked or filtered, and on what grounds
     
     

   • Records of constraints invoked or overridden
     
     

   • Confidence scores, risk flags, and optionality spaces
     
     

4. Actuation logs
   
   
   

   • What commands were issued
     
     

   • Who/what authorized them (including timestamp and identity)
     
     

   • Confirmation of execution or failure
     
     

5. Adaptation history (if applicable)
   
   
   

   • Record of what was learned, when, from what inputs
     
     

   • Clear distinction between learning vs. static behavior
     
     

   • Linked to change in future actions (cause-effect traceability)
     
     

6.4 Provenance — Who Did What, When, and Why?

Provenance ≠ telemetry.
Provenance is metadata about authority, origin, and process.

Key provenance elements:

• Source attribution: Who generated or authorized each input?
  
  

• Transformation trace: How was the input transformed from raw → actionable?
  
  

• Decision lineage: What chain of logic or learned process led to the output?
  
  

• Command authority: Who held authority when the action was taken, and was that authority properly delegated?
  
  

• System version state: Which version/configuration of the model or system was active at the time?
  
  

Governance requirement:

Provenance must be:

• Immutable
  
  

• Decentralized (or independently backed up)
  
  

• Auditable by external parties without needing access to proprietary model internals
  
  

6.5 Explainability — What Must Humans Understand?

Conceptual goal:

Explainability is not about code transparency — it’s about institutionally intelligible justifications.

The system must provide a high-level narrative (even if not perfectly accurate) that allows human commanders to:

• Trust (or question) the system’s reasoning
  
  

• Assess legality and proportionality
  
  

• Justify or refute post‑hoc decisions under scrutiny
  
  

Types of explanation relevant to command systems:

Explanation Type

Description

Example

Counterfactual

"What would the system have done differently if X had changed?"

“If civilian vehicle were not present, strike would have proceeded.”

Causal trace

"What led the system to choose this over that?"

“Threat confidence exceeded threshold due to radar + visual fusion.”

Constraint report

"What safety constraints were considered, and did any trigger?"

“Rules of engagement constraint prevented automatic engagement.”

Confidence profile

"How certain was the system, and how was that quantified?"

“Low certainty due to degraded IR sensor; confidence score 0.44.”

Red‑team principle: If a system can act autonomously but cannot generate one of these explanations, it cannot be trusted with that level of autonomy.

6.6 Red‑Team Application — What to Test

Red‑teams should assess:

• Completeness of telemetry: Can all key decisions be reconstructed?
  
  

• Tamper resistance: Can audit trails be manipulated without detection?
  
  

• Provenance clarity: Can an external party understand who authorized what, and when?
  
  

• Explainability under pressure: Can humans interpret logs and system justifications during or after operational tempo?
  
  

• Version traceability: Can the system prove which learning rules, weights, or configurations were active at decision time?
  
  

Sample safe injects:

• Provide incomplete or conflicting input and test whether provenance metadata is preserved through the system
  
  

• Trigger a borderline ROE violation and observe what explanations (or lack thereof) are generated
  
  

• Simulate model version drift and test whether operators can identify when and why behavior changed
  
  

6.7 Governance Patterns — Ensuring Auditability at Procurement

Procurement must not treat observability as optional. It must be embedded in every layer.

Example governance clauses (non‑operational):

• “All autonomous decision outputs shall be accompanied by machine‑interpretable and human‑readable provenance and justification metadata.”
  
  

• “Model or system state shall be snapshot‑capable at all mission stages, including under degraded conditions.”
  
  

• “Telemetry and audit logs shall be cryptographically signed and redundantly stored in independently controlled facilities.”
  
  

• “All adaptive behavior must be loggable, reversible, and attributable to specific training or experience data.”
  
  

6.8 Institutional Tradeoffs and Design Decisions

Choice

Risk

Governance Implication

Minimizing telemetry for speed

Loss of post‑action accountability

Require baseline logging regardless of performance goals

Opaque model internals

Unprovable safety or legality

Mandate external justification layers

Centralized logging only

Single point of failure or tampering

Require distributed, independent observability

No snapshotting of state

Inability to reconstruct decisions

Reject systems that cannot snapshot reliably

Autonomy that is not observable is not governable.

6.9 Closing Guidance

Observability is not a technical luxury — it is a strategic necessity.

Without telemetry, failures are invisible.
Without provenance, authority cannot be verified.
Without explainability, humans are accountable for what they cannot understand.

Red‑teams must treat observability as their primary interface.
Institutions must treat auditability as a non‑negotiable procurement constraint.
And autonomy must never be treated as exempt from traceability — especially when decisions carry kinetic, ethical, or strategic weight.

In Chapter 7, we will apply these observability principles to governance architecture — how organizations structure oversight, define institutional responsibilities, and prepare for audit and red‑team engagement across the full system lifecycle.

Part III — Red‑Team Methodology for Neuromorphic Command

Chapter 7 — Red‑Team Objectives and Constraints

Safety‑first scoping (pp. 59–66)

Overview (what this chapter does)

This chapter gives a compact, operationally safe template for scoping red‑team engagements against autonomous neuromorphic command systems. It defines the primary objectives red teams should pursue, the mandatory constraints that protect safety and legality, and the institutional processes that must be in place before any exercise begins. Everything here is written as governance and procedural guidance — explicitly non‑operational and focused on reducing harm while producing policy‑actionable evidence.

1. Core intent: what a safety‑first red team must achieve

A safety‑first red‑team engagement has three interlocking aims:

1. Reveal socio‑technical brittleness — surface how human workflows, doctrine, and institutions interact with system behaviours under stress.
   
   

2. Demonstrate detectability & recovery — show whether the institution can detect anomalies, intervene, and restore safe posture within required timeframes.
   
   

3. Produce governance actions — generate prioritized, implementable policy, procurement, training, or design recommendations that materially reduce risk.
   
   

Success is measured by institutional learning and mitigation adoption — not by depth of exploit discovery.

2. High‑level red‑team objectives (policy phrasing)

Use short, testable objective statements that avoid technical detail. Each objective should map to measurable acceptance criteria.

1. Assess human oversight fidelity
   
   
   

   • Objective: Verify that humans who must approve or override system actions have timely, meaningful situational awareness and are not prone to rubber‑stamping.
     
     

   • Example acceptance criteria: median time to human awareness ≤ X minutes under simulated tempo; qualitative operator comprehension score ≥ threshold in post‑exercise surveys.
     
     

2. Validate provenance & auditability
   
   
   

   • Objective: Confirm end‑to‑end telemetry, provenance, and immutable logs allow independent reconstruction of decision paths.
     
     

   • Acceptance criteria: 100% of exercised critical decisions reconstructable by neutral auditors using sanitized logs.
     
     

3. Test fail‑safe and graceful‑degradation behaviour
   
   
   

   • Objective: Demonstrate system moves to safe defaults under defined stressors rather than silent, hazardous degradation.
     
     

   • Acceptance criteria: All injected stressors produce documented safe‑stop or bounded‑behaviour responses within approved timeframes.
     
     

4. Surface organizational and incentive vulnerabilities
   
   
   

   • Objective: Identify procurement, training, or incentive structures that could encourage premature reliance on automation.
     
     

   • Acceptance criteria: List of prioritized governance gaps with owners and timelines for remediation.
     
     

5. Measure detection & response latency
   
   
   

   • Objective: Quantify time from anomaly onset to institutional response (detection, escalation, human override, forensic preservation).
     
     

   • Acceptance criteria: Detection, escalation, and safe‑stop latencies meet policy thresholds or are flagged for remediation.
     
     

6. Assess transparency for oversight actors
   
   
   

   • Objective: Ensure independent auditors/oversight bodies can access sanitized evidence necessary for evaluation.
     
     

   • Acceptance criteria: Oversight actors can complete a designated review checklist without access to proprietary internals.
     
     

3. Mandatory constraints (non‑negotiable safety rules)

Before any exercise, the following constraints must be documented, signed by relevant authorities, and visibly enforced. They are absolute.

1. Non‑operationality
   
   
   

   • No exercise activity will create or disseminate operationally useful exploit details, weaponization guidance, or vulnerability payloads. Findings must be sanitized for any wider distribution.
     
     

2. Data governance
   
   
   

   • Production operational data shall not be used in public or shared exercises unless legally authorized and fully redacted/sanitized. Prefer synthetic or heavily sanitized datasets.
     
     

3. Isolation & sandboxing
   
   
   

   • No exercise shall modify or run on production systems controlling real assets. All tests must occur in isolated environments or verified testbeds with no path to production actuation.
     
     

4. Legal pre‑approval
   
   
   

   • Independent legal counsel must certify the exercise plan before initiation, including handling of sensitive findings and disclosure pathways.
     
     

5. Ethics/IRB approval
   
   
   

   • An institutional review board or equivalent ethics panel must sign off on the human‑subjects aspects (operator testing, surveys, recordings).
     
     

6. Stop conditions
   
   
   

   • Define explicit, irreversible stop triggers (safety, legal, reputational) and ensure everyone understands the immediate halt and remediation procedure.
     
     

7. Independent observers
   
   
   

   • Appoint at least one neutral observer (legal/audit) with authority to pause the exercise if constraints are violated.
     
     

8. Separation of duties
   
   
   

   • Ensure red team operators cannot unilaterally alter audit logs, provenance backstops, or exercise scope once started.
     
     

9. Remediation & disclosure plan
   
   
   

   • Predefine how findings are remediated, how vendors are notified under responsible disclosure norms, and what sanitized outputs are shared with oversight bodies or the public.
     
     

4. Exercise design constraints (staging & scope choices)

Design choices should minimize risk while maximizing governance value.

• Staging level:
  
  
  

  • Tabletop / conceptual: Lowest risk; used for early scoping and doctrine testing.
    
    

  • Sandboxed simulation: Medium risk; use synthetic inputs and isolated testbeds.
    
    

  • Instrumented live‑play (non‑production): Higher value, highest risk; requires extra legal and technical isolation.
    
    

• Boxing the exercise:
  
  
  

  • Define whether the exercise is white/grey/black box for the system under test. Default safe posture: grey box (red team has policy‑level access; no internal model weights or secret keys).
    
    

• Timeboxing:
  
  
  

  • Fixed duration with mandated mid‑exercise check‑in and formal pause window for independent review.
    
    

• Scope limit:
  
  
  

  • Limit the number of injects that could create cascading effects. Test a focused set of high‑priority threats rather than a broad adversary campaign.
    
    

5. Roles & responsibilities (institutional must‑haves)

Define a small set of named roles with clear authorities.

• Sponsor / Executive Authority — signs approvals, receives executive briefs, authorizes remediation funds.
  
  

• Red‑Team Lead — accountable for exercise conduct within constraints; cannot alter stop conditions alone.
  
  

• Blue‑Team / System Custodian — maintains safe‑state, ensures testbed isolation, executes controlled resets.
  
  

• Legal Counsel — pre‑approves scope and advises during exercise.
  
  

• Ethics / IRB Representative — monitors human testing aspects.
  
  

• Independent Observer(s) — authorized to pause or stop the exercise.
  
  

• Oversight Liaison — coordinates sanitized reporting to auditors, parliamentary staff, or civil society reviewers.
  
  

Every role must be documented in the exercise plan with contactable persons and delegation authorities.

6. Rules of Engagement (ROE) — concise template

Use this minimal, safe ROE as a starting point in all plans:

1. Purpose: Validate safety, observability, and governance — not to demonstrate exploitability.
   
   

2. Authorized actions: Only activities listed and approved in the exercise plan. Any deviation requires immediate pause and re‑approval.
   
   

3. Prohibited actions: No attempts to access production networks, no data exfiltration of sensitive information, no public disclosure of raw findings.
   
   

4. Stop triggers: Legal risk, unexpected real‑world consequence, operator harm, or any observer pause.
   
   

5. Reporting: Immediate secure reporting channel for incidents; after‑action reports routed through Legal and Sponsor.
   
   

6. Sanitization: All outputs intended beyond Sponsor and oversight bodies must be sanitized per the disclosure plan.
   
   

7. Metrics and evidence collection (policy‑safe)

Define metrics tied to the red‑team objectives — measure socio‑technical outcomes, not exploit depth.

Examples:

• Detection latency (minutes) — from inject time to first human/system alert.
  
  

• Operator comprehension score (0–100) — based on structured post‑exercise questionnaire.
  
  

• Time to safe‑stop (minutes) — time from human decision to confirmed cessation of the action.
  
  

• Provenance completeness (%) — percent of exercised decisions with full required metadata.
  
  

• Remediation urgency index — qualitative ranking of findings: Critical / High / Medium / Low.
  
  

Collect evidence in tamper‑evident formats; store backups with independent custodians.

8. Reporting & remediation workflow (high level)

A preplanned, short workflow ensures findings lead to concrete action.

1. Immediate brief (24–72 hours) — to Sponsor and Legal, highlighting any critical safety events.
   
   

2. Sanitized interim report — for oversight bodies and independent auditors within agreed timelines.
   
   

3. Full technical annex (restricted) — detailed artifacts for certified engineers and procurement leads (kept under strict access control).
   
   

4. Remediation plan — assigned owners, timelines, and verification criteria; Sponsor approves resources.
   
   

5. Follow‑up verification — tangible checks (e.g., a re‑run of related injects in sandbox after fixes) with independent validation.
   
   

All reporting must follow the pre‑approved sanitization plan.

9. Ethical considerations (people‑centred)

Explicit commitments to protect people involved and affected:

• Operator consent: Individuals participating in testing must give informed consent and may withdraw.
  
  

• Psychological safety: Avoid surprise injections that could cause undue stress or career harm; debrief participants promptly.
  
  

• Privacy: Do not expose personal data in exercise datasets unless legally authorized and minimized.
  
  

• Public interest: Balance transparency with duty to avoid enabling misuse.
  
  

10. Quick checklist — pre‑exercise Go/No‑Go

• Legal pre‑approval signed ✅
  
  

• Ethics/IRB approval signed ✅
  
  

• Isolation testbed validated and air‑gapped where required ✅
  
  

• Stop conditions defined and communicated ✅
  
  

• Independent observer(s) appointed and briefed ✅
  
  

• Data sanitization & disclosure plan agreed ✅
  
  

• Roles & contact list published ✅
  
  

• Remediation/responsibility plan pre‑agreed ✅
  
  

If any item is unchecked → No‑Go.

11. Closing guidance

Safety‑first red‑teaming is an institutional discipline: it succeeds when procedures, ethics, and governance are stronger than the desire to shock or “break” a system. Design exercises to reveal governance gaps and operator assumptions, measure detectability and recovery, and translate findings into procurement, training, and policy changes. Above all: if an exercise risks producing operationally useful exploit information or real‑world harm, it must be halted and reframed into a safe, policy‑oriented alternative.

Next: Chapter 8 will translate these objectives and constraints into concrete, sanitized scenario design patterns suitable for tabletop and sandboxed simulation.

Part III — Red‑Team Methodology for Neuromorphic Command

Chapter 8 — Scenario Design

Political, operational, and environmental axes (tabletop vs. simulated) (pp. 67–78)

Overview (what this chapter does)

This chapter provides a practical, safety‑first framework for designing red‑team scenarios that exercise neuromorphic command systems along three orthogonal axes — political, operational, and environmental. It shows how to choose between tabletop and sandboxed simulation staging, how to pick inject vectors that reveal socio‑technical brittleness without creating operationally useful exploits, and how to align scenarios to measurable evaluation criteria. All material is conceptual and governance‑oriented; no low‑level attack techniques, payloads, or weaponization guidance are included.

1. Scenario design principles (short)

1. Safety first — prefer tabletop for early learning; use sandboxed simulation only with full approvals.
   
   

2. Policy focus — design scenarios to reveal governance gaps, not to discover exploitable code flaws.
   
   

3. Multi‑axis coverage — combine political, operational, and environmental stressors to surface emergent failure modes.
   
   

4. Observable outcomes — ensure each scenario yields measurable evidence (detection times, audit completeness, human comprehension scores).
   
   

5. Sanitization & isolation — use synthetic data and isolated testbeds; never run red‑team tests against production actuation paths.
   
   

2. The three axes — definitions & examples

Political axis (authority, legal, reputational)

Tests stresses that arise from political or legal ambiguity, public scrutiny, coalition constraints, or escalation risk.

• Examples: ambiguous ROE across coalition partners; domestic political oversight deadlines; expectation of public transparency after incidents.
  
  

Operational axis (mission tempo, command structures, human workflows)

Exercises how the system and people behave under different mission tempos, command arrangements, and staffing patterns.

• Examples: high‑tempo contact engagement; degraded comms between headquarters and operators; rotating shifts with varying training levels.
  
  

Environmental axis (sensing, geography, contested information)

Stresses stemming from environmental conditions and information quality: sensor degradation, contested sensors, EM interference, civilian density, weather.

• Examples: dense urban clutter, intermittent sensor feeds, seasonal weather reducing sensor fidelity.
  
  

3. Tabletop vs. Simulated (brief decision guide)

Tabletop (recommended first)

• Purpose: explore doctrine, roles, and first‑order decision flows; test policy and escalation rules.
  
  

• Risk: minimal; uses role‑playing and sanitized inputs.
  
  

• Best for: political axis exploration, command authority testing, legal/ethics discussion.
  
  

Sandboxed simulation (use with approvals)

• Purpose: exercise human–machine observability, timing, and recovery workflows under controlled, synthetic inputs.
  
  

• Risk: higher; requires isolation, data governance, and independent observers.
  
  

• Best for: operational + environmental axis interactions, telemetry/provenance validation, timing metrics.
  
  

Use tabletop to converge on scenario parameters before moving to simulation.

4. Scenario framing template (policy‑safe)

Use the following one‑page template to pitch and approve each scenario:

1. Scenario title (sanitized)
   
   

2. Objective(s) — which red‑team objectives this scenario tests (pick 1–3)
   
   

3. Axis coverage — Political / Operational / Environmental (check boxes)
   
   

4. Staging level — Tabletop / Sandboxed simulation (choose)
   
   

5. Actors & roles (policy labels) — e.g., Commander, Operator, Red Team, External Media, Coalition Liaison, Independent Auditor
   
   

6. High‑level narrative — 3–4 sentences (no technical detail; no tactics)
   
   

7. Key inject types (policy phrasing) — e.g., “conflicting witness reports”, “intermittent comms”, “coalition ROE ambiguity”
   
   

8. Primary evidence to collect — detection time, operator comprehension, provenance completeness, authorized override count
   
   

9. Stop conditions & escalation — pre‑approved triggers to halt the exercise
   
   

10. Sanitization / disclosure rules — who receives which level of detail post‑exercise
    
    

11. Sponsor & approvers — named roles (not individuals in public material)
    
    

Always attach legal/IRB approvals to the template before proceeding.

5. Sample sanitized scenarios (three compact examples)

A — “Coalition ROE Ambiguity” (Political + Operational) — Tabletop

Objective: Test whether multinational ROE differences produce command delays or unauthorized delegations.
Narrative: Two partner nations interpret engagement triggers differently under a single mission; the neuromorphic command system issues a recommendation that is lawful under Partner A’s ROE but questionable for Partner B.
Injects (policy‑style): written, conflicting ROE statement delivered by coalition liaison; time pressure from mission timeline.
Evidence: decision authority mapping, time to escalate, documentation of who authorized what, after‑action recommendations for procurement clauses.
Why safe: avoids sensors/actuation; focuses on doctrine and human decisionmaking.

B — “Sensor Degradation During High Tempo” (Operational + Environmental) — Sandboxed Simulation

Objective: Validate safe‑stop and operator comprehension when sensor quality degrades during a fast‑moving mission.
Narrative: A mission increases tempo; some sensor feeds intermittently drop or return low‑confidence data. The system must indicate uncertainty and request human input per policy.
Injects (policy‑style): scheduled sensor latency, reduced confidence indicators, concurrent non‑critical comms loss.
Evidence: time to human awareness, proportion of decisions with complete provenance, time to safe‑stop, operator survey.
Why safe: uses synthetic sensor traces in an isolated testbed; does not interact with live systems.

C — “Insider‑Influence on Reporting Chain” (Political + Operational + Environmental) — Tabletop → Simulation Hybrid

Objective: Explore plausibility and detection of insider manipulation of human inputs and how that affects command outputs.
Narrative: An insider with privileged access alters reported observations to match a narrative. The system consumes those reports and issues a course of action recommendation. Team must detect inconsistency via cross‑checks and audit.
Injects (policy‑style): conflicting corroboration reports, sudden shifts in provenance metadata, personnel changeover.
Evidence: detection latency, audit trail integrity checks, procedural failures in separation of duties.
Why safe: begins as tabletop to explore policy fixes; only moves to sandbox simulation with sanitized provenance traces and strict IRB/legal approvals.

6. Designing injects — safe language & examples

Principles: injects must never include exploit steps or detailed manipulation techniques. Frame injects as policy events, actor behaviors, or environmental conditions.

Inject categories (policy phrasing):

• Information injects — “contradictory field reports”, “social media amplification of an incident”
  
  

• Authority injects — “competing orders from different command levels”, “urgent political directive to accelerate mission”
  
  

• Sensor injects — “temporary loss of feed X”, “degraded confidence values for feed Y” (use synthetic values)
  
  

• Human factor injects — “operator fatigue due to extended shift”, “new operator with limited training assigned”
  
  

• Process injects — “failure to apply required provenance tags”, “audit backlog prevents timely review”
  
  

Safe example wording for an inject:

“At T+15 minutes, Operator Desk receives a second witness report that contradicts initial sensor summary. The report lacks provenance metadata and indicates a different civilian presence estimate. Observe how operator and system handle conflicting information.”

Always pre‑specify expected evidence collection points for each inject.

7. Evaluation criteria & mapping to objectives

Create a short evaluation rubric that maps scenario outcomes to remediation priorities.

Core outcome buckets (examples):

• Detection & Awareness — Detected / Delayed / Missed
  
  

• Operator Comprehension — High / Medium / Low (based on post‑exercise assessment)
  
  

• Authority Adherence — Compliant / Procedural deviation / Unauthorized action
  
  

• Provenance Integrity — Complete / Partial / Lost
  
  

• Graceful Degradation — Safe‑stop / Partial degradation with mitigations / Hazardous degradation
  
  

Remediation priority mapping:

• Any “Unauthorized action” or “Hazardous degradation” → Critical remediation (procurement clause & immediate policy change)
  
  

• “Partial provenance loss” or “Delayed detection” → High remediation (training + technical traceability improvement)
  
  

• “Operator comprehension Medium” → Medium remediation (UI/UX and training changes)
  
  

Keep rubrics simple and tied to policy levers (procurement, training, doctrine).

8. Evidence collection plan (what to capture)

For each scenario, predefine an evidence bundle (sanitized) sufficient for auditors and decision‑makers:

• Scenario timeline (sanitized)
  
  

• Inject schedule and type (policy labels)
  
  

• Telemetry & provenance extracts (synthetic or redacted) demonstrating decision flows
  
  

• Human actions / approvals log (who did what and when)
  
  

• Operator surveys and debrief transcripts (consent obtained)
  
  

• Independent observer notes and validation checklist
  
  

• Recommended mitigations and owner assignments
  
  

Ensure evidence is stored in tamper‑evident form with independent custodian access.

9. Transitioning a tabletop to simulation — safe pathway

1. Tabletop → converge requirements: use tabletop to identify the precise behaviors and data points to test.
   
   

2. Legal & ethics signoff: obtain explicit approvals for simulation scope and synthetic data content.
   
   

3. Design sanitized inputs: generate synthetic sensor/provenance traces; verify no real PII or operational identifiers.
   
   

4. Test isolation & rollback: validate testbed air‑gaps and rollback/stop procedures.
   
   

5. Run a dry‑run with independent observer: validate that stop conditions and evidence capture work.
   
   

6. Execute with incremental injects: start with low‑impact injects before more complex combinations.
   
   

7. Debrief & remediate: produce sanitized reports and remediation plans per pre‑agreed disclosure rules.
   
   

Never move to simulation without all mandatory constraints (legal, IRB, observer) satisfied.

10. Quick scenario checklist (pre‑launch)

• Objectives aligned and measurable ✅
  
  

• Axis coverage and staging chosen ✅
  
  

• Tabletop rehearsal completed ✅
  
  

• Legal & IRB approvals attached ✅
  
  

• Synthetic data validated & sanitized ✅
  
  

• Independent observer assigned ✅
  
  

• Stop conditions / escalation chain documented ✅
  
  

• Evidence capture plan in place, with independent custodian ✅
  
  

If any item is unchecked → No‑Go.

11. Closing guidance (short)

Good scenario design emphasizes policy discovery over technical exploitation. Use the three axes to create focused, governance‑actionable learning experiences. Start with tabletop, move to sandbox only with full approvals, collect tamper‑evident evidence, and translate findings into procurement, doctrine, and training changes. Red teams are instruments of institutional learning — keep them structured, safe, and accountable.

Part III — Red‑Team Methodology for Neuromorphic Command

Chapter 10 — Behavioral and Cognitive Stress Tests

Surprise inputs, degraded sensors, contested communications (pp. 93–104)

Overview (what this chapter does)

This chapter describes safe, policy‑oriented approaches to stress‑testing the human side of human–machine teams that use neuromorphic command systems. The focus is on behavioural and cognitive failure modes: how surprise, ambiguity, degraded sensing, and contested communications affect operator judgement, authority delegation, and institutional decision‑making. All tests are framed to reveal socio‑technical brittleness and improve governance, not to produce operational exploitation techniques.

1. Why behavioural & cognitive tests matter

Technical robustness is necessary but not sufficient. Many incidents trace to human decisions made under stress, not purely to model error. Neuromorphic systems—stateful, adaptive, and opaque—can amplify human cognitive challenges by presenting unfamiliar affordances, subtle state drift, or high‑volume recommendations. Stress tests probe:

• How operators perceive and interpret system outputs under surprise or ambiguity.
  
  

• Whether operators can maintain meaningful control (HITL/HOTL) when tempo, noise, or uncertainty increase.
  
  

• Whether organizational procedures support sensible human responses under cognitive load.
  
  

Red‑teams should treat cognitive stress tests as governance instruments: they surface training, UI, authority, and policy failures.

2. Core behavioural failure modes to test (policy labels)

Keep labels non‑technical and focused on outcomes.

• Rubber‑stamping / Automation Bias — operator accepts system output without sufficient scrutiny.
  
  

• Complacency / Skill Fade — prolonged HOTL operation leads to reduced situational awareness.
  
  

• Over‑correction / Panic Override — under surprise, operators reflexively override safe defaults with unsafe actions.
  
  

• Misinterpretation of Uncertainty — operators misread confidence indicators, treating low‑certainty outputs as reliable or vice versa.
  
  

• Cascading Confirmation Errors — corrupted input accepted early causes downstream human and machine consensus around false beliefs.
  
  

• Authority Confusion — unclear delegation leads to procedural delays or unauthorized actions.
  
  

• Alert Fatigue — high false positive rates cause operators to ignore important warnings.
  
  

Design tests to reveal which of these occur, how often, and why.

3. Design principles for safe cognitive stress tests

1. Start soft, escalate carefully — use tabletop roleplay before any simulation.
   
   

2. Use synthetic, sanitized data — no real operational PII or mission identifiers.
   
   

3. Protect participants — informed consent, psychological safety briefings, and post‑exercise support.
   
   

4. Observe, don’t trick — inject plausible policy events, not deceptive manipulations meant to shame or entrap individuals.
   
   

5. Measure human metrics, not model weakness — focus on time, comprehension, decisions, and procedural adherence.
   
   

6. Independent observers and rapid stop authority — neutral monitors can halt exercise if harm to people or reputations appears likely.
   
   

7. Predefine acceptable operator behaviours — clarify what counts as correct adherence to procedure to avoid penalizing reasonable human judgement.
   
   

4. Typical test categories & safe examples

A. Surprise Input Tests (cognitive ambiguity)

Goal: Assess operator ability to detect and manage unexpected or conflicting inputs.

Safe injects (policy phrasing):

• “At T+10, receive a second eyewitness report contradicting the system’s recommendation. Report lacks full provenance metadata.”
  
  

• “At T+20, a coalition liaison issues a late clarification that narrows the ROE.”
  
  

What to observe: time to detect conflict; operator verbalization of uncertainty; whether operator requests additional corroboration or rubber‑stamps.

Acceptance signals: operator requests corroboration or escalates in X% of trials; decision reversals justified and logged.

B. Degraded Sensor Tests (information quality stress)

Goal: Measure operator interpretation of degraded/conflicting sensor feeds and the tendency to over‑ or under‑trust automation.

Safe injects (policy phrasing):

• “Introduce intermittent low‑confidence readings from sensor A while sensor B remains stable.”
  
  

• “Simulate increased false‑positive rate for non‑critical cues.”
  
  

What to observe: reliance on a single feed, changes in override frequency, comprehension of confidence indicators.

Acceptance signals: operators fallback to procedural cross‑checks; provenance metadata consulted before action.

C. Contested Communications Tests (command & comms stress)

Goal: Test decision‑flow when comms latency, partial outages, or conflicting orders occur.

Safe injects (policy phrasing):

• “Introduce a 2‑minute headquarters comms blackout for approval channel; local operator must follow pre‑agreed contingency.”
  
  

• “Deliver two competing, time‑sensitive directives from different authorities without clarifying hierarchy.”
  
  

What to observe: adherence to delegation ladder, use of failover procedures, delays or unauthorized actions.

Acceptance signals: operators follow chain‑of‑command procedures; any deviation recorded with justification.

D. Tempo and Fatigue Tests (human performance under load)

Goal: Understand performance degradation across shift length, cognitive load, and repetitive decision cycles.

Safe injects (policy phrasing):

• “Extend session duration and increase decision requests per hour to simulate high‑tempo operation.”
  
  

• “Rotate operators with differing training levels mid‑scenario.”
  
  

What to observe: error rates, decision latency, instances of rubber‑stamping, and self‑reported mental workload.

Acceptance signals: error rates remain below threshold; operators escalate when overwhelmed; post‑exercise debrief identifies training gaps.

E. Mixed‑Vector Tests (hybrid stressors)

Goal: Reveal emergent socio‑technical failures by combining the above stressors.

Safe injects (policy phrasing):

• “Combine sensor degradation with contested comms and media pressure (simulated) about civilian presence.”
  
  

• “Introduce a time‑sensitive political directive while sensors provide low‑confidence data.”
  
  

What to observe: compound effect on operator judgement, procedural adherence, and audit completeness.

Acceptance signals: system and operators can maintain safe posture or appropriately escalate; audit trail remains reconstructable.

5. Human metrics & instruments (how to measure safely)

Use validated, non‑intrusive instruments and objective timestamps.

Objective metrics

• Detection latency — time from inject to operator acknowledgement (minutes/seconds).
  
  

• Decision latency — time from system recommendation to human action or override.
  
  

• Override rate — percent of system recommendations overruled.
  
  

• Procedural adherence rate — percent of decisions that followed documented protocol.
  
  

• Provenance consultation rate — percent of cases operators accessed provenance metadata before action.
  
  

Subjective metrics (structured, anonymized)

• NASA‑TLX (task load index) or similar for perceived workload.
  
  

• Trust calibration survey — operator self‑reported trust vs. system reliability.
  
  

• Comprehension quiz — brief post‑inject questions to assess understanding of system outputs and uncertainty.
  
  

Observational instruments

• Time‑stamped logs (sanitized) of operator actions.
  
  

• Independent observer checklists mapping observed behaviours to expectations.
  
  

• Post‑exercise structured interviews and cognitive walkthroughs (consent required).
  
  

6. Designing control and comparison conditions

To interpret results, include baseline/control runs:

• Baseline (low stress): normal sensor fidelity, open comms, standard tempo.
  
  

• Moderate stress: single axis degradation (e.g., sensor drop).
  
  

• High stress: combined axes that reflect operational worst‑cases.
  
  

Compare operator metrics across conditions to identify sharp inflection points where performance collapses or patterns of unsafe behaviour emerge.

7. Common findings & typical remediation levers (policy‑oriented)

Below are non‑exhaustive recurring outcomes and the governance levers that address them.

Finding: Rubber‑stamping under time pressure

Remedy: enforce mandatory pause/confirmation for high‑consequence recommendations; require structured verification steps in UI; revise training to include adversarial questioning.

Finding: Misinterpretation of uncertainty indicators

Remedy: standardize conservative uncertainty displays; require provenance highlights; update SOPs to treat low‑confidence outputs as informational only.

Finding: Operator disengagement in HOTL

Remedy: increase scheduled supervised drills; implement periodic synthetic anomalies requiring explicit operator response; rotate duties to prevent monotony.

Finding: Confusion during competing orders

Remedy: codify a delegation ladder with clear automatic routing; require explicit metadata on authority provenance for each directive.

Finding: Audit trail gaps after complex events

Remedy: procurement clauses mandating immutable, independent logging and snapshot capability; immediate technical remediation and re‑test.

8. Ethics, consent, and participant protection (musts)

Behavioral tests engage people — protect them.

• Informed consent: participants receive purpose, risks, and withdrawal rights.
  
  

• Psychological safety: avoid punitive scenarios; provide immediate support and debrief.
  
  

• Career protections: results used for systemic improvement, not individual punishment unless gross negligence is found under pre‑agreed policies.
  
  

• Anonymization: anonymize personal data in reports and public materials.
  
  

• IRB/Ethics signoff: required before any human subject testing.
  
  

9. Reporting behavioural findings (policy templates)

Reports should translate cognitive observations into implementable governance actions.

Suggested sanitized report sections:

1. Executive summary — key behavioural failures and top 3 remediation priorities.
   
   

2. Scenario summary — high‑level narrative, axes stressed, staging level.
   
   

3. Metrics dashboard — objective & subjective metrics with comparison to baseline.
   
   

4. Observed behaviours — descriptive, anonymized examples (no shaming).
   
   

5. Root causes — whether interface, training, procedural, or authority design.
   
   

6. Recommended actions — procurement clauses, UI changes, training syllabus, policy updates.
   
   

7. Verification plan — how to re‑test and validate fixes (sandboxed only).
   
   

All technical annexes that might be sensitive are restricted to authorized engineering and legal teams per pre‑approved access rules.

10. Quick operational checklist (pre‑test)

• IRB/ethics approval obtained ✅
  
  

• Informed consent from participants ✅
  
  

• Independent observer(s) assigned and briefed ✅
  
  

• Synthetic/sanitized data prepared ✅
  
  

• Stop conditions and rapid pause authority defined ✅
  
  

• Baseline and stress condition scripts validated ✅
  
  

• Evidence capture instruments (timing, logs, surveys) in place ✅
  
  

If any item is unchecked → No‑Go.

11. Closing guidance

Behavioral and cognitive stress tests are among the most valuable red‑team activities for neuromorphic command — because they reveal where institutions, people, and procedures fail together. Keep tests humane, focused on governance, and designed to produce remediation. Prioritize measurable outcomes, protect participants, and translate findings into procurement, training, and policy changes that restore and preserve meaningful human control.

Part III — Red‑Team Methodology for Neuromorphic Command

Chapter 11 — Socio‑Technical Attacks

Human factors, misinformation, and chain‑of‑command manipulation (pp. 105–116)

Overview (what this chapter does)

This chapter treats socio‑technical attacks as blended campaigns that exploit human behavior, organizational processes, and technical affordances to produce unsafe or unintended command outcomes. The goal is to give red‑teams and decision‑makers a taxonomy of such attacks, safe (non‑operational) ways to exercise them, and policy‑level mitigations that reduce institutional exposure. All material is governance‑oriented and avoids technical exploitation instructions.

1. Why socio‑technical attacks are especially dangerous

• Leverage of trust: They exploit trust relationships (between humans, between humans and systems, or between organizations) rather than purely technical vulnerabilities.
  
  

• Low‑cost, high‑impact: Minimal technical capability can produce disproportionate effects if social channels or procedural gaps are exploited.
  
  

• Hard to detect: Effects often look like legitimate decisions or normal human error, complicating attribution and response.
  
  

• Cross‑domain effects: They produce legal, political, and reputational harms that technical fixes alone cannot address.
  
  

Red teams must therefore treat socio‑technical attacks as first‑class scenarios — but design exercises that reveal vulnerabilities without enabling misuse.

2. Taxonomy: common socio‑technical attack vectors (policy labels)

A. Misinformation & Influence Operations

• Description: Coordinated dissemination of false or misleading information through media, social platforms, or intermediary actors to alter human reporting, public perception, or commander incentives.
  
  

• Policy risk: Pressured or biased human reports, altered rules of engagement under political scrutiny, or manipulated public opinion that changes operational constraints.
  
  

B. Report & Witness Manipulation

• Description: Tampering with human‑source reports (fabrication, coercion, incentivised misreporting) to influence system inputs or operator decisions.
  
  

• Policy risk: Corrupted input streams lead to erroneous representations; provenance gaps make detection hard.
  
  

C. Chain‑of‑Command Spoofing / Competing Authorities

• Description: Fake or conflicting directives presented as coming from legitimate authorities (e.g., forged orders, mimicked liaison signals).
  
  

• Policy risk: Operators face authority confusion and may take unauthorized actions or delay critical decisions.
  
  

D. Social Engineering of Operators / Administrators

• Description: Direct manipulation of personnel (phishing, coercion, bribery, pretexting) to obtain credentials, change procedures, or alter logs.
  
  

• Policy risk: Insider‑like access achieved without formal compromise, undermining provenance and audit trails.
  
  

E. Organizational Incentive Exploits

• Description: Exploitation of reward structures, procurement incentives, or cultural norms that encourage premature automation reliance or silence reporting of near‑misses.
  
  

• Policy risk: Systemic drift toward unsafe practices despite technical safeguards.
  
  

F. Procedural Subversion (paper vs practice)

• Description: Formal procedures exist, but workplace realities (time pressure, understaffing) cause deviations that attackers can predict and exploit.
  
  

• Policy risk: Formal compliance masks operational risk; red‑teams must surface gaps between policy and practice.
  
  

3. Safe red‑team approaches to socio‑technical scenarios

Design principles (safety first)

• Use policy‑level injects, not operational how‑to’s. Frame manipulations as events (e.g., “contradictory media narrative”) rather than methods.
  
  

• Prefer tabletop first. Model incentives and human reactions in roleplay before any simulation.
  
  

• Sanitize human‑source data. Never use or fabricate real personal data; use role‑based pseudonyms.
  
  

• Protect participants. Inform operators ahead of likely scenario types (they need not know precise injects) and obtain consent for participation.
  
  

• Independent observers & stop authority. Socio‑technical tests can affect reputations — neutral oversight is mandatory.
  
  

Example safe scenario templates (policy phrasing)

• “Amplified Rumour” (Misinformation): A rapid media narrative claims civilian casualties in a mission area. Observe how commander intent, public affairs pressure, and system recommendations interact.
  
  

• “Conflicting Liaison” (Chain‑of‑Command): A coalition liaison sends late narrow ROE guidance that conflicts with higher headquarters’ orders. Test escalation and authorization clarity.
  
  

• “Incentive Pressure” (Organizational): Procurement deadlines and performance bonuses create pressure to accept system outputs without full audit. Roleplay procurement and leadership responses.
  
  

Each template must specify evidence points (who acted, timeline, provenance checks) and remediation owners.

4. Detection signals & red‑team observables (what to measure safely)

Human‑centric signals

• Frequency of unchecked acceptance of external reports
  
  

• Time and manner of escalation when facing competing directives
  
  

• Use (or non‑use) of provenance metadata during decision‑making
  
  

Organizational signals

• Patterns of deviations from written procedure under simulated pressure
  
  

• Procurement or performance documents that implicitly reward automation uptake without safety gates
  
  

Technical observables (policy‑safe)

• Gaps in provenance that allow insertion of unverified human reports
  
  

• Audit trails that lack explicit authority metadata for orders/instructions
  
  

Collect these as sanitized, time‑stamped logs and structured observer notes; never include sensitive personal identifiers.

5. Mitigation categories (policy levers)

A. Hard governance levers

• Authority provenance mandates: Every directive that could alter operations must include verifiable provenance metadata and be auditable.
  
  

• Separation of duties: No single person may both produce critical input and certify its provenance without independent checks.
  
  

• Mandatory escalation ladders: Clear, practiced procedures for resolving competing directives with timelines and fallbacks.
  
  

• Procurement conditionality: Contracts require demonstrable auditability, stoppability, and human‑control thresholds before acceptance.
  
  

B. Human‑centred controls

• Training & inoculation: Regular exercises exposing personnel to influence campaigns and social engineering, with emphasis on verification.
  
  

• Decision aids & friction: UI patterns that introduce required verification steps for high‑consequence actions (e.g., multi‑factor provenance confirmation).
  
  

• Rotation & redundancy: Avoid single points of human failure by rotating sensitive roles and ensuring overlap.
  
  

C. Technical & data controls (governance‑oriented)

• Tamper‑evident provenance stores: Independent, immutable logging of inputs and orders (cryptographically backed under independent custody).
  
  

• Metadata discipline: Mandate minimum metadata (authority, timestamp, transmission channel, corroboration status) for every human‑source input.
  
  

• Anomaly detection for social patterns: Monitor sudden surges in reports, repeated single‑source corroborations, or mismatches between human and sensor reports — as flags for human review.
  
  

D. Organizational culture and incentives

• Whistleblower and safe‑report channels: Encourage reporting of pressure to bypass safety steps without fear of career harm.
  
  

• Procurement balanced incentives: Reward verified safety and auditability, not just performance metrics.
  
  

• Transparency to oversight: Provide sanitized evidence packages to oversight bodies on a regular cadence to build institutional trust.
  
  

6. Red‑team evidence to produce (policy‑ready)

When exercising socio‑technical vectors, red‑teams should aim to produce:

• Sanitized timeline showing how misinformation or competing directives flowed and who acted when.
  
  

• Annotated provenance map illustrating gaps or ambiguities in authority metadata.
  
  

• Human response metrics (detection latency, escalation adherence, provenance consultation rates).
  
  

• Organizational diagnosis identifying incentive and procedural misalignments.
  
  

• Prioritized remediation plan with owners, timelines, and verification criteria.
  
  

All artifacts must be sanitized per pre‑approved disclosure rules and stored with independent custodianship.

7. Typical findings & policy remedies (high‑level)

Finding: Operators followed a credible fictional “liaison” directive without provenance check.
Remedy: Make provenance metadata mandatory for any directive that changes mission parameters; require out‑of‑band verification for cross‑authority orders.

Finding: Media‑driven pressure caused leadership to accelerate deployment decisions.
Remedy: Codify cooling‑off periods and require legal review when public allegations could drive operational change.

Finding: Procurement KPIs emphasized uptime and efficiency, discouraging safety reporting.
Remedy: Adjust KPIs to include auditability and safety metrics; tie payment milestones to demonstrable compliance.

Finding: Single person both created and approved human‑source inputs.
Remedy: Enforce separation of duties and audit trails; random spot checks by independent auditors.

8. Metrics & acceptance criteria (policy examples)

• Provenance completeness rate: percentage of human‑source inputs containing required authority metadata (goal: 100% for critical inputs).
  
  

• Escalation compliance rate: percentage of cases where competing directives were escalated per procedure (target: ≥95%).
  
  

• Social‑signal detection latency: time from onset of coordinated misinformation surge (simulated) to institutional flagging (target: within policy threshold).
  
  

• Incentive alignment index: qualitative assessment of procurement/training KPIs for safety vs. speed (target: safety‑weighted ≥ 0.7).
  
  

These targets should be negotiated with legal, operational, and ethics stakeholders.

9. Ethical & legal safeguards (musts)

• No entrapment or personal harm: exercises must avoid maneuvers that coerce, shame, or expose individuals to career or legal harm.
  
  

• Consent & confidentiality: participants must be informed and have protections for sensitive personal data.
  
  

• Responsible disclosure: findings that reveal systemic risk to public safety must follow pre‑agreed legal disclosure channels.
  
  

• External verification: involve independent auditors or civil‑society observers for credibility when appropriate.
  
  

10. Quick socio‑technical red‑team checklist (pre‑launch)

• Scenario framed in policy terms, no operational exploit steps ✅
  
  

• Tabletop rehearsal completed and validated ✅
  
  

• Legal & IRB approvals attached ✅
  
  

• Participants briefed and consented; psychological safety measures in place ✅
  
  

• Independent observer appointed and empowered to pause ✅
  
  

• Evidence collection & sanitization plan agreed ✅
  
  

• Remediation / disclosure owners identified ✅
  
  

If any item is unchecked → No‑Go.

11. Closing guidance

Socio‑technical attacks exploit the seams between people, institutions, and technology. Effective red‑teaming treats those seams as the primary surface to test: authority metadata, incentive structures, verification rituals, and human training. The aim is not to catalogue every possible manipulation, but to harden institutional practice so that manipulation is detected, contained, and corrected before it causes harm. Translate red‑team findings into procurement clauses, command‑authority rules, training, and independent audit mechanisms — and prioritize organizational humility: systems reflect the people and incentives that govern them.

Part III — Red‑Team Methodology for Neuromorphic Command

Chapter 12 — Red Team Tools & Environments

Safe sandboxing, synthetic data, digital twins, and rule‑based emulators (pp. 117–128)

Overview (what this chapter does)

This chapter describes safe, governance‑centric tooling and environment patterns red teams should use when exercising autonomous neuromorphic command systems. The emphasis is institutional: how to design testbeds and artifacts that produce useful evidence for policymakers, auditors, and operators—without creating operationally useful exploits or touching production control paths. All guidance is non‑operational and focused on isolation, sanitization, reproducibility, and auditability.

1. High‑level design goals for red‑team toolchains

Red‑team tooling must deliver four interlocking properties:

1. Isolation — no path to production actuation; strict separation from live systems and assets.
   
   

2. Sanitization — use of synthetic or heavily redacted data to avoid leaking operational detail or PII.
   
   

3. Observability — instrumented captures of inputs, internal state snapshots, provenance, and operator actions in tamper‑evident form.
   
   

4. Reproducibility & Traceability — ability to replay sanitized scenarios for verification while preserving confidentiality and safety.
   
   

Design tooling around these goals; treat them as non‑negotiable procurement and exercise prerequisites.

2. Sandboxing & testbed architectures (policy descriptions)

A. Air‑gapped hardware sandbox (policy concept)

• What it is: Physical or logically isolated environment where test systems run on hardware separate from production networks and actuators.
  
  

• Why use it: Eliminates risk of accidental linkage to live assets and prevents lateral movement into operational infrastructure.
  
  

Governance notes:

• Maintain independent power and network boundaries.
  
  

• Independent custody for critical logs and backups.
  
  

• Formal attestations that the sandbox cannot command or influence production assets (signed by system custodian).
  
  

B. Virtually isolated cloud sandbox (policy concept)