Security policy
Codaegis welcomes good-faith reports of security issues in live Codaegis web, account, billing, support, security, and admitted PR-review surfaces.
Security intakesupport@codaegis.com
The machine-readable security contact at /.well-known/security.txt should match this route unless Codaegis later splits security into a dedicated address.
Scope
- Report issues in live Codaegis web, account, billing, support, security, and admitted PR-review surfaces.
- Do not treat public API, SDK, CLI, Cursor, VM-agent, broad self-serve, autonomous writeback, or non-PR paid work-family surfaces as in scope unless Codaegis separately admits them and publishes that scope.
Please do not test
- Denial-of-service or load testing.
- Social engineering or physical attacks.
- Attacks on third-party systems.
- Payment abuse.
- Destructive testing.
- Attempts to access customer data.
- Activity that modifies repositories, deploys code, exfiltrates data, or disrupts service.
How to report
- Where the issue appears.
- Steps to reproduce it.
- Likely impact.
- A minimal proof of concept, if non-destructive.
- Logs, requests, screenshots, or packet IDs that help confirm the report.
- Do not include secrets, private keys, production credentials, customer data, or unrelated private code unless narrowly requested and lawful to share.
Response posture and rewards
- Codaegis aims to acknowledge good-faith security reports within five business days as an operational posture, not as a contractual SLA.
- No emergency incident response, 24/7 monitoring, guaranteed response time, or customer-system remediation is promised by this page.
- Codaegis does not currently offer paid bounties or monetary rewards unless a later public policy says otherwise.
- Report privately and allow a reasonable remediation window before public disclosure.
Security and trust boundaries
- Codaegis governed packets are decision support only. They do not certify code as safe, compliant, approved, secure, or ready to deploy.
- Codaegis may describe practical safeguards that are true and evidenced, such as read-only review posture, bounded packet retention, no merge/deploy authority, and Stripe-handled payment data if Stripe is activated.
- Formal compliance features and trust artifacts are planned.
- Any named certification, audit, regulated-use, data-processing, or trust-center claim requires separate proof, legal review, and operator signoff before publication.