Vulnerability Disclosure Policy

1. Our commitment

Watchdogs exists to keep people safe from attacks, so we hold our own platform to the same standard we ask of everyone else. If you believe you have found a security vulnerability in Watchdogs, we want to hear about it, we will work with you to fix it quickly, and we will not take legal action against you for good-faith research that follows this policy.

Watchdogs is operated by koderAI Corp. ("Watchdogs," "we," "us"). This policy explains what you may test, how to report what you find, and what you can expect from us in return. How we handle vulnerabilities that we find in other organizations' software is covered separately in our Coordinated Disclosure Policy.

2. Scope

In scope

• The Watchdogs website and waitlist at koder.com and its subdomains.
• The Watchdogs web application, including account, billing and team features.
• The Watchdogs public API and any SDKs, CLIs, plugins or integrations we publish.
• Draco and the other Watchdogs agents, including the chat interface, the tools agents can call, and the systems that generate reports and deploy fixes.
• Infrastructure we operate to run the above.

Out of scope

• Our customers' websites and applications. Even though Watchdogs monitors them, they belong to our customers. Do not test them under this policy. Report issues to the owner directly.
• Third-party services we use (for example, payment, email, hosting and AI model providers). Report those to the provider under its own policy. If the issue is in how Watchdogs configures or uses the service, it is in scope.
• Denial-of-service, load or volumetric testing.
• Social engineering, phishing or physical attacks against our staff, offices or customers.
• Findings that only come from automated scanners and have no demonstrated security impact.
• Missing best-practice headers, cookie flags, SPF/DMARC records or TLS settings without a working attack, clickjacking on pages with no sensitive actions, and self-XSS.

3. AI agent issues we especially want to hear about

Watchdogs agents can read customer systems, call security tools and, with a customer's permission, change code and infrastructure. We treat the following as security vulnerabilities, not content-quality issues:

• Prompt injection with real impact. Content in a website, repository, email, ticket or tool output that makes an agent take an action its user did not authorize, reveal data, or change its own instructions or permissions.
• Cross-tenant exposure. Any way to see, influence or act on another customer's data, reports, findings, conversations or connected systems.
• Unauthorized fixes or deployments. Any way to make an agent write, merge or deploy changes outside the scope or approval rules the customer configured.
• Tool abuse. Any way to use the scanning and testing tools Watchdogs agents run to target systems the user has not verified ownership of or is not authorized to test, including SSRF through those tools.
• Secrets and credentials. Exposure of API keys, tokens or credentials that customers connect to Watchdogs, or of our own.
• Sandbox or isolation escape from the environments where agents run code or tools.

The following are not security vulnerabilities on their own: getting a model to say something rude or off-topic, inaccurate or hallucinated answers, and model-quality complaints. Please send those through in-product feedback instead. If a jailbreak leads to one of the impacts listed above, it is in scope.

4. Rules of engagement

To stay within this policy and the safe harbor in Section 8, please:

• Test only against accounts you created yourself. You may create more than one account to test cross-tenant issues.
• Do not access, modify or delete data that is not yours. If you access someone else's data by accident, stop, do not keep or share it, and tell us in your report.
• Do only what is necessary to demonstrate the issue. For example, show that you can read one record, not that you can download the database.
• Do not use Watchdogs agents or tools to scan, test or attack systems you do not own or are not authorized to test.
• Do not degrade the service for other users, and keep automated requests to a reasonable rate.
• Do not use the vulnerability for any purpose beyond confirming and reporting it, and delete any data you obtained once your report is resolved.
• Keep the details confidential until we have agreed on disclosure (Section 7).

5. How to report

Email security@koder.com.

A useful report includes:

• A description of the vulnerability and its impact.
• The affected URL, endpoint, agent or feature.
• Step-by-step instructions to reproduce it, plus any proof-of-concept code, prompts, requests or screenshots.
• The account(s) you used, so we can find your activity in our logs.
• Whether you want to be credited, and under what name.

You may report anonymously. We do not currently run a paid bug bounty. We are happy to credit researchers publicly, and we may offer rewards at our discretion for significant findings.

6. What you can expect from us

We will tell you when the issue is fixed, credit you (if you want) in our security acknowledgments and any advisory, and explain our reasoning if we decide the report is not a vulnerability. If a fix will take longer than the target, we will tell you why and agree on a new date with you.

7. Disclosure

We believe in coordinated disclosure. Please give us a reasonable chance to fix the issue before sharing any details publicly. We ask that you wait until the fix is released or 90 days after your report, whichever comes first, unless we agree on a different date together. We will not ask you to stay silent indefinitely.

Where an issue affects software customers install or run themselves, we will publish a security advisory and request a CVE ID through the appropriate CVE Numbering Authority. For issues in our hosted service, we will publish an advisory when customers need to take action or when the issue is significant, and we will tell affected customers directly when their data was exposed.

8. Safe harbor

When you conduct security research and report vulnerabilities in good faith and in line with this policy, we consider your research to be:

• Authorized under the Computer Fraud and Abuse Act and similar state and international laws, and we will not bring a claim against you for accidental, good-faith violations of this policy.
• Exempt from the anti-circumvention provisions of the Digital Millennium Copyright Act, and we will not bring a claim against you for circumventing technology controls.
• Exempt from restrictions in our Terms of Service and Acceptable Use Policy that would interfere with security research, and we waive those restrictions on a limited basis for that purpose.
• Lawful, helpful to the overall security of the internet, and conducted in good faith.

You are expected, as always, to comply with all applicable laws. If a third party takes legal action against you for activities conducted under this policy, we will make it known that your actions were authorized by us. If you are unsure whether something is allowed, ask us at security@koder.com before going further.

This section is modeled on the open-source disclose.io safe harbor framework.

9. Changes to this policy

We may update this policy as Watchdogs grows. The version and effective date at the top of this page show the latest change, and the version in effect when you started your research applies to it.