Security, Governance & Responsible Disclosure

Capability bound by strict defensive governance.

Autonomous vulnerability research carries dual-use responsibility. Operated under EarlyBird AI, LLC security leadership, Threat.Blue enforces hard contractual, technical, and human-in-the-loop controls on every run.

Charter version: FY 2026 Security & PSIRT: security@threat.blue RFC 9116: /.well-known/security.txt
01

Authorized scope & vetting

Threat.Blue does not offer self-serve unvetted scanning and never targets unauthorized third-party infrastructure. Before any analysis begins, we verify organizational identity and require explicit legal authorization under one of three documented paths:

  • Customer-owned code & artifacts: Written Rules of Engagement (RoE) and verified repository, binary, or domain ownership signed by an authorized officer or engineering lead of the contracting organization.
  • Sanctioned safe-harbor programs: Documented scope under established vulnerability disclosure and bug bounty frameworks (including identity-verified researcher accounts on HackerOne and Immunefi) strictly adhering to program rules and local-reproduction requirements.
  • Defensive open-source hardening: Local-only source auditing of open-source packages for the sole purpose of private maintainer remediation under Coordinated Vulnerability Disclosure.

Offensive exploitation, weaponized payload development, unauthorized network reconnaissance, and sale or transfer of unpatched vulnerability intelligence to exploit brokers are unconditionally prohibited.

02

Ephemeral air-gapped sandboxes

When Threat.Blue proves a vulnerability, reproduction never touches live customer production systems or public networks:

  • Local harness execution only: Candidate flaws are compiled and exercised inside isolated, single-tenant ephemeral containers and virtual machines against loopback harnesses (127.0.0.1), simulated protocol peers, or local state forks.
  • Non-destructive proof: Proofs of concept are minimal deterministic inputs designed to trigger a sanitizer assertion (such as AddressSanitizer or UndefinedBehaviorSanitizer) or controlled invariant check—never destructive payloads or persistence mechanisms.
  • Zero model training & post-run destruction: Client source code, binaries, symbols, and crash artifacts are never used to train or fine-tune models. Ephemeral workspaces are torn down and cryptographically wiped at engagement close in accordance with our Data Processing Addendum.
03

Human oversight & parent governance

Autonomous agents propose; accountable engineers decide. Every Threat.Blue engagement operates under dual control:

  • Human review before delivery: Findings, reproduction harnesses, and candidate pull requests undergo human researcher validation before external disclosure or repository submission.
  • Customer engineering sign-off: Threat.Blue never deploys changes directly into production. Patches are delivered as standard diffs or pull requests reviewed and merged by the customer’s own engineering team.
  • Audit logging & corporate accountability: Research runs, model invocations, and artifact handling are governed under EarlyBird AI, LLC security governance alongside EarlyBird AI Security.
04

Coordinated Vulnerability Disclosure (CVD)

When defensive research identifies a previously unknown vulnerability in an upstream open-source project or third-party software component, Threat.Blue follows industry-standard Coordinated Vulnerability Disclosure practices aligned with ISO/IEC 29147:

  • Private maintainer reporting: We notify the upstream maintainer, vendor PSIRT, or designated coordinator (such as GitHub Security Advisories, CERT/CC, or CISA) over encrypted or maintainer-specified channels with root-cause details, a minimal local reproducer, and a proposed fix.
  • 90-day remediation window: We observe a standard 90-day embargo from vendor acknowledgment before any public technical advisory, with good-faith extensions granted when complex multi-party or firmware patch rollouts require coordinated release dates.
  • Reporting an issue in Threat.Blue: Security researchers who discover a vulnerability in threat.blue infrastructure may report it in good faith to security@threat.blue (see /.well-known/security.txt). We acknowledge reports within 48 hours and do not pursue legal action against good-faith research that respects customer privacy and avoids service disruption.
05

Platform & web security controls

Our public infrastructure is engineered with the same restraint we bring to client software:

Strict Content Security Policy default-src 'none' with SHA-256 script pinning, frame-ancestors 'none', and HSTS preload.
Zero Third-Party Code Self-hosted fonts and static assets; zero analytics pixels, ad networks, or external JS CDNs.
IAM Permissions Boundaries Serverless handlers run under explicit IAM boundaries with AWS WAF edge rate limiting and SigV4 OAC.
Authenticated Mail & TLS TLS 1.2+ enforced everywhere, CAA certificate pinning, RSA-2048 DKIM, strict SPF, and DMARC p=reject.
06

Verification FAQ

Direct answers to common enterprise procurement, maintainer, and trust-and-safety questions:

Does Threat.Blue perform offensive security or target live third-party infrastructure?

No. Threat.Blue operates under a strict defensive-only charter managed by EarlyBird AI, LLC. All vulnerability reproduction runs exclusively against isolated local builds inside ephemeral sandboxes—never against unauthorized third-party servers or live production networks.

Is customer source code or binary data ever used to train AI models?

Never. Customer repositories, compiled binaries, firmware images, crash traces, and patches are processed solely inside single-tenant ephemeral environments, are never used for model training or weight updates, and are cryptographically destroyed after engagement completion.

How does Threat.Blue handle vulnerabilities discovered in open-source software?

Upstream open-source flaws discovered during research are reported privately to project maintainers or vendor PSIRTs with a minimal deterministic reproducer and proposed patch under a 90-day Coordinated Vulnerability Disclosure (CVD) policy.

Who operates Threat.Blue?

Threat.Blue is operated by EarlyBird AI, LLC (EarlyBird AI, LLC d/b/a Threat.Blue) as its dedicated defensive security research and autonomous vulnerability remediation division.

Questions for our security team?

Reach our research and disclosure team directly at security@threat.blue or schedule an engineering briefing.