Vulnerability Disclosure Policy
Scope, safe harbor and response times.

1. Our commitment

Frazer runs other people’s code, agents and data. Finding a weakness before an attacker does protects all of them, so we welcome reports from everyone: researchers, customers, students and other companies. If you follow this policy, we treat your research as authorized, work with you to understand and fix the issue, and tell the world about the fix with credit to you if you want it.

2. Safe harbor

When you make a good-faith effort to follow this policy in your security research:

• we consider your research authorized under the US Computer Fraud and Abuse Act and similar laws, and we will not bring, or ask anyone to bring, a legal claim against you for it;
• we waive the restrictions in our Terms of Service and Acceptable Use Policy that would otherwise forbid your research, for that research only;
• we will not bring a claim against you for working around technical measures that protect our services, for the purpose of that research;
• if someone else brings a legal claim against you for research that followed this policy, we will make it known that you acted with our authorization.

Good faith means you tried to follow the rules below. If you are unsure whether something is allowed, ask us at security@frazer.ai before you do it. This safe harbor covers Frazer’s own systems; we cannot authorize testing of systems that belong to others, including our customers and our providers.

3. Rules for testing

You must:

• test only against accounts, organizations and resources you own, or that their owner has allowed you in writing to test;
• stop as soon as you reach data that is not yours, such as another customer’s code, secrets or personal data. Do not keep it, copy it, share it or use it to go further, and tell us what you saw;
• do only what is needed to show the problem. One record, one file or one command is proof enough;
• keep the details to yourself until we have fixed the problem or agreed a date to publish, as section 7 describes;
• follow the law.

You must not:

• degrade or interrupt Frazer for others: no denial-of-service testing, load or stress testing, or traffic floods;
• attack our staff, customers or providers through phishing, social engineering, or physical access to offices or data centers;
• send spam, or test Frazer Mail by sending mail to people who did not agree to receive it;
• plant persistent access, malware or cryptocurrency miners, or change or delete data that is not yours;
• use a vulnerability to get anything for yourself beyond showing it exists.

4. Scope

In scope

• The website and services at frazer.ai and its subdomains, including the console, the API and the MCP server.
• The frazer CLI, the installers, the Frazer app and the editor extensions.
• Fir, Frazer CI, Frazer Runners and GitHub runners, as Frazer runs them.
• The Frazer agent that runs on servers, tested on a server you own and have added to your own organization.
• Isolation between customers, between projects and between agents: any way one tenant can reach another’s data or compute is the most important thing you can find.
• Code Frazer publishes as open source.

Out of scope

• Customers’ own applications, sites and data, including those served from frazer.run or from customers’ own domains. Report those to the customer.
• Servers customers bring, other than your own.
• Services run by other companies that Frazer uses, such as our website host and our mail host. Report problems with them to those companies.
• Our status page, which runs outside the platform.
• Findings with no security impact: missing best-practice headers, banner and version disclosure, clickjacking on pages without sensitive actions, rate limits on non-sensitive actions, self-inflicted problems, and reports made only from automated scanners without a working proof.
• Email authentication of our domains, unless you can show a way to send mail that passes as Frazer’s.

Vulnerabilities in open-source software we use should go to its maintainers. If one affects Frazer, tell us too.

5. How to report

Write to security@frazer.ai. The same address is in our security.txt. Please include:

• what the problem is and where: URLs, hostnames, versions, or the component;
• the steps to reproduce it, and a proof of concept if you have one;
• the impact as you see it;
• whether you want to be credited, and under what name.

You may report anonymously. Write in English if you can. If you need to send something sensitive, say so in your first message and we will set up a secure way to receive it.

6. What you can count on from us

We rate severity by its real impact on customers, using the CVSS standard as a guide. Isolation failures and access to other customers’ data are critical by default.

7. Disclosure

We believe in coordinated disclosure. When the fix is out, we publish an advisory on our security notices, with credit to you if you want it, and request a CVE identifier where one applies. We ask you to wait for the fix, or 90 days from your report, whichever comes first, before you publish details. If a fix needs longer, we will explain why and agree a date with you. If the issue is being exploited, we may publish sooner, and we will tell you first.

8. Rewards

We do not run a paid bug bounty. We credit researchers publicly, with their permission, and we are grateful for every good report.

9. Questions

If something in this policy is unclear, or you are not sure whether a test is allowed, write to security@frazer.ai before you start. We would rather answer a question than receive a report we cannot accept.