Gray Team

Overview

The Gray Team operates as the reconnaissance and boundary exploration arm of the Prismatic Platform's six-team color-team security architecture. Positioned at the frontier between defined and undefined system behavior, Gray Team systematically discovers specification gaps, edge cases, implicit assumptions, and affordance drift — surfacing ambiguity without resolving it. This raw intelligence feeds directly into Red Team adversarial scenario development, Blue Team defensive gap awareness, and Purple Team synthesis operations.

The Gray Team's operational philosophy is fundamentally different from the other color teams. While Red attacks, Blue defends, and Purple synthesizes, Gray explores. All Gray operations enforce zero state changes — pure observation and documentation with no writes, no modifications, and no resource allocations. This read-only constraint ensures that exploration never inadvertently introduces the vulnerabilities it seeks to discover. The distinction between Gray's boundary exploration and Black Team's theoretical threat modeling is enforced by the gray-escalation-guard agent, which has override authority to halt any Gray operation that approaches weaponization territory.

The theoretical foundation of Gray Team operations draws from boundary value analysis in software testing, specification gap analysis in formal methods, and affordance theory from human-computer interaction research. By treating system boundaries as first-class objects of investigation rather than assumed constraints, Gray Team provides the platform with continuous visibility into the frontier of its own behavior — the zone where assumptions meet reality and where most vulnerabilities originate.

Mission and Doctrine

The Gray Team mission is to systematically explore and document the boundaries of the platform's defined behavior, identifying areas where specifications are incomplete, assumptions are implicit, edge cases are unhandled, and usage patterns have drifted from design intent.

Mission Principles

The NO MERCY, NO DOUBTS doctrine governs Gray operations with particular emphasis: NO MERCY demands thoroughness in boundary exploration — no specification gap is left undocumented due to inconvenience or perceived low risk. NO DOUBTS requires that every finding is grounded in observable boundary behavior, not speculation about what might be problematic.

Team Composition

The Gray Team comprises three agents with a unique safety-critical architecture: the escalation guard has override authority over the commander, reflecting the principle that safety constraints take precedence over operational objectives.

gray-explorer-commander

The Explorer Commander orchestrates systematic exploration campaigns across the platform's specification boundaries. The commander maintains an exploration map that tracks which boundaries have been investigated, what findings emerged, and which areas require deeper analysis. Campaign planning considers both the coverage requirements (ensuring all boundaries receive periodic attention) and the priority signals from Red and Blue teams about where vulnerabilities are most likely.

gray-edge-finder

The Edge Finder conducts the tactical work of boundary analysis — examining input validation limits, state transition boundaries, error condition behavior, type coercion edge cases, and resource limit boundaries. This agent applies formal boundary value analysis techniques to identify the specific values, states, and conditions where system behavior transitions from defined to undefined.

gray-escalation-guard

The Escalation Guard provides continuous safety monitoring over all Gray operations, with override authority to halt any operation immediately. This agent detects when exploration approaches Black Team territory — when boundary analysis begins to resemble threat modeling, when edge case discovery starts to produce attack vectors, or when specification gaps suggest exploitable vulnerabilities. The guard ensures that Gray findings remain descriptive (documenting what is) rather than prescriptive (suggesting how to exploit).

Operational Methodology

Gray Team follows a structured exploration methodology that systematically covers the platform's specification boundaries while maintaining strict read-only constraints.

Exploration Domains

Boundary Value Analysis Framework

defmodule PrismaticDark.GrayTeam.BoundaryAnalyzer do
  @moduledoc """
  Systematic boundary value analysis for specification gap discovery.
  All operations are read-only — no state modifications permitted.
  """

  @type boundary :: %{
    domain: atom(),
    parameter: String.t(),
    min_value: term(),
    max_value: term(),
    transition_points: [term()],
    undefined_zones: [Range.t()]
  }

  @spec analyze_module(module()) :: {:ok, [boundary()]}
  def analyze_module(target_module) do
    specs = Code.Typespec.fetch_specs(target_module)
    docs = Code.fetch_docs(target_module)

    boundaries =
      specs
      |> extract_parameter_boundaries()
      |> cross_reference_docs(docs)
      |> identify_specification_gaps()
      |> classify_edge_cases()

    :telemetry.execute(
      [:prismatic, :gray_team, :analysis, :complete],
      %{boundary_count: length(boundaries), module: target_module},
      %{domains: Enum.map(boundaries, & &1.domain) |> Enum.uniq()}
    )

    {:ok, boundaries}
  end

  defp extract_parameter_boundaries(specs) do
    Enum.flat_map(specs, fn {:ok, type_specs} ->
      Enum.flat_map(type_specs, &analyze_type_boundaries/1)
    end)
  end

  defp identify_specification_gaps(boundaries) do
    Enum.map(boundaries, fn boundary ->
      gaps = find_undefined_zones(boundary.min_value, boundary.max_value, boundary.transition_points)
      %{boundary | undefined_zones: gaps}
    end)
  end
end

Specification Gap Discovery Process

1. Documentation Audit
   └── Compare stated behavior vs actual implementation
   └── Identify undocumented functions, parameters, return values

2. Interface Analysis
   └── Examine all public API contracts (@spec, @doc)
   └── Identify missing type specifications
   └── Catalog implicit parameter constraints

3. State Machine Mapping
   └── Extract state machines from GenServer implementations
   └── Identify unstated state transitions
   └── Document error/recovery paths

4. Error Condition Enumeration
   └── Catalog all possible failure modes
   └── Identify unhandled error conditions
   └── Document error propagation paths

Technical Architecture

Gray Team operations are implemented with strict read-only enforcement at the process level, ensuring that exploration cannot inadvertently modify system state.

System Architecture

flowchart TD
    Cmd["Gray Explorer Commander (L3)"]
    Cmd --> Plan["Campaign Planner"]
    Cmd --> Find["Edge Finder (L4)"]
    Cmd --> Guard["Escalation Guard (L4, SAFETY-CRITICAL)"]
    Cmd --> Out["Output Pipeline"]

    Plan --> P1["Coverage Tracker"]
    Plan --> P2["Priority Selector<br/>(Red/Blue signals)"]
    Plan --> P3["Schedule Manager<br/>(domain rotation)"]

    Find --> F1["Boundary Value Analyzer"]
    Find --> F2["Specification Gap Scanner"]
    Find --> F3["State Machine Extractor"]
    Find --> F4["Affordance Drift Monitor"]

    Guard --> G1["Scope Monitor<br/>(continuous)"]
    Guard --> G2["Weaponization Detector"]
    Guard --> G3["State Change Detector"]
    Guard --> G4["Override Controller<br/>(halt authority)"]

    Out --> O1["Finding Formatter"]
    Out --> O2["Provenance Logger"]
    Out --> O3["Team Router<br/>(Red/Blue/Purple)"]

    classDef tier fill:#1e293b,stroke:#64748b,color:#fff
    classDef safety fill:#1e293b,stroke:#dc2626,color:#fff
    classDef leaf fill:#0f172a,stroke:#475569,color:#e2e8f0
    class Cmd,Plan,Find,Out tier
    class Guard,G1,G2,G3,G4 safety
    class P1,P2,P3,F1,F2,F3,F4,O1,O2,O3 leaf

Read-Only Enforcement

defmodule PrismaticDark.GrayTeam.ReadOnlyEnforcer do
  @moduledoc """
  Enforces zero state changes for all Gray Team operations.
  Wraps all external calls in read-only transaction contexts.
  """

  @forbidden_operations [:insert, :update, :delete, :write, :put, :send]

  @spec enforce(fun()) :: {:ok, term()} | {:error, :write_attempted}
  def enforce(exploration_fn) do
    Process.put(:gray_team_read_only, true)

    try do
      result = exploration_fn.()
      {:ok, result}
    catch
      :throw, {:write_attempted, operation} ->
        :telemetry.execute(
          [:prismatic, :gray_team, :violation, :write_attempt],
          %{},
          %{operation: operation}
        )
        {:error, :write_attempted}
    after
      Process.delete(:gray_team_read_only)
    end
  end
end

Telemetry Events

Safety Protocols

Escalation Guard

The gray-escalation-guard agent has override authority to halt any Gray operation that:

• Approaches Black Team territory — boundary analysis begins to resemble theoretical threat modeling or weaponization
• Risks state modification — any detected attempt to write, modify, or allocate resources
• Exceeds exploration scope — investigation extends beyond approved campaign parameters
• Touches production data — any access to non-synthetic, non-public data sources

Escalation Detection Criteria

Audit Requirements

Every Gray operation produces:

1. Timestamped activity log — immutable record of all exploration steps
2. Scope boundary certificate — confirmation that exploration stayed within approved parameters
3. Escalation decision trace — log of all escalation guard evaluations
4. Handoff documentation — structured finding reports for downstream teams

NABLA Compliance

Gray Team operations embody several NABLA axioms that are central to boundary exploration.

Performance Metrics

Integration Points

Signal Flow

flowchart TD
    Code["Platform Codebase<br/>(read-only)"]
    Gray["Gray Team Exploration"]
    Red["Red Team"]
    Blue["Blue Team"]
    Purple["Purple Team"]
    White["White Team"]

    Code --> Gray
    Gray --> Red
    Gray --> Blue
    Gray --> Purple
    Gray --> White

    classDef source fill:#0f172a,stroke:#475569,color:#e2e8f0
    classDef gray fill:#1e293b,stroke:#94a3b8,color:#fff
    classDef team fill:#0f172a,stroke:#64748b,color:#e2e8f0
    class Code source
    class Gray gray
    class Red,Blue,Purple,White team

Outputs

Related Resources

• Red Team — Consumes Gray findings for adversarial scenario development
• Blue Team — Uses Gray findings for defensive gap awareness
• Purple Team — Synthesizes Gray findings with Red/Blue outputs
• White Team — Formally verifies edge cases identified by Gray
• Black Team — Separated from Gray by escalation guard (no direct integration)
• Quality Gates — Quality enforcement informed by specification coverage
• Telemetry Integration — Observability infrastructure explored by Gray

Connect & Contribute

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

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