Security and Vulnerability Disclosure Policy

1. Introduction

MIOSA builds infrastructure that customers use to run sandboxes, computers, agents and production workloads, and the security of that infrastructure depends on both our own engineering and on the work of the security community. If you believe you have found a vulnerability in any MIOSA product or service, we want to hear about it.

This policy governs how we receive, investigate and disclose security vulnerabilities, and it sets out the commitments we make to researchers who act in good faith. We follow a coordinated-disclosure model: we ask that you give us a reasonable opportunity to investigate and remediate an issue before you publish it, and in exchange we commit to acknowledging your report, keeping you informed, and telling you when a fix ships.

This policy applies to MIOSA-operated properties only. It does not authorise testing of systems we do not control, and it does not change any obligation you have under our Terms of Service or our Acceptable Use Policy.

2. Scope

In scope

We welcome reports concerning the MIOSA platform, including:

• The MIOSA API at api.miosa.ai, including authentication, authorisation, session handling and tenant isolation.
• The MIOSA dashboard and web application, including account, workspace, billing and team-management surfaces.
• The MIOSA documentation site and any other site we operate under the miosa.ai domain.
• Our official client libraries and SDKs, such as the TypeScript, Python and other published packages under the MIOSA organisation.
• The MIOSA CLI and its distribution channels.
• The MIOSA MCP server and any MCP tooling we publish.
• The sandbox and agent runtime, including Firecracker microVM isolation, the in-VM agent daemon, and the boundaries between one customer's workload and another's.

Cross-tenant access, authentication bypass, privilege escalation away from the permissions granted to your account, remote code execution on our infrastructure, and escape from the microVM boundary are all examples of issues we consider high priority in this scope.

Out of scope

The following are not in scope for this policy:

• Third-party services. Products we integrate with but do not operate, including payment processors and cloud providers. Report those to the provider directly; if a vulnerability in a third-party service is reachable through MIOSA, tell us and we will coordinate.
• Social engineering. Phishing, pretexting, impersonation and other attacks directed at MIOSA staff, contractors or customers.
• Physical attacks. Any attack against our offices, data centres, hardware or people.
• Automated scanner output. Findings produced by a scanner with no demonstrated, exploitable impact, including generic reports of outdated software versions without a working proof of concept.
• Denial-of-service and volumetric attacks. Do not attempt to exhaust resources, and do not run load or stress tests against our services.
• Missing security headers with no demonstrated impact. Absent headers are only actionable when you can show a concrete attack they enable.
• Self-XSS. Issues that require the victim to paste attacker-controlled content into their own browser console or address bar.
• Clickjacking on non-sensitive pages. Framing or UI-redress issues on pages that perform no state-changing or sensitive action.
• Reports requiring a compromised environment. Findings that depend on a device, browser extension, root certificate, network position or account the attacker already controls.

If you are unsure whether something is in scope, email us and ask before you start. We would rather spend a few minutes clarifying than have you spend hours on an out-of-scope test.

3. Rules of engagement

When researching against MIOSA, you must follow these rules. Activity that breaks them is not protected by the safe harbour in section 7.

• Test only what you own or are authorised to test. Use accounts, workspaces, organisations and sandboxes that you created and control, or that the owner has explicitly authorised you in writing to test.
• Do not access, modify or delete other people's data. If you encounter data that belongs to another customer, stop, do not copy it, and report what you saw.
• Do not exfiltrate data. Do not download, store or transfer data that is not yours. Use the minimum access needed to demonstrate the issue, and treat any incidental exposure as confidential.
• Do not run denial-of-service or load tests. Do not degrade, overload or disrupt the platform.
• Do not use social engineering, phishing or physical attacks. Against MIOSA, our staff, our contractors or our customers.
• Do not degrade service for other customers. Keep testing narrow, and stop immediately if you observe an effect on anyone other than you.
• Do not use automated scanning that generates significant load. Targeted manual testing is welcome; broad brute-force or high-volume fuzzing is not.
• Give us reasonable time to fix the issue before public disclosure. We ask for 90 days, and we will tell you if we need to move faster or slower.

4. How to report

Send your report to security@miosa.ai. This address reaches the security team directly, and it is the fastest path to a response.

If your report contains sensitive detail, such as a working exploit, credentials, or personal data, encrypt it before you send it. Ask us at the same address and we will provide a public key. We also publish contact details for security matters via our Trust Center, and you are welcome to reach out there if you prefer.

5. What to include

A clear, complete report lets us reproduce and fix an issue far faster. Please include:

• The affected product and component. The URL, endpoint, SDK method, CLI command or MCP tool involved, and the version or environment where you observed the issue.
• Steps to reproduce. A numbered sequence, or a minimal proof of concept we can run. Include requests, payloads and screenshots where they help.
• Impact. What an attacker can actually do, on what data or systems, and under what conditions. If the issue requires a specific account type, workspace configuration or feature flag, say so.
• Reproduction environment. Browser, operating system, SDK version or client used, and whether the issue is reproducible from a fresh account.
• How you would like to be credited. Your name, handle, or organisation, or a note that you prefer to remain anonymous.

6. Our response timeline

We commit to the following. These are targets, not contractual guarantees, but we hold ourselves to them.

• Acknowledgement within 3 business days. A human on the security team will confirm we received your report and begin triage.
• An assessment. We will tell you whether we were able to reproduce the issue, our initial severity assessment, and where possible a remediation timeline.
• Ongoing updates. We will keep you informed as the fix progresses, particularly if the timeline changes or we need more information.
• Notice when the fix ships. When a fix is deployed, we will tell you which products and environments are covered.

Severity and complexity both affect the timeline. A critical issue in the authentication path may be mitigated within hours, while a lower-severity issue in a complex subsystem may take longer to remediate correctly. We will be transparent with you about where things stand.

7. Safe harbour

We consider security research conducted in accordance with this policy to be authorised conduct. If you follow this policy, we will not pursue or support legal action against you for researching or reporting a vulnerability, and we will not report you to law enforcement for activity that complied with these terms.

If a third party brings legal action against you for activity covered by this policy, we will make it clear that your activity was conducted in accordance with this policy. This commitment applies only to good-faith research; it does not apply to anyone who violates the rules of engagement, exfiltrates customer data, degrades the service, or acts for extortion or other bad faith purpose.

8. Recognition

We are grateful to the researchers who help keep MIOSA and our customers safe. With your permission, we credit reporters who find and responsibly disclose valid security issues. You choose how you are listed, whether by name, handle or organisation, and you may also ask to remain anonymous.

We do not currently operate a paid bug bounty program. If you believe a reward is warranted, include that expectation in your report so we can discuss it openly before you invest further effort. Being forthcoming helps us be forthcoming with you.

9. Our security commitment

Vulnerability disclosure is one part of how we protect the platform. Our controls, security practices, and compliance posture are documented in our Trust Center, which includes our current status, our data-handling practices, and our list of subprocessors.

• SOC 2 Type I complete. We have completed a SOC 2 Type I audit covering security.
• SOC 2 Type II in progress. We are working toward a SOC 2 Type II report and will publish our status as it progresses.
• HIPAA-supported infrastructure. MIOSA supports workloads that handle protected health information, and we offer a business associate agreement where it is required.

For current detail, and for anything not covered by this policy, refer to the Trust Center. If you need a specific document, contact us and we will tell you what is available and under what terms.

10. Contact

Security reports: security@miosa.ai
Abuse reports: abuse@miosa.ai

Use the security address for vulnerabilities and anything covered by this policy. Use the abuse address for reports of misuse of the platform, including spam, malicious content, or customers violating our Acceptable Use Policy.