Definition

The Blue Team is a defensive Color Team composed of 4 specialized agents focused on epistemic defense through evidence synthesis. In traditional cybersecurity, a blue team defends networks against attacks. In the Prismatic Platform, the Blue Team defends the epistemic integrity of the platform's knowledge systems -- ensuring that beliefs are well-evidenced, signals are not corrupted, and the platform's reasoning has not drifted from its validated baseline.

The fundamental distinction between Prismatic's Blue Team and conventional blue teams is the output type. A conventional blue team produces alerts: "suspicious login detected," "malware signature found," "anomalous traffic observed." Prismatic's Blue Team produces structured evidence: documented observations with provenance, confidence levels, signal plurality compliance, and explicit uncertainty quantification. Alerts are ephemeral and actionable; evidence is persistent and analyzable.

This shift from alerts to evidence reflects the platform's NABLA Infinity axiom framework. An alert that says "drift detected" is a single signal that may or may not warrant action. A structured evidence artifact that documents the drift, provides multiple independent measurements, preserves contradictory observations, and traces its reasoning back to raw telemetry data is a knowledge claim that can be verified, disputed, refined, and synthesized with other evidence through the Purple Team.

The 4 Blue Team Agents

The Blue Team operates under the command of a single L3 Strategic Commander with three L2 Operational Specialists. Each agent has a distinct domain responsibility, and together they provide comprehensive defensive coverage across the platform.

blue-commander (L3 Strategic Commander)

The blue-commander orchestrates all Blue Team operations. It synthesizes evidence from the three specialists into a unified defensive posture assessment, prioritizes investigation targets, and routes evidence to the Purple Team for synthesis with Red Team adversarial findings.

Attribute	Value
Classification	L3 Strategic Commander
Authority	Full Blue Team coordination, evidence synthesis, Purple Team reporting
Inputs	Specialist evidence reports, Red Team findings (via Purple), platform telemetry
Outputs	Unified defensive posture, investigation directives, evidence packages for Purple
NABLA Compliance	Enforces all 7 axioms across all Blue evidence outputs

The blue-commander's primary output is the Defensive Posture Assessment -- a structured document that represents the Blue Team's current understanding of the platform's epistemic health. This assessment includes:

Current belief integrity status across all domains
Active drift trends (improving, stable, or degrading)
Open contradictions that require Purple Team synthesis
Confidence levels for all defensive conclusions
Evidence gaps where additional investigation is needed

blue-auth-sentinel (L2 Operational Specialist)

The blue-auth-sentinel monitors authentication and authorization boundaries across the platform. It detects privilege escalation attempts, unauthorized access patterns, and authentication bypass conditions.

Attribute	Value
Classification	L2 Operational Specialist
Authority	Authentication boundary monitoring, read-only platform access
Focus Areas	Login patterns, token validation, RBAC enforcement, session integrity
Detection Methods	Behavioral analysis, threshold monitoring, pattern matching
Output Format	Evidence artifacts with access log provenance

The auth-sentinel operates at the boundary between external users and internal platform state. It monitors:

Authentication attempts: Patterns of failed logins, credential stuffing indicators, brute-force detection
Authorization boundaries: Requests that test RBAC limits, privilege escalation sequences, role confusion attempts
Token integrity: JWT validation failures, token reuse detection, session fixation indicators
API boundary: REST API access patterns, rate limiting triggers, OpenAPI schema violation attempts

blue-drift-detector (L2 Operational Specialist)

The blue-drift-detector is the Blue Team's most broadly scoped specialist. It monitors four dimensions of drift across all 90+ umbrella applications, detecting gradual changes that individually fall below alert thresholds but collectively indicate systemic degradation.

Drift Dimension	What It Monitors	Detection Method	Alert Condition
Behavioral	Function call patterns, execution paths, output distributions	Statistical comparison against baseline	Distribution shift > 2 standard deviations
Configuration	Application config, environment variables, feature flags	Diff against committed configuration	Any unauthorized or undocumented change
Dependency	Library versions, external API contracts, data schemas	Version tracking, contract testing	Breaking changes, security advisories
Performance	Response latency, throughput, resource utilization	Time-series analysis with seasonal adjustment	Sustained deviation > 20% from baseline

The drift-detector's critical contribution is detecting sub-threshold drift: changes that are individually too small to trigger conventional alerts but accumulate over time into significant degradation. This is analogous to the "boiling frog" problem in physical systems -- gradual temperature increases that never trigger a discrete alarm but eventually become lethal.

defmodule PrismaticSecurity.BlueDriftDetector do
  @moduledoc """
  Detects gradual drift across behavioral, configuration,
  dependency, and performance dimensions.
  Produces NABLA-compliant evidence artifacts.
  """

  @drift_dimensions [:behavioral, :configuration, :dependency, :performance]

  @spec detect_drift(app_id(), baseline(), current_state()) ::
          {:ok, [drift_evidence()]} | {:ok, :no_drift}
  def detect_drift(app_id, baseline, current) do
    drift_findings =
      @drift_dimensions
      |> Enum.flat_map(fn dimension ->
        case compare_dimension(dimension, baseline, current) do
          {:drift, evidence} -> [build_evidence(app_id, dimension, evidence)]
          :stable -> []
        end
      end)

    case drift_findings do
      [] -> {:ok, :no_drift}
      findings -> {:ok, findings}
    end
  end

  defp build_evidence(app_id, dimension, raw_evidence) do
    %{
      type: :drift_detection,
      app: app_id,
      dimension: dimension,
      magnitude: raw_evidence.magnitude,
      confidence: compute_confidence(raw_evidence),
      provenance: %{
        detector: "blue-drift-detector",
        baseline_timestamp: raw_evidence.baseline_timestamp,
        current_timestamp: DateTime.utc_now(),
        method: raw_evidence.detection_method,
        raw_data_hash: hash_evidence(raw_evidence)
      },
      signal_count: raw_evidence.signal_count,
      contradictions: raw_evidence.contradictions
    }
  end
end

blue-signal-aggregator (L2 Operational Specialist)

The blue-signal-aggregator correlates signals across domains, enforcing signal plurality (minimum 2 independent signals per belief) and producing synthesized evidence from multiple sources. This agent is the Blue Team's primary interface with the NABLA Infinity axiom framework.

Attribute	Value
Classification	L2 Operational Specialist
Authority	Cross-domain signal correlation, read-only access to all domain telemetry
Primary Function	Enforce signal plurality, correlate independent signals, produce synthesized evidence
NABLA Axioms	Primary enforcer of Signal Plurality and Source Independence
Output	Correlated signal packages with plurality certification

The signal-aggregator answers a critical question for every Blue Team finding: Is this observation supported by at least two independent sources? A single anomalous measurement could be sensor noise. Two independent measurements of the same anomaly from different sources is signal.

Signal independence tracking requires understanding source correlation:

Source Combination	Independence	Rationale
Shodan scan + Censys scan	High	Different scanning infrastructure, different methodologies
Two Shodan scans	Low	Same infrastructure, same methodology, different times
Port scan + Service banner	Medium	Same target, different observation types
Telemetry metric + Log entry	High	Different collection systems, different data types

Defensive Posture Assessment

The Blue Team's primary deliverable is the Defensive Posture Assessment (DPA), a structured evidence document that represents the current state of the platform's epistemic defenses. The DPA is not a dashboard or a metric -- it is a formal evidence artifact that passes through Trinity Gate validation.

The DPA structure:

Section	Content	Confidence Requirement
Integrity Status	Current belief graph health, axiom compliance rates	>= 0.90
Active Drift Trends	Per-dimension drift analysis across all applications	>= 0.80
Open Contradictions	Unresolved contradictory evidence requiring synthesis	N/A (contradictions are preserved, not resolved)
Evidence Gaps	Areas where signal plurality is not met	N/A (gaps are documented, not filled)
Threat Posture	Assessment incorporating Red Team findings	>= 0.85
Recommendations	Prioritized actions to strengthen defenses	>= 0.80

The DPA is produced on a regular cadence and on-demand when triggered by significant events (Red Team findings, Purple Team closure failures, platform upgrades). Each DPA is versioned, timestamped, and stored with full provenance, enabling trend analysis over time.

NABLA Axiom Grounding

The Blue Team's evidence production is fundamentally grounded in NABLA Infinity axioms. This grounding is not optional -- it is structurally enforced through the evidence data model:

Axiom	Blue Team Application	Enforcement
Signal Plurality	Every finding requires 2+ independent signals. Signal-aggregator certifies plurality.	HARD -- single-signal findings are quarantined, not published
Contradiction Preservation	When one detector finds drift and another finds stability, both observations are preserved	HARD -- contradictions annotated with severity and routed to Purple
Absence Informative	Expected signals that are missing are tracked. A service that should emit telemetry but does not is itself a finding	SOFT -- absence logged, investigation triggered
Time Decay	Evidence older than the configured staleness threshold receives reduced weight	HARD -- stale evidence decays toward neutral confidence
Unknown Valid	When evidence is insufficient for a determination, the Blue Team reports "unknown" rather than guessing	HARD -- forced determinations are forbidden
Source Independence	Signal-aggregator tracks source correlation and discounts correlated observations	SOFT -- correlated sources flagged, independence assessment included
Provenance Mandatory	Every evidence artifact traces back to raw telemetry through documented processing steps	HARD -- unprovenanced evidence rejected

Evidence Synthesis vs. Alert Generation

The distinction between evidence synthesis and alert generation is central to understanding the Blue Team's role:

Dimension	Alert-Based Defense	Evidence-Based Defense (Blue Team)
Output	"Anomaly detected at 14:32"	Structured evidence artifact with provenance chain
Confidence	Binary (alert or no alert)	Continuous (0.0-1.0 with uncertainty quantification)
Contradiction Handling	Alerts may contradict each other with no resolution	Contradictions preserved, annotated, and routed to Purple
Actionability	Requires human interpretation	Can be machine-processed by Purple for synthesis
Persistence	Typically ephemeral (alert fires and is acknowledged)	Persistent evidence enters the belief graph
Composability	Individual alerts, difficult to combine	Evidence packages compose into larger assessments
NABLA Compliance	Not applicable	Mandatory -- all evidence satisfies 7 axioms

This approach enables the Purple Team to perform automated synthesis between Blue defensive evidence and Red adversarial findings, closing the adversarial-defensive loop programmatically rather than relying on manual review of alert logs.

Red-Blue Loop Through Purple

The Blue Team does not interact with the Red Team directly. All Red-Blue interaction flows through the Purple Team, which serves as the synthesis hub for the adversarial-defensive loop:

Red Team                    Purple Team                    Blue Team
(adversarial)              (synthesis)                   (defensive)

  Scenarios ──────>  purple-mapper ───────> Defense improvements
  Findings ──────>  purple-closure ────────> Posture adjustments
                         ^                         |
                         |                         v
                   purple-regression ────── Evidence reports
                         |
                         v
                   Closure decision
                   (all 4 conditions)

The Purple Team's closure analysis requires four conditions before a Red-Blue interaction cycle is considered closed:

Attack Reproduced: The Red Team's scenario has been reproduced in the sandbox
Defense Validated: The Blue Team's countermeasure addresses the specific attack vector
Regression Tested: The defense does not introduce new vulnerabilities
Evidence Complete: Both Red and Blue evidence satisfies NABLA axioms

The Blue Team's contribution to this loop is critical: it must produce evidence that is not merely reactive ("we fixed the alert") but structural ("we have verified through 2+ independent signals that the defense is effective, with confidence 0.92, and the evidence chain traces from the original Red Team finding through our defense implementation to the validation measurement").

The Color Teams Ecosystem

The Blue Team operates within a broader ecosystem of 20 agents across 6 Color Teams:

Team	Role	Interaction with Blue
Gray Team	Boundary exploration	Surfaces edge cases that Blue should monitor
Red Team	Adversarial simulation	Produces attack scenarios that Blue defends against
Blue Team	Epistemic defense	--
Purple Team	Synthesis	Closes Red-Blue loop, validates Blue defenses
White Team	Constructive verification	Formally verifies Blue Team evidence and defenses
Black Team	Theoretical threat modeling	Abstract models inform Blue Team threat awareness

The signal flow follows a specific path: Gray surfaces boundary conditions that may become Red scenarios. Red produces adversarial findings. Purple synthesizes Red findings with Blue defensive evidence. White formally verifies the resulting defense claims. Black provides theoretical models that inform both Red attack generation and Blue defense design. Blue receives signals from all other teams (through Purple) and produces evidence that feeds back into the ecosystem.

Safety Protocols

All Blue Team operations are subject to the platform's security safety protocols:

Protocol	Enforcement
Read-Only Operations	Blue agents have read-only access to platform state. They observe and measure but never modify.
Synthetic Data	All Blue Team testing uses synthetic data. No real PII or production data enters Blue Team analysis.
Ethics Checks	Automated validation runs every 10-15 seconds across all Blue agents.
Audit Logging	Every Blue Team operation is logged in an immutable audit trail.
Scope Boundaries	Blue agents cannot escalate to Gray or Red operations. Scope is strictly defensive.

Best Practices

Ground every finding in NABLA axioms. Blue Team evidence must satisfy all seven axioms before publication. Evidence that fails even one hard axiom is quarantined, not published. This discipline prevents the common failure mode where urgency overrides epistemic rigor.
Maintain independent signal sources for every active monitoring dimension. The signal-aggregator requires at least two independent signals per belief. Design monitoring infrastructure so that every critical dimension has at least two independent observation paths -- different collection systems, different methodologies, different observation points.
Preserve contradictions explicitly. When the drift-detector and the auth-sentinel produce contradictory assessments of the same phenomenon, both assessments must be preserved in the Defensive Posture Assessment. The Purple Team handles synthesis; the Blue Team handles preservation.
Emit structured evidence, not alerts. The fundamental output of the Blue Team is structured evidence with provenance, confidence levels, and contradiction annotations. Avoid the temptation to reduce evidence to binary alerts for simplicity -- the structure is what enables machine-processable synthesis.
Monitor for sub-threshold drift. Individual measurements that fall below alert thresholds can accumulate into significant degradation. The drift-detector's primary value is detecting these gradual, individually invisible changes.
Version and timestamp all evidence artifacts. Every evidence artifact must carry its creation timestamp, the baseline it was compared against, and the detector version that produced it. This enables trend analysis and retrospective investigation.
Separate observation from interpretation. Blue Team agents observe and measure; they do not interpret or recommend. Interpretation is the Purple Team's responsibility. This separation ensures that defensive evidence is not biased by premature conclusions.

Common Pitfalls

Alert fatigue from over-sensitive drift detection. Setting drift thresholds too low produces a flood of weak findings that overwhelm analysts and obscure genuine threats. Calibrate thresholds using historical baseline data and adjust based on false positive rates.
Single-source findings masquerading as evidence. A finding based on a single signal source does not meet NABLA's signal plurality requirement. Resist the pressure to publish single-source findings as "preliminary evidence" -- they must be explicitly marked as unvalidated observations.
Conflating Blue Team defense with Red Team offense. Blue agents have read-only access and strictly defensive scope. Any Blue Team operation that modifies system state or simulates attacks has violated its scope boundary and must be immediately halted.
Ignoring temporal dynamics in drift detection. A metric that appears stable when sampled hourly may show significant drift when sampled at minute resolution. Match sampling frequency to the expected drift timescale for each dimension.
Treating the Defensive Posture Assessment as a dashboard metric. The DPA is a formal evidence artifact, not a number on a dashboard. Reducing it to a single score discards the structured information that makes it valuable for Purple Team synthesis.
Neglecting to update baselines. The drift-detector compares current state against a baseline. If the baseline is never updated after legitimate changes, drift detection produces false positives. Implement a controlled baseline update process with audit trail.

Use Cases

Platform Quality Monitoring

The Blue Team monitors the Prismatic Platform's 13 quality domains for drift. When the compilation warning count, Credo violation count, or Dialyzer error count changes, the drift-detector captures the change, the signal-aggregator correlates it with recent code changes, and the blue-commander produces an evidence package for the Quality Floor Guardian.

OSINT Source Reliability Assessment

When OSINT intelligence sources produce conflicting data about the same entity, the Blue Team preserves the contradiction and produces a structured evidence artifact documenting which sources disagree, the confidence levels of each source, and the potential impact on downstream assessments. This evidence feeds into the Prismatic Perimeter security rating calculations.

Authentication Boundary Monitoring

The auth-sentinel monitors authentication patterns across the platform's REST API and LiveView endpoints. When unusual patterns emerge -- spike in failed authentications from a new IP range, unexpected token validation failures, session fixation indicators -- the auth-sentinel produces evidence artifacts that feed into the defensive posture assessment.

Dependency Supply Chain Monitoring

The drift-detector tracks dependency versions across all 115 umbrella applications. When a dependency releases a security advisory, the detector produces evidence documenting which applications are affected, the severity classification, and the OTP supervision tree impact. This evidence enables prioritized remediation.

Red Team -- Adversarial counterpart whose findings Blue Team defends against
Purple Team -- Synthesis hub mediating the Red-Blue adversarial-defensive loop
White Team -- Constructive verification team formally validating Blue defenses
Gray Team -- Boundary exploration team surfacing edge cases for Blue monitoring
Black Team -- Theoretical threat modeling informing Blue defense design
Color Teams -- Full overview of all 6 security teams and their interactions
NABLA Infinity -- Epistemic framework grounding all Blue Team evidence
Signal Plurality -- Core axiom enforced by the signal-aggregator
Contradiction Preservation -- Axiom requiring preservation of conflicting observations
Provenance Mandatory -- Axiom requiring traceable evidence chains
Trinity Gate -- Verification gate that Blue Team evidence must pass
Epistemic Robustness -- Measure of defense resilience to epistemic attack
Confidence Scoring -- Uncertainty quantification for Blue Team evidence
Agent -- Autonomous entities composing the Blue Team

Connect & Contribute

Created by Tomas Korcak (korczis) | Open Source under GHL

GitHub | GitLab | LinkedIn | Contact
Developer Portal | Architecture | Meet the Creator

Blue Team