Do not open public issues for security vulnerabilities.

Report security vulnerabilities privately using either channel:

• Email: security.aegaeon@codetakt.com, handled by the Aegaeon Security Reports group.
• GitHub private vulnerability reporting.

Private vulnerability reporting is enabled for this repository. GitHub reports are visible to the reporter and the repository's security advisory collaborators until disclosure.

• A description of the vulnerability and its potential impact
• Steps to reproduce or a proof of concept
• Affected version(s) and configuration
• Any suggested mitigation or fix

We follow coordinated disclosure. We will credit reporters in the advisory unless they prefer to remain anonymous.

The following are considered security issues:

• Authentication or authorization bypass
• Token leakage, replay, or injection
• Cryptographic weaknesses (algorithm downgrade, key exposure, timing attacks)
• SSRF, CSRF, XSS, or injection vulnerabilities
• Privilege escalation across tenants or environments
• Bypasses of sender-constrained token mechanisms (DPoP, mTLS)

The following are not security issues (please use regular issues):

• Feature requests or usability improvements
• Non-security bugs or test failures
• Performance issues without security impact
• Documentation errors

Aegaeon maintains formal-verification assets and security-test tooling. Its server assurance contract fixes requirements for an assumption-qualified formally verified and security-tested foundation. The foundation claim is inactive until the obligations are closed for an identified release artifact/configuration.

The separate SDK contract also remains pending. The public assurance statement specification defines the four distinct claims (specification, implementation/state, symbolic security, and security testing), required release disclosures, and correction or withdrawal rules. Finalized wording does not activate either release guarantee.

Matrix verified rows are component/model evidence, not a release attestation. The contract requires implementation correspondence, adversarial model adequacy, durable state semantics, and release-specific test results. External cryptography, entropy, toolchain, OS/network/storage contracts must be disclosed; own-code validation, configuration and orchestration remain verification obligations.

Existing F*/Low*/HACL*, EverParse, Tamarin and Kani assets have distinct evidence meanings and bounds. See evidence interpretation and the assumption inventory. Dependency review, audit, fuzzing, sanitizers and SBOM tooling provide empirical evidence when actually run for the identified target; their presence alone does not mean a release passed security review or is free of vulnerabilities.

Operators can tune security behaviour through environment variables and policy gates documented in docs/. Key controls include DPoP enforcement, PKCE requirements, token lifetimes, and allowed signing algorithms.

For security matters, use the channels in Reporting a Vulnerability. For Code of Conduct concerns, use conduct.aegaeon@codetakt.com, as described in the Code of Conduct. For general questions and non-security bugs, use GitHub Issues.