Security posture.

Imitation Engine is a small, independently operated product. Our security model reflects that honestly: minimise what we hold, put every check on the server, use managed providers for the hard parts, and keep no secrets in code that ships to customers.

• Data minimisation by architecture. No page content, no screenshots, no generated code, no target credentials and no source code ever reach us. Our API is a bookkeeping surface, not a pipeline.
• Server-side authority. Every entitlement, quota and permission check runs on our server. The plugin is a client; it decides nothing.
• No secrets in the client. The distributed plugin contains no API keys, no signing secrets and no bypassable logic. Reading it gives an attacker nothing that defeats billing or another account.
• Isolation by default. Database row-level security means an account can only read its own rows, enforced by the database rather than by application code remembering to filter.
• Managed providers. Authentication, database, hosting and payments are run by specialists. We do not build our own crypto, store card data, or operate our own servers.

If your organisation requires certified vendors for the data it would put through this product, we are not the right supplier and we would rather tell you now. What we can offer is an architecture that gives us very little of your data to lose.

A useful consequence: a total compromise of our servers would expose email addresses, subscription state, project names and URLs, and usage counters. It would not expose anyone’s cloned sites, generated code, or credentials for any target — because we never had them.

• Transport. HTTPS everywhere, HSTS on the production domain, TLS terminated by our hosting provider with modern cipher suites.
• Authentication. Sign-in is Google OAuth or an emailed one-time link, handled by our managed authentication provider. We never see or store a password, so there is no password database to leak.
• Authorisation. Postgres row-level security scopes every read to the owning account. Privileged writes go through server-side routes using a service credential that never reaches the browser.
• Encryption at rest. Provided by our database and hosting providers on managed, encrypted volumes.
• Input handling. Strict validation on names, URLs and status transitions; parameterised queries only; a request body size cap; a cap on projects per account.
• Rate limiting and abuse controls. Per-token hourly request limits, a cap on distinct machines per token per 24 hours, a cap on token regenerations per day, and an append-only event log that is both the audit trail and the rate-limit data source.
• Webhooks. Payment webhooks are verified by constant-time HMAC over the exact raw bytes received, then claimed idempotently against an event table so a replayed or reordered delivery cannot move your subscription state backwards.
• Least privilege. The plugin may only set a narrow set of project statuses. It cannot mark itself paid, extend its own access, grant its own quota or write another account’s rows.
• Dependencies. Lockfiles are committed, versions of security-relevant packages are pinned, and we update when advisories warrant it.

• A token is generated with a cryptographically secure random source, prefixed ie_, and shown to you exactly once.
• We store only a SHA-256 hash of it, plus a short display prefix and timestamps. We cannot read your token, recover it, or tell you what it was — only replace it.
• One active token per account. Regenerating revokes the previous one immediately and everywhere.
• Every use is logged with route, status, machine hash and timestamp, so unexpected use is visible.
• On your machine the token lives in ~/.imitation-engine/credentials.json, or in the IMITATION_ENGINE_TOKEN environment variable. Treat it like an SSH key: never commit it, never paste it into a shared terminal or a CI log, never put it in a screenshot.
• Suspect exposure? Regenerate it in Settings immediately — that is a self-serve kill switch — and email legal@imitationengine.com.

The plugin is code you install and run locally. It drives a headless Chromium, writes files into your working directory, and makes network requests to the targets you choose and to our API. Understand what that means for your own threat model:

• It runs with your user’s privileges. Run it as a normal user, never as root or administrator, and prefer a container or a dedicated machine for untrusted targets.
• It renders untrusted third-party web pages. That is inherent to cloning; Chromium’s sandbox is the boundary, and keeping it updated is your responsibility.
• It downloads assets from targets into your working directory. Treat extracted assets and generated code as untrusted input until you have reviewed them.
• Generated code is machine-written and may contain insecure patterns. Review it before deploying anything, anywhere.
• Artefacts under .imitation-engine/ can contain a recognisable copy of a target, including anything visible in an authenticated session. Keep them out of public repositories and off shared drives.
• Install only from our published marketplace and installer. Do not run a modified build, and do not install a copy from an unknown source.

• Card, bank and mandate details are collected and held by Razorpay, a PCI DSS compliant payment processor. They never pass through our servers and we never store them.
• We hold only Razorpay’s own identifiers — subscription, customer, plan and payment references — plus plan, amount, period and status.
• Checkout signatures are verified server-side with a constant-time HMAC before any subscription state changes, and state is always re-fetched from Razorpay rather than trusted from a redirect or a webhook payload.
• Our payment secrets and webhook signing secret exist only as server environment variables. Only the publishable key reaches the browser.

We build on managed platforms rather than operating servers. The current providers, what each sees, and their role are listed in the Privacy Policy: a managed Postgres and authentication provider, a hosting and edge provider, Razorpay for payments, and an email provider for transactional mail.

• Production secrets live in the hosting provider’s encrypted environment store, are never committed, and are rotatable.
• Access to production consoles is limited to the proprietor, protected by multi-factor authentication.
• Backups are the managed database provider’s automated snapshots. We do not offer per-account point-in-time restore, and you should not treat our database as a backup of your work.
• A provider’s own security posture is theirs, not ours. We choose reputable ones and rely on their controls; we cannot audit them for you.

• Source control with reviewed changes, typed end to end, with tests over the billing projection and quota arithmetic — the two places where a bug costs someone money.
• Metering and enforcement read the same ledger the dashboard displays, so what you are shown is exactly what was enforced.
• Billing writes fail open for paying customers and closed during a trial: bookkeeping must never block a paid run, and a trial that cannot be recorded cannot be capped.
• Webhook handlers return a server error on misconfiguration so deliveries are retried, rather than a client error that would cause the processor to disable the endpoint for everyone.
• No customer data is copied to development machines, and we do not restore production data into a test environment.

If we become aware of a security incident affecting our systems, we triage it, contain it, and assess whether personal data was involved. Where a notifiable breach has occurred we notify the relevant authorities and affected individuals within the timeframes the applicable law requires, as described in Breach notification.

We are a small operation without an on-call rotation. Response begins when we see the report — usually within one business day, and faster for anything that looks like active exploitation. Notification is not an admission of fault or liability.

Security here is shared, and several of the important controls are only available to you:

• Protect your email account — it is the recovery path for everything — and turn on multi-factor authentication there.
• Keep your plugin token secret, and regenerate it at the first hint of exposure.
• Keep Claude Code, bun, Chromium and your operating system patched.
• Never give the plugin credentials for a system you are not authorised to access, and never use someone else’s credentials.
• Review generated code before deploying it, and keep clone artefacts out of public repositories.
• Back up anything you care about. We hold no copy of your work and cannot restore it.

We welcome reports about our own systems — imitationengine.com, the dashboard, our API and the published plugin. Email legal@imitationengine.com with steps to reproduce, the impact you believe it has, and anything we need to confirm it. We will acknowledge within 3 business days, keep you updated, and credit you if you would like that.

Write to legal@imitationengine.com and put the subject in the first line — the same inbox handles vulnerability reports, suspected account compromise, abuse complaints and data-protection questions.

• Vulnerability reports — read Vulnerability disclosure first; safe harbour depends on following the rules there.
• Your account may be compromised — regenerate your token in Settings before you email us. That is the kill switch, and it is instant.
• Misuse by a customer — see the complaints process for what we can and cannot do about a cloned site.
• Privacy and data protection — rights requests are handled under the Privacy Policy.