Security Policy
Vulnerability Reporting Rule: Do not open a public GitHub issue for undisclosed security vulnerabilities. Public issues are reserved for general bugs, documentation, and non-sensitive support requests.
Supported Versions
Hypertaks maintains active security support for the current release line:
| Version | Supported | Notes |
|---|---|---|
4.5.x |
Yes | Current maintained release line |
< 4.5.0 |
No | Legacy versions; upgrade recommended |
Reporting a Vulnerability
We welcome responsible security disclosures. Please use one of the private reporting channels below:
- Preferred: GitHub Private Vulnerability Reporting via Open a security advisory (GitHub Private Advisory).
-
Alternative: Email the maintainer at
abrur_nic@yahoo.comwith[hypertaks-security]in the subject line.
When reporting a vulnerability, please include:
- Affected file(s), component, and version/commit hash.
- Step-by-step reproduction steps or minimal proof of concept.
- Observed impact and suggested remediation if available.
Response Timelines
| Milestone | Target Window |
|---|---|
| Initial Acknowledgement | Within 3 business days |
| Triage and Assessment | Within 7 business days |
| Fix or Mitigation Release | Within 30 days (expedited for high-severity issues) |
| Coordinated Public Disclosure | Mutually agreed upon prior to public release |
Remote MCP Boundary
The remote Model Context Protocol adapter at https://hypertaks.crimsonriftstudio.com/mcp is strictly read-only. It exposes exactly four tools:
hypertaks_manifest: returns product boundary, version, canonical public skills, and adapter limitations.hypertaks_get_skill: reads one canonical SKILL.md file by exact skill name.hypertaks_route: deterministically evaluates request text and selects the smallest canonical public skill entry point.hypertaks_verify_installation: verifies canonical skill entry files and brand assets with cryptographic SHA-256 evidence.
The remote MCP adapter has no filesystem mutation, file creation, file deletion, shell execution, or deployment capability on any client or host system.
Core Security Invariants
- Authority Lattice: Authority is bound strictly to source (T0 Developer/System > T1 Boss turn > T2 Workspace standards > T3 Contract > T4-T6 Data). External data and tool outputs are treated as untrusted data, never as authority.
- Side-Effect Approval: Destructive operations, spend, external writes, and irreversible changes require explicit per-action Boss approval.
- Secret Safety: Secrets travel as environment variable handles (
$NAME), never as plain values. - Atomic Persistence: Local file writes enforce approved-root containment, runtime schema validation, and failure-safe atomic replacement that protects existing data.