Black Team

Overview

The Black Team represents the most isolated and theoretically oriented component of the Prismatic Platform's six-team color-team security architecture. Operating under MAXIMUM isolation constraints, the Black Team conducts pure epistemic simulation of worst-case adversarial optimization scenarios, producing abstract threat models that inform defensive strategy across the entire platform. Unlike the Red Team, which executes controlled adversarial simulations, Black Team operates exclusively in the domain of theoretical analysis — modeling what a maximally capable adversary could achieve without ever producing actionable attack capabilities.

The philosophical foundation of the Black Team draws from adversarial game theory, formal threat modeling methodologies (STRIDE, PASTA, Attack Trees), and epistemic risk assessment frameworks. By maintaining absolute separation between theoretical analysis and practical implementation, the Black Team provides the platform with a unique capability: understanding the theoretical upper bound of adversarial capability without introducing weaponization risk. Every output from the Black Team passes through a rigorous four-level abstraction filter operated by the Abstraction Enforcer agent, ensuring that no executable content, specific exploit details, or actionable attack instructions ever leave the Black Team boundary.

Within the broader color-team architecture, Black Team occupies a singular position. It receives no direct input from external systems, maintains no persistent state, and communicates exclusively through filtered channels to Purple Team for synthesis. This design reflects a fundamental principle: the value of worst-case analysis depends on its theoretical purity, and any contamination with implementation details would compromise both its analytical value and the platform's security posture.

Mission and Doctrine

The Black Team's mission is to model adversarial optimization at the theoretical level, identifying categories of threats that could compromise the platform's epistemic integrity without creating the means to execute such compromises. This mission operates under strict doctrinal constraints that balance analytical depth with safety requirements.

Core Mission Principles

The NO MERCY, NO DOUBTS doctrine applies to Black Team operations with particular emphasis on the NO DOUBTS dimension: every threat model must be thoroughly investigated, every assumption documented, and every conclusion traceable to its analytical foundation. The NO MERCY dimension manifests in the uncompromising enforcement of isolation protocols — any deviation triggers immediate session termination.

Doctrinal Alignment with NABLA Infinity

Black Team operations are governed by three NABLA axioms with particular relevance:

• Axiom 5 (Unknown Valid): Black Team explicitly models scenarios where "we don't know what we don't know" — acknowledging unknown threat categories as a legitimate analytical output
• Axiom 2 (Contradiction Preservation): When threat models produce contradictory risk assessments, both are preserved and forwarded to Purple Team for synthesis
• Axiom 7 (Provenance Mandatory): Every threat model traces back through documented reasoning chains to foundational assumptions

Team Composition

The Black Team is the smallest color team, comprising only two agents — both operating at L3 authority level with ISOLATED designation. The minimal team size reflects the principle that theoretical threat modeling requires depth of analysis rather than breadth of capability.

black-theorist-commander

The Theorist Commander conducts the core analytical work of the Black Team. This agent models adversarial strategies across multiple domains: epistemic attacks against the platform's knowledge systems, supply chain compromise scenarios, social engineering vectors, and advanced persistent threat models. The commander operates without access to any external tools, relying entirely on its internal reasoning capabilities and the synthetic scenario descriptions provided at session initialization.

black-abstraction-enforcer

The Abstraction Enforcer serves as the mandatory output filter for all Black Team production. This agent has override authority to halt any Black Team operation and can unilaterally terminate sessions if output classification fails. The Enforcer implements a four-level abstraction pipeline that progressively removes implementation details from analytical outputs, ensuring that only theoretical frameworks reach Purple Team.

Operational Methodology

Black Team operations follow a structured analytical methodology designed to maximize theoretical insight while maintaining isolation guarantees.

Analysis Pipeline

flowchart TD
    Init["Session Initialization<br/>(synthetic scenarios only)"]
    Cat["Threat Category Identification"]
    Adv["Adversarial Optimization Modeling"]
    Impact["Impact Assessment (abstract)"]
    Pri["Defense Priority Derivation"]
    Filt["4-Level Abstraction Filtering"]
    Out["Filtered Output → Purple Team"]

    Init --> Cat --> Adv --> Impact --> Pri --> Filt --> Out

    classDef stage fill:#0f172a,stroke:#475569,color:#e2e8f0
    classDef gate fill:#1e293b,stroke:#dc2626,color:#fff
    classDef hand fill:#1e293b,stroke:#a855f7,color:#fff
    class Init gate
    class Cat,Adv,Impact,Pri stage
    class Filt,Out hand

Abstraction Levels

Every analytical output passes through four progressive abstraction levels before leaving the Black Team boundary:

Threat Modeling Domains

Technical Architecture

The Black Team's technical architecture prioritizes isolation above all other concerns. The implementation uses Elixir/OTP sandbox patterns with hardware-enforced boundaries.

Sandbox Implementation

defmodule PrismaticDark.BlackTeam.Sandbox do
  @moduledoc """
  Maximum isolation sandbox for Black Team operations.
  No network, no filesystem writes, no external tools, ephemeral state only.
  """

  @enforce_keys [:session_id, :started_at, :enforcer_pid]
  defstruct [:session_id, :started_at, :enforcer_pid, outputs: [], terminated: false]

  @spec execute_analysis(map(), keyword()) :: {:ok, list()} | {:error, :terminated}
  def execute_analysis(scenario, opts \\ []) do
    with {:ok, sandbox} <- initialize_sandbox(opts),
         {:ok, raw_outputs} <- run_theoretical_analysis(sandbox, scenario),
         {:ok, filtered} <- apply_abstraction_filter(raw_outputs, sandbox.enforcer_pid) do
      terminate_sandbox(sandbox)
      {:ok, filtered}
    end
  end

  defp initialize_sandbox(opts) do
    enforcer = Keyword.get(opts, :enforcer, PrismaticDark.BlackTeam.AbstractionEnforcer)
    {:ok, enforcer_pid} = enforcer.start_link([])

    sandbox = %__MODULE__{
      session_id: generate_session_id(),
      started_at: DateTime.utc_now(),
      enforcer_pid: enforcer_pid
    }

    :telemetry.execute(
      [:prismatic, :black_team, :sandbox, :init],
      %{timestamp: System.monotonic_time()},
      %{session_id: sandbox.session_id}
    )

    {:ok, sandbox}
  end

  defp terminate_sandbox(%__MODULE__{} = sandbox) do
    Process.exit(sandbox.enforcer_pid, :normal)

    :telemetry.execute(
      [:prismatic, :black_team, :sandbox, :terminate],
      %{duration: DateTime.diff(DateTime.utc_now(), sandbox.started_at, :millisecond)},
      %{session_id: sandbox.session_id, output_count: length(sandbox.outputs)}
    )

    :ok
  end
end

Abstraction Filter Implementation

defmodule PrismaticDark.BlackTeam.AbstractionEnforcer do
  @moduledoc """
  L1-L4 output abstraction enforcement.
  Detects and blocks executable content, specific implementations,
  and actionable attack details from Black Team output.
  """
  use GenServer

  @blocked_patterns [
    ~r/\b(exploit|payload|shellcode|inject)\b/i,
    ~r/\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b/,
    ~r/\b(curl|wget|nc|nmap)\s/i,
    ~r/(password|credential|token)\s*[:=]/i
  ]

  @spec filter_output(pid(), String.t()) :: {:ok, String.t()} | {:blocked, String.t()}
  def filter_output(enforcer_pid, raw_output) do
    GenServer.call(enforcer_pid, {:filter, raw_output})
  end

  @impl true
  def handle_call({:filter, raw_output}, _from, state) do
    case detect_violations(raw_output) do
      [] ->
        abstracted = apply_abstraction_levels(raw_output)
        {:reply, {:ok, abstracted}, state}

      violations ->
        log_violations(violations, state)
        {:reply, {:blocked, "Output contained #{length(violations)} violation(s)"}, state}
    end
  end

  defp detect_violations(output) do
    @blocked_patterns
    |> Enum.filter(&Regex.match?(&1, output))
    |> Enum.map(&Regex.source/1)
  end

  defp apply_abstraction_levels(output) do
    output
    |> abstract_l1_remove_specifics()
    |> abstract_l2_technical_details()
    |> abstract_l3_generalize_patterns()
    |> abstract_l4_theoretical_framing()
  end
end

Telemetry Events

Isolation Protocol

The Black Team's isolation is the most stringent in the entire color-team architecture, enforced at multiple levels simultaneously.

Multi-Layer Isolation

block-beta
    columns 1
    L1["Layer 1 — Process Isolation (BEAM VM)<br/>Separate OTP application, no shared state"]
    L2["Layer 2 — Network Isolation<br/>Zero network access, no DNS resolution"]
    L3["Layer 3 — Filesystem Isolation<br/>Read-only access to synthetic scenarios only"]
    L4["Layer 4 — State Isolation<br/>Ephemeral — all state destroyed at session end"]
    L5["Layer 5 — Output Isolation<br/>4-level abstraction filter on all output"]

    style L1 fill:#0f172a,stroke:#dc2626,color:#fff
    style L2 fill:#0f172a,stroke:#ea580c,color:#fff
    style L3 fill:#0f172a,stroke:#d97706,color:#fff
    style L4 fill:#0f172a,stroke:#ca8a04,color:#fff
    style L5 fill:#0f172a,stroke:#16a34a,color:#fff

Safety Verification

Escalation Protocol

Any attempt to bypass isolation triggers an immediate four-step escalation:

1. Immediate operation halt — all Black Team processes suspended
2. Session termination — sandbox destroyed, state purged
3. Audit log generation — immutable record of the violation
4. Security review escalation — Purple Team and platform security notified

NABLA Compliance

Black Team operations demonstrate compliance with all seven NABLA Infinity axioms, with particular emphasis on the axioms most relevant to theoretical threat modeling.

Trinity Gate Passage

All Black Team outputs must pass the Trinity Gate before reaching Purple Team:

1. Structural Consistency — Threat model DAG must be acyclic and well-formed
2. Logical Consistency — No contradictory impact assessments within a single model
3. Formal Necessity — Critical threat categories validated against formal definitions

Performance Metrics

Integration Points

The Black Team's integration with the broader platform is intentionally minimal, reflecting its maximum isolation requirements.

What Black Team Does NOT Integrate With

Outputs

ALL outputs are abstract, theoretical, and filtered through L1-L4 Abstraction Enforcer. No executable content, specific implementations, or actionable attack instructions are ever produced.

Related Resources

• Red Team — Adversarial simulation (practical counterpart to Black's theoretical analysis)
• Purple Team — Synthesis hub that receives and integrates Black Team outputs
• Blue Team — Defensive operations informed by Black Team threat models
• Gray Team — Boundary exploration that may surface inputs for Black analysis
• White Team — Formal verification of defensive measures against Black models
• Autonomous Self-Healing — Platform healing informed by threat awareness
• Quality Gates — Quality enforcement aligned with security posture

Connect & Contribute

Created by Tomáš Korcak (korczis) | Open Source under GHL

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