StellarRequiem - Security Research

Security Research and Verification Controls

Authorized defensive vulnerability research focused on AI infrastructure, MCP-style tooling, and authorization-logic failures. Work is bounded by explicit scope, local reproduction, coordinated disclosure, and audit records.

Operating Boundaries

  • Authorized targets only.
  • Deny-by-default scope checks before testing.
  • Local reproduction and disposable runners where possible.
  • Human review before disclosure or escalation.
  • No public exploit release while a report is private or embargoed.
  • No live-target probing outside the applicable program or maintainer scope.
  • No claims of impact without reproducible evidence.

Primary Control

scope-gate models "am I allowed to test this?" as an explicit gate. It is the boundary that keeps dual-use security work tied to scope, authorization, and human disclosure decisions.

github.com/StellarRequiem/scope-gate
deny by default coordinated disclosure human gated

Publication Controls

All public-facing claims on this page are governed by a local claim registry and approval queue. Changes to disclosure entries, metric wording, or evidence positioning require explicit review before deployment.

Approval queue

Public wording changes route through a written approval queue before deployment. Being queued is not approval; a human decision is required.

Claim registry

Every metric-bearing or security-sensitive statement is bound to a registered claim with its evidence, caveats, and forbidden wording. Published figures may not exceed what the cited public artifact shows. Results that have not been scored under the published method are not presented as headline numbers.

Disclosure mode

Ledger rows stay placeholder-only unless FastMCP public PR entries or operator-provided entries are explicitly curated.

Evidence Assets

mcp-bench

Independent benchmark for whether MCP/source security scanners detect authorization-logic vulnerabilities.

Expanded result: 19 labeled cases, including 11 authorization-logic cases across 10 root-cause classes, 2 control bugs, and 6 clean negatives.

Evidence caveat: semgrep and bandit report 0/11 authorization-logic detections while catching 2/2 control bugs; because two authz cases share a root cause, the stricter class-level reading is 0/10.

authz logic 0/11 class caveat 0/10 controls detected disposable CI

aisec-check

Read-only AI-app and MCP-style security triage scanner. It is a lead generator, not a precision gate.

Validation: 59 public AI repos, 1410 raw leads, 140 sampled for human adjudication, about 3-4 percent precision.

read only human confirmed SARIF receipts

verify-suite

Reference implementation that composes claims, citations, benchmarks, datasets, calibration, scope, and security leads into one receipt.

Absent checks report n/a. Receipts are reproducible, and limitations are stated plainly.

one receipt transparent rollup n/a is honest

verity-core

Shared audit and sealing primitive for the verification toolchain.

Unkeyed seals are treated as integrity checks, not overstated as tamper-proof evidence.

audit chain canonical JSON replayable

Claim Controls

Public and reviewer-facing claims are routed through a local claim registry before wording is strengthened. Metric-bearing, security-sensitive, or reusable claims get a claim card with evidence, caveats, forbidden wording, and disclosure-safety checks.

Published trust surface

Governs what this site may assert about capability and status, and the wording that is off-limits.

Workflow manual

Governs how the public method write-up may describe scope, evidence, verification, and disclosure.

mcp-bench metric

Binds the authorization-logic figures to the published corpus, including the stricter class-level reading. Verifiable in the public repository.

aisec-check methodology

Requires the tool to be described as a lead generator with its measured precision stated, never as a precision gate.

FastMCP public fixes

Limits these to what the merged public pull requests actually changed. Verifiable upstream.

Billing boundary

Prohibits presenting payment integration work as production-ready.

TAC Use Case

Trusted Access for Cybersecurity would support defensive, policy-bounded workflows:

  • Triage source-code security leads.
  • Compare suspected findings against known vulnerability classes.
  • Prepare maintainer-safe disclosure summaries.
  • Review patches and regression tests.
  • Improve benchmark cases and defensive guidance.
  • Keep all disclosure, target selection, and live-testing decisions human-gated.

Out of Scope

  • Autonomous exploitation.
  • Unsolicited live-target testing.
  • Credential theft or data exfiltration.
  • Malware creation or deployment.
  • Public release of private exploit details.

Disclosure Process

Findings are handled through coordinated disclosure. Public references are included only when the issue is already safe to discuss.

Current safe modes are placeholder-only, FastMCP public PR entries only, or operator-provided entries curated locally before any publication.

Date Channel Class Status Reference Notes
pending operator review pending pending pending pending sanitized entries only; no exploit steps or active-target details

This table is a placeholder until disclosure outcomes are curated for public release.

Current Hardening Plan

Repo Policies

Add SECURITY.md coverage to the core public repos only after the SECURITY.md application gate is explicitly approved.

CI

Add verify-suite CI only after the workflow application gate is explicitly approved and public run evidence is verified.

Stripe

Complete webhook verification, idempotency, and checkout handling before production billing claims; no Stripe keys or dashboard actions are part of this page.