Security & PrivacyCopy link to this section

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 readinessCopy link to this section

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 accessesCopy link to this section

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 you explicitly enable API execution or support MCP tools)
Content on screens the user has not navigated to

Page capture works at the browser UI layer: it cannot read anything your UI doesn't render on screen. The two exceptions are yours to configure. With API execution, the agent calls the endpoints you enabled. 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 pageCopy link to this section

The section above describes the in-product agent (onboarding and support) — the only one that reads the page it is embedded on, because it is the only one that acts on that page.

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. 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; it does not capture typed content from the host page.
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.

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, path-only page views, and which nudge was shown or clicked.

Full page capture and host-page action listeners are installed only for the in-product agent. This is enforced in the SDK, not left to configuration.

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.

What gets storedCopy link to this section

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.
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.
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.

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. Website Agent events, conversation content, and contact details have configurable retention, described under Visitor data controls.

Contact detailsCopy link to this section

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: Website Agent conversation details and Demo Agent session details. Insights never shows an address, not on the outcome numbers and not on the evidence lists behind them. 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.

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 dataCopy link to this section

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 controlsCopy link to this section

Site owners can open Site → Settings → General → Visitor data collection to control the data the Website Agent collects:

Collect visitor analytics events controls page-view, widget, conversation, demo, booking, and nudge telemetry. Turning it off stops that collection and pauses conversation summaries. The agents and live conversations keep working.
Record conversation transcripts controls storage of Website Agent chat messages. Turning it off does not disable the agent: new message content is not retained and no summary can be generated, 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 dashboardCopy link to this section

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), and the Insights evidence lists for Asked a question, Shared email, and Took demo.

Members still see every Insights outcome count, aggregate session statistics and trends, and the evidence lists that carry no identity (Unique visitors, Opened agent, and Booked call). The counts are never withheld, only the records behind them.

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 are on the Took demo list, as the prospect typed them into the demo form, 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, while the chat remains usable. See Browser SDK: Consent gating.

Scheduling-provider accessCopy link to this section

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 or internal-channel follow-up links. See booking setup.

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

AI tool connections (MCP)Copy link to this section

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.

Creating and editing plans is restricted to Floe staff accounts at present.

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, ingested content and derived product knowledge.

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 settings → 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 isolationCopy link to this section

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-path and nudge events described above. It does not read page content in the background.

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 whose email came from your own system also erases that 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. This address-wide erasure is available only from a customer-provided identity, 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 practicesCopy link to this section

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; 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.

FAQCopy link to this section

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.