# Privacy policy

> Page: https://docs.plotwork.dev/privacy-policy. Index of every page: https://docs.plotwork.dev/llms.txt

This policy says what personal data Plotwork collects, why, how long it is kept, who handles it for us, and how to use your rights. It covers the Plotwork website, the documentation, the portal, the HTTP API, and the hosted MCP (Model Context Protocol) server. It does not cover the npm package you run on your own device, which sends nothing to us.

Last updated: 2026-10-20

## TL;DR

| Question | Answer |
|---|---|
| Who is responsible for your data? | Buun Group Pty Ltd, ABN 75 687 193 675, registered in Spring Mountain, QLD 4300, Australia. |
| What do you collect? | If you make an account: your email address, when you signed in, your API key details, the agents you connected, daily call counts, and a short record of account actions. If you use an organisation, we also store who belongs to it and the email addresses of the people invited to it, and on Pro and Enterprise its audit log: who changed what in it, and the network the change came from. If your organisation signs you in through its own identity provider, we store which account at that provider is yours, never a token from it. If your Enterprise organisation sends its audit events and drift results to its own tools, such as Datadog or Microsoft Sentinel, we store where to send them, with the secret sealed, and send copies there at its request. If you send an Enterprise enquiry, we store what you typed in the form for 24 months, and from the portal, where you opened it, your account and the organisation you opened it from. If your organisation is on an Enterprise contract, we store the name and email address of its billing contact with the contract's terms, and if you ask for help on its Support page, we store your request and what you wrote in it for 365 days. If you only read the sites, we store no data about you in our database. |
| What do you not collect? | The content of your diagrams. Diagram source is worked on in memory to produce the answer and is not stored or logged. A view link carries the source after `#`, which a browser never sends to us, so opening one sends us no diagram, but anyone given the link can read it. The one exception is a diagram you choose to publish, to a public link or to an organisation: its picture is kept so the link or the library works. If you also turn on `embedSource` when you publish, save the diagram in the portal's editor, or publish to an organisation whose owner keeps diagrams editable, the diagram source is written into that picture and kept with it. See Hosted diagrams and Organisations below. |
| Who handles payments? | Stripe. Plotwork never sees or stores your card number. It stores only your Stripe customer and subscription ids, your plan, its status, the end of your billing period, whether and when it is set to cancel, and whether Plotwork gave it to you at no charge. See Payments below. |
| Do you count how Plotwork is used? | Yes. The hosted service keeps anonymous daily totals. The local npm package sends pseudonymous daily totals, with a random identifier that changes every month, only if you turn it on, and it is off unless you do. Neither can be linked to your account. See Usage totals below. |
| Do you sell data or show ads? | No. Plotwork shows no advertising and does not sell or rent personal data. |
| Is there analytics? | Google Analytics runs on plotwork.dev and docs.plotwork.dev only if you press Accept analytics. It never runs on the portal. See the [cookie policy](https://docs.plotwork.dev/cookie-policy.md). |
| Where do I ask a question or use a right? | Write to legal@buungroup.com. We answer a request about your account within 30 days. |

## Who we are

Plotwork is run by Buun Group Pty Ltd ("Buun Group", "we", "us"). Buun Group decides why and how the personal data described here is used. That makes it the controller under the GDPR (General Data Protection Regulation) and the organisation that answers for the data under Australian privacy law.

| Detail | Value |
|---|---|
| Legal name | Buun Group Pty Ltd |
| ABN (Australian Business Number) | 75 687 193 675 |
| Registered office | Spring Mountain, QLD 4300, Australia |
| Privacy and legal contact | legal@buungroup.com |

## What we collect and why

Most of this is data about an account. A visitor who never signs in has no account data. The table lists every kind of personal data we hold or process, where it lives, and how long it stays.

| Data | Where it lives | Why | How long | Basis |
|---|---|---|---|---|
| Your email address, an account id, the time the account was made, and the time of your last sign-in | The Plotwork account database, hosted by Cloudflare | To make your account when you first sign in, and to know which keys and connections are yours | Until the account is deleted | Contract |
| Sign-in codes: your email address, a hash of the six-digit code, the times, and a count of wrong guesses | The account database | To check the code you type, and to limit guessing and repeated requests | A code works for 10 minutes. Codes older than one day are deleted the next time anyone asks for a code. | Contract and legitimate interests |
| Sign-in sessions: a hash of your session token, the times it was made, last used, and expires, and, for a session opened through an organisation's identity provider, that organisation's id | The account database. The token itself is in your browser (see the cookie policy). | To keep you signed in | 30 days after you last use it, or until you sign out, which deletes the row. A row for a session that ran out on its own stays until the account is deleted. | Contract |
| API keys you make: the name you gave, the start and last four characters, a hash of the key, an encrypted copy of the key, and the times it was made, last used, and revoked | The account database | To check your key on each call, and to let you list, reveal, and revoke it | Until the account is deleted, which deletes the row and the encrypted copy with it. Revoking a key deletes its encrypted copy and keeps the rest of its row. | Contract |
| Agent connections: the name an agent gave itself, its client id, and details of the key made for the connection (a hash, and the start and last four characters). For an agent whose client id is a web address (a client ID metadata document), also the return address its sign-in used, which is usually a port on your own computer | The account database | To list your connections and let you end them. The return address tells two computers running the same agent apart, so connecting it on one does not disconnect the other | Until the account is deleted | Contract |
| Agent sign-in records: the agent's registered name and return address, and a grant that holds your account id and the connection's key, kept encrypted | The hosted MCP server's store at Cloudflare | To let an agent you approved call the tools without a pasted key | A registration lasts up to 90 days, an agent's refresh token up to 30 days, and an access token one day. Ending the connection stops the grant working on the agent's next use. | Contract |
| Daily call counts: your account id, the UTC date, and how many API calls and MCP tool calls you made, including calls made with the key of an organisation you own | The account database | To keep each account inside its daily allowance, and to show your usage in the portal | Until the account is deleted. Nothing removes old days automatically. | Contract and legitimate interests |
| Hosted diagrams, if you publish any: the picture (an SVG file, which also carries the diagram's own id and, only if you turn on `embedSource` when you publish or save the diagram in the portal's editor, the diagram source), up to ten earlier pictures of it that a save in the editor replaced (kept in the file storage with no public address), and a record with its name if you gave one, the folder you filed it in if you did, its size, its theme, when it was first and last published, when it expires, the time you locked it if you did, a random token that is part of its public link, a hash of the picture, and your account id | The record is in the account database. The picture is in Cloudflare's file storage. | To serve the link you asked for, to keep each account inside its plan, and to let you list, lock and delete your diagrams | On the Free plan, 30 days after you last publish it. On the Pro plan, until you delete it. Deleting a diagram or the account removes it, and a deleted picture can stay in a cache for up to 1 hour. | Contract |
| Stable links, if you make any: the name you gave the link (text you chose, such as `checkout-flow`), a random token that is part of its public address, the id of the hosted diagram it shows now, when it was made and last moved, and your account id. Beside it, a copy of that diagram's picture (the same SVG its own link serves), kept at the link's address | The record is in the account database. The copy is in Cloudflare's file storage, beside the pictures. | To serve the link's address with the diagram you last pointed it at, and to let you list, move and delete your links | Until you delete the link or the account. A link whose diagram is deleted or expires stays, showing nothing and with its copy removed, until you point it at another diagram or delete it. A deleted copy can stay in a cache for up to 1 minute. | Contract |
| Organisations you make or belong to: the organisation's name and handle, the id of the account that owns it, when it was made, and a row for each member with the member's account id, role (owner, admin, member or reader) and the date they joined | The account database | To know who may open the organisation's library, and to show the members to one another by email address | Until the member leaves or is removed, or the organisation or the account is deleted | Contract |
| Folder rules, if the owner of an organisation makes any: the folder name (text the owner chose), the roles the rule names, the account ids of the members it names, and when it was made | The account database | To restrict a folder to the roles and people the owner chose | Until the owner removes the rule, or the organisation or the owner's account is deleted. A member who leaves or is removed, or whose account is deleted, drops out of every rule that named them. | Contract |
| Brand colors, if an owner or admin of an organisation saves them: one to three colors written as hex codes, the id of the account that last saved them, and when. If you choose an organisation's brand for your own calls, the id of that organisation and when you chose it | The account database | To draw the diagrams the hosted service makes for the organisation, and for you if you chose it, in those colors | Until an owner or admin removes them, or the organisation is deleted. Your choice stays until you change it or your account is deleted. | Contract |
| Where members publish, if an owner or admin of an organisation chooses: the setting (members choose, the organisation's library by default, or its library always) and whether view links are hidden. If you choose a default organisation for your own publishes, the id of that organisation and when you chose it | The account database | To send members' publishes to the organisation's private library, or to refuse a public link, as the organisation chose | The setting until an owner or admin changes it, or the organisation is deleted. Your choice stays until you change it, or your account or the organisation is deleted. | Contract |
| Custom icons, if an owner or admin of an organisation uploads them: each icon's file as the upload check rewrote it (an SVG holding only drawing, or a PNG holding only its picture, at most 32 KB), its name and aliases, its size, the id of the account that uploaded it, and when | The account database | To draw the organisation's own logos in the diagrams the hosted service makes for the organisation, and for you if you chose it, and to find them in icon search | Until an owner or admin deletes them, or the organisation is deleted | Contract |
| Organisation avatar, if an owner or admin of an organisation uploads one: the picture as the upload check rebuilt it (an SVG holding only drawing and animation of its own shapes, or a PNG, GIF or WebP holding only its frames, at most 256 KB), a version made from its hash, the id of the account that last uploaded it, and when | The account database | To show the organisation's picture to its members in the portal | Until an owner or admin removes it, or the organisation is deleted | Contract |
| Style rules, if an owner or admin of an organisation saves them: the rules file as they typed it (patterns, icon names, tones, node types, kinds and hints, all text they chose), the id of the account that last saved them, and when | The account database | To give the organisation's CI the same rules wherever it runs, read with one of its API keys | Until an owner or admin removes them, or the organisation is deleted. | Contract |
| Drift reports, if an organisation's CI sends them with one of its API keys: for each run the repository's name, the git ref, the commit, the event, and the links to the run and the pull request; for each diagram its name, its path in the repository, its status, how many items were added, removed and changed, how many errors, and its owners as the repository's CODEOWNERS file writes them (team and user handles, and email addresses); and when each run was reported | The account database | To show the organisation's members, in one place, which diagrams no longer match the files they are made from, and who owns them | 90 days after the run was reported on a Pro owner's organisation. On a plan without the drift dashboard nothing is stored, and what was stored before is removed by the next daily clean-up. Everything goes when the organisation is deleted. | Contract |
| Organisation audit log, on an organisation whose plan keeps one (Pro and Enterprise): for each change in the organisation the time, the action, who did it (the account id and email address of a member, or the id and name of one of its API keys, or "Plotwork support" with the reason typed, never the operator's identity), what it was done to (an id, and a member's or invited email address, a key's, a diagram's or an icon's name, or a folder), a few facts such as the role given or the setting chosen, the network the request came from (the first three parts of an IPv4 address or the first three groups of an IPv6 address, never the full address), the first 200 characters of the browser's user agent, and a request id. Never a diagram's source, a key's value, a token or a color | The account database | To let the organisation's owner and admins answer who did what and when, and on Enterprise to export it to their own security tools | 30 days on a Pro owner's organisation, 365 days on Enterprise or the days the contract sets. On the Free plan nothing is recorded, and what was kept before is removed by the next daily clean-up. The daily clean-up removes events past the plan's days. Everything goes when the organisation is deleted. When an account is deleted, its email address is cleared from every log and its id stays. | Legitimate interests |
| Single sign-on settings, if an owner or admin of an Enterprise organisation sets it up: for OpenID Connect, the provider's issuer address, the client id, the client secret sealed with AES-256-GCM under a key only the API holds (never shown again, not even to the owner), and the provider's three endpoint addresses; for SAML, the provider's entity id, the address of its sign-in service, its signing certificates (public keys, with each one's fingerprint and expiry date), the address its metadata was fetched from if it was not pasted, and the name of the attribute that carries the email address; and for both, the email domains the organisation proves, the random value of each domain's DNS record and when it was checked and verified, and the switches (on, Require single sign-on, adding people on first sign-in and with which role) | The account database | To sign the organisation's members in through its own provider, and only on domains it proved | Until an owner or admin removes them, or the organisation is deleted | Contract |
| Single sign-on links: for each person who signs in through an organisation's provider, the provider's issuer and the provider's id for the person (its `sub` for OpenID Connect, its name identifier for SAML, which some providers make your email address; for SAML the issuer is stored as the organisation's id and a one-way hash of the provider's entity id), the organisation's id, your account id, and when the link was made and last used. Never a token or an assertion from the provider, and nothing else it sends | The account database | To sign the same person in to the same account every time, even if their address at the provider changes | Until the account or the organisation is deleted. Removing the organisation's provider keeps them, so setting it up again finds its people. | Contract |
| SCIM provisioning, if an owner or admin of an Enterprise organisation turns it on: a hash of the organisation's SCIM token (the token is shown once and never stored), its first characters, who made it and when, and when it was last used; for each person the organisation's identity provider manages, the account, the provider's id for them (`externalId`), the address it sent (`userName`), the given and family name it sent, and whether it has them active; and the provider's groups, who is in each, and the role an owner or admin gave each | The account database | To add, update and remove the organisation's members as its identity provider says, and give them the roles its groups carry | Until the provider deletes the person or the group, the token is revoked or replaced (the hash is kept with the revocation time), or the organisation is deleted. A person's record also goes when their account is deleted. | Contract |
| Destinations for audit events and drift, if an owner or admin of an Enterprise organisation adds them: the kind (Datadog, Dynatrace, Splunk, Microsoft Sentinel or a webhook), the name they gave it, what it receives (the audit log, the drift results, or both), its addresses and ids (a Datadog site, a Dynatrace environment id, a Splunk or webhook address and index, the Microsoft Entra tenant and app ids and the Azure Monitor endpoint, rule and stream), its secret (an API key, a token, a client secret or a webhook signing secret) sealed with AES-256-GCM under a key only Plotwork's servers hold (never shown again, not even to the owner), and when it was added and changed | The account database | To send the organisation's audit events and drift results to the tools it named | Until an owner or admin removes it, or the organisation is deleted | Contract |
| Events waiting to be sent: a copy of each audit event and drift result for each destination that takes it, the same fields as the audit log and the drift dashboard and never diagram source, and for each destination how many were sent and dropped (with an hourly count for the last day), when it last took a batch, when its current run of failures began, whether Plotwork support paused it and when, its last error as one sentence of our own (never what the destination answered), and its newest 20 sends and test events (the time, how many events, and that sentence) | A Durable Object's storage at Cloudflare, one for each organisation | To send them in batches and try again while a destination is down | Until the destination takes them, and at most one day, after which they are dropped and counted. At most 10,000 waiting for one destination. A removed destination's copies are dropped at the next try. | Contract |
| Started single sign-on sign-ins: hashes of the sign-in's state, nonce and browser binding, the PKCE verifier (useless without the code the provider sends only to us), the email address typed, the address to return to, and the times. For SAML, hashes of the RelayState and the browser binding and the id of the request sent to the provider instead. The binding itself is in the `plotwork_sso_flow` or `plotwork_saml_flow` cookie in your browser | The account database | To finish the sign-in safely, once, in the browser that started it | Usable for 10 minutes. Deleted once used, or a day after it ran out, by the next sign-in or the daily clean-up. | Contract and legitimate interests |
| Pending invitations: the email address invited, the role offered, the id of the account that invited, the times it was made and expires, and a hash of the invitation token, never the token | The account database | To send the invitation, and to check that the person who accepts is the person invited | Until it is accepted or revoked, or 7 days after it was made. The daily clean-up deletes invitations that have run out. | Legitimate interests |
| Organisation diagrams, if a member publishes any: the picture (an SVG file, which carries the diagram source only if the member turns on `embedSource` when they publish, the owner keeps the organisation's diagrams editable, or a member saves the diagram in the portal's editor), up to ten earlier pictures of it that a save in the editor replaced, and a record with its name and folder if given, its size, its theme, when it was first and last published, when it expires, a hash of the picture, the organisation's id, the id of the account that published it, and, if the owner locked it, the time and the id of the owner's account | The record is in the account database. The picture is in a second file storage at Cloudflare that has no public address. | To keep the organisation's library, to keep each organisation inside its owner's plan, and to let members list, download and delete diagrams, and the owner lock them | On a Free owner's organisation, 30 days after the diagram was last published. On a Pro owner's, until it is deleted. Deleting the diagram, the organisation or the owner's account removes it. | Contract |
| Organisation API keys: the same details as your own keys (the name, the start and last four characters, a hash, an encrypted copy, and the times), held for the organisation and tied to the id of its owner's account | The account database | To let an owner or admin give a script or an agent access to the organisation's library | Until the key is revoked, or the organisation or its owner's account is deleted. Revoking a key deletes its encrypted copy. | Contract |
| Billing, if you upgrade or Plotwork gives you a plan: your Stripe customer id, your subscription id, your plan, the status Stripe reports for the subscription, the end of your current billing period, whether and when it is set to cancel, and whether Plotwork gave it to you at no charge | The account database | To know which plan's limits apply to you, and to open Stripe's pages for you | Until the account is deleted | Contract |
| Audit trail: the time, your account id, the action (sign in, sign out, make, reveal, or revoke a key, connect or disconnect an agent, publish or delete a hosted diagram, make, move or delete a stable link, make, rename or delete an organisation, join, leave or remove a member, change a role, invite or revoke an invitation, make, reveal or revoke an organisation key, publish, change or delete an organisation diagram, set or clear a folder rule, save or remove an organisation's brand colors, save or remove an organisation's style rules, upload or delete an organisation's icon, upload or remove an organisation's avatar, choose where an organisation's members publish, move or unpublish a member's public diagram, choose your default organisation for publishing, set up, change or remove an organisation's single sign-on or its domains, sign in through an organisation's identity provider or fail to, join an organisation on first sign-in, sign in with an emailed code while an organisation you own requires single sign-on, make a Stripe customer for your account, or a change to your plan), the id of the thing it concerned, and a request id. An organisation action is recorded with the organisation's id, and never with an email address, a name, a folder or diagram text. That is this trail, which only the operator reads; the organisation's own audit log, above, names more, for its owner and admins. The operator's own console sign-ins are recorded too, with no account and no address | The account database | To investigate misuse and to settle questions about what happened | Nothing removes these rows automatically. They stay after the account is deleted, with the account id but no email address. | Legitimate interests |
| Log lines: event names, account and key ids, a request id, and for each MCP tool call the tool name, outcome, duration, input size, and key id | Cloudflare's logging service | To find faults and abuse | For the period Cloudflare's logging service keeps them | Legitimate interests |
| Short-lived copies: your signed-in session including your email address, your key's id and account id, and the name of your plan | The memory of a Cloudflare server, which is not written to storage | To answer quickly without asking the database every time | Up to 1 minute for a session, up to 1 minute for a key, and up to 1 minute for the plan. A copy is lost sooner when that server restarts. | Legitimate interests |
| A count of refused checks: for an MCP connection, your key's id and how many diagram checks were refused since the last valid one | The memory of the hosted MCP server, which is not written to storage | To count, without naming you, how many tries a valid diagram takes (see Usage totals) | Until the next valid check, and at most 30 minutes after the last check. It is lost sooner when that server restarts. | Legitimate interests |
| Your IP address, when you call sign-in, the API, or the MCP server | Cloudflare's rate-limiting service, as a counter key. Plotwork's own code does not store it. | To slow down guessing and abuse | Counted over a window of 60 seconds | Legitimate interests |
| Operator log: the time, a one-way hash of the operator's address, the action taken on an account, an organisation or the service, the id it concerned, the reason the operator typed, and whether it changed anything. If the operator suspends an account, the time of the suspension | The account database | To keep a record of every action taken from the operator's console, and to refuse a suspended account | The suspension until the account is unsuspended or deleted. Nothing removes log rows automatically; they stay after the account is deleted, with its id and no email address. | Legitimate interests |
| Enterprise enquiries, if you send one from the Enterprise page or the portal's Talk to sales form: the name, work email address, company, company size, number of repositories, the boxes you ticked for what you need, and use case you typed, when you sent it, and whether the email about it was sent. From the portal we also store where in it you opened the form, and if you were signed in, your account id (your account's email address is used as the reply address) and the organisation you opened it from, when you are a member of it. Nothing else is stored with it: no IP address, no header and no cookie. An email with the same details goes to Plotwork's own inbox, with your address as the one a reply goes to | The account database. The email goes through Resend. | To answer your enquiry and to keep a record of it for the contract that may follow | 24 months after you sent it. The daily clean-up deletes older enquiries, and the operator deletes one sooner if you ask | Legitimate interests |
| Enterprise contracts: for an organisation on an Enterprise contract, the limits written for it, when they were set and changed, and the commercial terms the operator records: the price, the currency, how often and how it is billed, the start and end dates, renewal and notice, a purchase order or contract reference, internal notes, and the name and email address of the customer's billing contact. Only the operator console shows the terms; members of the organisation see only the day the contract ends, and the owner and admins also see its start day and how it renews, never its price or billing contact. The contract also records its support: the name and email address of the Plotwork person who answers the organisation, the first response target and the support hours, which every member sees on the portal's Support page. Every change is in the operator log, which names the terms that changed and never their values | The account database | To hold the organisation to the limits its contract sets, to invoice and renew the contract, and to say who answers its support requests | Until the contract ends or the organisation is deleted. Ending the contract deletes the terms, the billing contact with them | Contract |
| Enterprise support requests, if you send one from your organisation's Support page in the portal: the organisation, your account id and email address, the subject, the severity and the message you typed, when you sent it, whether the email about it was sent, and when Plotwork marked it answered. What you write is kept as you wrote it, so leave out anything you would not email. An email with the same details goes to your organisation's named contact at Plotwork, or to Plotwork's own inbox when none is named, with your address as the one a reply goes to | The account database. The email goes through Resend. | To answer your request, and to keep a record of what was asked and when it was answered under the contract's response target | 365 days after you sent it. The daily clean-up deletes older requests, and they go sooner with the organisation or with your account | Contract |
| Sign-in and invitation emails: your email address and the message with the code, or for an invitation the invited address, the email address of the member who invited them, the organisation's name, the role and the link. Each email also shows the Plotwork logo, which your mail program loads from plotwork.dev: the same file for everyone, with nothing in its address that names you. Plotwork's host can see that request, as it can any request to it. The emails have no tracking pixel and no tracked links | Resend, which delivers the email | To get the code or the invitation to you | Held by Resend under its own policy | Contract and legitimate interests |
| Analytics, if you accept: a random visitor id in a cookie, the address and title of each page you view (the address has no query string or fragment), and the technical details your browser sends | Google Analytics | To count visits and see which pages help | The cookies last 13 months. Google keeps the data for the period set in our Google Analytics property, between 2 and 14 months. | Consent |

Contract means we need the data to give you the service you asked for. Legitimate interests means we need it to keep the service secure and working, and we have weighed that against your privacy. Consent means we only do it if you say yes, and you can take it back at any time.

## What we do not collect

| We do not | What that means |
|---|---|
| Store or log your diagrams | The source, Markdown, and pictures you send to the hosted API or MCP server are worked on in memory, and the answer is sent back. Nothing from them is saved. Because we do not keep them, we do not use them to train any model. The one exception is a diagram you choose to publish, to a public link or to an organisation: its picture is kept so the link or the library works, as the Hosted diagrams and Organisations sections below explain. If you turn on `embedSource` when you publish, save the diagram in the portal's editor, or publish to an organisation whose owner keeps diagrams editable, the diagram source is part of that picture. |
| Show ads or sell data | There is no advertising on Plotwork. Google's advertising signals stay off, and no personal data is sold or rented. |
| Track the local npm package, unless you ask us to | `@buun_group/plotwork-mcp` runs on your device. It has no key and no account. With nothing set, it reads no file but your repository's settings (`plotwork.config.json`, if you have one), writes no file, and makes no network request of its own. The view link in a drawing's answer is built on your device and sends nothing. If you set `PLOTWORK_OPEN=1`, it writes each drawing to your system's temporary folder to open it in your browser. The one exception is the `read_diagram` tool: when a caller gives it the link of a Plotwork picture, it fetches that link from `cdn.plotwork.dev` or `cdn-preview.plotwork.dev` and sends nothing else. It counts or shares anything only if you set `PLOTWORK_USAGE`, and then only as the Usage totals section below describes. npm contacts the npm registry to download it, under npm's terms. |
| Send Google your identity | No user id, email address, account id, API key, or diagram content goes to Google. The portal, where keys are shown, runs no analytics at all. |
| Keep your full IP address ourselves | Our own code never stores a full IP address, and the audit trail has no IP address column. The organisation audit log keeps only the network a request came from: the first three parts of an IPv4 address (a /24) or the first three groups of an IPv6 address (a /48), which points to an office or a provider and not to a device. Cloudflare sees IP addresses as part of running the network (see below). |

## How sign-in and keys work

There is no password. You give an email address and we email you a six-digit code through Resend. The code works for 10 minutes, dies after 5 wrong guesses, and only one code is sent to an address each minute and five an hour. Only a hash of the code is stored, never the code. The first successful sign-in makes your account.

A successful sign-in sets two cookies. `plotwork_session` holds a random token, and we store only a hash of that token, so a copy of our database cannot be used to sign in as you. `plotwork_signed_in` holds the number 1 and identifies no one. It lets the site and the documentation know whether to ask who you are.

An API key is a long random value that starts with `pw_`. We store a hash of it, which checks the key on every call and cannot be turned back into the key. For a key you make, we also store an encrypted copy (AES-256-GCM, tied to that key and your account), so you can reveal the key again while you are signed in. Only you, signed in, can ask to see it. Revoking the key deletes the copy, and deleting the account deletes it too. A key made before this existed, or on a server that was not set up for it, has no copy and cannot be shown again. The key behind an agent connection is never shown to anyone and never has a copy. The account database keeps only its hash, and the grant in the MCP server holds the key itself, encrypted.

If your organisation uses single sign-on, the sign-in page sends you to its identity provider instead, and you come back with the same two cookies. Plotwork asks the provider for your address and an id for you, checks that the provider signed the answer and that the address is on a domain the organisation proved with a DNS record, and keeps the provider's id for you so the next sign-in finds the same account. It keeps no token or SAML assertion from the provider: a SAML answer is checked in memory, in a separate part of the API that stores nothing, and dropped. A third cookie, `plotwork_sso_flow` (or `plotwork_saml_flow` for a SAML provider), lives for 10 minutes while you are away at the provider and ties the sign-in to your browser. The provider is your organisation's choice, under its own terms with your organisation.

When you connect an agent with a browser sign-in, the portal shows you the request and you approve it. Plotwork then makes a key for that connection, which appears in your list of connections and not in your list of keys. Disconnecting revokes the key, and the agent has to connect again.

## The hosted MCP server and API

The hosted MCP server at mcp.plotwork.dev and the HTTP API at api.plotwork.dev need an API key or a browser sign-in. That gives each caller an identity we can count, limit, and revoke.

| Question | Answer |
|---|---|
| What is checked on a call? | The key is checked against its stored hash, the call is counted against the account's daily allowance, and a per-minute limit is applied. |
| What happens to the diagram you send? | It is parsed, laid out, and drawn in memory, and the result is returned. No diagram source, Markdown, or picture is written to a database or a file. The exception is the publish routes and the `publish_diagram` tool, which you use on purpose to host a picture, at a public link or in an organisation. Their option `embedSource` is off unless you turn it on, or, for a publish to an organisation, unless its owner keeps the organisation's diagrams editable, and with it on the diagram source is written into the picture. Saving a diagram in the portal's editor also writes the source into the picture, so it can be edited again. See Hosted diagrams and Organisations below. |
| What is logged? | One line for each MCP tool call: the tool name, the outcome, the duration, the size of the input in bytes, and the key id. What you sent is not logged. An unexpected internal failure is logged with its own error message so it can be fixed. |
| What does the API record? | The audit trail and counts described above. It does not record request bodies. |
| What do the sites ask the API? | The site and the documentation ask the API whether you are signed in, so their headers can show Sign in or your account. They ask only when your browser holds the `plotwork_signed_in` cookie, so a visitor who is not signed in sends no request. The request goes to api.plotwork.dev, and your session cookie goes with it. If the answer is no, nothing is stored. |

## View links

A drawing tool's answer carries a view link (`viewUrl`) so you can see the diagram in a browser. The [Viewing diagrams guide](https://docs.plotwork.dev/viewing-diagrams.md) shows how.

| Question | Answer |
|---|---|
| What is in a view link? | The address of the viewer page, then `#`, then the diagram source, compressed. The source is carried in the link itself. Plotwork does not store it. |
| Is the diagram sent to Plotwork when the link is opened? | No. The part after `#` is the fragment, which a browser never sends to a server. The request for the viewer page reaches Plotwork's host at Cloudflare as an ordinary page request, with the IP address and browser details any request carries, and no diagram. The page draws the diagram in the browser, and its downloads are made there too. |
| Who can read the diagram? | Anyone who has the link. Treat a view link like the diagram's text: a chat or a service that stores the link stores the source with it. |
| Is it logged or counted? | No. The viewer page runs no analytics and makes no call to the API. Building the link is part of the tool's answer, which is not stored or logged. |
| Does the local server send anything? | No. It builds the link on your device and sends nothing. If you set `PLOTWORK_OPEN=1`, it also writes each drawing to your system's temporary folder and opens it in your browser, with no network request. |

## Hosted diagrams

A hosted diagram is a picture Plotwork keeps for you and serves from a public link. A diagram is hosted only when you, or an agent using your account, publish it on purpose. The [Hosted diagrams guide](https://docs.plotwork.dev/hosted-diagrams.md) shows how.

| Question | Answer |
|---|---|
| What is stored? | The picture Plotwork's own renderer drew from your diagram, as an SVG file. Beside it, a record in the account database: the name you gave it if any, the folder you filed it in if any, its size, its theme (light or dark), when it was first and last published, when it expires, a random token that is part of its link, a hash of the picture, and the id of your account. The name and the folder are text you chose, and neither is part of the link. The picture file also carries the diagram's own id, a random identifier that is not your account id. Anyone who has the picture can read that id, but only you, signed in, can use it to manage the diagram. The picture holds the diagram source only if you turn on `embedSource` when you publish, as the next row explains. |
| Is my diagram source stored? | No, unless you choose to embed it. Only the picture is stored, and it shows the text of the diagram, such as its labels. If you publish with `embedSource` set to true, the diagram source is also written into the picture's metadata, so anyone who has the link can read it. Plotwork turns `embedSource` on for you only when you save the diagram in the portal's editor, which needs the source to open it again. Otherwise you, or the agent using your account, must set it for each publish, and a picture published without it holds no source. A save in the editor keeps the picture it replaced, up to ten of them, in the file storage that has no public address, and they go with the diagram. Deleting the diagram deletes the source with the picture, and a cached copy can stay visible for up to 1 hour. |
| Who can see it? | Anyone who has the link. The link holds a long random token that cannot be guessed, and it does not name you or your account. Only you can list your diagrams. Do not publish a diagram that must stay private. |
| Can I keep a diagram private? | Not with a personal link. A diagram published to an organisation has no public link and only its members can open it. See Organisations below. |
| How long is it kept? | On the Free plan, 30 days after you last published it. Publishing the same diagram again starts the 30 days over. On the Pro plan, until you delete it. A clean-up that runs once a day removes an expired diagram, so a link can keep working a little past its expiry date. |
| What happens when my plan changes? | Moving to Pro stops every expiry. Moving to Free gives each diagram a full 30 days from the change. Nothing is deleted at once. |
| How do I delete one? | Press Delete on the Diagrams page of the portal, or ask an agent connected to your account to delete it with the `delete_diagram` tool. That deletes the record and the picture. Only you, or an agent you connected, can delete your diagrams. If the file storage cannot remove a picture at once, Plotwork keeps the picture's random storage name, and nothing else, on a list, and removes the file within a day. |
| What is a stable link? | A link you name, such as `checkout-flow`, that always shows the diagram you last published or pointed under that name, so a page that embeds it shows each new version. Its address holds its own random token, not the name, your account, or a diagram's token. Plotwork keeps the name, the token, the diagram it shows, two times, and a copy of that diagram's picture at the link's address. The copy is the picture already public at the diagram's own link, never the diagram source unless that picture carries it through `embedSource`. Deleting the link deletes the copy, and its address stops working within 1 minute. |
| Can I lock a diagram? | Yes. A locked diagram cannot be deleted, renamed or moved until you unlock it, which protects it from a slip or from an agent. Plotwork keeps the time you locked it. A lock does not extend a Free plan diagram's 30 days, and deleting the account still removes it. |
| Does it stay visible after I delete it? | It can, for up to 1 hour. The picture is cached, and Plotwork does not clear the cache for each delete. |
| Who stores the pictures? | Cloudflare, as listed under Who handles data for us. |
| Is it logged? | The audit trail records that a diagram was published or deleted, with its id. It never records the diagram source. |

## Organisations

An organisation is a named group of accounts that share a private library of diagrams. A person who makes one is its owner, and invites the others by email address. The [Organisations guide](https://docs.plotwork.dev/organisations.md) shows how it works.

| Question | Answer |
|---|---|
| What is stored about an organisation and its people? | In the account database: the organisation's name and handle (a short name used in addresses), the id of the account that owns it, when it was made, and one row for each member with the member's account id, role (owner, admin, member or reader) and the date they joined. A reader is a member who may look and download but not change anything. A reader stores the same data as every other member and counts as one of the organisation's people. |
| Who can see who is in it? | Every member sees the other members' email addresses, because a team knows who is in it. Owners and admins also see the pending invitations. Nobody outside the organisation can find it: there is no public page and no search for an organisation or for a person. |
| What is stored for an invitation? | The email address invited (in lowercase), the role offered, the id of the account that invited, the times it was made and expires, and a hash of the token in the link. The token itself is only in the email. An invitation is deleted when it is accepted or revoked, and 7 days after it was made if it is not. The daily clean-up deletes the ones that have run out. The person must sign in with the invited address to accept, so a forwarded link is no use to anyone else. |
| Who sends the invitation email? | Resend, from the same address as the sign-in code. The email names the member who invited the person by email address, the organisation's name and the role. If it cannot be sent, no invitation is stored. |
| What is stored for an organisation diagram? | The picture Plotwork's own renderer drew from the diagram, as an SVG file in a second file storage at Cloudflare that has no public address. Beside it, a record in the account database: the name and folder if given, its size, its theme, when it was first and last published, when it expires, a hash of the picture, the organisation's id, and the id of the account that published it, and, if the owner of the organisation locked the diagram, the time and the id of the owner's account. A locked diagram cannot be renamed, moved or deleted by anyone, its publisher included, until the owner unlocks it. The source is not stored. The picture shows the text of the diagram, such as its labels. The exceptions are a diagram a member publishes with `embedSource` set to true, a diagram published while the owner keeps the organisation's diagrams editable (a setting only the owner can turn on; a publish that sets `embedSource` to false still leaves the source out), and a diagram a member saves in the portal's editor: the diagram source is then written into the picture, so every member who can open the diagram can read it. A save in the editor keeps the picture it replaced, up to ten of them, and they are deleted with the diagram. |
| Who can see an organisation diagram? | Only members who are signed in, and API keys that belong to the organisation or to a member. The owner can restrict a folder to some roles and some named members, and then only they, and the owner, can see what is in it. There is no public link. Only the API reads the private storage, and it serves a diagram with headers that tell caches not to keep it. |
| How long is it kept? | On a Free owner's organisation, 30 days after the diagram was last published, which publishing it again starts over. On a Pro owner's organisation, until it is deleted. When the owner's plan changes, the organisation's diagrams follow it as the owner's own do. The daily clean-up that removes expired personal diagrams also removes expired organisation diagrams, file first. |
| What is stored for a folder rule? | In the account database: the folder name, which is text the owner chose, the roles the rule names, the account ids of the members it names, and when it was made. A rule stays until the owner removes it, even while the folder holds no diagram. Removing a member removes them from every rule. The folder name is never in the audit trail or a log line, and a rule is audited by the organisation's id and the account's id only. |
| What is stored for a brand theme? | In the account database: the organisation's brand colors (one to three hex codes), the id of the account that last saved them, and when. If you choose an organisation's brand for your own calls, a row with your account id, that organisation's id and when you chose it. No diagram is stored to make or apply a brand: the colors are read when the hosted service draws, and the diagram is drawn in memory like every other. The audit trail records that the colors were saved or removed, with the organisation's id, and never the colors. The [Brand themes guide](https://docs.plotwork.dev/brand-themes.md) says how it works. |
| What is stored for a custom icon? | In the account database: the icon's file as the upload check wrote it, never the bytes you uploaded (an SVG is rebuilt from drawing elements only, and a PNG keeps only its picture, so text and EXIF metadata such as a location are left out), its name and aliases, its size, the id of the account that uploaded it, and when. No diagram is stored to draw one. The audit trail records that an icon was saved or deleted, with the organisation's id, and never its name or file. The [Custom icons guide](https://docs.plotwork.dev/custom-icons.md) says how it works. |
| What is stored for an organisation avatar? | Nothing until an owner or admin uploads one: without it the portal draws a mark made from the organisation's id, and stores nothing. An uploaded avatar is kept in the account database as the upload check wrote it, never the bytes you uploaded: an SVG is rebuilt from drawing and animation elements only, and a PNG, GIF or WebP keeps only its frames, so text, EXIF and XMP metadata such as a location are left out. With it we keep a version made from its hash, the id of the account that uploaded it, and when. Only the organisation's members and its keys can read it. The audit trail records that it was uploaded or removed, with the organisation's id, and never the file. |
| What is stored for style rules? | In the account database: the organisation's rules file as the owner or an admin typed it, the id of the account that last saved it, and when. It holds patterns, icon names, tones and hints, and never a diagram. CI reads it with one of the organisation's API keys and checks diagrams on the machine that runs it; no diagram is sent to make or apply a rule. The hosted MCP server also checks a member's or a key's diagrams against them in memory, as it draws, and stores nothing of the diagram. The audit trail records that the rules were saved or removed, with the organisation's id, and never the rules. A settings file kept in a repository is never sent to us; settings an agent passes to a hosted tool are worked on in memory and not stored. The [Repository settings guide](https://docs.plotwork.dev/repository-settings.md) says how it works. |
| What is stored for the drift dashboard? | In the account database, for each run the GitHub Action reports with one of the organisation's API keys: the repository's name, the git ref, the commit, the event, the links to the run and the pull request, and when it was reported; and for each diagram the run checked, its name, its path in the repository, its status (in step, drifted, written or failed), how many items were added, removed and changed, how many errors, and its owners as the repository's CODEOWNERS file writes them, which can be team handles, user handles and email addresses. Never the names or details of what changed, never a file's content and never diagram source: the run compares the diagram with its files on the machine that runs it. A run replaces what the dashboard showed for its repository. Every member can see the dashboard. Runs and statuses are kept for 90 days after they were reported on a Pro owner's organisation, and the daily clean-up removes older ones; on a plan without the dashboard a report is refused and nothing is stored, and the next daily clean-up removes what was stored before. The dashboard goes with the organisation. A report is not in the audit trail. The organisation's audit log records that CI sent one, with the repository's name, how many diagrams it checked, and the key that sent it. |
| What is stored for where members publish? | In the account database: the organisation's setting (members publish where they choose, to the organisation's library by default, or to its library always) and whether hosted answers leave out view links, and, if you choose a default organisation for your own publishes, a row with your account id, that organisation's id and when you chose it. Nothing about a diagram is stored to apply it: a publish is sent where the setting says. If the organisation requires its library, its owner and admins can see a list of the public diagrams its members published since they joined, with each member's email address, and move each into the library or unpublish it. Nothing is read for that list but what the members' public links already show, and each move or unpublish is in the organisation's audit log. People whose email address is on a domain the organisation verified are held to its library too, before they join, but their diagrams are never listed. |
| Is an organisation's name checked? | Yes. A name, and a handle a person chooses, is checked against a list of English profanities and slurs when the organisation is made and when it is renamed. The check is a word list run in memory, and a name that fails it is refused and not saved. |
| What happens when someone leaves? | Their member row is deleted. The diagrams they published stay in the organisation, and no longer name them as the publisher. The same happens to the diagrams of a member whose account is deleted. |
| How do I delete one? | A diagram: the member who published it, an admin or the owner can delete it in the portal, and so can an organisation key. The organisation: the owner deletes it in its Settings tab. That deletes every picture first, then the records (diagrams, members, invitations, keys and the organisation). |
| Is it logged? | The audit trail records the action with the organisation's id, and with the account id or the diagram id where they apply. It never records an email address, a name, a folder or diagram text. That is the operator's trail. The organisation also has its own audit log, below. |
| What is in the organisation's audit log? | On Pro and Enterprise, every change in the organisation: members invited, joining, leaving, removed and their roles changed; keys made, shown again and revoked; diagrams published, renamed, moved, edited, restored, locked, unlocked and deleted; folder rules; the brand, icons, avatar and style rules; "Keep diagrams editable"; where members publish, and members' public diagrams moved or unpublished; drift reports from CI; and what Plotwork support changed, with the reason given. Each event names who did it (a member by email address, a key by its name, CI, or "Plotwork support"), what it was done to by id and name, a few facts such as the new role, the network the request came from (never the full IP address) and the first 200 characters of the user agent. Only the owner and the admins can read it, and on Enterprise export it as CSV or JSON Lines, also with an organisation key that has only the `audit:read` scope. A person's export is itself recorded. It never holds a diagram's source, a key's value, a token or a color. It is kept 30 days on Pro and 365 days on Enterprise, or the days the contract sets. On the Free plan nothing is recorded. It goes with the organisation, and a deleted account's email address is cleared from it. |
| What is sent to an organisation's own tools? | On Enterprise, an owner or admin can add up to five destinations: Datadog, Dynatrace, Splunk, Microsoft Sentinel or an HTTPS webhook the organisation runs. Each audit event the organisation's log records, and each drift run its CI reports, is then sent there as it happens: the same fields as the audit log's export and the drift dashboard, never a diagram's source, a key or a token. That is data leaving Plotwork for a service the organisation chose and controls, at its request; what that service keeps is under the organisation's agreement with it. A destination's secret is sealed and opened only in memory to send, and Plotwork sends only to public HTTPS addresses. Removing a destination, or the organisation moving off Enterprise, stops the sending. Plotwork support can see each destination's type, host and delivery status, never its secret, and can send it a test event, try it again at once, or pause one that keeps failing; a paused destination keeps its events for a day, and the Integrations tab says it is paused by Plotwork support. The [guide](https://docs.plotwork.dev/siem-delivery.md) lists every field. |
| Do the cookies change? | No. The portal uses the session cookie it already used, and runs no analytics. |

## Payments

Plotwork charges for the Pro plan. You pay on pages that Stripe hosts, and Stripe processes the payment.

| Question | Answer |
|---|---|
| Who processes payments? | Stripe. You pay on a Stripe page and manage your card and invoices on another. Plotwork shows no card form and loads no Stripe script on its own pages. |
| Does Plotwork see my card? | Not the number. Plotwork never sees or stores your card number, its expiry date or its security code. Stripe collects and keeps them under its own privacy policy. When you open a receipt in the portal, Plotwork asks Stripe for the card brand and the last four digits, shows them to you, and does not store them. |
| What does Plotwork store? | Your Stripe customer id, your subscription id, your plan, the status Stripe reports for the subscription (such as active or past due), the end of your current billing period, whether and when the subscription is set to cancel, and whether Plotwork gave it to you at no charge. |
| What does Plotwork send to Stripe? | Your email address and your Plotwork account id, when you first start an upgrade, so that Stripe can make a customer. If you cancel on the Plan page and write a reason, Plotwork sends that text to Stripe as the comment on the cancellation. Plotwork keeps no copy of it. Stripe also receives whatever you enter on its pages. |
| What does Stripe tell Plotwork? | Events about your subscription, such as a payment, a failed payment, a change, or a cancellation. Plotwork reads each one and changes your billing record to match. |
| How long is it kept? | The billing record stays until the account is deleted. Stripe keeps its own records under its own policy. |
| Is it logged? | The audit trail records that a Stripe customer was made for your account, that your plan changed, and that you cancelled or kept your plan, with the id of the customer or the subscription. It records no card details and never the reason you gave for cancelling. |

## Usage totals

Plotwork keeps totals of how it is used, so we can see how many diagrams are made, how often a request is refused, and for which kind of diagram. The totals are tallies, not events. They hold no account, key, address, or diagram text. The hosted ones carry no identifier at all, so they are anonymous. The local package's, if you turn them on, carry a random identifier that changes every month, so they are pseudonymous: they cannot be tied to your account, but one month's totals share an identifier.

### The hosted service

| Question | Answer |
|---|---|
| What is counted? | For each day, how many calls the hosted service answered, grouped by how the call arrived (the REST API or the hosted MCP server), what it did (for example draw, validate, or publish), which kind of diagram the request named (flow, sequence, schema, git, gantt, class, state, timeline, journey, mindmap, treemap, pie, quadrant, layers, c4, matrix, sankey, xychart, tree, swimlane, or none), and how it ended (done, refused because of the input, or failed on our side). |
| What else is counted to improve the hints? | For each day, how many calls returned each diagnostic code, such as `E120` for an unknown node type, grouped the same way. Only the code is kept, never its message, its hint, its line, or anything you wrote. The hosted MCP server also counts how many refused checks came before a valid one (0, 1, 2, or 3 or more), by kind of diagram. To do that, it keeps one number for your connection, the refused checks since your last valid one, in the memory of one server for at most 30 minutes, and sends only the bucket. That number is never written to storage and never sent with your key. |
| What is never in it? | An account, an API key, an IP address, diagram text, an error message, a name, a folder, or a time of day. |
| Is it linked to me? | No. It is separate from the daily call count tied to your account, which enforces your usage limit. |
| How long is it kept? | Without a time limit, because it holds no personal data. It is not deleted with an account, since nothing in it links to one. |

### The local npm package

| Question | Answer |
|---|---|
| Does the package send anything by default? | No. With nothing set, it reads no file but your repository's settings (`plotwork.config.json`, if you have one), writes no file, and makes no network request. The one exception is the `read_diagram` tool, which fetches a Plotwork picture link only when a caller gives it one, and sends nothing but that request. |
| How do I turn counting on? | Set `PLOTWORK_USAGE=local`. The package then keeps counts in one file on your device, `usage.json` in a `.plotwork` folder in your home folder (or the folder named by `PLOTWORK_HOME`). Nothing leaves your device. |
| How do I turn sharing on? | Set `PLOTWORK_USAGE=share`. The package then also sends anonymous daily totals to Plotwork. Setting `DO_NOT_TRACK=1` stops it from ever sending. Any other value of `PLOTWORK_USAGE` means off. |
| What does sharing send? | Once a day, for each finished day: how many times each local tool ran and how each run ended (done, refused because of its input, or failed), grouped by the kind of diagram the request named. It also sends a random identifier that changes every month, the package version, your operating system family (linux, darwin, win32, or other), and your Node major version. |
| What is never sent? | Diagram text, tool arguments or results, names, folders, file paths, error messages, your user name, your host name, environment variables, the time of day, and any cookie, account, or key. |
| What is the identifier? | It is made on your device from a secret that never leaves it, and it changes every month. Plotwork can count how many installs were active in a month but cannot follow one install from month to month. |
| Where does it go? | To the API at api.plotwork.dev, hosted by Cloudflare. Plotwork stores no IP address, header, or cookie with it, and does not link it to your account or to your use of the hosted service. The route is rate limited, and Cloudflare's rate-limiting service holds your IP address as a counter key for 60 seconds. Plotwork's own code does not store it. Cloudflare also sees your IP address while it carries the request, as it does for every request. The package chooses only a content type and a user agent that names the package and its version. |
| How can I see what it would send? | Run `npx -y @buun_group/plotwork-mcp@0.1.0-beta.10 usage` to see your counts, and `npx -y @buun_group/plotwork-mcp@0.1.0-beta.10 usage preview` to see the exact request. Neither sends anything. `usage reset` deletes the file. |
| How long is it kept? | Up to 400 days, then it is deleted. |
| How do I have mine deleted? | Run `usage` to read your current identifier and send it to legal@buungroup.com. Totals sent under earlier months' identifiers cannot be tied to you, and are deleted as they age out. |

## The operator's console

Plotwork's operator uses a console to run the service and to answer support requests. It is not part of the service you use.

| Question | Answer |
|---|---|
| Who can sign in? | Only the Plotwork operator, through a separate sign-in that is not linked to any customer account. |
| What does it show? | The totals above, and, for each account: its email address, when it signed up and last signed in, its plan and the subscription details Plotwork stores (status, period end, whether it cancels, the Stripe customer and subscription ids), the names and dates of its API keys and agent connections (never a key), the dates of its sessions (never a token), the organisations it belongs to and its role, the names, folders, sizes and dates of its hosted diagrams and their public links, its stable links, its daily call counts, and its audit trail. For each organisation: its owner, members and their roles, pending invitations with the invited addresses, keys by name, diagrams by name and folder, folder rules, brand colors, icon names, and whether style rules or an avatar are saved. For each destination for audit events and drift: its organisation, kind, name, what it receives, its host (for a webhook the host and path, with any part that looks like a token hidden, and never the query), and its delivery status: the counts, the times, the last error sentence and the newest 20 sends and test events. For each Enterprise support request: the organisation, the address and role of the person who sent it, the severity, the subject and the message as they wrote it, and whether it was emailed and answered. It never shows diagram source, a picture, a key, a code, a token, a destination's secret or full address, or what was sent to a destination. |
| Why? | To operate and protect the service and to answer requests from account holders. The basis is the contract with you and our legitimate interest in running a safe service. |
| What can the operator do? | Suspend or unsuspend an account, sign it out everywhere, revoke its keys or agent connections, delete it on request, and, in an organisation, transfer ownership to a member, remove a member, revoke an invitation or key, unlock a diagram, remove its brand colors, icons or style rules, or delete it, and send a test event to one of its destinations for audit events and drift, pause or resume one, or try one again at once, and mark a support request answered. The operator can also pause the hosted drawing tools for maintenance and show a short announcement. |
| What happens when an account is suspended? | Its sessions end, and its sign-ins, API keys, agent connections, and the keys of organisations it owns are refused until it is unsuspended. Nothing is deleted, and its public diagram links keep working. |
| Is it logged? | Every action is written to an operator log: the time, a one-way hash of the operator's address, the action, the id of the account, organisation or service it concerned, the reason the operator typed, and whether it changed anything. The audit trail also records that a code was sent and that the operator signed in or out, with no account and no address. |
| What is stored for the sign-in? | In the account database: a hash of a one-time code (never the code), a count of wrong guesses, and times; and a hash of a session token together with a one-way hash of the operator's address. |
| How long is it kept? | A session ends after 8 hours. A daily clean-up deletes expired sessions, and codes more than an hour after they expire. Nothing removes operator log rows automatically; they stay after the account or organisation they concern is deleted, with its id and no email address. |

## Analytics and cookies

On plotwork.dev and docs.plotwork.dev, a banner asks whether you accept Google Analytics. Nothing is requested from Google until you press Accept analytics. The [cookie policy](https://docs.plotwork.dev/cookie-policy.md) lists every cookie and stored item, what happens when you accept, reject, or do nothing, and how to change your mind. The portal asks for nothing and runs no analytics. If you tick Remember my email on this device on the portal's sign-in page, your email address is kept in your own browser so the page can fill it in next time; it is not sent to us by being kept there, and unticking the box removes it.

## Who handles data for us

| Provider | What it does for us | What it sees | Where |
|---|---|---|---|
| [Cloudflare](https://www.cloudflare.com/privacypolicy/) | Hosts the sites, the API, the MCP server, the account database, the caches, the rate limits, and the storage and delivery of hosted diagrams, and the private storage of organisation diagrams. Its DNS over HTTPS service answers the check of an organisation's single sign-on domain, which sends it only the record name. | Everything that reaches those services, including IP addresses and request details, and the account data and hosted diagrams held in them | A global network. Cloudflare chooses where the database runs, and the choice is not limited to Australia. |
| [Resend](https://resend.com/legal/privacy-policy) | Delivers the sign-in, invitation and support request emails | Your email address and the email with your code, or for an invitation the invited address, the email address of the member who invited them, the organisation's name, the role and the link, or for a support request your address, your role, the organisation and what you wrote | United States |
| [Stripe](https://stripe.com/privacy) | Takes payments for the Pro plan, and hosts the pages where you pay and manage billing | Your email address and Plotwork account id, and what you enter on its pages, including your card and billing details | Stripe chooses where it processes payments, and describes it in its privacy policy. |
| [Google](https://policies.google.com/technologies/partner-sites) | Runs Google Analytics, only for visitors who accept | What the cookie policy lists under "What Google receives" | United States |
| GitHub | Hosts the public repository of the npm package, where people can open issues | Only what a person chooses to post there | Public, under GitHub's terms |

These providers handle data outside Australia, and for a visitor in the European Union or the United Kingdom, outside their own region. Each provider describes its own safeguards for such transfers in its privacy policy, linked above. The service sends data to no other provider, and we disclose data to others only where the law requires it. The tools an Enterprise organisation names for its own audit events and drift results are not our providers: we send copies there because the organisation asks us to, and it chose them.

A deleted record can remain for a limited time in Cloudflare's own database restore history.

## Your rights

You can ask us to:

- tell you what we hold about you, and give you a copy
- correct data that is wrong
- delete your data
- restrict or stop a use of your data, where you object to it
- withdraw consent to analytics, which needs no request to us: use Cookie settings in the footer of the site or the documentation

For visitors in the European Union and the United Kingdom, these rights come from the GDPR. For visitors in Australia, they come from the Privacy Act 1988 and the Australian Privacy Principles (APPs), which include access to and correction of your personal information.

To use a right, write to legal@buungroup.com from the address on the account, or say which address it is. We answer a request about an account within 30 days. We may need to check it is you before we act, because acting on a false request would harm the real owner.

If you are not satisfied, you can complain to us first at the same address. You can also complain to the Office of the Australian Information Commissioner ([oaic.gov.au](https://www.oaic.gov.au/)). A visitor in the European Union or the United Kingdom can complain to the data protection authority of their own country, such as the Information Commissioner's Office ([ico.org.uk](https://ico.org.uk/)) in the United Kingdom.

## Deleting your account

The portal has no delete button, so write to legal@buungroup.com. When we delete an account:

| Removed | How |
|---|---|
| The account: email address, creation time, last sign-in time | The row is deleted. |
| Every session, every API key (including the keys behind agent connections, and the encrypted copy of any key you made), every single sign-on link, and every daily call count | They are deleted with the account, because each one belongs to it. |
| Unused sign-in codes for your address | They are deleted with the routine that clears codes older than one day. |
| Agent grants in the hosted MCP server | They stop working on the agent's next use, because the key behind them no longer exists, and they lapse at most 30 days after they were made. |
| Hosted diagrams: every record, and every picture | The records are deleted with the account, because each one belongs to it. We also delete the pictures, so the links stop working. A copy can stay cached for up to 1 hour. |
| Stable links: every name, token and copy | We delete the copies, then the records, so their addresses stop working, within 1 minute of any cached copy. |
| Organisations you own: the organisation, its members, its folder rules, its pending invitations, its keys, its brand colors, its style rules, its custom icons, its avatar, its drift reports, its audit log, its support requests, its destinations for audit events and drift with their sealed secrets and what waits to be sent, its single sign-on settings, domains and links, and every diagram and picture in it | The pictures are deleted first, then the records, so the organisation and its library go with the account. Its other members lose access. |
| Your place in organisations you do not own | Your member row is deleted, and so is your name in every folder rule there. Every support request you sent there goes too. Your choice of an organisation's brand is deleted too. Diagrams you published there stay, without your account id. Invitations you sent stay until they are accepted or run out, without your account id. |
| Your email address in the audit logs of organisations you do not own | It is cleared wherever it names you as the person who acted, the member an event was about, or an invited address. The events stay with your account id, which no longer points to any account. |
| Enterprise enquiries you sent from the portal while signed in | The enquiry stays for its 24 months as the sales record, with what you typed, but the link to your account is cleared. Ask us to delete the enquiry too. |
| Pending invitations to your email address | They are not part of your account, so deleting it does not remove them. They run out 7 days after they were made, and the organisation's owner or an admin can revoke one sooner. |
| The billing record: your Stripe customer id, subscription id, plan, status, and period dates | It is deleted with the account, because it belongs to it. |
| Short-lived copies | They expire within minutes. |

Audit trail rows and operator log rows stay. They keep the account id, the time, the action, and the ids of the things concerned, but not your email address, and the id no longer points to any account. Emails already sent through Resend, payment records held by Stripe, and analytics data held by Google are kept by those providers under their own policies. We do not link analytics to your account.

## Changes to this policy

We change the date at the top whenever this policy changes. If a change affects how your data is used in a way that matters to you, we say so on this page. If the cookie policy changes materially, the banner asks everyone about analytics again.

## See also

| Page | Why |
|---|---|
| [Cookie policy](https://docs.plotwork.dev/cookie-policy.md) | Every cookie and stored item, what each is for, and how to change your choice |
| [Connecting an agent](https://docs.plotwork.dev/mcp/connect.md) | How the API key and browser sign-in routes work |
| [MCP server](https://docs.plotwork.dev/mcp/overview.md) | What the tools do, what is logged, and how the local and hosted servers differ |
| [Hosted diagrams](https://docs.plotwork.dev/hosted-diagrams.md) | How to publish a diagram, who can see its link, and how to delete it |
| [Organisations](https://docs.plotwork.dev/organisations.md) | How a team shares a private library, who can see it, and how it is deleted |
| [Plans and billing](https://docs.plotwork.dev/plans-and-billing.md) | What Free and Pro include, and how to upgrade and cancel |
| [Trademarks and icons](https://docs.plotwork.dev/trademarks-and-icons.md) | Who owns the icons Plotwork draws |