securityReport a vulnerability

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 the Acceptable use policy.

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.

• 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].

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.

The Expires field in /.well-known/security.txt is 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.