The repository implements the bounded local runtime through Feature 014 and the Feature 015 security/release evidence gate. It is still pre-release software: the committed 0.1.0rc1 decision is NO-GO, and no production or universal-security claim is permitted. Do not process sensitive or adversarial production documents merely because the regression suites pass; parser isolation is defense in depth and the declared residual risks in docs/06_SECURITY_MODEL_V2.md remain binding.

OpenARDP is currently a private GitHub repository. GitHub exposes repository security advisories and private vulnerability reporting for public repositories, so a Report a vulnerability form is not available during this private phase.

If you already have a private channel to the repository owner, use it first and request a secure reporting route without sending vulnerability details in the initial message. If no private channel exists, open a metadata-only repository issue that says only that you need a private security contact. Do not include affected components, exploit details, logs, attachments or impact claims in that issue. Move the substantive report to the private route supplied by the owner.

Before any public release, the owner must enable GitHub private vulnerability reporting and replace this fallback with the repository's Security → Advisories → Report a vulnerability form. Never open a public issue containing exploit details.

Never include real confidential documents, production credentials or unnecessary personal data in a report. Use a minimal synthetic reproducer wherever possible.

• affected commit, version, feature and platform;
• concise impact and attacker prerequisites;
• reproducible steps or a minimal synthetic proof of concept;
• relevant logs with document bodies, secrets and identifiers removed;
• suggested mitigation, if known;
• whether the issue is already public or under active exploitation.

These are coordination targets, not a guarantee or bug-bounty promise:

• acknowledge receipt within five business days;
• complete initial severity/affected-scope triage within ten business days;
• agree on mitigation and disclosure timing after triage;
• provide status updates at least every ten business days while remediation is active.

If no acknowledgement arrives through the configured private route, send a metadata-only follow-up. Do not switch to a public issue merely to obtain a response.

The maintainer and reporter should agree on a disclosure date based on severity, exploitability, downstream impact and patch availability. A 90-day window is a default coordination target, not an automatic deadline. Earlier disclosure may be appropriate for active exploitation after users have an actionable mitigation; longer coordination may be appropriate for complex ecosystem fixes.

Published advisories should credit the reporter if requested, describe affected versions, explain the fix and avoid exposing confidential source material.

• Original documents are authoritative and must never be overwritten.
• Document content is untrusted data and cannot authorize side-effecting tools.
• The default installation has no external model or provider call.
• Unit tests run without network access and use synthetic or redistributable fixtures.
• Initial MCP is read-only; parsers require isolation before hostile inputs are supported.

See the complete threat model for future product controls and residual risk.

The exact Feature 015 control manifest is benchmarks/release/v0.1.0/security-controls.json, and the current machine decision is release/evidence/v0.1.0/decision.json.