Security & Privacy

Floe operates inside your product's browser automation environment. That position requires clear boundaries around what the agent can access, what gets stored, and how sessions are isolated. This page covers the specifics.

SOC 2 readiness

Floe's architecture is built to SOC 2 Type II standards. Certification is in progress. Enterprise customers can request our current security documentation, including architecture diagrams, data flow maps, and control descriptions, by contacting the team directly.

The controls are in place regardless of the certification timeline: encrypted data at rest and in transit, role-based access, and isolated processing environments.

What the agent accesses

During an active session, the agent sees what's on screen. It reads the page content, interactive elements, and layout the same way a user sitting in front of the browser would. This is how it navigates your product, clicks buttons, and fills forms.

What the agent can see during a session:

Page content visible in the browser viewport
Interactive elements (buttons, inputs, links, menus) and the labels that identify them
The value a control currently displays, including a read-only or disabled one
Text content on the current page
Navigation structure and URL paths

What browser page capture excludes:

User passwords or authentication tokens. Password fields are visible as fields, but their values are never sent to the agent.
Payment card numbers, bank details, or billing credentials
Browser cookies or local storage from your application
Data from other browser tabs or applications
Your product's database or backend systems (unless Floe enables API execution for your site at your request, or you connect support MCP tools)
Content on screens the user has not navigated to

During a supported form review, the in-product agent reads and sends the current values of the fields that workflow asks you to review, including corrections you type directly into those fields. Floe uses those values to check the form and ask for your next choice; they may appear in the conversation and its recording. This review does not collect unrelated form inputs or password fields.

Page capture works at the browser UI layer: it cannot read anything your UI doesn't render on screen. Both exceptions happen only at your request. With API execution, Floe turns on only the endpoints you ask for, and the agent calls only those. With support MCP, your application supplies a user token through getBearerToken (Floe never searches your application's storage for one), the token travels encrypted to the session that presents it to your MCP server, and the tools you allow can return account data beyond what is on the page. Your MCP server must authorize each request for that user. See Support.

Which agent reads which page

The section above describes the in-product agent (onboarding and support) — the only one that reads the whole page it is embedded on, because it is the only one that acts on that page. Visitor analytics, described below, reads a much narrower set, and runs only with the Website Agent and the Demo Agent.

The two top-of-funnel agents are different, and if you are putting Floe on a marketing site this is the part that matters:

Website agent — does not read your page content to answer. It answers from the content you ingested ahead of time. To show contextual nudges it checks, locally in the browser, whether the page sections you configured are on screen. To fetch a page's nudges, the SDK tells Floe that page's path when it loads, without the query string or fragment. This happens on every page load, whatever the consent mode or analytics setting; Floe does not store the path or link it to a visitor. When tailoring is on, it is also given a summary of the visitor's page activity; see What the agent is given about a visitor.
Demo agent — reads the product it is demoing, inside a browser on Floe's servers. It does not read the page you embedded it on to give the demo. When tailoring is on, it is given the same summary of the visitor's page activity.

Beyond that, for all three agents, the SDK sends only bounded page context during an active session: the page URL with query strings and fragments removed, the page title, and the path at session start and on each navigation. It also sends the browser's timezone and language setting, which Floe uses to interpret a phone number given without a country code. When visitor analytics is enabled and consent permits it, Floe also records widget activity, which nudge was shown or clicked, and path-only page views. With the Website Agent and the Demo Agent it also records the page activity listed under What visitor analytics reads from the page.

Full page capture, and the listeners an agent uses to follow what a user does in your product, are installed only for the in-product agent. This is enforced in the SDK, not left to configuration. Visitor analytics uses its own, narrower set, described next, and only with the Website Agent and the Demo Agent.

What visitor analytics reads from the page

Visitor analytics records how a visitor moves through a page, so your team can see what a lead did before they talked to the agent. It runs on every page where the Website Agent or the Demo Agent loads, and only when both of these are true. Both are true by default, so it is on unless you change one of them:

Collect visitor analytics events is on for the site (see Visitor data controls). Floe's servers refuse this data when it is off.
The visitor's consent permits it: with consentMode: "pending", nothing is read until your site calls consent("granted"), and consent("denied") stops it in either mode. See Consent gating.

It does not run with the in-product agent (onboarding and support). Inside your product, a page view is recorded as its path only: no title, no headings, no clicks, and no form submissions.

For each page a visitor views, Floe reads and stores:

The page path and the page title.
Time on the page, counted only while the page is visible.
How much of the page they saw: the lowest point of the page that was on screen, as a percentage of its length.
Sections read: the text of a heading, or the id of a section that has no heading, once it has stayed on screen for a few seconds. At most 12 per page.
Links and buttons clicked: the link's or button's own label and, for a link, its path on your site. For a link to another site only that site's host is kept. At most 10 per page.
Form submissions: that a form was submitted, identified by the form's id, name, or action path. At most 5 per page.
On the first page view after each page load, the referring page's host when it is a different host, and the campaign tags utm_source, utm_medium, utm_campaign, utm_term, and utm_content. No other query parameter is read, and nothing of the referring page but its host.

Visitor analytics never reads a form field. It does not read the value or text of any input, text area, native select, or editable region, and it does not listen for keystrokes. An element inside a form field or an editable region is skipped. So is a custom control that uses the standard accessibility roles for a choice, such as a combobox, listbox, option, checkbox, radio, switch, or pressed toggle. Password fields are never read. A link to an email address or phone number is recorded without its target.

Something a visitor typed is stored only where your own page repeats it in its title, a heading, a link or button label, or the URL path. A search-results page that puts the query in its title is one example. A dropdown built from plain buttons or links, with none of those roles, has the options a visitor clicks recorded as clicks.

It keeps one summary per page view. It takes no screenshot, records no mouse movement, and makes no replay of the page. Each label is cut to 80 characters and a title to 120. Before anything is stored, Floe replaces anything that looks like an email address, and any run of seven or more digits (including one written with spaces, dots, or dashes, such as a phone or card number), in titles, labels, and form identifiers. In a path, an address and an unbroken run of seven or more digits are replaced. In a campaign tag, only an address is. Names are not removed. Query strings and fragments are removed from every path.

To keep part of a page out of visitor analytics, add the data-floe-ignore attribute to an element. Nothing inside it is read: no heading, no link or button label, no form, and a click inside it is not recorded.

<section data-floe-ignore>
  <h2>Account for Jane Doe</h2>
  <button>Cancel Jane's plan</button>
</section>

Use it for any area that shows personal or account-specific information, such as a signed-in header or a customer portal embedded in the page.

Marking part of a page does not change what is recorded about the page as a whole: its path, title, time, and how much of it was seen. To exclude a whole page, put the attribute on its <html> or <body> element. Floe then records only that the path was viewed.

This data is sent only to Floe; the SDK contains no third-party analytics. It is kept for your Event retention window, and deleted sooner when the visitor's People record or the site is deleted. People with conversation access see it on the lead timeline, and the Website Agent and the Demo Agent can be given a summary of it: see What the agent is given about a visitor. It is tied to one browser and is never joined across devices.

Where a configured workflow confirms a record's identity or checks that a field is unchanged before a change, the values it compares are held in browser memory for that workflow only and are never written to browser storage. The normal page-context and session-data rules apply to the pages the workflow opens and to values in captured URLs, page content, or conversation.

In a staff-enabled file-selection workflow, you choose a file using Floe's browser prompt, review its displayed name and size, and select Supply this file before Floe assigns it to the specified upload control. The page hosting Floe may access a selected file before you confirm; cancelling prevents Floe from assigning it to the upload control, but does not prevent the page from accessing a file you already selected. After assignment, the site may process or upload the file immediately. Floe checks its configured filename extension and byte count in your browser; it does not inspect the file contents to establish its type. The workflow result sent to Floe contains the file extension, byte count and a SHA-256 digest, tied to that task and session; it does not include the file bytes or filename. The filename shown inside Floe's prompt is excluded from Floe's page capture; if the site separately displays the filename or file contents, those rendered details follow the normal page-capture and session-data rules above. Floe does not submit a separate Import or Confirm action as part of file selection.

What the agent is given about a visitor

When Tailor the agent to what a visitor has read is on (see Visitor data controls), the Website Agent and the Demo Agent are given a short summary of that visitor's page activity when a conversation or a demo starts: where the visit came from, the pages they viewed with the time spent and how much of each they saw, the headings they stopped on, the links, buttons and forms they used, and the pages they viewed on earlier visits. The agent uses it to choose what to offer: which part of your product to lead with, how much to explain, and which walkthrough to suggest.

The agent is instructed never to say or hint at any of it. It is told not to mention a page, a link, how long someone stayed, where they came from, or an earlier visit. If a visitor asks whether the agent can see what they browsed, it is told neither to list it nor to deny it, and to point them to your site's privacy policy. Make sure that policy covers this use.

The summary is built from the page activity visitor analytics records, including the page the visitor is on when the conversation or demo starts. Nothing more is read from the page for it, and it never contains the value of a form field. It covers one browser only, and only activity still inside your Event retention window. A visitor with no recorded page activity, for example because they did not consent, gets a conversation without it. The in-product agent is never given it.

The summary is part of the instructions sent to the AI model for that conversation or demo, so the agent runtime host and the AI providers listed at Sub-processors receive it, and it can be included in AI content diagnostics where those are enabled for your deployment (see Technical diagnostics).

What gets stored

Floe stores session data to power replays, analytics, and product insights in the dashboard.

Stored after each session:

Session recordings: A replay of the session. Product demos include the demonstrated screen and conversation audio; a voice conversation that never opened the product screen is audio-only.
Transcripts: The conversation between the visitor and the agent, with each visitor turn marked as spoken, typed, or submitted through a form.
Session metadata: Duration, pages visited, actions taken, timestamps
Agent decisions: What the agent chose to do and why (used for debugging and quality improvements)
Contact details: An email address or phone number a prospect shares with the Website Agent or Demo Agent, together with the conversation or demo it was shared in, its status, and the page it was shared from. See Contact details below.
Lead score: After a conversation or demo ends, the lead's score: its fit and engagement scores, the result of each fit check, and a short quote or paraphrase of the visitor's own words behind each check. See Lead scores.
Recap delivery status: Whether a recap email or CRM write succeeded, so a temporary failure can be retried without sending twice. This record does not contain the email address or phone number.
Booking-provider connection: For a connected Cal.com or Calendly account, the provider, the account label shown in the dashboard, connection health, and each site's selected event type. Provider credentials are encrypted at rest.
Slack connection: For a workspace connected with Add to Slack, the workspace's name and ID, the channel you chose, and connection health. The app's credential is encrypted at rest.
Verified bookings: When a connected provider confirms a meeting, the booking's status and scheduled time, linked to the conversation or demo it came from. The attendee's email address is not stored.

Stored as visitors browse, when visitor analytics is on and consent permits it:

Page activity: one summary per page view, holding what is listed under What visitor analytics reads from the page. It never includes the value of a form field.
Agent and nudge activity: that the agent was loaded, opened or closed; that the microphone was turned on or off, and how long the voice connection took to start; that a booking link was clicked, with the link's address without its query string; which nudge was shown or clicked; and that a conversation or a demo started or ended, an email was shared, or a meeting was booked.

Never stored:

User passwords entered during sessions
Payment information visible on screen (redacted from recordings)
Raw authentication tokens
Data from pages outside the active session

Session recordings are retained for 90 days by default. The delivery log of which recaps were sent for a session, and whether each went through, holds no message text or addresses and is deleted on the same 90-day schedule. Website Agent events, conversation content, and contact details have configurable retention, described under Visitor data controls.

Lead scores

To score a lead's fit, Floe sends an AI provider listed at Sub-processors three things: your ideal customer profile, what the agent recorded about the prospect (company, role, team size, tools, and the problems they described), and the visitor's own messages. The agent's replies are not sent, and neither are the visitor's name, email address or phone number as recorded contact details; anything a visitor typed or said in a message is part of that message. Engagement is counted from records Floe already holds and involves no AI provider.

The visitor's words kept with a score are treated as transcript:

They are deleted when the transcript they came from is: with a Website Agent conversation's content under Conversation retention, and with a demo session's recording and transcript on the session-recording schedule above. The scores themselves and the result of each fit check remain.
While Record conversation transcripts is off, Website Agent messages are not sent for scoring, and a lead scored while it is off stores none of the visitor's words.
Deleting a conversation, a session or a People record deletes the scores that belong to it. A conversation that survives an erasure is rescored without the erased demo. An address-wide erasure also removes the stored words from the score of any other conversation that held that address.
Email addresses and phone numbers are removed from the stored words.

In the dashboard, scores and the words behind them are shown only on views that require conversation access. Your team's recaps carry the score, its tier and its top reasons, and the CRM lead card carries the score and tier; neither carries the visitor's words.

Contact details

An email or phone number a prospect shares is stored encrypted, attached to the exact conversation or demo session it was shared in. Floe does not use it to build a person profile, merge activity from different browsers, or recall a conversation from another device. Two browsers can share the same address and remain separate visitors.

In the dashboard, a contact detail is shown only on views that require conversation access: Leads, Website Agent conversation details and Demo Agent session details. Insights never shows an address: not on the funnel, not on the evidence lists behind it, and not in Leads, which names a visitor by name and company, or by the demo link or page they arrived through. A number spoken or typed during a recorded conversation can still appear in that transcript and recording.

Contact capture is enabled per deployment. Until Floe turns it on for you, a submitted email or phone is not stored, and the conversation continues without it. An email address that is obviously not a real inbox (a placeholder, a disposable-inbox domain, or a domain that cannot receive mail) is never stored.

On deployments where Floe has enabled prospect enrichment, the submitted work email can be sent to a third-party enrichment service to look up the company. Contact Floe if you need this disabled.

Floe stores no customer-uploaded avatar media. The Website Agent's video avatar is chosen from a set Floe owns and hosts; your site's configuration records only which presenter was selected.

Reference Guide data

A Reference Guide title and body are site Customer Data. Floe stores the guide and its search index. When a guide is relevant to a question, its content may be used in an answer by any of the agents, and Website Agent answers can be seen by unauthenticated public visitors.

Do not store secrets, credentials, internal-only material, personal data, or customer-specific information in a Reference Guide. Guide content is treated as factual input, not as instructions: it cannot change the agent's rules or make it navigate.

Floe retains a guide until an Owner or Admin deletes it or the site is deleted. Deleting a guide removes it from new agent answers.

Visitor data controls

Site owners can open Site → Settings → General → Visitor data collection to control visitor data collection:

Collect visitor analytics events controls page-view and page-activity, widget, conversation, demo, booking, and nudge telemetry, plus SDK diagnostics across agent modes where enabled. Turning it off stops that collection, including everything under What visitor analytics reads from the page, and pauses conversation summaries and the scoring of Website Agent conversations. The agents and live conversations keep working.
Tailor the agent to what a visitor has read lets the Website Agent and the Demo Agent use a visitor's page activity to choose what to offer; see What the agent is given about a visitor. It is on by default and depends on Collect visitor analytics events: while that is off, this switch is off too and cannot be turned on. A change applies to the next conversation or demo that starts.
Record conversation transcripts controls storage of Website Agent chat messages. Turning it off does not disable the agent: new message content is not retained, no summary can be generated and a lead scored while it is off keeps none of the visitor's words (see Lead scores), but the dashboard still shows that a conversation happened. This setting also covers the chat turns of a conversation that hands off to a live demo. Direct Demo Agent recording is a separate, deployment-level control; contact us to change it.
Event retention is 365 days by default and can be set from 30–730 days. Raw visitor events older than the window are deleted; aggregate reporting remains.
Conversation retention is 90 days by default and can be set from 7–365 days. Transcript content, summaries, and contact details shared in Website Agent and Demo Agent interactions expire with that window. Shortening the window applies to existing data on the next daily retention pass. Floe keeps only the metadata needed to show that content expired.
Recap links and pending bookings cannot outlive the contact detail they came from. Once it expires or is deleted, the links stop working.

If a retention window is shorter than an Insights window, the dashboard disables that Insights window rather than presenting partial data as complete.

Who can see what in the dashboard

Roles are Owner, Admin, and Member. Owners and Admins have conversation access; Members do not. Conversation access covers everything that carries a visitor's identity or words: People records, Website Agent transcripts, Demo Session lists and details (including recordings and transcripts), onboarding and support recordings, the Insights evidence lists for Asked a question, Shared email, and Took a demo, and the Leads, What people ask, and In demos sections on Insights.

Members still see the Insights funnel, where leads come from, and the pages that start conversations, aggregate session statistics, and the evidence lists that carry no identity (Visitors, Opened the agent, and Booked a call).

No Insights evidence row carries an email address or a browser identifier; rows are grouped by a per-site reference that holds neither. The only names shown on an evidence list are on the Took a demo list, as the prospect typed them into the demo form, behind conversation access. Elsewhere on Insights, Leads names a visitor by name and company, also behind conversation access.

The SDK also supports host-controlled consent with consentMode: "pending". Until your site calls consent("granted"), Floe does not create browser identifiers, attach configured identity, or collect visitor analytics or SDK diagnostics, while the chat remains usable. See Browser SDK: Consent gating.

Technical diagnostics

Where enabled per deployment, Floe collects technical diagnostics to investigate connection problems, service failures, and slow AI operations. Structured operational events contain technical identifiers, SDK or model versions, timing, usage counts, and failure categories. Floe can also enable collection of its server application messages and error stack frames. Recognized credentials are redacted, and recognized conversation, model-payload, and media dumps are omitted, but application messages can still contain customer data. SDK diagnostics do not add a persistent browser identifier or capture your application's console output or network traffic.

Floe can separately enable AI content diagnostics to investigate incorrect answers. These records can include the instructions and messages sent to a model, product or page text included in those messages, and the model's response. Recognized credentials are redacted and media payloads are omitted, but conversation content can still contain personal information. Turning off Record conversation transcripts also prevents new AI content diagnostics for agent sessions and conversation summaries, including Direct Demo Agent sessions whose recording is separately enabled. This does not change Direct Demo Agent recording itself or remove diagnostic records already captured. This feature requires staff activation; contact Floe to confirm whether it is enabled for your deployment.

For eligible sessions with conversation recording and event collection enabled, Floe can group AI diagnostics across sessions using a pseudonymous identifier derived from an existing visitor or user record. Grouping does not require AI content diagnostics. The identifier is scoped to your site; it does not contain the person's email address, name, or your external user ID. This does not create another persistent browser identifier or establish a verified identity.

The consent and collection controls above apply to SDK diagnostics. Server-side service diagnostics have separate deployment controls. The Event retention and Conversation retention settings do not set technical diagnostic retention; contact Floe for your deployment's diagnostic retention and deletion requirements.

Slack access

Add to Slack uses Slack's own authorization screen. Floe asks for permission to post messages and to view basic information about channels: public channels, and private channels the app has been invited to. Of that, Floe reads each channel's ID and name and whether it is private or archived, to list channels for you to choose from, and posts recaps to the one you chose. The app cannot read messages or files in your workspace. Disconnect on the Slack card removes the stored credential and asks Slack to revoke Floe's access, unless another Floe site is still connected to the same workspace.

Scheduling-provider access

Connecting Cal.com or Calendly uses the provider's own authorization screen. Floe requests access to identify the connected account, list its scheduling pages, read booking state, and receive booking notifications. It does not use that access to create, cancel, or reschedule meetings. You never give Floe a webhook secret or personal access token.

The connection belongs to your Floe organization; each site picks its own scheduling page. The primary Connect action covers the connecting user's meetings. Connect whole organization (admin) requests organization-wide coverage where the provider role and plan allow it; when they don't, the narrower connection stays in place and the dashboard labels it Tracks your meetings only.

A booking counts as verified only when the provider confirms it. Browser callbacks and booking-button clicks never do. The attendee email in the provider's confirmation is never stored, logged, or added to the booking link.

Custom booking links do not receive visitor details by default. Configuring an explicit {email} query value opts into sharing the prospect's supplied email with your scheduling provider through the booking URL. In-agent prefill honors the site's consent setting; the prospect's recap scheduling action uses their email when opened. Prospect test emails fill the placeholder with the test inbox. The address may then appear in the provider's logs and the browser's history. Floe does not add it to booking-click analytics, and internal recaps carry no booking link. See booking setup.

Provider booking verification is enabled per deployment. Until Floe enables it, Connect is unavailable and the Booked a call row in Insights stays at zero, while a configured booking link keeps working in Link only mode.

AI tool connections (MCP)

A member can connect their own AI tool — Claude Code, Claude Desktop, claude.ai, ChatGPT or Cursor — to Floe's MCP server. This section describes that direction only. The Support Agent calling a customer's MCP server is a separate feature with its own controls, described under Support.

Every connection is approved by a signed-in member on a Floe consent screen, in the browser. Registering an AI tool grants nothing on its own.

One connection reaches one organization. The member chooses which at consent time. Reaching a second organization requires a second connection.

A connection can never exceed the member's own role. Its access is derived from that member's role, not from what the AI tool asked for, and it is re-checked on every request. If the member is demoted or removed from the organization, the connection loses that access within a minute. Reading full conversation transcripts requires the same Owner/Admin permission it does in the dashboard.

Tokens. Access tokens are short-lived, refresh tokens rotate on every use, and both are stored only in hashed form.

What a connection can read, subject to the access approved: site configuration, demo readiness, demo and conversation metadata, aggregated prospect questions, full conversation transcripts (only with the transcript permission), guides, reference guides, the product walkthrough and its steps, ingested content and derived product knowledge.

What a connection can change, with the matching access: demo guides, reference guides (Owner and Admin only, as in the dashboard) and the product walkthrough (Owner and Admin only; other plans are made by Floe).

What it cannot do: it cannot delete or archive anything — there are no such tools. It is never given a site API key or client key, and it is never given a link to a session recording.

Revocation. Every member sees their own connections under Organization → Connected apps, with the access each holds and when it was last used, and can revoke any of them. A revoked connection stops working within a minute.

Browser session isolation

Each Floe session runs in its own isolated execution context. One visitor cannot inspect another visitor's browser or live session.

For the demo agent, each demo runs in a dedicated browser instance. One prospect's demo has zero visibility into another prospect's session. The browser instance is destroyed after the demo ends.

For the in-product agent, the overlay runs within the user's own browser tab. It does not open background connections to other users' sessions or share context across users. The overlay renders in its own container and keeps no state in your product's DOM.

No voice connection exists before a visitor opens the agent. Minimizing an active conversation keeps the session connected; using End, disconnecting the SDK, or leaving the page tears it down. While the SDK is installed but no conversation is open, it renders the launcher and, where collection and consent settings allow, records the page activity and nudge events described under What visitor analytics reads from the page. The Website Agent also sends the page's path when it loads, as described under Which agent reads which page. The SDK reads nothing else from the page in the background, and never a form field.

Consent for voice recording: Microphone capture begins only after an explicit visitor action and browser permission. The website agent displays a recording notice and opens with the visitor's microphone off. The browser's permission request always follows an action the visitor took: turning the mic on, or opening the agent with a voice launcher, in which case the request comes after the agent's spoken welcome. A text, keyboard, nudge, or opener start never asks for the microphone. Revoking permission during a conversation stops capture immediately. Typing and listening require no microphone access, and a visitor who keeps the mic off leaves no visitor audio in the replay.

Anonymous-first visitor identity: The website agent never requires an email to start a conversation. When collection is enabled and consent permits it, the SDK stores a first-party identifier in the visitor's own browser. It is not shared across sites, clearing site data resets it, and it lets Floe resume an active conversation and keep that browser's activity together. It is a continuity aid, not authentication: it cannot prove which person is using a shared browser, and it does not follow someone to another device. Floe never looks up a visitor's history by email address or externalId.

Collecting email, phone, name, company, and role is configurable per agent. A Website Agent contact question never withholds an answer, though an unanswered required detail can hold the transition into a demo. Conversational asks are suppressed while configured consent is pending or denied; see Consent gating for how the Demo Agent's start form is treated.

Unsigned SDK context: Values in the browser SDK's userInfo object are current-session context, even when your application reads them after login. They do not authenticate the person or unlock history from another browser. Do not put access tokens or other secrets in userInfo.

Data deletion: Users can request deletion of their session data through the dashboard or via the API. Deletion covers session recordings, transcripts, contact details, and associated metadata for the conversation, demo, browser, or site included in the request. A site-wide deletion also removes that site's pending and verified booking records and its selected scheduling page; the organization's provider connection remains until an owner disconnects it.

Deleting a People record with a customer-provided identity also erases its email address across the site: every stored contact record for it, and every exact occurrence in surviving conversations, summaries, demo records, and recording metadata. Non-identifying session rows can remain for aggregate reporting; the delivery-log rows of every session involved are deleted. This address-wide erasure is available only from a customer-provided identity, including an email or external ID your team set in People, not from an address a visitor merely stated in conversation.

A record already delivered to an external CRM is not removed by deleting it in Floe or by changing the CRM delivery policy.

Data portability: Portability requests are handled by contacting Floe.

Processing location: Data is processed and stored in the United States. Transfers of personal data from the EEA, the UK, or Switzerland are covered by the Standard Contractual Clauses incorporated into our Data Processing Addendum. Talk to us if you have a specific regional hosting requirement.

Right to explanation: Because the agent's decisions are logged (what it chose to do and why), you can provide users with clear explanations of how the AI interacted with their data during any session.

Responsible AI practices

The agent is grounded in your product's content. It does not generate information beyond what it learned from your ingested documentation and configured product knowledge. When the agent doesn't know something, it says so rather than guessing.

Session recordings and transcripts are used to improve the agent's performance for your specific product via session intelligence. They are not used to train models for other customers. Your data stays yours.

Floe uses third-party AI providers to process conversation content, and to index your ingested content, Reference Guides, and plan content for search; each one, and what it receives, is listed at Sub-processors. A visitor's reply can itself contain personal information, so avoid entering credentials or other secrets in chat.

FAQ

Can I disable session recording entirely? For Website Agent conversations, yes. Turn off Record conversation transcripts under Site → Settings → General → Visitor data collection. The agent still functions, but those chats do not produce stored transcripts or summaries. Demo and onboarding recordings use separate controls; contact us if you need those disabled for your deployment.

Does the agent work with products behind authentication? Yes. For demos, the agent uses credentials you provide in the site configuration. For in-product onboarding, the user is already logged in and the overlay operates within their authenticated session.

Can the demo agent save, delete, or export real data? No. It can open forms and fill in fields to show how a workflow works, but the controls that commit that change — Save, Submit, a final Create confirmation, Download, Export — are blocked before the click happens. The same backstop blocks inviting or removing people, changing permissions, connecting integrations, and sending messages, plus destructive account actions like deleting or deactivating a user or canceling a subscription. It applies to every product, with no per-site exception.

It is a backstop, not a substitute for a low-privilege demo account. Use one anyway as a second line of defense.

What happens if a user shares sensitive information during a voice session? Transcripts are stored with your configured retention policy. If a user inadvertently shares sensitive information, you can delete that specific session's data through the dashboard.

Where can I find more details? Check the FAQ for additional questions about how Floe works. Enterprise customers can request a full security review with the team.