Responsible disclosure

If you have found a way to reach data you should not reach, to act as an account that is not yours, or to make the agent do something it must not do, we want to hear about it before anyone else does. Write to [email protected]. There is no form and no account required.

What we commit to

• Acknowledgement within two working days, from a person, saying we have it.
• A triage decision within five working days: whether we consider it a vulnerability, what severity we have assigned it, and why.
• Progress updates at least every ten working days until it is resolved or we have explained why we will not act.
• No legal action against good-faith research conducted within the scope below. We will not pursue or support a claim against you, and if a third party does, we will say publicly that your work was authorised by this policy.
• Credit if you want it. Tell us how you would like to be named when we publish the fix, or ask to stay anonymous.

We do not operate a paid bug bounty. We would rather tell you that plainly than imply a reward that does not exist.

In scope

• Our company surfaces and documentation.
• The FlowFinds application at FlowFinds and its API.
• Storefronts generated by the store engine, in their generated form.
• Prompt injection and agent-authority findings — for example, content that makes an agent act outside the limits described at safety approach.

Out of scope

• Anything requiring you to access, modify or delete another person’s data. Stop at proof that access is possible.
• Denial of service, load testing, and physical or social engineering against our staff, our customers or our vendors.
• Findings in a third-party service we use — report those to that vendor, and tell us so we can track it. The vendors are listed at sub-processors.
• Reports produced only by a scanner, with no demonstrated impact: missing headers, cookie flags on non-sensitive cookies, version disclosure, weak TLS ciphers with no working attack, or an SPF/DMARC observation.
• Self-inflicted findings that require a compromised device or browser extension.
• A model producing wrong, biased or embarrassing output. That is a quality report — send it to [email protected] — unless it crosses into an authority or data-access boundary, which is in scope.

Rules for testing

• Use your own account and your own test data. Create a free account if you need one.
• Stop as soon as you have demonstrated the issue. Do not pivot further into the system, and do not run automated exploitation against production.
• Do not degrade the service for other people.
• Do not retain data you encountered. Tell us what you saw and delete your copy, and we will confirm receipt.
• Do not publish before we have fixed it, or before 90 days have passed since your report — whichever comes first. If a fix is taking longer than 90 days, we will tell you why and agree a date with you.

What to include

A description of the issue and its impact, the exact steps or requests needed to reproduce it, the account or URL involved, timestamps, and anything else that would let an engineer see it happen. Screenshots and a short recording help. Write in English or Hungarian.

After a report

We reproduce it, assign severity, fix it, and — where customer data was affected — follow the notification path in security and clause 8 of the data processing addendum. Where a fix changes how the product behaves, it appears in the changelog. Where it changes a commitment, it appears on the page that made the commitment.

Testing conducted within this policy is authorised, and clause 5 of the acceptable use policy is disapplied to that extent. Anything outside this scope is not authorised.