SaaufAI
  • Loading…
  • WispsAssistants that keep working while you're awayPage
  • DocsGuides with screenshotsPage
  • Quick startDocs · first Wisp or first API callPage
  • API referenceDocs · Chat Completions, streaming, toolsPage
  • Create a WispDocs · step by stepPage
  • BlogNews and notesPage
  • All modelsDirectoryPage
  • CompaniesWho makes the modelsPage
  • Compare disclosuresEvery model, every questionPage
  • PoliciesTerms, privacy, acceptable usePage

Security disclosure

Found a security problem in SaaufAI? Tell us privately first, give us time to fix it, and we'll thank you publicly if you want. Good-faith research is welcome here.

First reply
Within a few days
Critical fixes
Within 7 days
High / other
30 / 90 days
Reward
Credit, no paid bounty
Report a problemEmail ai@saauf.xyz, in English or Polish. We don't publish a PGP key yet, so leave live secrets and other people's data out of the email.
Email a reportSupport page

What to include

  • What you found and where: the URL, endpoint or page, and the account or key type involved.
  • Steps to reproduce it, and what an attacker could do with it.
  • Whether and how you'd like to be credited.

A short, clear report beats a long one. Scanner output without a working issue behind it isn't a report.

In scope

  • ai.saauf.xyz: the website, sign-in, account and admin pages.
  • The API at api.saauf.xyz/v1 (also under /v1 and /api/v1 on the website): chat completions, responses, images, models and moderation.
  • API keys, Safeguards program keys and the limits, spending caps and safeguards attached to them.
  • Wisps: their chat, calls, memories, email addresses and the Apps and connections they use.
  • Anything that lets one account read or change another account's data.

Out of scope

  • Services we use but don't run (Vercel, Supabase, Discord, Pollinations, model providers): report to them.
  • Getting a model to say something it shouldn't. Jailbreaks belong with the model's provider, unless they get past one of our own safeguards or reach data they shouldn't.
  • Denial of service, load testing, spam and social engineering of the operator or users.
  • Missing headers, version banners, clickjacking on pages with nothing to click, self-XSS and other findings with no real impact.

Rules for good-faith research

  • Use your own accounts. Don't access, change or keep other people's data; if you reach some by accident, stop and tell us.
  • Don't disrupt the service or run automated scans at volume.
  • Keep the problem private until it's fixed, or until 90 days have passed since your report, whichever comes first. Tell us before you publish.
  • Don't demand payment in exchange for the details.

If you follow these rules, we won't take legal action over your research and will treat it as authorised. We can't speak for the services we use, so stay within scope.

What happens next

  1. We confirm we've got your report, usually within a few days.
  2. We check it, tell you whether we can reproduce it and how serious we think it is.
  3. We fix it within the times above, sooner if it's being exploited, and keep you updated.
  4. Once the fix is live, we tell you, and credit you below if you asked.

How the service is protected is in the Security Policy. The contacts are also in security.txt.

Thanks

No reports yet. Find something real and your name could be first here.