Privacy notice

Privacy notice for people who deal with Mulno

This notice covers you if you: sign in to Mulno as a workspace member, admin or owner (through the web app, Mulno Studio, or a remote MCP client such as Claude Code, claude.ai or ChatGPT); are invited to a workspace; start a workspace's checkout as its billing contact; visit mulno.com or the product's own web pages, or use Mulno Studio; ask for a download link for Studio, the Unity package or the Claude Code plugin; join our beta waitlist on mulno.com, or someone else types your e-mail address into its form; write to us through the contact form on mulno.com (or the short one at the foot of its pages) or at developer@mulno.com, security@mulno.com, privacy@mulno.com or copyright@mulno.com; send us a copyright notice or counter-notice; or deal with us on a studio's behalf. It covers a game's testers only for the traffic log in §2. Everything else about their playtest is covered by the studio's own notice, published under its domain.

1. Who we are

Somnolent Team Limited (บริษัท ซอมโนเลนท์ ทีม จำกัด), registration no. 0105566229327, 374/19 Soi Lat Phrao 71, Khlong Chao Khun Sing, Wang Thonglang, Bangkok 10310, Thailand, trading as Mulno, decides what is collected about you under this notice and why: we are the controller. Contact us at privacy@mulno.com (privacy questions and rights requests) or security@mulno.com (a security concern). No EU or UK representative is named yet (GDPR/UK GDPR Art. 27). We name both before we open accounts to people in the EEA or the UK; until then, write to privacy@mulno.com directly. We have no data protection officer (not required at our size yet, GDPR Art. 37(1)(b), PDPA s.41(2)). Mulno accounts are not offered to people in the EEA or the UK until we name those representatives. For now, new Mulno accounts are offered only to studios in Thailand: we go by the country Cloudflare sees for the request (if it can't tell, we don't refuse), and an account that already exists works from any country. For the same reason, our Terms don't allow a campaign aimed at testers in Europe or Worldwide for now, and the product refuses those audiences. A campaign's audience is still only what the studio says it wants, though, and we don't check where a tester is, so not inviting testers in the EEA or the UK rests on the studio.

During the beta, a new account is also only for someone we have let in from our waitlist, or someone invited into an existing workspace (see "The beta waitlist" in §2). Only visitors from Thailand, or from a country Cloudflare can't tell, can join the waitlist; everyone else gets the website's contact form, whose messages the website doesn't keep (§4).

What a workspace keeps in Mulno — its recordings, notes, project and campaign names — is the studio's data, which we process for the studio under its DPA; the studio is its controller, including a note you write there. We are also the controller of the cross-studio capture-health statistics described in what we store.

2. What we collect, why, and on what basis

"Contract" below means: if you sign up for yourself, our Terms; if you were invited into a workspace as a member, section 19 of the Terms, which you accept when you join. If you act for an organisation (as the owner or an admin of its workspace, or as its billing contact), the contract is the organisation's, not yours, so for you the basis is instead our and that organisation's legitimate interest in giving its people the service it chose (GDPR Art. 6(1)(f), PDPA s.24(5)).

Cookies and browser storage. We set no analytics, advertising, error-tracking or support-chat cookie (the website's analytics, below, uses none) — see subprocessors.md. The product sets two cookies, both Secure, HttpOnly and sent only to our own servers: the sign-in session (__Host-mulno_session, gone once you sign out or it expires, §6) and, only while you connect a remote MCP client, a 10-minute cookie that ties the steps of that one sign-in together (__Host-mcp_flow). The website sets one more, mulno_lang, only when you pick a language with its EN | ไทย switch: it holds en or th for a year so the site keeps your choice, and it identifies no one. Joining, confirming or leaving the beta waitlist sets no cookie. Turnstile, on the sign-in page, runs from Cloudflare's own address under Cloudflare's terms and may use its own browser storage to do the check. The web app also keeps your display choices (layout, sort order, drawing settings) in your own browser's storage, and, if you review a Private project in the browser, the bucket key you give it stays in your browser; neither is sent to us.

Website analytics (www.mulno.com). The website, and only the website (not the app, Mulno Studio or the sign-in page), uses Cloudflare Web Analytics to count visits and measure speed. Visitors from the EEA and the UK are not measured: a rule on our side tells Cloudflare not to add the script when the country Cloudflare sees for the request is in the EEA or the UK. Cloudflare adds a small script to each page. It reads the figures your browser keeps about loading the page and sends Cloudflare a short report when the page has loaded and when you leave it: the page's address and the address of the page that referred you (both without any query string), your browser and operating system and their versions, timing and size figures for the page, how much memory the page used, and a random number for that one page load. Like every request, that report also carries your IP address and your browser's description of itself, from which Cloudflare works out your country and device type and whether the visit looks like a bot. Cloudflare says the service uses no cookie or other storage in your browser, and doesn't fingerprint you or use your IP address to follow you from one visit or site to another. What it shows us are counts and figures with no IP address, cookie or other identifier for you: we cannot see who you are from them and don't try. Cloudflare, Inc. does this for us as our processor, under its data processing addendum (§5); as on every request to our servers, its network also handles your IP address for its own security purposes, under its own privacy policy (§4). Our basis is our legitimate interest (GDPR Art. 6(1)(f), PDPA s.24(5)) in knowing how the website is found and how it performs. We don't ask for consent and show no cookie banner. You can object at any time (§7). Because nothing in it identifies you, the way to stop it for your own browser is to block it: your browser's tracking protection or an ad blocker does, and the website works the same without it. For the same reason we couldn't pick out your visits to give you a copy or delete them.

The beta waitlist (www.mulno.com). While Mulno is in beta, a new account is opened only for someone we let in from our waitlist, or someone invited into an existing workspace. Only visitors from Thailand, or from a country Cloudflare can't tell, can join: from anywhere else the website shows "Coming soon" and its contact form instead, and our servers send a waitlist post from a country Cloudflare places outside Thailand to that contact form and keep nothing from it. When the form is sent, we keep the entry and e-mail the address a link to confirm it is yours; the page says the same "check your inbox" whatever the address's state. If the address already has a Mulno account, the e-mail we send it says so and nothing is added to the list. If the address is on the list and confirmed, nothing is sent and nothing changes; if it is on the list but not confirmed, the new form's answers replace the old ones and we send a new confirmation e-mail, and only the newest confirmation link works. We send an entry at most three confirmation e-mails: after the third, sending the form again for the same address sends nothing and changes nothing; an address that already has an account is told so at most once every 24 hours. We send at most one waitlist e-mail to an address every 10 minutes (for Gmail addresses, dots in the part before the @ are ignored for this, as Gmail ignores them), and the waitlist has its own limits on e-mail: at most 10 a day to one network, and 300 a day in total, which also counts the e-mail that tells someone they're in. When a limit is reached nothing is sent and the page you see is the same. An entry appears on our list only once its confirmation link is clicked; until then it is kept only to wait for that click, and our daily clean-up deletes an entry never confirmed once 7 days have passed since our last e-mail to that address. So if someone typed your address without asking you, you can ignore our e-mail: nothing more happens, and the entry goes within those 7 days, or at once with the link in that e-mail. The list is seen only by Mulno's owner, on a page of the web app that only the accounts named in our configuration can open; no AI agent reads it, and a person, not a program, decides whom to let in. Letting you in is recorded on your entry (when, and which of our accounts did it) and in our request logs by the entry's id alone. We then e-mail you that you're in, with a link to app.mulno.com, where you sign in as usual. As soon as an account exists for your address (you signed in, or you accepted an invitation to a workspace), we delete your entry. A confirmed entry is deleted 12 months after you joined if no account has been made by then. Our waitlist e-mails go out in the language of the form you used, and every one has a link to take you off the list, which works for as long as your entry exists and deletes it at once. Like any request to our servers, sending the form is written to our request logs and the traffic log (above), and counts towards the limits on how many e-mails one address and one network can be sent (§6); the network's waitlist limit counts every form sent from it, whatever the address's state.

Do you have to give us this? An e-mail address is needed to have an account — without one we can't sign you in. Everything else is either created as you use the service or optional. To join the waitlist, only an e-mail address is needed; the rest of the form is optional, though it helps us decide.

What we never collect under this notice: a name for your account (an account is only an e-mail address; we have your name only where you type it yourself — on the waitlist or contact form, in a message, or in a copyright notice), payment card details (Paddle collects those directly, as merchant of record), or anything about a game's testers beyond the traffic log — the rest is the studio's data, under the DPA, not ours.

No automated decisions. We make no decision about you based solely on automated processing that has legal or similarly significant effects on you (GDPR Art. 22). Who is let in from the waitlist is decided by a person. Automatic limits and steps — a plan's quota, a rate limit, the Turnstile check, whether the refund button is offered, a plan ending when Paddle approves a full refund or reports a chargeback — apply to a workspace's use of the service, or stop automated abuse; if one stops you wrongly, write to us and a person looks at it.

3. Where it comes from

• Directly from you: the e-mail address you type to sign in; what you type on the waitlist form; what you write when you contact us.
• From someone else, on the waitlist form: if someone types your e-mail address there, we learn it, and whatever else they typed, from them. We e-mail you to ask you to confirm (at most once every 10 minutes); if you don't, the entry is deleted within 7 days (§2).
• From a workspace admin: if someone invites you to their workspace, we learn your e-mail address from them, not from you.
• From your browser, Studio or MCP client: connection metadata, and the projects and scopes you tick when a remote MCP client asks to connect.
• From Cloudflare: whether the Turnstile check passed; and, from its Web Analytics, website visit figures (page views, referrers, browser, country, speed) with no identifier for you.
• From a copyright notice or counter-notice: what its sender tells us, which may be about you (for example, that material you put in a workspace infringes their work), and a copy of the other side's notice or counter-notice when you are part of the complaint.
• From Paddle: confirmation that a checkout, subscription, refund or chargeback event happened and, when an admin opens the Billing page's refund option, the latest payment's amount, date and kind (never card details).

4. Who receives it

• Your workspace. Its members see your e-mail address and role; its admins can also read and export its audit log, which names you on the entries for what you did.
• Our own team. Access to production is limited to the owner today, who signs in to every production account with multi-factor sign-in (see caiq-lite.md). A production change is made by the owner, or by an AI agent only after the owner's explicit confirmation of that specific change. AI agents don't read personal data in our production databases, our logs or our mailbox. The beta waitlist is seen only by the owner (§2).
• Cloudflare, Inc., our infrastructure — see subprocessors.md. It runs every server we have (Workers, D1, Workers KV, R2, Workers Logs), sends our sign-in, invitation and beta-waitlist mail and the notice a workspace's owners get when a plan change shortens how long it keeps sessions, runs Turnstile, measures the website's visits and speed (Web Analytics, §2), and its network sees your connection's IP address and approximate location on every request.
• Our mailbox. Cloudflare Email Routing receives what you write to privacy@, security@, developer@ or copyright@mulno.com and forwards it, without storing it, to Mulno's mailbox at Google LLC (Gmail), where it is kept. Google provides that mailbox under its own terms and privacy policy. A message sent through the website's contact form, or the short one at the foot of its pages, reaches the same mailbox as one e-mail to developer@mulno.com, sent by Cloudflare Email Service; the website keeps no copy and no log of what you typed, and we use it only to reply. (The beta waitlist form is different: its entries are kept, as §2 and §6 say.) We use the mailbox only for our own correspondence: studios and testers send requests about a playtest session through our product, not by e-mail.
• Paddle.com Market Limited, for a billing contact only — see subprocessors.md. Paddle is the controller of what it collects at its own checkout.
• Your own AI provider, if you connect an MCP client: what you ask your assistant to read goes to that provider under your own account with it, not ours.
• The other side of a copyright complaint (Terms section 20): the owners of the workspace a notice is about get a copy of it, and the person who complained gets a copy of a counter-notice, with its sender's name, postal address, phone number and e-mail address. We don't publish either.
• Authorities, only where the law requires it. The traffic log is kept so that an authority entitled to it under the Computer-Related Offences Act can ask for it.

We don't sell this data, and we don't use it for advertising.

5. Where it is processed, and transfers

We are in Thailand, which has no adequacy decision from the EU or the UK. When you sign in or write to us yourself, you give your data directly to us: in the European Data Protection Board's reading (Guidelines 05/2021, version 2 of 14 February 2023, example 1) that is not a "transfer" under Chapter V of the GDPR. Mulno doesn't offer accounts to people in the EEA or the UK and, for now, opens new accounts only to studios in Thailand, from its waitlist (§1). Where the GDPR or UK GDPR applies to our processing anyway, this notice is written to meet them.

Where it is kept:

• Your account, sign-in records, Terms acceptances and download records: a Cloudflare database placed in Asia-Pacific — a location preference, not a guarantee (see security.md).
• The beta waitlist: the same Cloudflare database as your account, placed in Asia-Pacific, as above.
• The traffic log: Cloudflare databases placed in Asia-Pacific, as above.
• Your membership, invitations, a workspace's legal name and the audit log: in the region the workspace chose when it was created — the EU (Cloudflare's guaranteed EU jurisdiction), Asia-Pacific or the US (location preferences).
• A remote MCP client's connection: Cloudflare Workers KV, which keeps copies worldwide.
• Our request logs: Cloudflare Workers Logs.
• Website analytics: Cloudflare Web Analytics, in the United States (Cloudflare offers no EU location for it).

When we pass it on, these safeguards apply:

• Cloudflare, Inc. (US): its data processing addendum, which includes the EU standard contractual clauses and the UK Addendum, and its certification under the EU–US Data Privacy Framework and its UK extension.
• Paddle.com Market Limited (UK): the EU's adequacy decision for the UK (renewed in December 2025).
• Google LLC (USA, our mailbox provider): its certification under the EU–US Data Privacy Framework and its UK extension.

Under Thai law, sending your data abroad from Thailand relies on Cloudflare's safeguards (PDPA s.29) or, for Paddle and our mailbox, on what's needed to carry out the purchase you asked for or to answer the message you sent us (s.28). A copy of a copyright notice or counter-notice goes to the other side of the complaint wherever they are, which may be a country whose law protects personal data less than Thailand's: passing it on is what Thailand's Copyright Act tells a host to do, and the reason the notice is sent (PDPA s.28, compliance with the law; GDPR Art. 49(1)(e), legal claims). Ask us for a copy of any safeguard at privacy@mulno.com.

6. How long we keep it

Deleted rows can remain in Cloudflare's point-in-time database backups for up to 30 more days; this cannot be turned off (a Cloudflare platform limit).

When a workspace is closed. Its owner closes it in the workspace's settings. Every membership, invitation and AI connection in it is removed at once. From 14 days later we delete the workspace's own rows, including its legal name and its record of who accepted the Terms for it, and we finish within 30 days. At the same moment we take your e-mail address, your account id and the hash of your IP address off its audit log; the entries themselves stay without them until each entry's year ends (above). Your account isn't affected: erase it separately if you want it gone.

7. Your rights

Depending on where you live, you can ask us to: tell you what we hold about you and give you a copy; correct it; delete it; restrict how we use it; object to our use of it (always, where we rely on legitimate interests); or give you what you gave us in a machine-readable form, or send it to someone else (portability). Where we rely on your consent for something, you can withdraw it at any time (today, nothing above rests on consent). The traffic log is kept because the law requires it, so we can't delete an entry before its 90 days on request, and finding yours needs the IP address and time you used.

Write to privacy@mulno.com from the address your account uses, so we can find your record; we answer within one month (30 days in Thailand) and may ask you to confirm it's you.

Leaving the waitlist. Every waitlist e-mail has a link that takes you off the list: it deletes your entry at once (a backup copy can remain up to 30 more days, §6). You can also write to privacy@mulno.com from the address you joined with.

Erasing your account. You can do it yourself: in a workspace's settings, choose Erase my account and type your e-mail address. If you are the only owner of a workspace that is still open, hand it to someone else or close the workspace first. If you no longer belong to any workspace (for example after closing your last one), the button isn't there: write to privacy@mulno.com from your account's address and we do it. Erasing is immediate. We delete your account, its sign-in links and sessions, your memberships, your pending invitations, the AI connections you made and your download and update-check records, and we take your e-mail address off the audit log's entries. What stays: those audit-log entries, with an opaque account id instead of your address, until their own retention ends (§6), kept so the workspace can still see what was done; the record of which Terms you accepted, under the same opaque id, and a workspace's record of who accepted for it (§6), kept as the record of what was agreed; the record that your account was erased (§6); notes you wrote in a workspace, which are the studio's (§1); Paddle's own records, including a billing contact's e-mail address (§6); and our backups, request logs, traffic log and sign-in rate-limit counter until they expire (§6).

You can also complain to a data protection authority: in the EU, the one where you live or work; in the UK, the Information Commissioner's Office; in Thailand, the Office of the Personal Data Protection Committee (PDPC).

8. Children

A Mulno account is for people working at or with a studio — we don't knowingly open one for a child, or keep a child on the waitlist. If you believe a child has an account or a waitlist entry under this notice, write to privacy@mulno.com and we'll remove it. (A game's testers, who may be any age a studio's own notice allows, are covered by that studio's notice instead, §1 above.)

9. Security

See security.md for how we protect what we hold. If a breach of what we hold about you is likely to put you at high risk, we tell you without undue delay (GDPR Art. 34, PDPA s.37(4)).

10. Changes to this notice

If we change this notice, we update the version and date at the top. A change that reduces your rights is announced here at least 30 days before it takes effect.

11. Contact us

privacy@mulno.com (privacy questions, rights requests) or security@mulno.com (a security concern).

What changed in version 12

• The opening and §2: people who ask for a download link for Studio, the Unity package or the Claude Code plugin, or whose signed-in Studio checks for updates. A new row says what a download record holds (your account id; which file a link was made for, or for an update check the platform; a random link id; when it was made and when it expires; no IP address, no e-mail address), why (to trace a download link that was passed on, or misused, back to the account it was made for, and an update-check token copied off a PC likewise; nothing else) and the basis (legitimate interests), and that the request that makes a link is also in our request log and traffic log while the file itself and Studio's update check are answered by updates.mulno.com, which keeps no log. The row on Studio's check for updates now says that, from Studio 0.4.2, the check carries a token we can link to your account.
• §5, §6 and §7: the records are kept in the same database as your account; a download record is deleted automatically after 90 days and an update-check record after 14 days; erasing your account deletes them. §6 also names the per-account counter that limits how often an account can make download links.

What changed in version 11

• §1: our company's English name is written as Thailand's company register has it, Somnolent Team Limited (it was Somnolent Team Co., Ltd.). It is the same company, บริษัท ซอมโนเลนท์ ทีม จำกัด, registration no. 0105566229327, and nothing else changes.

What changed in version 10

• The opening, §1 and §2: people who join the beta waitlist on mulno.com (from Thailand, or a country Cloudflare can't tell), and people whose address someone else typed into it: what we keep, why and on what basis, and that during the beta a new account is only for someone we let in from the waitlist or someone invited into a workspace. "What we never collect" no longer says we never have your name: we have it where you type it.
• §2 and §4: the short contact form at the foot of the website's pages is named; like the contact form, it keeps nothing on the website (what it sends also says which page it came from and in which language). The waitlist form is the one whose entries are kept.
• §3, §4 and §5: where an entry comes from, that only the owner sees the list, that Cloudflare sends its e-mails, and where it is kept.
• §6, §7 and §8: an entry never confirmed is deleted 7 days after our last e-mail to it, a confirmed one when an account exists for the address or 12 months after joining, whichever comes first; every waitlist e-mail has a link that deletes the entry at once. §6 also names the counters that limit e-mail: a hash of the address for the waitlist, and the network a request came from (the latter already counted sign-up e-mails before this version, and wasn't named).
• Cookies: the waitlist sets none.

What changed in version 9

• §2, "Cookies and browser storage": the website sets one cookie, mulno_lang, only when you pick a language with its EN | ไทย switch. It holds en or th for a year so the site keeps your choice, and it identifies no one.

What changed in version 8

• The opening and §2: people who send us a copyright notice or counter-notice (Terms section 20), what we collect from them and why, and the record of copyright strikes against a workspace or an account.
• §3, §4 and §5: where that comes from; who receives a copy (the workspace's owners get a notice, the person who complained gets a counter-notice); copyright@mulno.com joins our mailbox; and sending a copy abroad.
• §6: notices, counter-notices and strikes are kept up to 3 years after the complaint is closed.

What changed in version 7

• §1 and §5: for now, new Mulno accounts are offered only to studios in Thailand; an account that already exists works from any country.
• The opening, §2 and §4: the contact form on mulno.com sends one e-mail to developer@mulno.com, and the website keeps no copy.

What changed in version 6

• §1: the product now refuses campaigns aimed at Europe or Worldwide.
• §2: the Terms record also covers an AI client's sign-in and keeps the workspace's legal name at the moment of acceptance; the legal name can be given when a workspace is created; the audit log also records refunds asked for, exports, sessions deleted or restored, closing a workspace and a member erasing their account; automatic steps include the refund button and a plan ending after a full refund or a chargeback.
• §3 and §4: what Paddle tells us about refunds and chargebacks; Cloudflare also sends the notice of a plan change that shortens retention.
• §6: erasing an account (yourself, or by asking us), what happens to the audit log's entries and the Terms record when you do, the legal name's copy on the Terms record, the record that an account was erased or a workspace closed, and what closing a workspace deletes and when, including every member's address, account id and IP-address hash on its audit log, whose entries then stay without them until their year ends.
• §7: erasing your account in the product, and what stays.