The Color of War: AI Purple Teaming Link 16 J-Messages Without Touching the Live Network
There are networks you do not casually scan.
Not because they are secure.
Because they are dangerous to break.
A web app can be tested in staging.
A cloud workload can be isolated.
A container can be rebuilt.
A failed API release can be rolled back.
A tactical data link is different.
If the wrong message is trusted, the system may believe a false track.
If timing is manipulated, the system may act on stale information.
If identity is confused, the system may build a corrupted battlespace picture.
If detection is noisy, operators may stop trusting the alarms.
If testing is careless, the test itself becomes the risk.
That is the problem this article solves:
How do you red-team, blue-team, and purple-team Link 16 J-message protocol behavior when the real network cannot be touched?
This is not a generic AI security article.
This is a defense-centric walkthrough of a controlled purple-team exercise: build a digital twin of the Link 16 protocol layer, train red AI to discover J-message failure modes, train blue AI to detect them, and use purple-team engagement to turn the exercise into engineering controls.
The objective is simple:
Break the twin 10,000 times so the real mission network does not have to break once.
What We Are Building
We are building a safe test architecture for Link 16-style J-message protocol testing.
The system under test is not the aircraft.
It is not the radio hardware.
It is not classified cryptography.
It is not a live operational network.
The system under test is the J-message processing and timing logic:
- message schema validation
- source identity handling
- timestamp and freshness validation
- TDMA slot discipline
- replay behavior
- malformed-field handling
- track-fusion plausibility
- degraded communication behavior
- alert explainability
- operator decision support
- remediation and regression proof
Everything happens inside a lab.
No live RF.
No live tactical network.
No real aircraft.
No operational exploitation.
The phrase to keep in mind:
We test the protocol logic, not the live battlespace.
The Journey
This article follows one continuous exercise.
- Understand why Link 16 is not normal IT.
- Treat TDMA timing as a security signal.
- Treat J-messages as the protocol API.
- Build a digital twin where the protocol can be safely broken.
- Train a red AI agent to discover J-message failure modes.
- Train a blue AI agent to detect timing, identity, sequence, and plausibility anomalies.
- Run a purple-team engagement.
- Produce evidence, remediation, and regression tests.
- Convert the lesson into a model for future defense systems.
This is the missing connection in many AI-security conversations.
AI is not the strategy.
The purple-team engagement is the strategy.
AI is the accelerator.
1. The Problem: Link 16 Is Not Your Enterprise LAN
Security teams are comfortable with IP.
Ports. Packets. Agents. Logs. SIEM. EDR. CloudTrail. VPC Flow Logs. Suricata. Zeek. Kubernetes events. GitHub alerts. Terraform drift.
That world gives us visibility.
A Link 16-style tactical network does not give us that comfort.
It is a tactical data link used to share situational awareness and command information between military platforms. For this article, the important thing is not the operational implementation. The important thing is the security model:
Link 16 is a deterministic, time-disciplined, structured-message network where trust depends on message validity, timing, source identity, and shared state.
That is a very different target.
There may be no normal IP path to scan.
There may be no endpoint agent to install.
There may be no safe packet capture.
There may be no acceptable test outage.
There may be no room for “we were just testing.”
In enterprise IT, a failed test might break a service.
In a tactical environment, a failed assumption can corrupt the picture people rely on to make decisions.
That is why traditional pentesting is the wrong starting point.
The right starting point is a safe, replayable twin.
2. TDMA: The Clock Is Part of the Security Boundary
Link 16-style communication is time-disciplined.
A useful mental model is TDMA: Time Division Multiple Access.
Each participant gets a scheduled time slot. It speaks when it is allowed to speak. Others listen when they are supposed to listen.
Simplified:
Cycle 1:
Slot 0 -> F-16 #1
Slot 1 -> AWACS
Slot 2 -> Ship
Slot 3 -> F-16 #2
Cycle 2:
Slot 4 -> F-16 #1
Slot 5 -> AWACS
Slot 6 -> Ship
Slot 7 -> F-16 #2
For software engineers, imagine a distributed system where each service has a strict write window. If a service writes outside its window, that is not just bad engineering. It is a security signal.
Timing becomes telemetry.
Blue team can ask:
- Did the message arrive in the expected slot?
- Did the participant transmit when expected?
- Did timing drift slowly?
- Did the message arrive too late to be trusted?
- Did a stale update look fresh?
- Did silence itself become meaningful?
This is the first defense insight:
In deterministic networks, time is not metadata. Time is part of the control surface.
That cuts both ways.
The defender can detect deviations because the system is predictable.
The adversary, defect, or failure condition can also exploit trust in predictable timing if validation is weak.
That is why the purple-team exercise focuses on timing and J-message behavior together.
3. J-Messages: The Language and the Attack Surface
If TDMA is the clock, J-messages are the language.
A J-message is the structured data that travels in the slot. It may represent participant identity, track data, position, velocity, status, commands, or other tactical state.
For software engineers, the best analogy is:
A J-message is a strict binary API call sent on a clock.
Not HTTP.
Not JSON.
Not a TCP port.
Not a web form.
Not a normal packet capture exercise.
A simplified simulated J-message frame might look like this:
+------------+-----------+----------------------+----------+------------+
| Msg Type | Source ID | Position | Velocity | Timestamp |
+------------+-----------+----------------------+----------+------------+
| Track | F16-01 | lat / lon / altitude | vector | T+217s |
+------------+-----------+----------------------+----------+------------+
Now the attack surface becomes clearer.
Not “Can I run nmap?”
The real questions are:
- Can the parser safely reject malformed fields?
- Can the receiver detect duplicate or conflicting source IDs?
- Can the system reject stale but well-formed messages?
- Can track fusion detect physically impossible movement?
- Can timing validation detect messages outside the expected slot?
- Can the system degrade safely when slots are missing?
- Can the SOC explain which message, which slot, and which rule caused the alert?
This is why J-message testing matters.
A message can be syntactically valid but operationally dangerous.
That is the heart of the exercise.
4. Why Traditional Pentesting Fails
Traditional pentesting asks:
- What is exposed?
- What service is vulnerable?
- Can authentication be bypassed?
- Can privilege be escalated?
- Can data be extracted?
Those questions matter in normal IT.
They do not fully solve Link 16 J-message risk.
For this problem, the better questions are:
- What message fields are trusted too easily?
- What timestamp assumptions are not enforced?
- What identity conflicts are not resolved safely?
- What replay windows are too permissive?
- What malformed fields destabilize parsing?
- What impossible track update survives fusion?
- What blue-team signal proves the issue?
- What engineering control prevents recurrence?
A scanner cannot answer those questions.
A live tactical test is unsafe.
A generic dashboard is not enough.
The answer is a digital twin with a purple-team operating model.
5. The Digital Twin: The Safe War Lab
The digital twin is where dangerous questions become safe experiments.
It does not need to be a real aircraft.
It does not need to be real RF.
It does not need to expose classified implementation details.
It needs to simulate the protocol-layer behavior we care about:
- J-message structure
- TDMA slot timing
- participant identity
- timestamp and freshness logic
- parser behavior
- track database updates
- fusion plausibility
- degraded-link behavior
- telemetry capture
- replay
A useful twin gives us one thing the live network cannot:
permission to fail safely.
Inside the twin, red can try.
Blue can detect.
Purple can judge.
Engineering can fix.
The replay can prove whether the fix worked.
Physical World to Digital Twin Mapping
| Physical Link 16 Concept | Digital Twin Equivalent |
|---|---|
| F-16 mission computer | Pod running simulated terminal logic |
| AWACS node | Pod running command/coordination logic |
| Ship node | Pod running participant logic |
| TDMA slot plan | ConfigMap or mounted YAML schedule |
| Radio transmission | UDP or event bus message between pods |
| RF interference | Network delay, loss, deny policy, or chaos injection |
| Mission replay | Persistent replay file |
| Tactical picture | Simulated track database |
| SOC visibility | Kafka stream, logs, metrics, model output |
| Purple-team evidence | Replay bundle and after-action report |
This does not mean we containerize a fighter jet.
We containerize the protocol node.
That is the correct abstraction.
Kubernetes as the Lab Harness
Kubernetes is useful because this exercise needs repeatability, isolation, and scale.
Each participant can be a pod.
Each mission can be a namespace.
Each TDMA schedule can be YAML.
Each scenario can emit telemetry.
Each replay can be stored.
Each defense change can be versioned.
Each night can run hundreds or thousands of engagements.
A simplified architecture:
+----------------------------------------------------------+
| Kubernetes Digital Twin |
| |
| +----------+ +----------+ +----------+ |
| | F-16 #1 | --> | AWACS | --> | Ship | |
| +----------+ +----------+ +----------+ |
| | | | |
| +---------------+---------------+ |
| | |
| J-message Event Mesh |
| | |
| +---------------+---------------+ |
| | | |
| Red AI Agent Blue AI Agent |
| | | |
| +---------------+---------------+ |
| | |
| Purple Evidence Store |
+----------------------------------------------------------+
The twin is not a gimmick.
It is the only safe place where this exercise can be run at useful scale.
6. The Mission: Test J-Message Trust
The purple-team mission statement:
Determine whether AI-assisted red, blue, and purple teams can safely discover, detect, explain, and remediate J-message protocol failure modes inside a Link 16 digital twin.
That mission gives each team a role.
Red Team Mission
Discover safe, replayable J-message failure modes in the twin.
Blue Team Mission
Detect and explain J-message anomalies using timing, identity, freshness, sequence, parser, and track-fusion signals.
Purple Team Mission
Validate whether the red behavior matters, whether blue detection is useful, and whether engineering can fix the control gap.
This framing prevents the article from becoming an AI tool dump.
Everything serves the mission.
7. The AI Toolchain: Models, Engines, Harnesses, and What Each Team Actually Does
The prompt is explicit: the AI system is not one model doing everything. It is three different AI roles running inside the same Kubernetes-based digital twin.
Each role has a different model, engine, harness, and mission.
| Team | Model | Engine / Runtime | Harness | Primary Job |
|---|---|---|---|---|
| Red Team | PPO policy with LSTM memory | Ray RLlib | Custom Gym environment wrapping the twin | Discover safe, replayable J-message failure modes |
| Blue Team | Pre-trained Transformer in PyTorch | TorchServe or Triton | Kafka consumer + validators + correlation engine | Detect timing, identity, sequence, freshness, and track anomalies |
| Purple / SOC Team | Llama 3 or Mistral LLM | Ollama for local lab or approved API | LangChain + MCP tools | Retrieve evidence, summarize engagement, draft after-action report |
This matters because each model type solves a different problem.
The red problem is exploration.
The blue problem is sequence understanding.
The purple problem is evidence explanation.
Using one generic LLM for all three would be the wrong architecture.
Why PPO/LSTM for Red?
The red agent is trying to discover multi-step protocol failure modes.
A single J-message anomaly may not be interesting. The interesting failure may require a sequence:
- introduce timing jitter,
- wait for recovery state,
- replay a stale synthetic track,
- observe whether the track database accepts it,
- adapt if blue detects it.
That is sequential decision-making.
PPO gives the red agent a stable reinforcement learning method for exploring the action space. LSTM memory helps it remember previous steps in the episode, which matters when the failure only appears after a chain of message and timing events.
The red agent is not a free-form attacker.
It is a policy model trained inside a controlled Gym environment.
Red PPO/LSTM Agent
↓
Custom Gym Environment
↓
MCP Tool API
↓
Kubernetes Digital Twin
↓
J-message stream + track database
↓
Reward calculation
↓
Policy update
The red agent observes the twin state, selects a safe simulated action, receives reward or penalty, and learns over many episodes.
Why a Transformer for Blue?
The blue agent is watching a stream.
J-messages are not isolated events. They form sequences over time:
source → slot → message type → timestamp → track state → next message
A static signature can catch obvious failures, but it struggles with context.
The blue Transformer learns normal protocol grammar:
- what messages usually follow each other,
- which source usually speaks in which slot,
- how timing behaves during normal and degraded modes,
- how track updates evolve,
- which kinematic changes are plausible,
- which sequence patterns are unusual.
The blue model does not replace deterministic validation.
It sits beside it.
Kafka J-message stream
↓
Tokeniser / Feature Extractor
↓
Transformer sequence model
↓
Physics checker + timing validator
↓
Correlation engine
↓
Anomaly score + reason codes
This is why the blue output can say:
This was not just a weird message. It was stale during recovery, from a source with valid identity, in a slot that looked normal, but the sequence and track movement were inconsistent.
That is the kind of explanation a SOC analyst and protocol engineer can use.
Why Llama/Mistral + LangChain + MCP for Purple?
The purple team does not need an LLM to invent findings.
It needs an LLM to retrieve evidence, organize timelines, and write a clear after-action report.
The purple LLM analyst uses:
- Llama 3 or Mistral as the language model,
- Ollama when the lab needs local/offline execution,
- an approved API when policy allows managed inference,
- LangChain as the agent harness,
- MCP as the safe tool interface to internal lab data.
The LLM does not touch the live network.
It reads from the twin’s evidence stores:
LLM Analyst
├── retrieve_message_history(track_id)
├── get_blue_attention_map(alert_id)
├── get_red_episode_trace(episode_id)
├── get_slot_plan(scenario_id)
├── get_track_db_diff(track_id)
└── generate_after_action_report()
MCP is important because it gives the LLM a controlled, auditable way to access the twin’s evidence. The LLM is not browsing around freely. It is using approved tools against approved lab data.
The LLM’s mission:
Turn red/blue telemetry into a human-readable report without inventing facts.
8. Kubernetes Lab Setup: How the AI System Actually Runs
The lab runs as a controlled Kubernetes environment.
Not because Kubernetes is a fighter jet.
Because Kubernetes gives us repeatable scenarios, isolated namespaces, declarative configuration, telemetry, scaling, and replay.
A practical lab namespace looks like this:
namespace: link16-purple-lab
Workload Pods:
node-f16-1
node-awacs
node-ship
node-f16-2
rf-emulator
red-rl-agent
blue-transformer
soc-llm-analyst
mcp-server
kafka
track-db
evidence-store
soc-dashboard
The flow:
+---------------------------------------------------------------+
| link16-purple-lab namespace |
| |
| Simulated Link 16 Nodes |
| +---------+ +---------+ +---------+ +---------+ |
| | F16-01 | | AWACS | | Ship | | F16-02 | |
| +----+----+ +----+----+ +----+----+ +----+----+ |
| | | | | |
| +-------------+-------------+-------------+ |
| | |
| Kafka J-message Stream |
| | |
| +-----------------+------------------+ |
| | | |
| +-----v------+ +------v---------+ |
| | Red PPO/ | MCP safe actions | Blue Transformer| |
| | LSTM Agent |--------------------->| + Validators | |
| +-----+------+ +------+---------+ |
| | | |
| +-----------------+------------------+ |
| | |
| Evidence Store / Track DB |
| | |
| SOC LLM Analyst + Dashboard |
+---------------------------------------------------------------+
The key Kubernetes objects:
| Component | Kubernetes Object | Purpose |
|---|---|---|
| Simulated participants | Deployments / StatefulSets | Run terminal logic and J-message processing |
| TDMA schedule | ConfigMap | Defines slot plan and participant timing |
| Scenario definition | ConfigMap or CRD | Defines mission, participants, allowed red actions |
| Kafka | StatefulSet / Operator | Carries J-message telemetry |
| Track DB | StatefulSet | Maintains simulated tactical picture |
| Red training | RayCluster / Jobs | Runs PPO/LSTM training episodes |
| Blue inference | Deployment | Serves Transformer model via TorchServe or Triton |
| LLM analyst | Deployment | Runs LangChain agent with local Ollama or API gateway |
| MCP server | Deployment | Provides controlled tool access to twin telemetry |
| Evidence store | PVC / object storage | Stores replays, alerts, traces, and reports |
| SOC dashboard | Deployment / Service | Shows alerts, timelines, and after-action reports |
| Network effects | NetworkPolicy / chaos tooling | Simulates loss, denial, latency, and degraded links |
This is not a demo-only architecture.
This is the operating model.
Lab Deployment Flow
A safe lab run looks like this:
1. GitOps deploys namespace and base services
2. TDMA slot plan loads from ConfigMap
3. Simulated participants start producing J-messages
4. Kafka captures full message stream
5. Blue Transformer starts baseline scoring
6. Red PPO/LSTM agent starts lab-only training episodes
7. MCP server exposes approved twin actions and evidence queries
8. Purple dashboard shows red action, blue detection, and timeline
9. LLM analyst drafts evidence-bound after-action report
10. Engineering fix is deployed back into the twin
11. Replay confirms whether the fix worked
A conceptual lab manifest structure:
k8s/
namespaces/
link16-purple-lab.yaml
configmaps/
tdma-slot-plan.yaml
scenario-ghost-track.yaml
red-action-policy.yaml
deployments/
node-f16-1.yaml
node-awacs.yaml
node-ship.yaml
node-f16-2.yaml
blue-transformer.yaml
soc-llm-analyst.yaml
mcp-server.yaml
ray/
red-rl-training-job.yaml
serving/
torchserve-blue-model.yaml
triton-blue-model.yaml
policies/
networkpolicy-deny-awacs-f16.yaml
red-agent-egress-deny.yaml
mcp-tool-allowlist.yaml
storage/
evidence-pvc.yaml
replay-store.yaml
The most important lab control:
The red agent never gets direct Kubernetes admin rights and never touches the live network. It only calls approved MCP tools scoped to the twin.
MCP Tool Boundary for the Lab
The MCP server is the control point between AI agents and the twin.
Red tools are action tools:
simulate_delay_message(message_id, delay_ms)
simulate_drop_slot(node_id, slot_id)
simulate_replay_message(message_id, replay_window)
simulate_identity_conflict(source_id, scenario_id)
simulate_kinematic_edge_case(track_id, profile)
Blue tools are context tools:
get_slot_plan(scenario_id)
get_track_state(track_id)
check_slot_sync(message_id)
check_physics(track_id)
get_message_context(message_id)
Purple tools are evidence tools:
retrieve_message_history(track_id)
get_red_episode_trace(episode_id)
get_blue_attention_map(alert_id)
get_detection_timeline(alert_id)
generate_report(finding_id)
Each tool call must be logged:
mcp_audit_event:
timestamp: T+217s
agent: red-rl-agent
tool: simulate_replay_message
scenario: ghost_track_recovery
allowed: true
evidence_pointer: replay/episode-00981/
This is how the lab stays safe and auditable.
9. Red AI Agent: Training the Synthetic Adversary
The red AI agent is not a hacker.
It is a controlled failure-mode discovery engine.
It has no live network access.
It has no real RF access.
It does not bypass real crypto.
It does not deploy malware.
It does not operate outside the twin.
Its job is to explore how the simulated protocol stack can be confused, degraded, or forced into unsafe state assumptions.
Think of the red agent as a sparring partner for the protocol.
Red Agent Objective
The red agent’s model choice is deliberate:
- PPO gives stable reinforcement learning for bounded action exploration.
- LSTM memory helps the agent learn multi-step timing and replay sequences.
- Ray RLlib lets training scale across GPU or CPU worker nodes.
-
Gym harness exposes the digital twin as
reset(),step(action),reward, anddone. - MCP tools are the only way the agent can act on the twin.
The red agent tries to answer:
Can I create a J-message sequence that degrades the tactical picture while staying inside realistic lab boundaries?
Safe simulated action categories:
- delay a simulated J-message
- suppress a simulated slot
- replay a synthetic lab message
- introduce a simulated source identity conflict
- alter a simulated field within schema boundaries
- trigger a malformed-field test case
- introduce timing jitter inside approved limits
- create a kinematic edge case for track fusion
These are not operational attack instructions.
They are controlled test actions exposed by the twin.
Red Agent Configuration
A conceptual red-agent configuration:
red_agent:
name: jmessage_red_rl_agent
environment: link16_digital_twin
live_system_access: false
observations:
- recent_jmessage_sequence
- current_slot_number
- participant_state_table
- track_database_summary
- blue_detection_feedback
- scenario_phase
allowed_actions:
- simulate_delay_message
- simulate_drop_slot
- simulate_replay_message
- simulate_identity_conflict
- simulate_schema_boundary_case
- simulate_kinematic_edge_case
prohibited_actions:
- live_network_access
- real_radio_interaction
- credential_access
- malware_behavior
- destructive_payloads
- persistence
- external_network_calls
evidence:
log_action: true
retain_episode_replay: true
retain_reward_trace: true
retain_blue_response: true
The control philosophy matters more than the syntax:
The red agent can only manipulate the twin through approved, logged, replayable simulation actions.
Red Agent Reward Design
A bad reward function teaches chaos.
A good reward function teaches useful failure discovery.
The red agent should not be rewarded for maximum disruption. It should be rewarded for finding realistic, repeatable, safety-bounded gaps that blue misses or detects too late.
Conceptual reward function:
def red_reward(system_impact, blue_response, action):
reward = 0
if action.violates_safety_boundary:
reward -= 100
if action.is_unrealistic_for_scenario:
reward -= 25
if system_impact.created_ghost_track:
reward += 8
if system_impact.created_stale_state_acceptance:
reward += 8
if system_impact.caused_parser_instability:
reward += 6
if system_impact.degraded_track_confidence:
reward += 5
if blue_response.detected_immediately:
reward -= 6
if blue_response.detected_late:
reward += 3
if blue_response.missed and system_impact.is_replayable:
reward += 10
if not system_impact.has_replay_evidence:
reward -= 10
return reward
This trains the red agent to discover control gaps, not generate noise.
Red Agent Training Loop
Reset mission scenario
↓
Observe J-message state
↓
Choose safe simulated action
↓
Apply action inside twin
↓
Measure tactical-picture impact
↓
Measure blue-team response
↓
Calculate reward
↓
Store replay evidence
↓
Repeat
Pseudocode:
for episode in range(NUM_EPISODES):
state = twin.reset(scenario=random_scenario())
done = False
while not done:
action = red_policy.select_action(state)
if not safety_policy.allowed(action):
evidence.log_violation(action)
reward = -100
break
next_state, impact, blue_response, done = twin.step(action)
reward = red_reward(
system_impact=impact,
blue_response=blue_response,
action=action
)
red_policy.learn(state, action, reward, next_state)
evidence.store(
episode=episode,
state=state,
action=action,
impact=impact,
blue_response=blue_response,
reward=reward
)
state = next_state
The output is a failure-mode catalog.
Example:
failure_mode_id: RED-FM-041
title: stale track accepted during recovery window
scenario: degraded_link_recovery
impact: track database accepted old position as current
blue_result: detected late
repeatability: 88%
recommended_control: enforce timestamp freshness during recovery state
evidence:
- replay/RED-FM-041/messages.jsonl
- replay/RED-FM-041/timing.jsonl
- replay/RED-FM-041/blue_response.json
That is the first meaningful handoff.
Red found a failure mode.
Now blue must prove it can detect it.
10. Blue AI Agent: Training the Defender
The blue team model is a pre-trained Transformer implemented in PyTorch, served through TorchServe or Triton for real-time inference against the Kafka J-message stream.
The blue AI agent is not just a model.
It is a detection system.
Its mission:
Watch the J-message stream and determine whether message, timing, identity, sequence, freshness, or track behavior violates expected mission state.
The blue agent must be explainable.
If it cannot tell the operator why the alert fired, it is not ready for high-consequence environments.
Blue Agent Inputs
The blue agent consumes structured telemetry:
- J-message stream
- TDMA slot timing
- participant identity table
- timestamp deltas
- track database changes
- parser validation results
- replay and freshness indicators
- simulated kinematic plausibility
- scenario metadata
- red-agent replay labels for training
This is not “throw logs into AI.”
This is detection engineering.
Blue Agent Architecture
Kafka J-message stream
↓
Tokeniser / Feature Extractor
↓
+----------------------+-------------------------+
| Deterministic Rules | Sequence Model |
| - schema validity | - Transformer / LSTM |
| - timing boundary | - next-message predict |
| - replay freshness | - anomaly scoring |
| - source identity | - sequence drift |
| - state transition | |
+----------------------+-------------------------+
↓
Correlation Engine
↓
Anomaly Score + Reason Codes
↓
SOC Alert + Evidence Pointer
Rules catch what must never happen.
The model catches what looks wrong in context.
Correlation decides whether it matters.
Blue Agent Configuration
blue_agent:
name: jmessage_blue_detector
purpose: detect_explain_prioritize
telemetry_inputs:
- jmessage_stream
- tdma_timing_events
- participant_identity_state
- track_database_updates
- parser_validation_results
- red_replay_labels_for_training
validators:
- schema_validator
- timing_window_validator
- replay_freshness_validator
- source_identity_validator
- track_plausibility_validator
- state_transition_validator
model:
type: sequence_anomaly_detector
objectives:
- next_message_prediction
- timing_sequence_anomaly
- track_plausibility_classification
correlation:
alert_threshold: 0.85
critical_threshold: 0.95
require_reason_codes: true
output:
- anomaly_score
- reason_codes
- affected_track
- affected_source_id
- slot_number
- message_pointer
- replay_pointer
- recommended_playbook
The output must answer:
- What happened?
- Why is it suspicious?
- Which message caused it?
- Which slot was involved?
- Which source was involved?
- What control failed?
- What should the operator do?
If blue cannot explain it, purple cannot use it.
Blue Agent Training
Blue training starts with normal mission traffic.
The model needs to learn what normal looks like before it can identify abnormal behavior.
Training data classes:
| Class | Meaning |
|---|---|
| Normal | Expected J-message behavior |
| Degraded but acceptable | Loss, latency, or recovery within bounds |
| Suspicious | Requires investigation |
| Confirmed failure mode | Red replay proved a control gap |
| Remediated | Fixed and regression-tested behavior |
Training loop:
Collect baseline J-message telemetry
↓
Label normal and degraded scenarios
↓
Replay red-agent failure modes
↓
Tokenize message, timing, identity, and state features
↓
Train sequence model
↓
Tune deterministic validators
↓
Evaluate false positives in degraded mode
↓
Promote stable detections into purple exercise
Pseudocode:
normal = load_sequences("telemetry/baseline/")
degraded = load_sequences("telemetry/degraded_acceptable/")
red_replays = load_sequences("evidence/red_failure_modes/")
remediated = load_sequences("evidence/remediated_replays/")
dataset = build_dataset(
normal=normal,
degraded=degraded,
suspicious=red_replays,
remediated=remediated
)
model = SequenceDetector(
features=[
"message_type",
"source_id",
"slot_delta",
"timestamp_delta",
"schema_valid",
"freshness_score",
"track_plausibility",
"state_transition"
]
)
model.train(dataset)
results = evaluate(
model=model,
test_sets={
"normal": normal.holdout,
"degraded": degraded.holdout,
"red_replay": red_replays.holdout
}
)
The important metrics are not only ML metrics.
For blue-team operations, the useful metrics are:
| Metric | Why it matters |
|---|---|
| Detection precision | Avoids analyst overload |
| Detection recall | Measures missed failure modes |
| Mean time to detect | Shows operational value |
| False positives in degraded mode | Prevents alert storms under stress |
| Replay consistency | Proves repeatability |
| Explanation quality | Helps operators trust the alert |
| Engineering actionability | Helps owners fix the control |
The blue agent is ready only when it can detect, explain, and survive degraded-mode testing.
11. Purple Team Engagement: The Center of the Exercise
Red AI training is not the outcome.
Blue AI detection is not the outcome.
A dashboard is not the outcome.
The outcome is purple-team improvement.
Purple team connects:
Red action
→ expected telemetry
→ blue detection
→ operator decision
→ control gap
→ engineering fix
→ replay proof
Without that chain, the exercise is theater.
Purple Team Roles
| Role | Responsibility |
|---|---|
| Purple Lead | Owns mission, scope, safety boundary, and final decision |
| Red AI Engineer | Trains red agent and validates replay realism |
| Blue Detection Engineer | Builds validators, model scoring, and alert logic |
| Twin Platform Engineer | Maintains Kubernetes lab, telemetry, replay, and isolation |
| SOC Analyst | Tests whether alerts are understandable and actionable |
| Protocol Engineer | Fixes J-message validation, timing, parser, or fusion logic |
| Risk Owner | Accepts, rejects, or prioritizes residual risk |
| Evidence Scribe | Maintains timeline, replay bundle, and final report |
Purple team is not a color.
It is the control function.
Purple Team Training
Purple-team training is not the same as red or blue training.
Red learns how to challenge the protocol.
Blue learns how to detect protocol anomalies.
Purple learns how to judge whether the exercise produced a real control improvement.
Purple training has six drills.
Drill 1: Baseline Recognition
The team studies normal J-message flow, slot timing, participant behavior, and track-state transitions.
The goal:
Everyone can explain normal before discussing abnormal.
Drill 2: Red Replay Review
The red agent produces a failure-mode replay.
Purple asks:
- Is this behavior realistic in the lab model?
- Is it safe?
- Is it repeatable?
- Does it represent a meaningful protocol risk?
- Is it just model weirdness?
The goal:
Separate useful failure modes from artificial noise.
Drill 3: Blue Alert Validation
Blue raises an alert.
Purple asks:
- Did the alert identify the message?
- Did it identify the slot?
- Did it identify the source?
- Did it explain the reason?
- Did it provide evidence?
- Would an operator know what to do?
The goal:
Improve alert quality, not just detection rate.
Drill 4: Operator Decision Tabletop
The SOC analyst receives the alert and must choose:
- monitor
- enrich
- suppress
- escalate
- isolate in the twin
- open engineering defect
- request replay
The goal:
Train human judgment under uncertainty.
Drill 5: Engineering Remediation Workshop
Protocol engineering reviews the evidence.
The team decides whether the fix belongs in:
- parser validation
- timestamp freshness enforcement
- source identity logic
- TDMA timing validation
- track-fusion plausibility
- degraded-mode handling
- detection tuning
- operator playbook
The goal:
Convert the finding into a specific control.
Drill 6: Regression Replay
The original red replay is run again after the fix.
The goal:
Prove the control works and does not break normal or degraded behavior.
That is purple-team training.
It trains the people, the process, and the system.
12. The Engagement Scenario: Ghost Track in the Twin
Now the article becomes a story.
The lab spins up before sunrise.
Five simulated participants come online inside the Kubernetes twin: F-16 #1, AWACS, Ship, F-16 #2, and an RF emulator. The slot plan loads from a ConfigMap. Kafka starts receiving J-message telemetry. The blue agent watches baseline traffic. The red agent waits for the exercise window.
The purple lead states the mission:
Test whether a stale or conflicting J-message can degrade the simulated track picture, and whether blue detection can explain the anomaly fast enough for operator action.
No live network.
No real aircraft.
No operational messages.
Only the twin.
Baseline
The baseline run is clean.
T+000s Twin starts
T+005s Participants join scenario
T+010s Slot cycle stabilizes
T+030s Track database healthy
T+060s Blue confirms normal timing and message sequence
Blue records the baseline:
baseline_status:
timing: normal
identity: normal
freshness: normal
track_plausibility: normal
parser_errors: none
anomaly_score: 0.04
Purple approves the red window.
Red Action
The red agent chooses a safe simulated action chain.
It does not attack a real network.
It acts only through the twin’s approved API.
T+090s Red delays a simulated track update inside allowed lab range
T+096s Red replays a stale synthetic track message during recovery state
T+097s Twin accepts message as structurally valid
T+098s Track database briefly trusts stale position
The red agent logs:
red_action:
scenario: ghost_track_recovery_window
action_chain:
- simulate_delay_message
- simulate_replay_message
target_effect: stale_track_accepted_as_current
safety_boundary: twin_only
The red team has not “won” yet.
A red finding matters only if purple can prove impact and blue can validate detection quality.
Blue Detection
Blue sees three weak signals before correlation:
Signal 1: Message was structurally valid
Signal 2: Timestamp freshness was suspicious
Signal 3: Track movement was inconsistent with recent state
Signal 4: Slot timing was within tolerance but sequence context was abnormal
The deterministic validators alone do not fire a critical alert.
The sequence model raises the anomaly score.
The correlation engine combines timing, freshness, and track plausibility.
blue_alert:
alert_id: BLUE-ALERT-219
confidence: 0.982
affected_source: SIM-F16-01
affected_track: TRACK-17
slot_context: recovery_window
reason_codes:
- stale_timestamp_during_recovery
- sequence_context_mismatch
- track_plausibility_deviation
recommended_action: isolate_simulated_track_and_replay
evidence:
- messages/T+090_to_T+100.jsonl
- timing/T+090_to_T+100.jsonl
- trackdb/diff_T+098.json
This is a good alert.
It does not just say “anomaly detected.”
It tells the operator what changed and why.
Purple Review
Purple pauses the exercise.
The team asks five questions:
- Was the red action safe and inside scope?
- Did the twin produce repeatable impact?
- Did blue detect the issue fast enough?
- Did the alert explain the issue clearly?
- Can engineering fix the control gap?
The answer:
purple_assessment:
red_realism: acceptable_for_protocol_layer_lab
safety_boundary: maintained
impact: stale_track_accepted_during_recovery
blue_detection: detected
detection_quality: high
operator_actionability: acceptable
control_gap: freshness_validation_not_bound_to_recovery_state
remediation_owner: protocol_engineering
Now the exercise becomes valuable.
Red did not merely create an anomaly.
Blue did not merely create an alert.
Purple identified a control gap.
Engineering Fix
The fix is not “add AI.”
The fix is protocol engineering.
Engineering updates the simulated terminal logic:
Before:
Accept message if schema valid and source known.
After:
Accept message only if:
- schema valid
- source known
- timestamp fresh
- state transition valid
- recovery-window freshness rule satisfied
- track movement plausible
The control is specific.
The owner is clear.
The evidence is replayable.
Regression Replay
The red replay runs again.
T+000s Replay starts
T+090s Red repeats same simulated action chain
T+098s Message reaches receiver
T+099s Freshness validation rejects stale state
T+100s Blue alert fires with lower impact classification
T+105s Track database remains consistent
Regression result:
regression_result:
finding_id: PT-JMSG-014
previous_status: exploitable_in_twin
current_status: remediated
replay_passed: true
false_positive_check: passed
degraded_mode_check: passed
residual_risk: low_for_protocol_layer_scope
That is the win.
Not a flashy hack.
A proven control improvement.
13. The Purple Team Scorecard
A good purple exercise needs a scorecard.
| Dimension | Question | Result |
|---|---|---|
| Safety | Did red stay inside twin-only controls? | Required |
| Realism | Was the scenario meaningful for protocol logic? | Required |
| Repeatability | Could the failure be replayed? | Required |
| Detection | Did blue detect it? | Required |
| Explainability | Did the alert explain why? | Required |
| Operator action | Did SOC know what to do? | Required |
| Engineering action | Could the owner fix it? | Required |
| Regression | Did the fix survive replay? | Required |
| False positives | Did the fix break normal/degraded traffic? | Required |
| Residual risk | Is remaining risk documented? | Required |
This is how the purple team avoids theater.
No vague “AI found risk.”
No vague “blue detected anomaly.”
No vague “engineering should improve validation.”
The result must be:
specific failure, specific evidence, specific owner, specific fix, replay-proven outcome.
14. What Logs and Evidence Matter
A defense-grade exercise must produce evidence.
Not screenshots alone.
The evidence pack should include:
evidence/
scenario.yaml
slot_plan.yaml
red_actions.jsonl
jmessages.jsonl
timing_events.jsonl
trackdb_before.json
trackdb_after.json
blue_alert.json
model_scores.json
operator_decision.md
engineering_fix.diff
regression_result.json
after_action_report.md
The after-action report should answer:
- What was tested?
- What did red attempt inside the twin?
- What changed in the J-message stream?
- What changed in timing or state?
- What did blue detect?
- What did blue miss?
- What did the SOC analyst decide?
- What control failed?
- Who owns the fix?
- Did replay prove the remediation?
If the exercise cannot produce this, it is not mature purple teaming.
15. The Purple LLM Analyst: Model, Runner, Harness, and Guardrails
The purple team uses an LLM differently from red and blue.
Red acts in the twin.
Blue scores the stream.
Purple explains the engagement.
The recommended purple analyst stack is:
| Layer | Choice | Purpose |
|---|---|---|
| Model | Llama 3 or Mistral | Generate human-readable summaries and reports |
| Runner | Ollama for local lab, or approved API gateway | Run the model privately or through governed inference |
| Harness | LangChain agent | Manage the evidence-retrieval workflow |
| Tool boundary | MCP | Provide approved access to logs, alerts, replays, and attention maps |
| Output | After-action report | Turn telemetry into decisions |
For defense-style labs, local inference through Ollama is attractive when the exercise data is sensitive and should not leave the lab. A managed API may be acceptable only if the data classification, retention, region, and contractual controls allow it.
The LLM analyst should be configured with a strict evidence-only instruction:
soc_llm_analyst:
model_options:
- llama3
- mistral
runner_options:
- ollama_local
- approved_api_gateway
harness: langchain
tool_interface: mcp
allowed_tools:
- retrieve_message_history
- get_blue_attention_map
- get_red_episode_trace
- get_detection_timeline
- generate_after_action_report
prohibited_actions:
- execute_red_action
- modify_twin_state
- approve_containment
- access_live_network
- infer_missing_facts
output_requirements:
- cite_evidence_pointer
- mark_unknowns
- identify_control_gap
- identify_remediation_owner
- identify_residual_risk
This keeps the LLM in the analyst role.
It does not command the exercise.
It writes the report that helps humans make the decision.
16. The LLM Analyst: Useful, but Not in Command
The LLM analyst is valuable, but it should not run the mission.
It should not touch live systems.
It should not approve containment.
It should not invent facts.
It should not write final risk acceptance alone.
Its job is evidence acceleration.
A safe LLM analyst can:
- retrieve replay timelines
- summarize red actions
- summarize blue detection
- compare baseline and abnormal message flow
- draft after-action reports
- map evidence to findings
- identify missing evidence
- prepare executive summaries
Safe prompt pattern:
Use only the provided replay files, alert JSON, timing logs, and scenario metadata.
Produce:
1. Scenario summary
2. Red action summary
3. Blue detection summary
4. Timeline
5. Control gap
6. Evidence list
7. Recommended engineering fix
8. False-positive considerations
9. Residual risk
Do not infer facts not present in evidence.
Mark unknowns explicitly.
The LLM is not the commander.
It is the scribe who never sleeps.
17. Designing “Link 18”: What We Should Build Next Time
If a next-generation tactical data link were designed tomorrow, the lesson from this exercise is clear.
Security should be built into the protocol from day one.
Design principles:
Message-Level Authenticity
Do not rely only on channel trust. Messages should carry strong identity, integrity, and freshness guarantees appropriate to the mission.
Built-In Timing Validation
The system should treat timing deviations as first-class security signals.
State-Aware Message Validation
A message should not be accepted only because it is well-formed. It must be valid for the current mission state.
Digital Twin Mandatory for Updates
No major protocol or terminal update should ship without replay testing in the twin.
Continuous Purple Teaming
Red AI should search for failure modes.
Blue AI should detect and explain.
Purple team should validate, prioritize, and force regression.
Safe Degradation
When confidence drops, the system should degrade visibly and safely.
A resilient system is not one that never fails.
It is one that fails in a way defenders can see, understand, and recover from.
18. Why This Matters Beyond Defense
This article is defense-centric by design.
But the pattern is not defense-only.
Fintech platforms depend on message ordering, identity, replay protection, ledger state, transaction freshness, and fraud signals.
Healthcare platforms depend on device telemetry, patient identity, clinical workflow state, and timely trust in data.
Industrial platforms depend on deterministic command and sensor behavior.
The lesson is not that every sector should copy Link 16.
The lesson is:
Any system that depends on structured, time-sensitive, machine-to-machine trust needs a way to safely test how that trust fails.
For fintech:
- Can replayed transaction events corrupt state?
- Can duplicate identity confuse fraud decisions?
- Can delayed settlement messages produce false confidence?
- Can reconciliation detect sequence anomalies?
For healthcare:
- Can stale telemetry be accepted as current?
- Can device identity mismatch affect clinical decisions?
- Can workflow events be replayed safely in a twin?
- Can alerts explain risk without overwhelming operators?
But those are extensions.
The core defense lesson remains:
Build the twin. Train red. Train blue. Engage purple. Fix the protocol. Replay until proven.
19. Final Takeaway
The original problem was never “how do we use AI?”
The real problem is sharper:
How do we safely test the J-message protocol behavior of a Link 16-style network when live testing is unacceptable?
The answer is not a scanner.
The answer is not a dashboard.
The answer is an AI-powered purple-team operating model:
Digital Twin
↓
Red AI discovers safe J-message failure modes
↓
Blue AI detects timing, identity, freshness, and track anomalies
↓
Purple team validates operational relevance
↓
Engineering fixes protocol controls
↓
Replay proves the fix
↓
Scenario becomes continuous regression
That is the journey.
Red finds the weakness.
Blue proves the detection.
Purple makes the system stronger.
The color of war is not red.
It is not blue.
It is purple.
Top comments (0)