security-research-orchestrator-prompt

KO | EN

gitlite — search

#javascript #hacktoberfest #typescript #llm #golang #machine-learning #deep-learning #docker #nodejs #java #windows #mcp #ios #open-source

security-research-orchestrator-prompt

(★ 22)

High-assurance, artifact-agnostic prompt for authorized security labs, exploit-chain research, PoC validation, and evidence-led reporting.

security-research-orchestrator-prompt Latest Version Download

Download Latest Version (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# Security Research Orchestrator Prompt

High-assurance, artifact-agnostic prompt for authorized security training labs,
exploit-chain research, PoC validation, and evidence-led reporting.

## About

This repository provides a reusable orchestration prompt for structured
security and vulnerability research against bounded, authorized lab targets.
It can be applied to:

- source repositories and code snapshots;
- binaries, libraries, firmware, and container images;
- configurations, infrastructure-as-code, and deployment material;
- logs, traces, packet captures, and protocol transcripts;
- supplied vulnerability claims, PoCs, reports, and mixed evidence bundles.

The prompt is designed to keep the research method and acceptance gates in the
trusted prompt itself. Optional skills and tools may contribute techniques, but
they cannot expand authorization, change the selected operating mode, waive an
evidence requirement, or promote an unproven exploit chain.

> **Manufacture the exploit chain when the lab objective requires it; never
> manufacture the evidence.**

## What it delivers

Depending on the selected mode, the workflow produces:

- an immutable target and artifact-lineage record;
- a threat model and deterministic coverage inventory;
- approach, candidate, exploit-chain, evidence, attempt, and pending-action ledgers;
- a working lab-only PoC or the strongest proven chain prefix;
- clean-reset reproduction and causal negative-control results;
- vulnerable-versus-fixed comparison for deliberately built labs;
- rejected hypotheses and exact remaining proof gaps;
- an application-owner-ready report with remediation and retest steps;
- an explicit G0-G7 final gate matrix.

It separates the state of the research run from the strength of the technical
claim. For example, a crash primitive may be `Proven` while the requested RCE
chain remains `Partial`.

## Operating modes

| Mode | Purpose | Affirmative premise |
|---|---|---|
| `LAB_SOLVE` | Solve an intentionally vulnerable, semantically unmodified training target | Assume an end-to-end chain is intended to exist, but prove every link |
| `LAB_BUILD` | Design a deliberately vulnerable lab and its working PoC | Engineer the lab, exploit, fixed comparison, reset, and teardown |
| `LAB_HUNT` | Perform inventory-driven vulnerability discovery | Do not assume a particular candidate is valid |
| `CLAIM_VALIDATE` | Validate a supplied report, PoC, or exploit claim | Treat every asserted chain link as a hypothesis |

`MODE` must be selected explicitly. The prompt never silently enables lab
mutation, credential use, destructive actions, or external target interaction.

## Research state machine

The prompt enforces these phases:

1. `G0` - preflight, provenance, authorization, and target identity
2. `G1` - threat model and deterministic review-unit inventory
3. `G2` - diverse discovery against the declared coverage profile
4. `G3` - candidate assessment and evidence classification
5. `G4` - exploit-chain synthesis when applicable
6. `G5` - safe PoC construction and validation
7. `G6` - independent adversarial falsification
8. `G7` - ledger reconciliation and owner-ready reporting

Every gate is reported as `PENDING`, `PASS`, `FAIL`, `BLOCKED`, or
`NOT_APPLICABLE`. A failed or blocked mandatory gate cannot become a successful
solve/build conclusion.

## Usage

The complete template is in [PROMPT.md](PROMPT.md). It contains three separate
copy blocks:

1. `BEGIN TRUSTED DEVELOPER PROMPT`
2. `BEGIN VALIDATED USER TASK PARAMETERS`
3. `BEGIN UNTRUSTED ARTIFACT INPUT`

### 1. Install the trusted research contract

Place the trusted developer block in the highest available trusted instruction
layer, normally a system or developer message. Do not claim that the method is
enforced when the block is supplied only as ordinary user text or after
target-owned instructions of equal or higher priority.

### 2. Fill and freeze the task parameters

Complete the user task-parameter block before target ingestion. Important
fields include:

- exact mode and objective;
- target identity and attacker starting position;
- target-interaction and research-network boundaries;
- authorized action classes and target-mutation policy;
- success marker and why it proves the requested impact;
- negative-control and clean-reproduction requirements;
- coverage profile, stop conditions, and reportability policy.

### 3. Supply the target separately

Pass repository content, binary strings, logs, documents, tool output, and other
target-controlled material through a separate message, attachment, content
part, or escaped structured field. XML-like delimiters help the model interpret
content; they are not a security boundary.

### 4. Run to an evidence-backed terminal state

In `LAB_SOLVE` and `LAB_BUILD`, static-first does not mean static-only. Once the
validated authorization envelope permits a dynamic action, the orchestrator is
required to proceed with construction and execution without repeatedly asking
for the same permission. New targets, action classes, side effects, or
destructive scope require new authorization.

## Multi-agent behavior

When independent workstreams materially improve coverage or quality, the root
orchestrator dynamically delegates different technical approach families. It
preserves early independence, prevents one attractive route from dominating,
and separates generator, skeptical judge, and runtime-verifier roles when
capacity permits.

Subagent output remains provisional. The root owns the canonical ledgers,
candidate promotion, exploit-chain reconciliation, severity, and final outcome.

## Prompt enforcement and runtime controls

The prompt contains the complete behavioral methodology: modes, evidence
taxonomy, ledgers, phase gates, persistence, stopping conditions, falsification,
and reporting requirements.

Prompt text is not a physical sandbox. Filesystem limits, network allowlists,
credential isolation, container/VM containment, approval policies, and hard
time or cost accounting must still be provided by the execution environment.

## Source inspiration

The orchestration pattern was inspired by OpenAI's two-page prompt for the Cycle
Double Cover Conjecture, particularly its exact acceptance contract, explicit
non-solutions, approach-family registry, independent exploration, blocked-route
handling, adversarial review, and persistent root-agent synthesis:

- [Prompt used for “A Proof of the Cycle Double Cover Conjecture”](https://cdn.openai.com/pdf/04d1d1e4-bc75-476a-97cf-49055cd98d31/cdc_prompt.pdf)
- Source PDF SHA-256: `0e48deee28caba82ee5b4191d4c5c6ec4d62e5d27890fa7f0d2c8868f8b758f3`

This project generalizes the orchestration pattern for authorized security labs;
it does not reproduce the mathematical task.

## Scope and responsible use

This project is intended for systems you own or are explicitly authorized to
test, especially isolated security-training and vulnerability-research labs.
Keep target identities, credentials, exploit artifacts, and validation
endpoints out of public repositories unless publication is explicitly approved.

## License

[MIT](LICENSE)

security-research-orchestrator-prompt

security-research-orchestrator-prompt Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

security-research-orchestrator-prompt

security-research-orchestrator-prompt Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

Download README