AmberKey is in invite-only beta. Join the newsletter to request an invite and hear the moment it opens to everyone. Sign up ↓
AmberKey

Security

Vulnerability disclosure policy

If you've found a security problem in AmberKey, we want to hear about it — before anyone else does. This page is the deal we offer researchers: clear scope, clear rules, and no legal games for acting in good faith.

Report to security@amberkey.app.You'll hear back within 72 hours. Include what you found, where, steps to reproduce, and any impact you can demonstrate. PGP is not required; if you need an encrypted channel, say so in a first plain email and we'll arrange one.

Scope

In scope:

  • amberkey.app (marketing site and docs)
  • app.amberkey.app (owner console and API)
  • recover.amberkey.app (recovery tool)
  • The open-source recovery components and specifications (github.com/amberkey-app/amberkey) — cryptographic findings in the SLIP-39/age handling are especially valuable

Out of scope:

  • Volumetric denial of service (we know load can take things down; demonstrating it helps no one)
  • Social engineering of AmberKey staff, users, or anyone's recovery-circle members
  • Physical attacks (stolen printed cards are covered honestly in the threat model, not a reportable finding)
  • Vulnerabilities in third-party services themselves (AWS, Stripe, Twilio) — report those to their programs; misconfigurations we made of those services are in scope
  • Findings that require a compromised device or browser (also already in the threat model)
  • Missing best-practice headers or TLS options without a demonstrable impact

Ground rules

  • Test only against your own account and data — or better, against the dev instance (dev.amberkey.app / app.dev.amberkey.app), which exists for exactly this. Never access, modify, or delete another user's data; if a flaw exposes someone else's data, stop at proof and report immediately.
  • Don't degrade the service for real users.
  • Don't run automated scanners against the API at volume.
  • Give us 90 days before public disclosure. We'll usually be much faster, and we'll coordinate timing with you.
  • Don't demand payment as a condition of disclosure — that's extortion, not research, and it voids every protection on this page.

Our commitments

  • Acknowledge your report within 72 hours.
  • Keep you informed as we investigate and fix.
  • Credit you publicly when the fix ships, if you want credit (anonymity is equally fine).
  • Never take legal action against good-faith research that follows this policy (safe harbor, below).

We don't currently pay bounties. We're a small company and we'd rather say that plainly than let you find out after you've done the work. Serious findings get serious credit, and this will be revisited as we grow.

Safe harbor

We consider security research conducted in line with this policy to be authorized, lawful, and welcome. We will not initiate or support legal action — including under the CFAA or DMCA §1201 — against good-faith, in-scope research that follows the ground rules above, and we waive any claim under anti-circumvention or computer-misuse terms of ourTerms of Service for such research. If a third party pursues you for research we authorized here, we'll say so on the record.

Draft, pending legal review. Like our terms, this safe-harbor language will be reviewed by counsel before launch. The commitment is sincere today; the wording may be tightened.

Why your report matters here

AmberKey holds the map to people's digital estates. The vault itself is client-side encrypted — our servers can't read it — but the surrounding machinery (authentication, liveness, the ceremony, the recovery tool) is exactly where a real attacker would push. The architecture and its honest limits are public in the threat model; if you can break a claim we make there, that is precisely the report we most want.

Machine-readable version: /.well-known/security.txt (RFC 9116).