Governance, ethics, and validation protocols.

Chelys operates under transparent, deterministic security frameworks. Review our zero-day disclosure procedures and agent alignment protocols.

Responsible Disclosure Policy

Chelys Security operates autonomous penetration testing agents that scan customer systems for vulnerabilities. In the course of authorized testing, these agents may discover vulnerabilities that are previously unknown to the affected software vendor — commonly referred to as zero-day vulnerabilities.

This policy governs what Chelys Security and its customers do when a zero-day or novel vulnerability is discovered during a scan. The core tension is this: the customer hired Chelys to find their weaknesses, and they own the finding — but the vulnerability may exist in third-party software that affects thousands of other organizations who have no idea they are at risk.

This policy resolves that tension by establishing clear roles, a standardized disclosure timeline, and escalation procedures that protect the customer, the affected vendor, and the broader public — in that order of priority.

1. Scope & Application Criteria

This policy applies when a Chelys scan produces a finding that meets all three of the following criteria:

Novel: The vulnerability has no existing public CVE, security advisory, patch, or vendor acknowledgment at the time of discovery.
Exploitable: The finding includes confirmed or highly credible evidence of exploitability — not a theoretical weakness. Chelys agents must have either (a) demonstrated exploitation or (b) produced evidence a qualified security researcher would reasonably assess as exploitable.
Third-party software: The vulnerability exists in software the customer did not write — a commercial product, open-source library, firmware, or operating system component used by the customer. (Vulnerabilities in the customer's own code are fully the customer's property to handle as they choose.)

Scope Clarification

Note: Misconfigurations, weak credentials, and unpatched known CVEs are not zero-days under this policy — they are standard pentest findings delivered to the customer with no vendor notification obligations. Only novel, exploitable vulnerabilities in third-party software trigger this policy.

2. CVE Assignment Process

A CVE (Common Vulnerabilities and Exposures) identifier provides a public, permanent reference for the vulnerability. CVE assignment follows this process:

Check for existing CVE Search the NVD and vendor advisories before requesting a new CVE.

Vendor requests CVE The preferred path — the software vendor requests the CVE from their CVE Numbering Authority (CNA). Most major vendors (Microsoft, Apple, Cisco, Red Hat, etc.) are CNAs.

CERT/CC requests CVE If the vendor is not a CNA or is unresponsive, CERT/CC can request the CVE on behalf of the reporting party via the CERT/CC CNA process.

MITRE direct request If neither of the above is possible, submit directly to MITRE at cve.mitre.org/cve/request_id.html. MITRE assigns CVEs as the CNA of last resort.

Chelys records the CVE Once assigned, the CVE is added to the customer's finding record in the platform and included in all public disclosure materials.

Responsible AI Framework

Operating autonomous AI agents in production target environments requires rigid, deterministic safety boundaries. Our Responsible AI Framework guarantees that agent cognition remains aligned with operational safety policies:

Safety Oracle Payload Inspection: 100% of generated exploit payloads are parsed by a local deterministic check prior to network transmission, catching unsafe commands before execution.
Curriculum Scheduler Scoping: Agents are bound to a strict progressive difficulty curriculum, ensuring high-risk tools cannot be used during passive enumeration phases.
Human-in-the-Loop Triggers: Any action presenting risk of service degradation immediately pauses agent execution and registers a manual authorization requirement for the operator.