Responsible Disclosure

Last updated: September 10, 2026 The security of our systems and the data our customers entrust to us is one of our top priorities. We welcome and appreciate the work of security researchers acting in good faith to help us identify and remediate vulnerabilities. This Responsible Disclosure Policy explains what we consider in scope, what we ask from you, what you can expect from us, and the safe harbor we offer good-faith researchers. If you discover a vulnerability that affects multiple AI vendors or platforms, please submit separate reports to each affected organization. We strongly support coordinated disclosure across the industry. TLTR: we do not run a paid bug bounty and cannot offer monetary rewards. Sistava is an early-stage project run by a solo founder. What we can offer good-faith researchers is fast acknowledgement, a real fix, and public credit in our hall of fame as soon as we confirm your report, no permission needed first (you can always change or remove it after). Full details in Section 5 below.

1. How to Report a Vulnerability

Please email vulnerability reports to [email protected] . If you would like to encrypt your report, request our PGP key in your first message and we will share it. We aim to acknowledge every good-faith report within three (3) business days. A complete report should include: One vulnerability per report, please. Detailed, well-written reports help us validate, reproduce, and fix the issue faster — and increase the likelihood of public credit (with your permission).

• The type and severity of the vulnerability (e.g. XSS, SSRF, IDOR, privilege escalation, RCE).
• A clear summary in one or two sentences.
• The affected URL, endpoint, page, desktop companion version, AI employee feature, or system.
• Step-by-step instructions to reproduce the issue.
• A working proof-of-concept (script, request, screenshot, or short screen recording).
• The potential impact if the vulnerability were exploited.
• Any recommended remediation, if you have one.
• Whether you intend to publish or coordinate disclosure, and your preferred timeline.

In scope

This Policy covers internet-facing systems we own, operate, or control, including: A subdomain is in scope when it resolves to infrastructure we run and serves our own application. A subdomain that points at a third-party product, even under one of our domains, belongs to that vendor and is out of scope. Test production only, and only against an account you created yourself. If you cannot tell which side of that line a given host falls on, email us before you touch it and we will tell you.

• Our primary web application and API at sistava.com and related subdomains.
• Our marketing and product pages at sista.ai and related subdomains.
• The Sistava desktop companion app.
• Our public APIs and WebSocket endpoints.
• Our publicly documented MCP servers and webhook endpoints.
• The Sistava mobile app, and other apps and services.

Out of scope

The following are not covered by this Policy and may not be tested under the safe harbor:

• Any system, service, or website owned, operated, or controlled by a third party, even where it is reachable via a Sistava domain. This includes our cloud providers (Hetzner, Cloudflare), AI model providers (OpenAI, Anthropic, Google, xAI, OpenRouter, Deepgram), payment processor (Stripe), tool integration platform (Composio), and any other sub-processor listed on our Sub-processors page . Please follow each provider's own responsible disclosure program for those.
• Customer-controlled accounts that are not your own, and any account you were given access to by someone else.
• Our non-public environments: staging, development, internal tooling, CI systems, and employee endpoints and devices. If you discover one of these reachable from the internet, that exposure is itself a valid finding, so report it and do not log in or explore further.
• Customer-uploaded data, training data, files, prompts, and AI employee outputs — these are the customer's responsibility, not a Sistava vulnerability.
• Open-source software dependencies. Please report these to the upstream project. If the issue affects how we use the dependency in a way that creates a Sistava vulnerability, that is in scope.

Welcome

We are particularly interested in:

• Authentication and session management flaws.
• Authorization bypass, privilege escalation, and tenant isolation breaks (cross-tenant data access).
• Server-side injection: SQL injection, command injection, SSRF, template injection.
• Cross-site scripting (XSS) and cross-site request forgery (CSRF).
• Insecure direct object references (IDOR).
• Remote code execution and deserialization issues.
• Path traversal and arbitrary file read or write.
• Vulnerabilities in the desktop companion app, including local privilege escalation, sandbox escape, IPC weaknesses, and update mechanism abuse.
• OAuth misconfigurations, token leakage, or scope escalation.
• Webhook signature verification bypass.
• Cryptographic flaws (weak hashing, predictable randomness, broken signature verification).
• Significant exposure of internal documentation, secrets, prompts, or system architecture.

Not in scope

The following are generally not eligible for this program at our discretion:

• Reports without a working proof-of-concept (general "best practice" suggestions, theoretical risks, or scanner output without validation).
• Missing security headers, missing HttpOnly or Secure cookie flags, weak SSL/TLS configurations without a working exploit.
• Rate limiting or brute-force on unauthenticated endpoints.
• Social engineering of any kind, including phishing of Sistava staff, contractors, customers, or partners.
• Physical attacks or attempts to gain physical access to our offices, devices, or staff.
• Denial of service attacks, distributed denial of service, or resource-exhaustion attacks of any kind.
• Account takeover attempts on accounts you do not own.
• Automated scanner output without a validated, exploitable finding.
• Reflected file downloads.
• Clickjacking on pages with no sensitive actions.
• Self-XSS that requires the victim to paste content into their own browser.
• Insider compromise scenarios.
• Dependency hijacking attempts.
• Widely publicized zero-day vulnerabilities for which no patch exists or for which a patch has been available for fewer than thirty (30) days.
• Red-teaming of AI models, prompt injection of AI employees, jailbreaks, and content-policy bypasses. These are AI safety issues, not platform vulnerabilities. Please report them separately to [email protected] with enough detail for us to reproduce the issue. We welcome these reports and take them seriously, but they are not part of this disclosure program.

4. Research Guidelines

We will treat you as acting in good faith and grant you safe harbor (Section 6) provided you abide by the following guidelines while researching vulnerabilities: If you are unsure whether a particular type of testing is permitted, please email [email protected] before proceeding. We are happy to clarify in advance.

• You test only for the purpose of identifying vulnerabilities and reporting them to us.
• You avoid causing any harm to the systems, our customers, our staff, or any third parties — including data destruction, denial of service, traffic floods, or anything that disrupts service.
• You do not exploit a vulnerability beyond what is minimally necessary to prove it exists.
• You do not access, acquire, download, store, retain, or transmit any data that is not your own. If you encounter customer data accidentally, stop, do not save it, and tell us in your report.
• You do not attempt to compromise the security or confidentiality of any account that is not yours.
• You do not perform any social engineering, phishing, or vishing attacks on Sistava staff, contractors, customers, or partners.
• You do not publicly disclose the vulnerability before we have had a reasonable time to remediate. We support your right to publish your findings, and we will work with you on a coordinated disclosure timeline that protects our customers.
• You do not condition disclosure on payment, threaten public disclosure, or otherwise behave in a way that could be construed as extortion.
• You are not on the U.S. OFAC Specially Designated Nationals (SDN) list, the EU consolidated sanctions list, the UK sanctions list, the UN sanctions list, or any other applicable sanctions list, and you do not reside in a sanctioned country.
• You comply with all applicable laws in your jurisdiction and ours while conducting your research.

5. What You Can Expect From Us

For every good-faith report, we will: We do not pay for vulnerability reports. Sistava is self-funded by one person, with no outside investor or company treasury behind it. This is not a limited budget with room to negotiate: a request for payment here is a request made directly to that one individual, not a policy under review. We do not operate a paid bug bounty program, and we will not pay bounties, rewards, or compensation of any kind, regardless of the severity of the finding, the time you invested, or how the report is framed. Please do not submit reports expecting payment. Reports conditioned on payment, or accompanied by threats of public disclosure as leverage, fall outside this Policy and our safe harbor (Section 4) and will be treated as extortion. What we can offer good-faith researchers, at our sole discretion, is public credit on our security hall of fame (with your permission) for valid, high-impact, reproducible findings after we have validated them. A note on our mission, and why we ask for patient, private disclosure. Sistava exists to give humans back their time by automating the work that drains it. We are a small team of AI Agents, working alongside Zalt our founder, trying to build something that, if it works, helps a lot of people get their lives back. Every hour spent firefighting a premature public disclosure is an hour stolen from that mission; and ultimately from the people the product is meant to serve. If you genuinely care about security, the most useful thing you can do is disclose privately, give us a reasonable window to fix the issue, and let us credit you when it ships. That is how security research actually moves the world forward. Pressure tactics do the opposite.

• Acknowledge receipt within three (3) business days.
• Validate the issue and confirm whether it is reproducible.
• Communicate our triage decision and severity assessment.
• Work to remediate confirmed vulnerabilities on a timeline appropriate to the severity, and keep you reasonably updated on progress.
• Coordinate the timing of public disclosure with you, where applicable.
• Always keep your contact information private, and never disclose it without your consent unless required by law or court order.
• Once we have confirmed your report as valid, add you to our hall of fame right away, using the name or handle you signed your report with. We will email you to confirm it, thank you, and let you change the name shown, add a link, or remove the listing entirely, no questions asked.
• Not pursue legal action against you for research conducted in accordance with this Policy (see Safe Harbor in Section 6).

6. Safe Harbor

If you make a good-faith effort to comply with this Policy and the research guidelines in Section 4, we will not pursue legal action against you, and we will not authorize others to do so on our behalf, in connection with your security research and disclosure to us. To qualify for safe harbor: This safe harbor applies only to claims we could otherwise bring against you under our own rights. It does not waive any claims of any third party, and it does not authorize you to violate the law. If a third party brings legal action against you for activity that complies with this Policy, we will, on request, confirm in writing that the activity was authorized under this Policy.

• Your disclosure must be unconditional — no payment demands, no threats of public disclosure as leverage, no extortion.
• You must comply with all applicable laws.
• You must respect the in-scope / out-of-scope boundaries in Section 2.
• You must follow the research guidelines in Section 4.

7. security.txt

We publish a security.txt file in accordance with RFC 9116 to make it easier for security researchers to find this Policy and reach us. Automated tools and security scanners can use that file to discover our disclosure contact and policy.

8. Changes to This Policy

We may update this Policy at any time. Vulnerabilities disclosed before an update remain governed by the version of the Policy in effect at the time of disclosure. The current version is always the one published on this page.

9. Contact

Vulnerability reports go to [email protected] . AI safety, jailbreaks, prompt-injection, and content-policy concerns go to [email protected] . General questions about this Policy go to [email protected] .

Program at a glance

The short answers to the questions researchers write to us with most often, so you never have to ask before you start. Each line is expanded in the numbered section named beside it, and Section 10 answers the longer version of every question below.

• Status: active and accepting new reports, continuously, with no submission window and no cap on submissions.
• How to join: no registration, no application, no invitation. Email a report and you are in the program.
• Where to report: [email protected] , one vulnerability per email, PGP key on request. Email is the only channel; we are on no bug bounty platform (Section 1).
• First response: within three (3) business days of receipt (Section 5).
• Fix targets: scored with CVSS v3.1, then critical within 5 business days, high within 10, medium within 30, low within a commercially reasonable timeframe ( vulnerability management ).
• Rewards: none. There is no bounty, no reward range, no swag, no credits, and no negotiation at any severity (Section 5).
• What you do get: a real fix, public credit in our hall of fame under the name or handle you choose, and a written confirmation of your disclosure on request.
• In scope: sistava.com and sista.ai plus the subdomains we operate, our public APIs and WebSocket endpoints, our documented MCP servers and webhook endpoints, and the desktop and mobile apps (Section 2).
• Out of scope, assets: third-party services and our sub-processors, accounts that are not yours, customer-uploaded data and AI outputs, upstream open-source dependencies, and our non-public staging, internal and CI systems (Section 2).
• Out of scope, bug classes: anything without a working proof of concept, raw scanner output, missing headers or cookie flags, TLS configuration without an exploit, rate limiting on unauthenticated endpoints, denial of service, social engineering, physical attacks, self-XSS, clickjacking without a sensitive action, and zero-days patched fewer than thirty (30) days ago (Section 3).
• AI model behaviour: jailbreaks, prompt injection and content-policy bypasses are welcome but belong on a separate track at [email protected] , not in this program (Section 3).
• Testing rules: production only, your own account only, light and rate-limited automation only, no data retention, and no public disclosure before a fix (Section 4).
• Safe harbor: yes, for good-faith research that follows this Policy (Section 6).
• Disclosure timing: coordinated with us, with a default window of 90 days from acknowledgement, extendable by agreement (Section 10).
• Paperwork: no NDA and no agreement to sign. Anonymous reports are accepted, though credit needs a name or handle.
• Machine-readable: /.well-known/security.txt (RFC 9116) and /llms.txt for the plain-text mirror of this page.
• Language: English.

10. Frequently Asked Questions

These are the questions researchers email us before they start. Everything below is already covered by the sections above; this section exists so you do not have to write to us first, and so you never have to guess. Where an answer and a numbered section disagree, the numbered section governs.

Is the program active and accepting new reports?

Yes. The program is live and open right now. It has no start or end date, no submission window, no queue, and no cap on the number of reports. It runs continuously until this page says otherwise. If you are reading this page, you can report today.

Do I need to register, apply, or be invited?

No. There is nothing to sign up for. Email your report to [email protected] and you are in the program. You do not need our permission to begin testing, as long as you stay inside the scope in Section 2 and the research guidelines in Section 4.

Do you run this program on HackerOne, Bugcrowd, Intigriti, or another platform?

No. Email is the only channel we operate. We are not on any bug bounty platform and we do not monitor third-party triage queues, so a report filed anywhere else may never reach us. We also do not use vulnerability brokers or exploit acquisition programs.

Who is eligible to take part?

Anyone who follows this Policy, with the sanctions and legal conditions in Section 4 as the only limits. There is no country restriction beyond those, no minimum reputation, no certification requirement, and no need to be a customer. Anonymous and pseudonymous reports are accepted, though we can only credit you publicly if you give us a name or handle to credit.

Is there a reward, a bounty range, or a payout table?

No, none of the three. There is no reward range because there are no rewards. We do not pay bounties, retainers, expenses, gift cards, crypto, swag, account credits, or free plans, for any severity, and we have no budget line from which such a payment could be made. This is not a starting position in a negotiation, and a critical finding does not change it. If payment is the reason you would test, please spend your time on a program that pays. Section 5 explains why in full.

Then what do I actually get for a valid report?

A fast human reply, a real fix, public credit in our security hall of fame under the name or handle you choose, and, on request, a signed written confirmation that you found and responsibly disclosed a specific validated issue, which you are free to show an employer or attach to a CV.

Can I change or remove my hall of fame entry later?

Yes, at any time and with no explanation needed. Email us and we will change the name, add or remove a link, or delete the entry entirely.

Exactly which assets are in scope?

The web application and API at sistava.com and the subdomains we operate under it, the marketing and product pages at sista.ai and the subdomains we operate under it, the Sistava desktop companion app, the Sistava mobile app, our public APIs and WebSocket endpoints, and our publicly documented MCP servers and webhook endpoints. Section 2 is the authoritative list.

What counts as a subdomain you operate, and what about hosts you do not list?

A subdomain is in scope when it resolves to infrastructure we run and serves our own application. A subdomain that points at a third-party product, even under our domain, belongs to that vendor and is out of scope under Section 2. If you are unsure which side a given host falls on, email us before you touch it and we will tell you within the same three business days we give any other question.

Are your staging, development, or internal systems in scope?

No. Test production only. Non-public environments, internal tooling, CI systems, and employee endpoints are out of scope, and attempting to reach them is outside the safe harbor even if you find them exposed. If you discover a non-public environment reachable from the internet, that exposure itself is a valid finding: report it, and do not log in or explore further.

I found an issue in one of your vendors. Do you want it?

Report it to that vendor under their own program. Our providers are listed on our sub-processors page and are out of scope here per Section 2. The exception is when the way we configure or use that vendor creates a vulnerability in our service, which is in scope and which we do want.

What about jailbreaks, prompt injection, and AI model behaviour?

We want those reports, but they run on a different track. Send them to [email protected] , not to the security address. They are AI safety issues rather than platform vulnerabilities, so they sit outside this program and outside its safe harbor, as Section 3 sets out. A prompt injection that crosses a real security boundary, for example one that reads another tenant's data or executes privileged actions, is a platform vulnerability and belongs here.

May I create an account to test with?

Yes. Create your own account and test against your own tenant, your own data, and your own AI employees. Never test against another customer's account, and never use an account you were given access to by someone else. If your research genuinely needs a longer-lived or higher-tier test account, ask us and we will usually arrange one.

May I run automated scanners, fuzzers, or crawlers?

Light, rate-limited automated testing against your own account is acceptable. High-volume scanning, brute force, credential stuffing, mass fuzzing, and anything that degrades service for other users is not, and falls outside the safe harbor. Separately, raw scanner output is not a report: Section 3 requires a validated, reproducible finding with a working proof of concept.

How should I identify my testing traffic?

Send the header X-Security-Research with your contact email on every request you can control, and put the same address in your User-Agent string. That lets us separate your traffic from a real attack, and it means an automated block on our side does not turn into an incident on yours. Tell us the source IPs and the testing window in your first email if you plan a sustained session.

What if I accidentally reach customer data?

Stop immediately, do not download, copy, screenshot, or retain it, and tell us in your report what you saw and roughly how much of it. Accidental exposure handled that way stays fully within the safe harbor. What breaks the safe harbor is continuing to pull data after you already have proof, or keeping a copy.

Is there a testing window or a blackout period?

No. You may test whenever you like. We ship many times a day, so the behaviour you see is the behaviour that is live. If your testing causes instability, stop and tell us right away; telling us promptly is treated as good faith, not as an admission.

Can I encrypt my report?

Yes. Ask for our PGP key in your first message and we will send it. You do not need to encrypt an initial message asking a scoping question.

How fast will you reply, and how fast will you fix it?

We acknowledge every good-faith report within three (3) business days. Once confirmed, the fix is scheduled by CVSS v3.1 severity: critical within 5 business days, high within 10, medium within 30, and low within a commercially reasonable timeframe. Those targets, and how we verify a fix actually closed the issue, are on our vulnerability management page.

What if I do not hear back?

Resend your original email with the first send date in the subject line. Mail filters and attachment scanners do occasionally eat a proof of concept. Silence from us is a mistake on our side, never a triage decision.

What happens if my report is a duplicate?

We tell you plainly that it is a duplicate and roughly when the original arrived. Credit for a given issue goes to the first person who reported it with enough detail to reproduce it. A duplicate is still a useful signal to us and it costs you nothing.

What if I disagree with your severity rating or triage decision?

Reply and say why, ideally with the attack path or impact you think we missed. We will re-examine it and give you a reasoned answer either way. We would much rather re-open a finding than be quietly wrong about one.

What language should I write in?

English. It is the only language we can guarantee a fast and accurate triage in.

When may I publish my findings?

After the issue is fixed and we have agreed the timing with you. Our default coordinated window is 90 days from the day we acknowledge your report, and we will usually be ready long before that. If a fix genuinely needs longer, we will explain why and agree an extension with you rather than let the clock run out silently. Tell us your intended timeline in your first email so there are no surprises on either side. Publishing before a fix ships leaves our customers exposed and falls outside the safe harbor.

Will you assign a CVE?

We are not a CVE Numbering Authority, so we cannot issue one ourselves. For an issue in software that other people run, such as our desktop companion app, we will support and cooperate with a CVE request you file with MITRE. Issues that exist only in our hosted service are generally not eligible for a CVE, which is a property of how CVE works rather than a judgement on the finding.

Do I have to sign an NDA or any agreement?

No. We do not ask researchers to sign anything, and we will not make a fix or a hall of fame credit conditional on your signing something. The only conditions are this Policy itself.

Could you take legal action against me?

Not for research that follows this Policy. Section 6 is our safe harbor commitment, and it includes confirming in writing to a third party, on request, that your activity was authorized here.

Is there a machine-readable version of this policy?

Yes. Our security.txt follows RFC 9116 and names the reporting address and this page, and /llms.txt points AI agents and crawlers at the plain-text mirrors of our public pages, this Policy included.

My question is not answered here.

Email [email protected] and ask before you test. We would far rather answer a scoping question in advance than have you guess, and any question that comes up more than once gets added to this section.