Responsible Disclosure

Last updated: June 7, 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.

1. How to Report a Vulnerability

Please email vulnerability reports to security@sista.ai . 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:

• 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 (AWS, Hetzner, GCP, Cloudflare), AI model providers (OpenAI, Anthropic, Moonshot AI, 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.
• 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 safety@sista.ai 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 security@sista.ai 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 an early-stage project run by a solo founder on a limited budget. 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.
• Protect your identity and contact information, and not disclose them without your consent unless required by law or court order.
• Credit you publicly (in our security advisories, security page, or hall of fame) with your permission.
• 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 security@sista.ai . AI safety, jailbreaks, prompt-injection, and content-policy concerns go to safety@sista.ai . General questions about this Policy go to contact@sista.ai .