Security

What we can prove about security — and what we do not claim

PolyDraft publishes nothing without a human approving it, deploys each finished site to infrastructure the customer owns and controls, and keeps the admin panel behind a private path with deny-by-default authorization. Report a security issue to support@polydraft.ai — never include passwords or keys.

Nothing publishes without a person

The build is automated; the decision to publish is not. The agent produces the research, the copy and the pages, and then hands them to you in a live preview. You read them, ask for changes in chat, and publish when you are satisfied. This is also the boundary that makes our editorial policy enforceable: a named person approves what goes out.

  • A human approves every publish

    The agent researches, writes and builds, then stops. Pages go live when the account owner reviews them and chooses to publish. There is no path where generated content reaches a public domain without a person deciding it should.

  • The admin panel lives at a private path

    Each site’s admin entrance is a randomized path known only to the owner, and it is never disclosed in robots.txt — listing it there would publish the secret it is meant to keep. Admin pages are also marked noindex, so they stay out of search results.

You own the domain, the cloud account and the code

A finished site deploys with one click into the customer’s own cloud account, under the customer’s own domain. That is a security property as much as a commercial one: the running site, its database and its uploaded files sit inside infrastructure you control and can revoke our access to. Update deployments do not reset or overwrite live content, and cancelling a subscription does not take a deployed site down. On the Agency plan the full source code exports, so the site can outlive the relationship. The mechanics are on what connects to what.

Admin access and authorization

  • The admin panel lives at a private path

    Each site’s admin entrance is a randomized path known only to the owner, and it is never disclosed in robots.txt — listing it there would publish the secret it is meant to keep. Admin pages are also marked noindex, so they stay out of search results.

  • Server actions are deny-by-default

    Every action requires an authenticated admin session except three that must work for anonymous visitors: sign-in, sign-out and the contact-form submission. Adding a new action grants it nothing until it is explicitly allowed.

  • Sessions are cookie-scoped and secure-only

    The admin session cookie is issued with the secure flag, so it is not transmitted over a plain-text connection.

Sign-in to the builder uses a Google account, so we never store a password of yours.

Forms, spam, and what a submission records

  • Optional anti-spam on contact forms

    Inquiry forms support Cloudflare Turnstile. It stays invisible until the site owner supplies their own keys in Settings; once the secret key is present, the server verifies each submission rather than trusting the browser.

  • A cookie-consent banner ships with every site

    Every generated site includes a consent banner the visitor can accept or limit. It is a functioning interface control, and we describe it as nothing more than that.

One thing worth stating plainly rather than burying: when a visitor submits an inquiry form on a generated site, the submission is stored with the sender’s IP address and the country it resolves to, alongside the fields they filled in. That data lands in the site owner’s own database, not ours. If you run a site built with PolyDraft, this is yours to disclose to your visitors.

Reporting a security issue

Email support@polydraft.ai with the subject line Security. Describe what you found, the URL involved and the steps to reproduce it.

  • Never send credentials. Do not include passwords, API keys, session cookies or access tokens in a report. If a key is exposed, tell us where — not what it is.
  • Do not test against other people’s sites. Sites built with PolyDraft run in their owners’ infrastructure. Test against your own project only.
  • Give us time before disclosing. We ask for a reasonable window to investigate and fix before a report is made public.

For context on general enquiries, a real person replies to a first message within five business days. That is a support expectation for ordinary mail, not a security response commitment — we do not publish one, and the list below says so.

Unsupported claims

What we do not claim

Most security pages are written to imply more than they can support. Here is the explicit list of things we are not asserting, so nobody has to guess from what is missing.

  • We hold no SOC 2 report and no ISO 27001 certification, and we have not been audited against either.
  • We have not commissioned a third-party penetration test and we do not run a bug bounty programme.
  • We publish no uptime SLA, no guaranteed response time for security reports, and no round-the-clock staffed coverage.
  • We make no data-residency guarantee. Where a deployed site’s data lives is determined by the cloud account it is deployed into, which is the customer’s own.
  • We publish no encryption specification and no backup or recovery guarantee for content held in a customer’s own deployed infrastructure.
  • We are not a security vendor, and nothing on this page should be read as an assessment of any site built with the platform.

If your procurement process needs something on this list, tell us what and why at support@polydraft.ai. A straight answer about what we do not have is more useful to you than a vague one about what we might.