Security disclosure
If you have found a weakness in Aqvitus, we want to hear about it, and we will not punish good faith.
Last updated 29 September 2026
Scope
This policy covers the Aqvitus service at app.aqvitus.com, the chat widget it serves, the public API, and this website at aqvitus.com. For how the platform is built — isolation between workspaces, the enforcement chain, the audit ledger — see the Security page and the Trust center.
How to report
Email support@aqvitus.com with “security” in the subject line. Tell us what the issue is, which component it affects, how to reproduce it, what you think the impact is, and include a proof of concept if you have one. Plain text is fine; screenshots and a short video help.
We do not run a paid bug bounty. We do credit researchers who want the credit, and we will say so publicly when the fix ships if you would like us to.
What happens next
- We acknowledge your report within three business days.
- We tell you what we think the severity is, and we keep you informed as we reproduce, fix and deploy. If we disagree that it is a vulnerability we will say why rather than go quiet.
- When it is fixed we tell you, and we agree a disclosure date with you if you want to write it up.
Ground rules
- Act in good faith. Do not degrade the service and do not disrupt anyone’s work.
- Test only against a workspace and data you created. Never access, download or keep records belonging to someone else. If a flaw exposes real customer data, stop at the minimum proof needed, do not keep a copy, and tell us immediately.
- No automated scanning that creates meaningful load, no denial-of-service testing, no brute forcing of credentials.
- No social engineering of our staff, our suppliers or our customers’ staff. No physical testing.
- Do not use the platform’s outbound channels to reach real people while testing — no live SMS, calls or email to anyone who did not agree to be part of your test.
- Give us a reasonable window to fix the issue before you publish, and coordinate the date with us.
Reports about the AI
Aqvitus is an AI platform, so we get reports about the model. The design assumption is that the model can be talked into proposing anything — customer text is treated as untrusted everywhere it appears in a prompt, and deterministic code, not the model, decides whether an action happens.
So the reports we can act on are the ones where the platform itself gave way:
- Interesting: a prompt that makes the platform execute an action its rules do not permit; a way to reach another workspace’s data, knowledge or secrets; a way to get an approval recorded that nobody gave; a way to make a personal detail reach a model, a log or an event untokenised; a way to alter or break the audit chain; a way past a second factor.
- Less interesting on its own: the model saying something rude, wrong or off-brand in a draft that a person would have reviewed. Tell us anyway if it is severe or systematic — we will look — but a jailbreak that produces text and no side effect is the system behaving as designed.
Out of scope
- Findings from automated scanners with no demonstrated impact, and missing best-practice headers alone.
- Rate limiting or brute-force reports without a working exploit.
- Anything requiring a rooted or physically compromised device, or an already-compromised account.
- Self-inflicted issues in a workspace whose own rules or roles were configured to permit them.
- Vulnerabilities in our suppliers’ own products — report those to them; tell us too, and we will follow up.
- Reports about a business that uses Aqvitus rather than about Aqvitus itself.
Safe harbour
If you follow this policy in good faith, we will not pursue or support legal action against you for your research, and we will treat your work as authorised under the computer-misuse laws that apply to us. If a third party brings an action against you for research that followed this policy, tell us and we will make clear that it was authorised.
This does not extend to research that breaks the ground rules above, nor to testing against our customers’ workspaces and accounts without their permission. If you are unsure whether something is in scope, ask first.
Machine-readable policy
This policy is referenced from /.well-known/security.txt, per RFC 9116.
Related: Security · Trust center · Acceptable use