Security
Report a vulnerability.
Email [email protected]. You do not need an account, an NDA, or an introduction.
The machine-readable version of this page is at/.well-known/security.txt.
Scope
What you may test.
In scope, because ByteKit owns or operates them:
- bytekit.com
- app.bytekit.com
- api.bytekit.com
- the ByteKit documentation site
- SDK, CLI, and MCP server packages published by ByteKit
Out of scope unless we authorize it in writing:
- third-party services ByteKit uses as sub-processors
- customer accounts, customer data, captured content, and third-party target sites
- physical security, social engineering, phishing, spam, and harassment
- denial of service, destructive testing, and anything that degrades availability
- high-volume automated scanning that measurably affects reliability
- reading, changing, or destroying data beyond what a proof of concept needs
Pointing the ByteKit API at someone else’s site is not security research on ByteKit. It stays prohibited by theAcceptable use policy.
Safe harbour
Good-faith research is welcome.
If your testing is in good faith, stays inside the scope above, avoids harm to ByteKit, our customers, and third parties, and you report what you find promptly, then we will not pursue legal action against you over it.
Safe harbour ends where this policy ends. It does not cover activity that breaks the law, pulls data beyond what a proof of concept needs, disrupts the service, targets third-party systems, or ignores the ground rules below.
What to expect
Response targets.
Acknowledgement — within 5 business days of your report.
Triage decision — within 10 business days: confirmed, needs more detail, or not a vulnerability.
Remediation — prioritized by severity. We tell you when the fix ships.
These are targets we hold ourselves to, not a contractual SLA. If a report has gone quiet past those windows, resend it to[email protected].
Ground rules
What to send, and what not to do.
Include, as far as you have it:
- the affected asset, endpoint, package, or version
- the vulnerability type and what an attacker gets from it
- reproduction steps we can follow
- proof-of-concept code, screenshots, request IDs, or timestamps
- how you want to be credited, if at all
- Stop and tell us immediately if you reach customer data, captured content, credentials, or tokens. Do not keep a copy.
- Do not disclose publicly until we confirm the fix has shipped, or until we approve disclosure in writing.
- There is no bug bounty and no promise of payment. We may credit researchers at our discretion.
Upkeep
Who keeps this current.
The Expires field in/.well-known/security.txtis owned by the ByteKit security escalation owner — the same role that owns the[email protected] mailbox. That owner reviews this page and re-issues the file at least 30 days before the published expiry date.
If the date in the file has already passed, treat the file as stale and email us anyway. An expired Expires means the file went unrenewed, not that we stopped reading the mailbox.