Security disclosure policy

Last updated 3 October 2026.

Whisk runs other people's apps and holds their data. If you find a weakness in the platform we want to hear about it, and we want you to be safe telling us. This page says how. It is also the policy that /.well-known/security.txt points at.

1. How to report

Email support@whisk.run with the subject "Security". Tell us:

• what you found and where (hostname, path, component),
• how to reproduce it, step by step, with a request and response where you can,
• what you think the impact is,
• how we can reach you, and whether you want to be credited.

If you are unsure whether something is a security issue, send it anyway. We would rather read ten reports that are not than miss one that is. If the report contains someone else's data you came across, say so and delete your copy once we confirm we have it.

We publish no PGP key. If a report is sensitive enough that you want it encrypted, say so in a first email and we will give you a Signal number to send it on. English is the language we read fastest; send in another and we will translate.

2. What is in scope

The platform we run:

• whisk.run (the dashboard), api.whisk.run, auth.whisk.run, git.whisk.run, hooks.whisk.run, skill.whisk.run and errors.whisk.run
• the edge in front of every app on whisk.page and custom domains: sign-in, the identity headers, cookie isolation, rate limits, security headers, the waking page
• the container isolation, the private network, the secrets service, the node agent and the build pipeline
• the CLI, the agent skill and the three starter templates as we publish them
• the control plane's handling of tokens, device codes, sessions and roles

The apps themselves are not ours. A bug in an app on whisk.page belongs to the organisation that runs it, unless the bug is that the platform let it do something it should not have (read another tenant's data, escape its container, set an identity header, reach a service route from the internet). That kind is ours, and we want it.

The findings we care most about, in order: escaping a container or reading another tenant's data; reading a secret value; taking over an account or a token; injecting into the build pipeline or the supply chain; bypassing the edge's sign-in or identity headers; anything that lets one tenant affect another.

3. What is out of scope

• Denial of service, load testing, or anything that degrades the platform for other tenants.
• Social engineering of our people or of tenants; physical attacks.
• Findings from automated scanners without a demonstrated impact.
• Missing best-practice headers or configuration on a tenant's app that the tenant controls through their manifest.
• Reports about third-party services we use (Hetzner, AWS, Backblaze, Stripe, Cloudflare) unless the issue is in how we use them.
• Content of tenant apps; that is the Takedown process.
• Reports that a software version is old, without a working exploit against our configuration.
• Missing SPF, DKIM or DMARC records on a domain that sends no mail; missing certificate pinning; cookie flags on cookies that carry nothing.
• Self-inflicted findings: what you can do to your own organisation with your own credentials, clickjacking on pages without a state-changing action, logout CSRF, tab-nabbing.
• Rate limits you can only show by exceeding them at a volume that hurts other tenants.
• Reports that consist of a demand for payment before disclosure. We do not pay under pressure, and we will still fix the bug.

4. Rules for testing

• Test only against accounts and apps you own. Create your own organisation on the Free plan; do not touch anyone else's.
• Stop as soon as you have shown the issue. Do not read, change or delete data that is not yours; if you see any by accident, stop and tell us.
• No denial of service, no spam, no brute force beyond what is needed to show a rate limit is missing.
• Do not use a weakness to keep access, to move laterally, or to reach our infrastructure providers.
• Do not exfiltrate data. A screenshot of a single record that proves the issue is enough; a dump is not, and turns a report into an incident.
• Keep automated traffic modest: no more than 5 requests a second against our hosts, run only against your own account, and identify yourself with a header or user agent we can recognise.
• Keep the details to yourself until we have fixed the issue and agreed disclosure with you (section 6).

5. What we promise

• We acknowledge your report within 3 business days and tell you who is handling it.
• We tell you what we found within 10 business days, and keep you informed until it is fixed.
• We fix real issues as fast as their severity demands: something that exposes tenant data or breaks isolation is worked on immediately. We publish no fix-by dates per severity, and we make no promise about one; we do tell you when the issue is fixed.
• We credit you on this page if you want, once the issue is fixed.
• We do not currently pay bounties. We say so plainly so nobody is surprised.

6. Safe harbour

If you follow this policy in good faith, we consider your research authorised. That means:

• We will not bring a civil claim against you, or report you to the authorities, over it.
• We will not accuse you of breaching the Terms of service or the Acceptable use policy for the testing this policy allows, and section 2.3 of that policy does not bar research that follows this page.
• Where the law in your country allows a claim over computer access, we waive it for research that follows this policy, so far as we are able.
• If a third party threatens you over such research, we will say publicly and in writing that you acted under our policy, and we will tell them so ourselves.

This protection is ours to give and covers only claims by us. It does not bind our providers, our tenants, or any authority, and it does not apply to research that goes beyond this policy, such as reading someone else's data, holding a finding for payment, or degrading the Service. If you are unsure whether something is within the rules, ask at support@whisk.run first and we will answer.

We will also apply this policy to the person's benefit where they broke a rule by accident, told us at once and did no harm. Honest mistakes are not what this is for.

7. Disclosure

We prefer coordinated disclosure. Once an issue is fixed, you may publish your findings; we ask that you give us 90 days from your report, or until the fix ships if sooner, and that you agree the timing with us where tenants need time to act (for example, to rotate a secret). If we cannot fix an issue within 90 days we will tell you why and agree a date with you. We will not ask you to stay quiet indefinitely, and we will not use a non-disclosure agreement as a condition of accepting your report.

Where an issue is in someone else's software, we report it to them and follow their disclosure process, and we tell you what we did.

8. What we do when a weakness affects tenants

If a weakness may have exposed a tenant's data or secrets we tell the affected owners without undue delay and within 48 hours of confirming it, say what was affected and what to do, write what we know to the affected organisations' audit logs, and publish a post-incident note on the status page. Where the law requires we notify the authority within 72 hours. The Data processing agreement section 9.2 sets out what a notification contains.

9. security.txt

https://whisk.run/.well-known/security.txt carries the fields RFC 9116 defines: Contact, Expires, Policy, Preferred-Languages and Canonical. The file is regenerated so that Expires is always within a year, as the RFC asks. There is no Encryption field, because we publish no PGP key, and Acknowledgments points at section 10 once someone is named there.

10. Credits

Nobody yet. Be the first.

Contact: Whisk, Auckland, New Zealand, support@whisk.run. Machine-readable: https://whisk.run/.well-known/security.txt.