Draft for review, last updated 10 November 2026
Vulnerability disclosure policy
We ask people to trust us with their code. If you find a way that trust could be broken, we want to hear about it, and we’ll treat you as a partner, not a threat.
How to report
Email manraj@patchlabs.dev with the subject “Security”. It goes straight to the founder.
We don’t publish a PGP key yet. If your report contains something sensitive, send a short first email and we’ll arrange a secure way to receive the details.
01In scope
patchlabs.devand every page under it, including the signed-in app at/app/.api.patchlabs.dev: the REST API, the MCP server at/mcp, badges, public proof data and receipts.- How our pipeline handles a submitted repository: anything that lets a repository escape the lab, steer the fix agent, read another customer’s data, or get a fix marked “proven” when it isn’t.
- Receipt signing: anything that lets someone forge or alter a receipt that still verifies.
02Out of scope
- Services we use (GitHub, Microsoft Azure, Anthropic, Spacemail by Spaceship, Google Fonts, cdnjs). Please report to them directly.
- Denial of service, load testing, or anything that degrades the service for others.
- Social engineering, phishing, or physical attacks.
- Automated scanner output without a demonstrated impact.
- Missing security headers, email authentication records (SPF, DKIM, DMARC) or best-practice settings, unless you can show a real impact.
- Leaks in other people’s apps. If you find one, tell the app’s owner. Our acceptable use policy explains how.
03Rules for good-faith research
- Use only accounts, workspaces and repositories you own. Don’t run checks on repos you don’t control.
- Access no more data than you need to demonstrate the issue, and never another user’s reports. If you reach someone else’s data, stop and tell us.
- Don’t change or delete data that isn’t yours, and don’t keep any data after reporting.
- Keep request rates reasonable and stop if you notice an impact on the service.
- Give us time to fix the issue before telling anyone else: we ask for 90 days, or less once a fix has shipped and we’ve agreed a date with you.
04Safe harbour
If you follow these rules in good faith, we will not take legal action against you or ask anyone else to, and we will treat your research as authorised. If someone else brings a claim over research that followed this policy, we’ll make it known that it was authorised. If you’re unsure whether something is allowed, ask us first.
05What to include
- What you found and where (URL, endpoint or step in the pipeline).
- Steps to reproduce it, ideally with requests or a short script.
- What an attacker could do with it.
- How you’d like to be credited, if at all.
06What you can expect from us
| Step | Target |
|---|---|
| Acknowledge your report | Within 2 working days |
| Confirm the issue and its severity | Within 5 working days |
| Fix critical and high issues | As fast as we can, aiming for 7 days |
| Fix other issues | Aiming for 30 to 90 days |
| Updates | At least every 7 days until it’s fixed |
If an issue exposed customer data, we tell the affected customers, and the ICO where the law requires it.
07Rewards and credit
We don’t run a paid bug bounty yet. With your permission, we’ll thank you by name on our changelog when the fix ships.
08security.txt
This policy is referenced from /.well-known/security.txt (RFC 9116).
Draft awaiting legal review. See also our security page.