Privacy Policy

1. Who We Are, and What This Covers

BranderUX ("BranderUX", "we", "our", or "us") is an AI-UX platform operated by Lev Kaplun from Israel. A business signs up, describes itself, and gets an AI assistant that answers its customers with branded screens generated as the conversation goes.

This policy covers six surfaces:

• • The app at branderux.com: where a business owner signs in and builds.
• • The embedded assistant: the iframe our customers place on their own websites, served from www.branderux.com/embed.
• • Published sites we host: a business's own site at{slug}.branderux.app.
• • The site MCP endpoint: {slug}.branderux.app/mcp, where an AI client can look a published business up in its own brand.
• • The agent control plane at mcp.branderux.com: where an owner's own coding agent builds and manages their projects.
• • Our own assistant: the chat bubble on branderux.com's public pages, where visitors ask about BranderUX and can ask for a demo.

Two roles, and the difference matters. For our customers' own accounts (the owner who signs up, the projects they build, their conversation with the Builder), we are the controller (the database owner under Israeli law): we decide why and how that data is processed. For the data of our customers' end users (the visitors who talk to a business's assistant on an embed, a published site or its MCP endpoint), the customer is the controller and we are a holder (מחזיק) processing on their instructions. Being a holder does not make us a bystander: Israeli law places security duties on a holder directly, in our own name, and section 8 below is what we do about them.

Our own assistant is the one place where we are the controller of a visitor's data: when you talk to the assistant on branderux.com, the business you are talking to is us. We decide what it collects and why, as section 2 (D) sets out.

If you are a visitor to a business that uses BranderUX, that business decides what its assistant collects and why. This policy tells you what we do with it on their behalf; their own notice governs the rest, and requests about your data should go to them first.

For anything privacy-related, contact contact@branderux.com.

2. Information We Collect

A. Your account and what you build: we are the controller

• • Account. Your name, email address, profile picture and Google account identifier when you sign in with Google; whether your account has beta or administrator access; and your sign-in history: last sign-in, failed attempts, and any lock that follows them.
• • Sign-in security records. Refresh tokens, each stored with the IP address and browser identifier of the device that created it, so a live session can be traced back to the login that started it.
• • Earlier access requests and first-touch source. The note you wrote if you asked for access through our earlier waiting list; the campaign or referring site recorded once at sign-up (utm_source, utm_medium and utm_campaign, or the referring site's host, never the full referring address); if you started building from our own assistant on branderux.com before you signed up, the time of that first step; and the name of the last MCP client that used your access.
• • Projects and brand. Project names, descriptions and tags, brand settings, screens, screen visibility and project settings.
• • Project members and invitations. The email address of each person you invite to a project, the role you give them, who invited them, and when they accepted. The invitation link's token is stored only as a hash.
• • Custom elements. Every saved version of an element's code, the prompt that produced it, its property and tool schemas, its click-query templates, and the studio chat transcript belonging to it.
• • Builder conversations. Your whole conversation with the in-app Builder agent, kept per project so you can resume it. A file you attach is sent to the model for that turn; the saved conversation keeps the file's name, a small thumbnail of an image, and any data the agent extracted into your project, not the file itself.
• • Agent configuration. Your assistant's persona and house rules (whether visitors must sign in, the address requests are handed to, language, timezone, which writes need confirming), its designed home screen, and its answer-quality setting.
• • Skills. The written knowledge packs you give the assistant.
• • Business data. The data model you define and the records under it (catalogue items, bookings, orders and customer requests), plus the address of any live source or endpoint of your own that you point us at.
• • Where your records go. The address new-record alerts and the daily summary go to, an address waiting to be confirmed (its link's token stored only as a hash) and your choices for both; your webhook's address and its signing secret (the secret encrypted, with only its last four characters kept readable as a hint); and the CRM you connected, also after you disconnect it: the account (its name and, where the CRM gives one, its email address), who connected it, your choices for it, and, while it is connected, its sign-in tokens, encrypted under a key used for nothing else.
• • Published sites. The site's address, its status, and the key that renders it.
• • API keys. A hash of the key, a short prefix, a label, the origins you allow it on, and when it was last used. The key itself is not stored.
• • Credentials. Secrets for your own systems, and your own model-provider key if you add one, encrypted before they are written; plus which connected apps you authorized and which of their tools you turned on.
• • Media. Images you upload, and screenshots of a website you asked us to analyze.
• • Usage counters. Daily request and token counts per project and per key, daily serving spend, and your monthly budget caps. Counts only, no content.
• • Agent authorizations (MCP). The clients you connect, and the authorization codes and refresh tokens for them stored as hashes, with the scopes you approved.
• • Plan and billing. Your plan and the price-list version it was bought under, your top-up packs and auto top-up setting, and the customer, subscription and invoice identifiers our payments processor assigns. Card details are typed on the processor's own pages and never reach us.

B. Your customers' visitors: you are the controller, we hold it for you

This group exists only for businesses that run a BranderUX-hosted assistant. Each business sees only its own.

• • Visitor accounts. Email address, name, the Google account identifier where a visitor signs in with Google, their status on that site, and when they were last seen.
• • Sign-in codes. The six-digit code emailed to a visitor, stored as a hash and valid for fifteen minutes.
• • Conversations. Every question a visitor asks a BranderUX-hosted assistant and the answer it gave, the screens they were shown, the actions taken, and a random identifier grouping one visit into a conversation. Turns from visitors who are not signed in carry no IP address and no device identifier.
• • Remembered preferences. Small facts a visitor asks the assistant to remember, capped at roughly two kilobytes per visitor.
• • Personalization events. The questions and item clicks of a signed-in visitor, used to personalize what that business's assistant shows them.
• • Conversation insights. An automated reading of each finished conversation: how satisfied the visitor seemed, how the conversation ended, and its topic.
• • Proposed and completed actions. What the assistant offered to write on a visitor's behalf and the values it would write, together with what happened and, where known, where the visit came from.
• • Records a visitor creates. Bookings, orders and requests, stored under the business's own data model and stamped with the visitor's identity where they were signed in. Each one can also carry a one-line summary of the request written by the assistant, where the visit came from, the key of the conversation it came from (so the business can open that conversation beside the record while the conversation is kept, also when the visitor never signed in), and what the business adds: a status, a follow-up date, notes and a timeline of what happened to the record (including a corrected field's earlier value). Where the business connected a CRM, we also keep the CRM's ids for what we sent there, one-way keys of the visitor's email address and phone number that let us recognise the same person again, and the name and status the CRM shows for that person.
• • Where a visit came from. The landing page's path, with any part that looks like an id, an email address or a phone number blanked; the referring site's host, never its full address; any campaign tags (utm) and ad click ids (Google, Meta, Microsoft) in the link the visitor followed; and whether the visit came through a published site, the widget, the SDK or an AI client. It is stored with what the visitor submits, not with the conversation.
• • Quality evaluations. Scores and notes produced when we evaluate how well published assistants answered.

Where a customer's own AI answers instead of ours, the visitor's question passes through us only so we can choose and enhance the screen that renders the answer. We keep no transcript of those conversations.

C. Running the platform

• • Requests and logs. The network request behind every page and API call (IP address, browser identifier, address and timing) and the server logs of those requests.
• • Contact form. The name, email address and message someone sends through the form on our own site are handled by our form provider and forwarded to our email. They are not stored in our database.
• • Legacy partner keys. Where a deployment still carries a design-partner key issued before per-project keys existed, we record each call it makes: the endpoint, the response time, and the IP address and browser identifier of the caller.

D. Visitors to our own assistant on branderux.com: we are the controller

• • Conversations. Your questions, the assistant's answers and the screens it showed you, and a random identifier that groups one visit into a conversation, renewed with each message until the visit has been quiet for 30 minutes.
• • Where the visit came from. The page you landed on, the site that linked to us and any campaign tags or ad click ids in the link, kept in the browser tab's session storage until the tab is closed and stored with a demo request when you send one.
• • A demo request. Your name, your company, your email address, what you would like to see, and, if you add them, your phone number and your website; and your answer to the box for product news, which stays unticked unless you tick it, together with the wording you agreed to and when.
• • Your first step toward building. The time you first started building from the assistant (Build yours, Build like this, or connecting your own AI), kept in your browser's local storage and added to your account if you sign up.

The answers come from the model providers listed in section 4.

Notice under the Israeli Protection of Privacy Law, 1981: you are under no legal obligation to give us any of this. Providing it is voluntary, but an account cannot be operated without it. It is collected for the purposes in section 3 and shared with the recipients in section 4.

3. How We Use Information

• • Operate, secure and provide the service and your account
• • Generate branded screens and answer your visitors' questions: the question, your brand settings, the screen configuration, the business data needed to answer, and (where personalization is on) a signed-in visitor's name, email and remembered preferences are sent to the model that answers. Section 4 lists exactly which providers can receive that.
• • Tell a business what its visitors send: an email alert for each new booking, order or request, and a daily summary if the business turns it on, sent to the business's own address through our email provider; and, where the business set them up, a copy of each record delivered to its own webhook or CRM, together with the conversation it came from when the business has its CRM take conversations too.
• • Manage access to your account and tell you about it, including telling people who joined our earlier waiting list that they can sign in
• • Answer questions about BranderUX and arrange the demos visitors ask for through our own assistant; read its conversations, the way our customers read theirs, to learn which answers help; and know which sign-ups the assistant helped
• • Meter usage against budget caps and prevent abuse
• • Run your subscription: your plan and its allowances, your packs and your invoices
• • Send service-related communications (not marketing lists)

We do not sell or rent personal information.

Improving the product: what automated systems read

No model is trained on your content. We do not fine-tune models on anything you or your visitors write, and we do not grant any provider permission to train on what passes through. Content is read by automated systems, though, and you should know which:

• • A classifier reads finished visitor conversations. When a business opens its analytics, a small model reads conversations on that business's own site that have been idle for half an hour and labels each one with a satisfaction, an outcome and a topic. The labels are that business's analytics, and only that business sees them.
• • An AI analyst reads stored transcripts and records to answer the owner. The analytics assistant inside a business's dashboard can read that business's own conversations, including full transcripts, the records its assistant collected, and the names and email addresses of its signed-in visitors, in order to answer its questions. It is scoped to one business's projects and never reads across accounts.
• • A learning loop reads build sessions across accounts. An administrator can run a job that reads owners' conversations with the Builder agent across accounts and has a model write down short, generalized observations about mistakes the Builder itself made, never business data, which the extraction prompt forbids and a mechanical check enforces. An observation is promoted only if it recurs across several accounts, a person approves each one before it is used, and approved ones are added to the Builder's instructions as plain text. Visitor conversations are not part of this.
• • Quality evaluations. An administrator can also run a job that scores a sample of published-assistant conversations so we can tell whether answers are getting better or worse.

4. Who We Share It With

We share data only with the service providers that run BranderUX, and only to provide the service. The list below is generated from the code that actually makes those calls, so it moves when the code moves, including the model providers that can answer your visitors. The same list is available as JSON at /api/legal/recipients.

A customer may also add managers to a project. A manager sees that project's visitor data and acts for the customer, who chose them; managers are the customer's people, not service providers of ours.

We may also disclose information where the law requires it. We never sell or rent personal data.

5. Where Data Is Stored & International Transfers

Our infrastructure runs on Google Cloud in the United States. The recipients listed in section 4 process data outside Israel, mainly in the United States, and each card says where.

We are honest about the basis. Written transfer undertakings with those recipients are being put in place; none is signed today. We do not claim that using the service is your consent to those transfers. What exists today is this disclosure, the recipient list in section 4, and each recipient's own data-processing terms; the written undertakings the Privacy Protection (Transfer of Data to Databases Abroad) Regulations, 2001 call for are the next step, and this paragraph will change as each one is signed. The registry behind section 4 records the basis for each recipient one by one.

Where a business points its assistant at an endpoint of its own, has its records sent to its own webhook or CRM, connects an AI client of its own to read its records, conversations and signed-in visitors, or has new records reported to its own measurement tags, that business chooses the destination and its own notice governs what happens there.

6. How Long We Keep It

• • Visitor conversations, and what is derived from them. Conversation turns and personalization events are deleted once they pass the window the business chooses for its own site: 180 days by default, and anywhere between 30 and 730 days if it changes the setting. The insights and quality evaluations belonging to a conversation are deleted with it. A nightly job does this, and it is a real deletion of the rows, not an archive flag.
• • Ceilings that apply whatever the window says. We keep at most the newest 2,000 conversation turns per project and the newest 200 personalization events per visitor.
• • Proposed and completed actions. 90 days.
• • What a record carries. A record's summary, where the visit came from, its status, follow-up date, notes and timeline, and what we keep about its copy in the business's CRM, are kept as long as the record and are deleted with it. Only when the business also asks us to delete that copy in its CRM do the CRM's ids for it outlive the record, as the record of that deletion below.
• • Alert, webhook and CRM logs. Finished entries in the logs of alert emails, daily summaries, webhook deliveries and deliveries to a business's CRM are deleted once they are 30 days old. Two kinds of failed CRM delivery stay until their record is deleted, because without them the CRM sync would send that record or conversation again by itself: a record that never reached the CRM, and a conversation. Such an entry keeps the CRM's reason for the failure, at most 300 characters, which can repeat what the visitor typed. The record of a request to delete a record's copy in a business's CRM, which keeps only the CRM's ids for that copy, is kept for 12 months after the deletion is done or the business declines it; one left for the business to finish by hand is kept for 12 months from the request.
• • Limits and counters. The log that limits how many records an AI client can change is kept 90 days, the daily counts of what a site takes in without a confirmation 7 days, the counters that pace calls to a CRM 2 days, and each CRM sign-in or admin link, used or not, until a day after it expires. None of them holds what a visitor wrote.
• • Visitor sign-in codes. Deleted when the code is used or expires, and never longer than 15 minutes.
• • Sign-in tokens. Your refresh tokens last 30 days; a revoked one stops working at once, and its row is removed by an hourly sweep once it expires. Agent (MCP) refresh tokens are removed by an hourly sweep a day after they expire or are revoked; their authorization codes go the same way as soon as they expire.
• • Usage counters. Daily token and request counts are kept 13 months; daily serving spend 90 days. Neither holds any content.
• • Everything else you build. Projects, brand settings, screens, elements, agent configuration, skills, entity records, builder conversations and your account are kept for as long as your account and the project exist. Deleting a project deletes what hangs off it.

Our own assistant on branderux.com

• • Conversations. Deleted after 180 days by the same nightly job as any hosted assistant's.
• • Demo requests. We delete a demo request 12 months after the demo, unless you become a customer, and sooner if you ask. We do this ourselves; no scheduled job does it for us.
• • Your first step toward building. Kept with your account for as long as the account exists.

7. Your Rights

If you are in Israel

• • Access (section 13). You may ask what personal information we hold about you, and we will answer within 30 days of the request.
• • Correction (section 14). If what we hold is inaccurate, incomplete or out of date, you may ask us to correct it, and we will answer within 30 days. Israeli law gives a right to have information corrected rather than a general right to erasure: where we can delete something we will, and where we have to keep it we will tell you why.
• • Closing your account. There is no self-service delete button today. Email us and we will delete the account and the projects under it.
• • Withdrawing consent. Disconnect your agents or close your account at any time.
• • Product news. We send it only if you ticked the box when you asked for a demo, and every message lets you stop it.
• • If we refuse a request you may appeal to the competent court, and you may complain to the Israeli Privacy Protection Authority at any point.

If you are a visitor to a business's published site

That business is the controller of your data and your request goes to it first; we help it answer. On a site we host you can also export the account, preferences, conversations, records and requests we hold for you there, and ask for that account to be deleted. One limit worth stating plainly: deletion removes your visitor account, your transcripts, the records held under data that is yours alone, and your identity stamp on everything else. A record you created in the business's own data (an order, a booking, an enquiry) stays with the business, and its contents commonly include the name, phone number or email address you typed into it.

If the GDPR applies to you

Users in the European Economic Area and the United Kingdom have, in addition, the rights to access, rectification, erasure, restriction of processing, objection and data portability, and the right to lodge a complaint with their national supervisory authority. These apply only where the GDPR applies to you; the Israeli rights above apply to everyone.

To exercise any right, email contact@branderux.com.

8. Security

What we can point at in the code, and nothing more:

• • Encrypted connections. Every connection to the service uses HTTPS/TLS, and the application's connection to its database is encrypted as well.
• • Encryption at rest. The managed Google Cloud services we run on encrypt stored data at rest. That is a property of the platform rather than something our own code adds: apart from the credential vault below, visitor emails, names and conversation transcripts sit in ordinary database columns.
• • API keys. Never stored in the clear. We keep an HMAC-SHA256 hash computed with a server-side pepper, plus a short prefix so you can tell your keys apart. The server refuses to start without that pepper.
• • Credential vault. Secrets for your own systems, and your own model-provider key, are encrypted with AES-256-GCM under a 32-byte key held in our cloud secret manager, and are never returned by any endpoint.
• • Other secrets. Visitor sign-in codes and agent authorization codes and refresh tokens are stored as SHA-256 hashes, never as the values themselves.
• • Scoped access. Project data is reachable only by the account that owns the project and the managers that owner added, and every project-scoped endpoint checks that before it answers. Our own staff read a project's visitor conversations only through our admin console, and only to investigate a specific fault or a specific request. Agent tokens are short-lived and bound to the single resource they were issued for.
• • No card data. Plans and packs are sold by Paddle.com, our reseller and merchant of record, in its own checkout: Paddle collects the billing address, tax number and card details there as a controller under its own privacy policy (Paddle.com Market Limited, and Paddle.com Inc. for buyers in the United States), not as our processor. Card numbers never touch our servers; we keep only the customer, subscription and transaction identifiers Paddle returns.

What we do not claim. We hold no security certification, we have not commissioned a third-party penetration test, and we keep no audit log of who read what. When any of that changes this section will say so, and it is the place to look before assuming otherwise.

9. Cookies

• • On branderux.com. auth_token keeps you signed in (about an hour) and refresh_token renews it (30 days); both are set by our own server and cannot be read by page scripts. beta-access-allowed records for five minutes that a beta check passed, and the page can read that one.
• • On a published business site. bux_site_user is set when a visitor signs in and identifies them to that business's assistant for 30 days. bux_agent_session is a random identifier that groups the questions of one visit into a conversation: it lasts 30 minutes, is renewed on each message, carries no name, and is set whether or not the visitor has signed in. Our server sets it with the Partitioned attribute, so it never crosses from one site to another, and the assistant's own frame keeps a copy of the same identifier in the browser tab's session storage until the tab is closed: on a published business site the page shares that storage with the assistant, and on a business's own site the page hosting the assistant cannot read it. Both cookies are set by our server and cannot be read by page scripts. A third, bux_site_slug, names the site to the page and is only ever read when the software runs on a developer's own machine. When the business has turned on its own measurement tags, the site also keeps the visitor's answer to its cookie banner in the browser's local storage (brander:tag-consent, 12 months), and the business's tags set their own cookies, for that site's address only, after the visitor accepts.
• • Visit source. On a published business site, on a business's own site where a BranderUX-hosted assistant runs through our widget or SDK, and on branderux.com where our own assistant runs, the page keeps where the visit came from in the browser tab's session storage under brander:visit-source (the landing page, the referring site and any campaign tags or ad click ids in the link) until the tab is closed, so that it can be added to what the visitor submits. It is not a cookie, and a business using the SDK can turn it off.
• • Preferences. Your dark-mode choice is kept in your browser's local storage, not in a cookie.
• • Our own assistant. On branderux.com, bux_widget_assist in your browser's local storage keeps the time you first started building from our assistant, and bux_widget_assist_posted that your account already has it. The assistant itself runs in a frame from www.branderux.com and uses the same bux_agent_session identifier described above.
• • Analytics. Our own pages on branderux.com use Vercel's page-view analytics, which counts visits without setting a cookie and without a cross-site identifier. It is not loaded on a business's published site, and not inside the embedded assistant.
• • No advertising. BranderUX sets no advertising cookies and does no cross-site tracking. A business can turn on its own Google measurement tags on its published site: they load only after the visitor accepts them in that site's cookie banner, the site's own privacy notice names them, and they are the business's recipients, not ours.

10. Children

BranderUX is a business tool and is not directed at children under 18. If we learn we hold a child's data, we will delete it.

11. Changes & Governing Law

We will post any changes to this policy on this page with an updated date. This policy is governed by the laws of Israel. Questions: contact@branderux.com or our contact form.