ChaseInTech

Build log

GreyTheory Research: a signal is not a vulnerability

Build milestone1 min readGreyTheory Research

How GreyTheory separates raw signals, deterministic validation, model-assisted reasoning and human authority—before anything can become a reportable finding.

Source: Public repository: chasedndt/GreyTheory-Research (README, scope policy, product boundary map and safe local proof plan)

Technical bibliography record

The build, in five parts.

01 Built
GreyTheory remains an incubation and architecture lane. The public repository contains policies, schemas, product boundaries and proof plans; it does not establish a live scanner, autonomous exploit engine, real-world finding or security outcome. The next credible milestone is a reproducible local defensive demo that proves the scope and evidence gates behave as designed.
02 Process
AI-assisted security tools can generate convincing explanations long before they have evidence. GreyTheory starts by refusing that shortcut. Its public architecture treats a version match, exposed path or unusual response as a signal to investigate—not a vulnerability, impact claim or report.
03 Learned
How GreyTheory separates raw signals, deterministic validation, model-assisted reasoning and human authority—before anything can become a reportable finding.
04 Skills
securityarchitecturegovernanceagent-safety
05 Saved
Source boundary: Public repository: chasedndt/GreyTheory-Research (README, scope policy, product boundary map and safe local proof plan)

Context#

AI-assisted security tools can generate convincing explanations long before they have evidence. GreyTheory starts by refusing that shortcut. Its public architecture treats a version match, exposed path or unusual response as a signal to investigate—not a vulnerability, impact claim or report.

A finding has to earn its name#

The shared taxonomy moves evidence through Informational, Contextual, Candidate, Validated and Report-Ready states. A candidate cannot advance because a model sounds confident: it needs a deterministic check, reproducible evidence and a human decision. Severity and remediation remain provisional until the underlying condition has actually been validated.

The model reasons; hard tools prove#

The intended labour split is explicit. Deterministic components own scope checks, requests, parsing, binary pass/fail decisions and audit records. The model interprets evidence, explains confidence factors and drafts human-readable rationale. That boundary keeps probabilistic reasoning useful without letting it silently become execution authority or proof.

Authority is a hard input#

GreyTheory's active scope policy defaults to local repo, documentation and toy-demo work. External scanning, live target interaction, credential validation, disclosure and public claims about real findings remain blocked unless a separate approval packet names the owner, written authorization, exact assets, allowed actions, limits, data handling and required audit artifact. Missing authority means hold, not improvise.

Build public proof without touching a target#

The safe proof plan uses intentionally local fixtures: mocked high-authority actions, prompt-injection samples and fictional finding records. Each demo must avoid external targets, real credentials and third-party data while producing a reproducible command or screenshot, an explicit local-only banner and a public-safe summary. That creates something inspectable before expanding the system's authority.

Current boundary#

GreyTheory remains an incubation and architecture lane. The public repository contains policies, schemas, product boundaries and proof plans; it does not establish a live scanner, autonomous exploit engine, real-world finding or security outcome. The next credible milestone is a reproducible local defensive demo that proves the scope and evidence gates behave as designed.