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, audit logging, 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), including accessible labels and control tooltips that identify those elements
Text content on the current page
Navigation structure and URL paths

What the agent never accesses:

User passwords or authentication tokens
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)
Content on screens the user has not navigated to

The distinction matters: the agent works at the browser UI layer, not the application layer. It cannot read anything your UI doesn't render on screen.

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 capture a DOM snapshot or read arbitrary page content. It answers from the content you ingested ahead of time. To place configured contextual nudges, the SDK locally resolves their configured CSS selectors or scans heading text and accessible labels for a configured heading label, checks the matched anchors' viewport positions, and listens for navigation, scroll and resize. It also handles interactions with Floe's own launcher and conversation controls. It does not capture typed content from the host page or send raw scroll coordinates.
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 bounded page context rather than page content during an active session: the URL with query strings and fragments removed, the page title, and the path at session start and on each navigation. This lets the agent answer about the right page and choose page-specific prompts. Those messages contain no DOM snapshot or page-body text.

Separately, when visitor analytics is enabled and consent permits it, Floe records widget activity and path-only page views. The Website Agent can also record which configured nudge was shown or clicked, including that nudge's ID, page, match, and topic; it does not send the surrounding page text.

This split is enforced in the SDK rather than left to configuration: full DOM capture and host-page action listeners are installed only for the in-product agent. The Website Agent's local nudge matching and launcher presentation do not turn a marketing embed into a page-content stream.

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 media captured during the session. Product demos include the demonstrated screen and conversation audio; a voice-first conversation that never opens the product screen can be audio-only.
Transcripts: The retained voice and text conversation between the visitor and agent. Stored turns identify whether visitor input was spoken, typed, or submitted through a form, and an interrupted agent response is not represented as fully played.
Session metadata: Duration, pages visited, actions taken, timestamps
Agent decisions: What the agent chose to do and why (used for debugging and quality improvements)
Shared-email claims: When a Website Agent or Demo Agent visitor submits an email, Floe stores the normalized address with the exact source browser (when consent produced one), conversation or demo session, claim status and timestamps, and the validated site origin and path. Query strings and fragments are not stored in that source path.
Claim-backed delivery state: When a prospect recap or confirmed-contact CRM write is eligible, Floe stores delivery status, source-claim references, and per-provider outcome state so temporary failures can be retried without duplicating an accepted write. Durable delivery state does not contain the raw email address; the current address is decrypted only inside the final authorized provider call. Schedule and rejection capabilities are stored only as hashes; the plaintext capability is placed in the emailed URL fragment and is never part of the initial HTTP request.

The address inside the contact-claim record is encrypted at rest with dedicated, versioned keys rather than copied into a canonical person or demo-profile field. Floe also stores a site-scoped keyed digest so an authorized dashboard search can match a complete email exactly without using the address as a global person key. The digest is not returned on public endpoints and cannot authorize a history read. In the dashboard, raw claim addresses appear only on views protected by the conversation-data permission: Website Agent conversation lists/details and the matching Demo Agent session detail. A claim that was rejected, bounced, expired or superseded is shown as evidence rather than a contactable mail link. Aggregate Insights do not expose raw addresses.

Source-bound claim capture is a staged deployment capability and defaults off until Floe enables it. A separate consumer activation controls claim-backed dashboard/search and CRM use. With capture off, Floe omits the submitted address instead of falling back to a canonical person or demo-profile email field; the agent can continue without it. Turning consumers off does not move the address elsewhere: existing claims remain under their retention policy but are not made available to those consumers. Contact Floe to enable the rollout for your deployment.

On deployments where optional pre-call prospect enrichment has been enabled by Floe staff, the submitted work address can be sent to the configured enrichment service for that lookup. Floe's enrichment cache uses a site-scoped keyed digest rather than the raw address, and the cached enrichment result excludes the address. Contact Floe if you need this processing disabled for your deployment.

Site configuration can also include a customer-uploaded Website Agent idle-loop video. Floe retains the active clip while it is configured. Replacing or removing it, or deleting the site, stops future Floe delivery and initiates deletion. The change reaches an embed when it reloads or reinitializes; a visitor's browser may retain a previously fetched clip for up to one year.

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 event, conversation-content, and shared-email-claim retention can be configured as described below.

Visitor data controlsCopy link to this section

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

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 Website Agent 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, but the dashboard can still show a transcript-free activity record and aggregate that an interaction occurred. Floe does not retain the visitor's words for that record, and no transcript-derived summary can be generated. This policy continues to govern stored chat turns if the Website Agent hands off to a live demo; direct Demo Agent recording is a separate control.
Event retention is 365 days by default and can be set from 30–730 days. Raw visitor events older than the selected window are deleted; aggregate reporting remains.
Conversation retention is 90 days by default and can be set from 7–365 days. Transcript content, summaries, open questions, and derived visitor memories expire with that window. Floe retains only the metadata needed to show that the content expired under the site's policy.
Shared-email claims from Website Agent and Demo Agent interactions use the same 7–365-day conversation-retention setting, measured from when the address was shared. The daily retention process deletes the entire claim record — its encrypted address, exact-match digest, status, and source metadata — once it reaches that window. Lowering the setting also shortens existing claims on the next retention pass; deleting their source or site removes them sooner.
Claim-backed recap deliveries and actions cannot outlive their source claim. Rejection revokes the other current actions, and claim expiry, retention deletion, source deletion, or a data-subject erasure makes delayed delivery and action attempts unavailable.

If the event-retention window is shorter than an Insights window, the dashboard disables the incomplete outcome window rather than presenting partial raw-event data as complete.

Aggregate Insights are available to organization members. People records and Website Agent transcripts contain visitor identity or message content and therefore require conversation access, which owners and admins receive by default. Demo Session lists and person-level details, including recordings and transcripts, use the same conversation-access boundary. Members can view aggregate session statistics and trends, but not those session-level records.

The SDK also supports host-controlled consent with consentMode: "pending". Until the host calls consent("granted"), Floe does not create browser identity keys, attach configured identity, or collect visitor analytics, while the chat remains usable. A denied decision is sticky for that page load. See Browser SDK: Consent gating.

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. In the same browser, the Website Agent can continue an active conversation across pages and tabs. Once that conversation is no longer active, a later visit starts a new conversation and may use retained conversation context from that same browser. The browser identifier that enables this continuity is not authentication, so it never proves which human is holding a shared browser; another person using that browser can inherit the same context. The agent does not use an email address alone to recall conversation context from another browser or device.

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's Shadow DOM container is isolated from your product's DOM, preventing cross-contamination of state.

No voice connection exists before a visitor opens the agent. While its launcher is visible, the Website Agent may evaluate configured nudge anchors and scroll activity locally, as described above. Minimizing an active conversation hides the panel but keeps that warm session connected; using End, disconnecting the SDK, or leaving the page tears the connection down.

While the SDK remains installed, it can still render the launcher and, when the configured collection and consent settings allow it, collect the first-party page-path and nudge events described above. It does not read page content in the background. The Website Agent keeps first-party browser identifiers for continuity (see “Anonymous-first visitor identity” below), but it does not use them across sites or for cross-site profiling.

Floe supports GDPR requirements across several areas. Learn more about how it works at the architecture level.

Consent for voice recording: Microphone capture begins only after an explicit visitor action and browser permission. The website agent displays a recording notice, opens with the visitor's microphone off, and does not initialize a microphone device on launcher open. The browser permission request occurs only when the visitor explicitly turns the mic on; typing and listening to the agent require no microphone access. If the visitor keeps the mic off and types, the replay can contain the agent's audio and the typed transcript but cannot contain visitor audio. After the visitor turns the mic on and grants permission, their captured speech is included in the session recording as well as the transcript.

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 first-party identifiers in the visitor's own browser — they are not shared across sites, and clearing site data resets them. They let Floe resume an active conversation, keep activity from that browser together, and use retained conversation and demo context owned by that exact browser on a later visit. They are bearer continuity identifiers, not authentication or proof of a person; a shared browser can therefore represent more than one human. The SDK's startup status check sends only an existing, consented visitor token. It never selects state by email or externalId, and it never creates a visitor token merely to run that check.

Collecting an email (and optionally name and company) is optional and configurable, and it never blocks the first answer. Floe stores the address as a claim on that exact source interaction, not as permission to create or merge a canonical person. Two browsers may claim the same address while their histories remain separate. A direct demo submitted without a consented browser token stays bound to that demo session; Floe does not mint a browser identity just to store the claim. An email alone never causes the agent to recall context from another browser. Conversation data tied to a browser record follows the same retention and deletion policy as other session data (see Data deletion below).

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

Data deletion: Users can request deletion of their session data. Submit deletion requests through the dashboard or via the API. Deletion covers session recordings, transcripts, and other associated metadata. Shared-email claims are removed with the exact browser, conversation, demo, or site source included in the deletion.

When an organization deletes a People record whose email identity came from a customer-provided source, Floe also performs an address-wide erasure within that site. It finds every retained claim for that exact normalized address, across claim statuses and retained key versions, without joining the affected browser histories. It deletes those claims; scrubs exact occurrences of the address from surviving conversations, messages, memories, demo records, summaries, and recording metadata; and reclaims the affected Floe-hosted recording media. The remaining non-identifying session rows can stay for aggregate reporting.

The erasure also places a site-scoped, non-plaintext fence for the remainder of the applicable conversation-retention window, preventing a racing or delayed capture from storing the address again. Source-erasure markers and final live checks separately prevent stale summaries, notifications, media finalizers, and CRM deliveries from restoring or using it. Shortening the site's conversation retention also shortens the fence; deleting the site removes it. This broader address lookup is permitted only from a customer-proven identity, not from an unverified conversational claim.

Data portability: Session data can be exported in standard formats for portability requests.

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.

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.

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.