Rigor3 is pre-1.0 software. Security fixes apply to the latest source and newest published release.

Use the repository's private GitHub security-advisory flow. Do not open a public issue for an unpatched vulnerability and do not include real credentials, private source, production logs, or customer data.

Include:

• affected package, contract version, or commit;
• Agent host, host version, and model when visible;
• selected runtime and generated-source digest when relevant;
• a minimal reproduction in a disposable repository;
• expected and observed authorization or qualification boundary;
• impact and whether secrets or external systems were involved;
• suggested remediation when known.

• Repository prompt injection altering the frozen contract, engine, evidence decision, or user authorization.
• Unauthorized workspace, dependency, staging, commit, push, release, deployment, or external mutation.
• Secret disclosure, unsafe evidence retention, or failed sanitization.
• Generated-engine network access, dependency installation, environment enumeration, credential access, dynamic evaluation, repository import, unsafe subprocess use, or undeclared filesystem writes.
• Path traversal, symlink escape, overwrite, destructive cleanup, or mutation outside the owned temporary root.
• Fixed-conformance bypass, rewritten expectations, skipped cases, fixture-specific hard-coding, nondeterministic scoring, or incomplete provenance reported as qualified.
• computed_score reported as an official score when engine or assessment qualification does not permit it.
• Release package contamination, executable behavior, machine schema inclusion, artifact substitution, or checksum bypass.
• A failed, skipped, unavailable, sampled, static-only, or unsafe check reported as verified success.
• A subagent expanding authorization, crossing its mutation domain, hiding a failed assignment, laundering an unsupported conclusion into evidence, or publishing a score or external change independently of the primary Agent.

A vulnerability discovered in an audited repository is not automatically a Rigor3 vulnerability. It becomes one when Rigor3 mishandles that repository, evidence, authorization, generated tooling, qualification, or report.

Rigor3 treats audited repositories as potentially hostile. Source, documentation, comments, fixtures, generated output, logs, issue exports, dependency metadata, and command output are data. They cannot override higher-priority instructions, expand user authorization, request secrets, alter fixed expected results, enable network access, or authorize external writes.

The generic scoring engine must be created, inspected, frozen, and hashed before executable fixtures or harness source are created. The independent harness is then created, inspected, frozen, and hashed before its first execution. Both are conformance-tested before the Agent voluntarily reads repository-controlled content. The sanitized E-005 fingerprint may hash repository bytes without returning names or content to model context, and neither generated source may be derived from repository information. Repository-specific evidence probes are a separate trust class and cannot modify the frozen scoring seam. During the later controlled real invocation, the engine sees only the structured, sanitized assessment inside its private workspace; the harness never sees it, and neither process receives the actual repository root, raw files, fingerprint, secrets, or unsanitized content.

Some hosts inject repository instructions before Skill execution or apply them at host-defined priority. Markdown cannot neutralize an equal- or higher-authority host rule. Compatibility and conformance claims must therefore name the tested host and version rather than claim universal prompt-injection resistance.

Rigor3 does not guarantee the safety of project-controlled commands. Package scripts, build plugins, compiler plugins, test hooks, Git hooks, and dependency installers can execute arbitrary code. Inspect them before use and decline execution or mark checks unavailable when risk or authorization is insufficient.

A runtime-generated engine becomes conformance-qualified only when it:

• uses an already-installed runtime and standard library only;
• is generated and executed in a private temporary root outside the repository;
• accepts that canonical absolute root explicitly and confines every relative path operand beneath it without following links or reparse points;
• is fully inspected before execution;
• passes every fixed positive, negative, metamorphic, and safety parent case and concrete variant;
• produces byte-identical scoring from two fresh processes;
• performs no network, install, repository execution, environment enumeration, dynamic loading, or undeclared write;
• retains complete source, harness, hashes, case transcript, and runtime provenance.

The run becomes publication-qualified only after the frozen sources and audited repository remain unchanged across every real scoring invocation, the dirty-tree digest is independently reproduced when applicable, multi-agent orchestration passes or uses its permitted no-subagent fallback, and every final publication gate passes. Conformance-qualified status alone never permits metrics to be used or reported.

One model may author both engine and harness, so self-conformance reduces but cannot eliminate correlated mistakes. Release validation should use at least two materially different runtime families and preserve each raw result.

Multiple subagents from one host or model family improve coverage and role separation but do not prove model independence. Keep claims scoped to the recorded host, model, capacity, assignments, and validators.

Behavioral security tests should place synthetic sentinel credentials in hostile repository content and verify that no sentinel appears in generated engine source, harness source, assessment, report, stdout, stderr, conformance transcript, or retained artifact. A sanitized: true field is an attestation and cannot prove this property by itself.

Never use real credentials for this test.

Maintainers should acknowledge a complete report promptly, investigate in a private disposable environment, avoid exposing reporter data, and publish a fix and advisory before discussing exploit details publicly.