Browse docs All docs
Introduction
Building your app
Configuration & deployment
Domains, previews & access
Databases
Storage
API
Account & team administration
Trust & security
Legal & policies
Docs / Vulnerability Disclosure Policy
Docdeploymill://docs/vulnerability-disclosure

Vulnerability Disclosure Policy

Last updated: June 12, 2026

DeployMill's whole premise is that it's safe to hand an autonomous AI agent the keys to production. We take that claim seriously, and security researchers who probe it are helping us keep it true. If you've found a vulnerability anywhere in the control plane, the MCP API, the secrets hand-off, or tenant isolation, we want to hear about it, we'll work with you in good faith, and we'll say thank you publicly if you'd like.

This policy explains what's in scope, the rules of engagement, our safe-harbor commitment, how to report, and what happens after you do.

Our commitment

  • We will acknowledge your report, keep you informed while we investigate, and tell you when the issue is fixed.
  • We will not pursue legal action against good-faith research conducted within this policy (see the safe harbor below).
  • We will credit you for the find if you want credit, or keep you anonymous if you prefer.
  • We treat the most security-critical claims of the product as the highest-priority targets: the zero-readback secrets vault, tenant isolation, OAuth token scoping, and the agent-safety guardrails described in Trust & Security. A real break in any of them gets our immediate attention.

Scope

In scope:

  • deploymill.com: the website, dashboard, sign-in/OAuth flows, and the /api surfaces.
  • The MCP API: the POST /mcp endpoint, the OAuth token issuance flow, MCP tools and resources, and anything reachable with an MCP access token. Findings where an agent-held token can do something it shouldn't (read a secret value, cross a tenant boundary, escalate scope) are exactly what we most want reported.
  • *.deploymill.app, where the vulnerability is in our infrastructure: the ingress and TLS layer, routing, preview isolation, tenant network isolation, or the platform-injected runtime environment.

A critical boundary on *.deploymill.app: the applications served under those subdomains are built and owned by our customers. A bug in a customer's own app code is theirs, not ours, so please report it to that customer, not to us. More importantly: other tenants' apps and data are never an authorized target. Test against your own workspace and your own apps. If a platform flaw unexpectedly exposes another tenant's data, stop immediately, do not explore further, and report it to us (see the rules below).

Out of scope (systems): third-party services we use (GitHub, Cloudflare, Neon, Supabase, Google, etc.; see Subprocessors). Report issues in those to their own programs. Social engineering of DeployMill staff or customers, and physical attacks on infrastructure, are never in scope.

Safe harbor

If you make a good-faith effort to comply with this policy while researching and reporting, we consider your research authorized under applicable anti-hacking and anti-circumvention laws (such as the CFAA and DMCA in the US, and their equivalents elsewhere, to the extent within our control):

  • We will not initiate or recommend legal action against you for your research.
  • We will not report you to law enforcement for activity conducted within this policy.
  • If a third party brings legal action against you for research that complied with this policy, we will make it known that your activities were authorized by us.
  • We waive any claim under our Terms of Service and Acceptable Use Policy for good-faith security research that follows this policy's rules.

This safe harbor applies only to research that stays within the rules of engagement below, and it cannot authorize actions against systems or data that belong to third parties (including other DeployMill customers). If you're unsure whether something is covered, ask us first at [email protected]. We'd rather answer a question than have you guess.

Rules of engagement

Good-faith research means:

  • Test only against accounts, workspaces, and apps you own or control. Create your own workspace. Don't probe anyone else's.
  • Don't access, modify, or destroy data that isn't yours. If demonstrating an issue requires touching data, use your own test data.
  • If you encounter another tenant's data, stop. Don't read further, don't copy more than the minimum needed to demonstrate the flaw, don't share it, and report it to us immediately. Delete anything you retained once we confirm receipt.
  • No denial of service. Don't run load tests, resource-exhaustion attacks, or anything designed to degrade the platform for other customers.
  • No social engineering (phishing, vishing, pretexting) of DeployMill staff, contractors, or customers, and no physical attacks on infrastructure or offices.
  • Don't pivot. If you gain unexpected access (to infrastructure credentials, another tenant, an internal system), demonstrate the initial flaw and report, but don't use the access to go deeper.
  • Use automated tooling responsibly. Keep scan rates reasonable. A scanner that hammers the API is a denial-of-service problem, not research.
  • Give us reasonable time to fix the issue before public disclosure. We ask for coordinated disclosure (timelines below) rather than zero-day publication.

How to report

Email [email protected] with as much of the following as you can:

  1. What you found: the type of vulnerability and where it lives (URL, endpoint, MCP tool name).
  2. Steps to reproduce: a precise, numbered walkthrough from a clean state. The faster we can reproduce it, the faster we can fix it.
  3. Impact: what an attacker could actually do with it (read another tenant's secrets? escalate an agent token? take down ingress?).
  4. Proof of concept: scripts, requests/responses, screenshots, or a recording. Redact any real customer data.
  5. Your environment: workspace/org slug used for testing, relevant timestamps (these help us correlate with our audit trail), and how you'd like to be credited (or that you'd prefer anonymity).

For encrypted reports: [PGP key / encrypted contact channel: confirm and publish fingerprint].

Please report each distinct vulnerability separately unless they chain together to demonstrate combined impact.

Our response & disclosure process

  1. Acknowledgement: we aim to acknowledge your report within 3 business days.
  2. Triage: we aim to confirm or decline the finding, assign a severity, and give you an initial assessment within 10 business days. We'll tell you what we concluded either way.
  3. Fix: we prioritize by severity. Breaks in the core guardrails (secrets readback, tenant isolation, token scoping) are treated as incidents and worked immediately. We'll keep you updated on progress for anything that takes longer.
  4. Coordinated disclosure: we ask that you hold public disclosure until we've shipped a fix or 90 days have passed since your report, whichever comes first. If we need longer for a genuinely hard fix, we'll ask and explain why. We're happy to coordinate on the content and timing of a public write-up, and we won't ask you to suppress one indefinitely.
  5. Recognition: with your permission, we'll credit you when we disclose the issue. There is [no paid bug bounty yet / bounty status: confirm], so we currently offer recognition and our genuine thanks, not cash. If that changes, this page will say so.

If an issue you report involves customer data exposure, our notification obligations under the DPA and Privacy Policy apply in parallel, and your report may trigger customer notification on our side. That's a good outcome, not something to avoid reporting.

Out of scope (findings)

The following are generally not accepted unless you can demonstrate a real, exploitable impact:

  • Missing best-practice headers (CSP, HSTS, X-Frame-Options, etc.) without a demonstrated exploit.
  • Missing or "weak" rate limiting, absent a demonstrated practical attack.
  • Self-XSS, or issues requiring a victim to paste code into their own console.
  • Clickjacking on pages with no sensitive state-changing actions.
  • Raw output from automated scanners with no proof of concept or analysis.
  • Version disclosure, banner grabbing, or "outdated software" reports without a working exploit against our deployment.
  • Email security configuration (SPF/DKIM/DMARC) reports without a demonstrated spoofing impact.
  • Issues only exploitable with physical access to a victim's unlocked device, or requiring rooted/jailbroken clients.
  • CSRF on logout or other no-impact endpoints.
  • Vulnerabilities in customer-built applications on *.deploymill.app (the app's own code, so report those to the app's owner).
  • Social-engineering or phishing susceptibility findings (these violate the rules of engagement anyway).

If you think your finding looks out-of-scope but has real impact, send it anyway and make the impact case. We read everything.

security.txt

We publish this policy in machine-readable form at https://deploymill.com/.well-known/security.txt (RFC 9116):

Contact: mailto:[email protected]
Expires: 2027-06-12T00:00:00.000Z
Preferred-Languages: en
Canonical: https://deploymill.com/.well-known/security.txt
Policy: https://deploymill.com/docs/vulnerability-disclosure

Contact

This policy is part of DeployMill's trust documentation. See Trust & Security for the full set.