Security and responsible disclosure

Malprompt is a security product, so it publishes its own disclosure path. If you've found a problem here, we want to hear about it, and you won't get a lawyer's letter for telling us.

Machine-readable version: /.well-known/security.txt.

How to report

Email [email protected]. No form, no account needed.

Helpful things to include, as far as you have them:

• What you found and where — a URL, an endpoint, a screenshot.
• The steps to reproduce it, in the order you did them.
• What an attacker could do with it.
• How you'd like to be credited, or that you'd rather not be.

Write in whatever language you're comfortable in; we read English fastest.

What we'll do

• Acknowledge within three working days. A person replies, not an autoresponder.
• Tell you what we think within ten working days — whether we can reproduce it, how serious we think it is, and roughly when we'll fix it.
• Keep you posted while we work, and tell you when it's fixed.
• Credit you on request once the fix is out.

We don't run a paid bug bounty today. We'd rather say that plainly than imply a reward that isn't there.

In scope

• The Malprompt website and its public API and feeds.
• The submission pipeline: URL validation, fetching, quotas, blocklists.
• Authentication: sign-up, sign-in, verification, sessions, API keys.
• The admin console and its wallet-based sign-in.
• Anything that gets attacker-controlled content out of its defanged form and into a live link, a script, or an instruction an AI agent would follow. That last one is the bug class we care about most.

Out of scope

• Findings against third parties — the repositories and pastes we report on. Those belong to their owners; tell them, not us.
• Reports from automated scanners with no demonstrated impact, missing hardening headers on their own, or best-practice opinions with no attack behind them.
• Social engineering of our team or our providers, physical attacks, and anything aimed at Railway, Resend or Cloudflare rather than at us.
• Denial of service, traffic floods, and automated testing that degrades the service for other people.
• Self-XSS, clickjacking on pages with no state-changing action, and missing rate limits with no demonstrated abuse.

Safe harbour

If you follow this policy while researching in good faith, we will treat your work as authorised. We won't pursue or support legal action against you, and if someone else does, we'll say publicly that your testing was authorised.

To stay inside that, please:

• Use only your own accounts and your own test data.
• Stop as soon as you've confirmed a problem — don't read, change, or keep other people's data, and don't hold data you came across.
• Don't degrade the service. Test gently; no floods, no destructive payloads.
• Give us a reasonable chance to fix it before you publish. Ninety days is our default, and we'll usually be done long before that. If you disagree with our assessment, tell us and publish anyway — we'd rather be corrected in public than quietly wrong.

This is our promise, not legal advice, and it can't bind anyone else.

What we won't do

• We won't threaten you for reporting something.
• We won't ask you to sign an NDA to hear whether your finding was valid.
• We won't sit on a fix and hope nobody notices.
• We won't report your testing to your employer.

How we handle hostile content

Worth knowing before you test us: everything we fetch is treated as hostile data.

• Fetched content is never executed, installed, evaluated, or rendered as code — not on the server, not in the browser, not in the pipeline.
• The analyzer model is given no tools, gets content inside randomised delimiters, must answer in a fixed schema, and is checked for tampering on every response. A response that looks like the content got to the model goes to a human, not to the Wall.
• Anything shown publicly passes through the defanger first: links are broken, invisible characters become visible markers, and excerpts are capped. Payload text is inert plain text, never markdown, never HTML, never a link, never inside a tooltip or a social card.
• The exact original bytes stay behind the admin login and never reach a public page, feed, or API response.

If you get past any of that, it's the best bug you can bring us.

Contact

[email protected]