Privacy at a glance

Limits today

Read this before you describe Sequential in a privacy notice or security questionnaire.

Area	What happens today
Analytics data	Sequential keeps events, and the user, session and account records built from them, for the organisation's events retention period: 7, 30, 90, 180 or 365 days. The default is 365 days. Only Sequential support can change it, for all the projects of the organisation. An event can stay for up to about a week longer. A server can set a shorter limit for every project. Sequential support can exempt the events of one organisation's projects from that limit. See A server-wide limit.
Recordings	After the replay retention period, Sequential no longer plays the recording. The storage deletes the recording files about 2 days after the period ends. If you delete the project, its recordings become unreadable at once, and the storage deletes the files later. The session stays until its events expire.
Heatmap data	On by default for each project that records websites. Owners and admins turn it on or off under Session replay → Web → Heatmaps. All four roles (owner, admin, member, viewer) see it on the Heatmaps page, with a page picture from one visitor's masked recording. See Heatmap data.
Erasure	You cannot delete one person's data. If you delete a project, Sequential permanently deletes its events within 14 days with the default schedule. It deletes judgments and identity links too. Its recordings become unreadable at once, and the storage deletes their files later. It keeps the project's per-day usage counts. These hold no user, session or event identifiers. Deleting an organisation does the same for each of its projects.
IP addresses	Sequential stores the full IP address with every event. No working option shortens or drops it.
Property values	If a property holds an email, name or phone number, Sequential stores it as you sent it.
Page URLs under Balanced	With Balanced masking, a web recording keeps each page's full address, with the query string and the #fragment. Only a secret, such as a long random token, is stored as [token]. Strict, the default, keeps only the route.
Settings not applied	Concurrent, the mobile Screens list and some API-only settings do nothing yet. Do not describe them as controls.

What Sequential collects

Data	What it holds
Events	Name, time, user and session ids, page URL, referrer, browser, operating system, country, the full IP address and your properties.
Replay recordings	What the page or screen showed and what the visitor did, masked on the device. Each recording also holds its session id and, if there is one, a user id.
DevTools data	Errors, console, network and performance data, stored with a replay by default.
Heatmap data	For a sample of recorded web sessions: the page's host and route, a device class, the clicked element as a place in the page structure, where in the element, and how far the page was scrolled. Counts only, with no text. From 11 October 2026, also the session id of each session with a rage click on an element. On by default. See Heatmap data.
Billing	The number of sessions of each organisation for each day. For an organisation that started a test checkout before 13 October 2026, also the pack, the billing state, the period dates and the payment provider's ids for its customer and subscription. See Payments.
Refused data	For each project and each UTC day: how many requests Sequential refused or did not store, the reason, and the source (the Sequential SDK, recordings, or another tool's SDK by its name). If the reason is a website or app that is not allowed, also its host, for example shop.example.com. At most 20 hosts a day are kept. The others count as (other). The host comes from the request, so it can be another website that uses your project's key. Kept 30 days. If you delete the project, Sequential deletes them, at the latest with its events. Counting started on 9 October 2026.
Judgments	The judge's answers as probabilities, kept 400 days after the session ends.
Your team's activity	This includes: Ask searches, from the app or from an agent, kept 180 days. Verdict feedback, kept 400 days. Audit log entries. A log of each fix brief delivery, kept 400 days. A log of each successful answer of an agent tool, except record_release, with counts and no visitor text, kept 400 days.
Saved filters, funnels and flows	The name, the conditions or steps, and who changed each item last. Conditions can hold values such as user ids, email addresses or property values. Sequential keeps an item until someone deletes it or the project is deleted.
Past filters	The last 10 filters that each person applied on each page of a project. A filter can hold the same values as a saved filter. The user ids that a funnel hands over to Events or Users are not added. Sequential deletes older entries, and deletes the list when the person's account or the project is deleted.

Heatmap data

Heatmap data shows where visitors click and how far they scroll on each page. The Heatmaps page in the app shows its click counts and, under Scroll, its scroll depth. Below the controls, it draws them on a picture of the page. See Heatmaps.

• It is on by default for each project that records websites. The web recorder collects it only while it records, and only for a sample of sessions. Mobile apps send none.
• Owners and admins turn it on or off with the Heatmaps switch in Settings. See Turn heatmap data on or off.
• It holds no text. It holds the page's host and route, a device class, places in the page structure, cells inside elements, scroll steps and counts.
• All four roles can see it (owner, admin, member, viewer). They see the counts and the page picture on the Heatmaps page. With a signed-in session, they can also read them through the API: GET /api/heatmaps/pages, GET /api/heatmaps/data and, from 11 October 2026, GET /api/heatmaps/element (one element's clicks per day). The answers hold counts and the project's sampling rate, never a session id. Access tokens and agent tools cannot read it. Sequential sends it to no third party.
• The page picture comes from one visitor's recording. The Heatmaps page asks GET /api/heatmaps/snapshot for it. It is one visitor's recording of the page, masked as the project's replay settings say. So anything that this recording shows unmasked appears in the picture, and all four roles (owner, admin, member, viewer) see it. See The page picture.

Turn heatmap data on or off

1. Open Settings → Projects → your project → Session replay.
2. Stay on the Web tab. The Heatmaps box is on it.
3. Click the switch. It shows On or Off.

Only owners and admins can change it. Members and viewers see the box read-only.

• Turning it on asks first. A sheet asks "Turn on heatmaps for …?", with your project's name. It says: "Sequential will count clicks and scroll depth from a sample of recorded sessions. Only numbers are stored: no text, URLs or visitor ids. A page picture is drawn from a recorded session, masked as your replay settings say, and is visible only to people who can watch replays." With a Fixed sample, the sheet gives the percentage in place of "a sample". Nothing is saved until you click Turn on. Cancel, Escape or a click outside the sheet saves nothing.
• Turning it off asks nothing. It saves at once.
• The switch saves on its own. It does not wait for Save, and it saves none of your other unsaved edits on the tab. Each change saves a new version of the settings, and the Audit log records it as project.config_changed. A message confirms it: "Heatmaps turned on — they apply on the next page load" or "Heatmaps turned off — they apply on the next page load".
• Sample sets the share of recorded sessions. Auto: "the server picks the rate from your recorded traffic". Fixed: a percentage of recorded sessions, from 0.1 to 100. Sample is part of the form: click Save to keep it. It is disabled while heatmaps are off. See Limits.
• It needs Recording and Web. While Recording or the Web platform is off, the switch and Sample are disabled. The box says "Recording is off, so no heat is collected." or "Web recording is off, so no heat is collected." It adds: "Heatmaps use recorded web sessions: turn on Recording and Web above to collect them."

Through the API

A script signed in as an owner or admin can set the same field, replay.heatmaps.enabled. Read the document with GET /api/projects/:id/config, change the one field, and send it back with PATCH /api/projects/:id/config. The API does not ask you to confirm. Access tokens cannot reach this route.

The page picture

A heatmap needs a picture of the page to draw clicks or scroll depth on. Sequential takes this picture from a recording. The Heatmaps page shows it below the controls, as Page picture, with the clicks or the scroll depth drawn on it. See Heatmaps.

• How it is built. A separate builder service makes each picture in the background. Builds run only there: the API server never makes one in production. A request answers queued, then building, and then the picture, in about 30 seconds. While it waits, the Heatmaps page shows "Preparing the page picture…". Requests for the same page and device share one build.
• When no builder runs. If no builder service has signalled in the last minute, a request answers no_builder at once and starts no build. Sequential queues nothing. A picture that is already stored is still shown. The answer says to ask again in 30 seconds. The Heatmaps page shows "Page pictures aren't available right now. The ranked list is complete." On the scroll map, it ends "The Scroll depth card is complete." It asks again on its own, up to 3 times, and then shows Check again. If Sequential cannot check for a builder, the answer is the usual 503 unavailable.
• The source is one visitor's masked recording. Sequential finds a recent recording of the page and device through the hourly pointer rows. The picture is that recording's page at one moment: its structure and the changes to its layout. The recording is masked as the project's replay settings say. So anything that it shows unmasked appears in the picture, as it does in a replay of that session. The picture takes no dates: the dates you set change only the heat on it.
• Who can see it. All four roles (owner, admin, member, viewer), on the Heatmaps page and through the API, with a signed-in session: GET /api/heatmaps/snapshot with a page and a device. It has the same checks as replays. Access tokens and agent tools cannot read it.
• What the answer holds. The recording's events for that moment, the moment itself (at_ms) and the window size (viewport). It holds no session id, user id, recording key or segment reference. Other answers hold only a state, such as queued, building, none, too_large, failed or no_builder.
• How long it lives. Sequential keeps a finished picture encrypted with the project's replay key, for at most 15 minutes. It never lives longer than the recording that it came from. The pointer rows follow the replay period, like other heatmap data.
• When you delete the project. Sequential deletes the project's replay keys, so a stored picture can no longer be read. It also removes the stored pictures and the waiting requests.
• A picture over 4 MB, compressed, is not kept. The answer is then too_large. The answer is too_large too when the builder refuses a part of the recording: it would use too much memory, it is too dense to read safely, or two earlier attempts on it did not finish. Sequential keeps a too_large answer for one hour, and starts no new build for that picture during the hour.

Where it goes

Destination	What it receives	When
TypeSafe, the AI judge's provider	A text digest of each judged session, with questions	Background judging, Insights, Ask in the app or from an agent (ask_sessions), rubric previews
TypeSafe, the AI judge's provider	Short parts of visitor text, redacted, each in one question: the quoted passages of a fix brief, the routes in a token's findings list, and the visitor text in the answer of a session tool, an analytics tool or ask_sessions	When Sequential delivers a brief, when an agent reads one finding with get_finding or the findings list, and when an agent uses a session tool, an analytics tool or ask_sessions. Sequential uses an earlier answer again when it has one.
The agent that you connect, for example claude.ai	What its tool calls return, screened as for any token, and Sequential's fixed tool descriptions and server instructions. An agent reads data with the scopes of its token or, for claude.ai, with the scopes chosen on the consent page, for one project, and only while the person who connected it is still an owner or admin who meets the 2FA rule	Only when the agent calls a tool. Anthropic runs claude.ai. Sequential sends nothing else to Anthropic.

Owners and admins can switch off background judging for a project. Then Sequential sends no new session to the judge in the background. Insights, Ask, rubric previews and agents still send data on request.

The Insights tab can send an email or user_id property with its value.

• Sequential does not scan values in the digest. For example, TypeSafe receives an email address in a button's text as it was stored.

Payments

The hosted preview takes no payments, and you cannot buy anything in it. Each organisation has a monthly session allowance. See Usage and limits.

Until 13 October 2026, the preview tested payments with a payment provider, in its test mode. No real payment was taken. For an organisation that started a test checkout then, Sequential keeps the provider's ids for the customer and the subscription. When you delete the organisation, Sequential keeps a record of the organisation's id with these ids. This record has no end date. Sequential does not send anything to the provider any more.

Who can see it

What	Who
See events, users, sessions, replays and DevTools data, and use Ask	Every role
See the project's saved filters, funnels and flows, with the values in them	Every role
See your own Past filters	Only you, in every role. Nobody else can read them, admins included
See ingest keys (Sources & keys)	Owner, admin and member
Create, rotate or revoke ingest keys, change Session replay settings (heatmaps included), archive or delete a project, and see the Audit log	Owner and admin
See, create and revoke access tokens	Owner and admin
See heatmap data	All four roles (owner, admin, member, viewer), on the Heatmaps page and through the API. From 15 October 2026, access tokens read heatmap counts through list_heatmap_pages and get_heatmap, with the sessions:explore scope. They never get element text or the page picture.
See the page picture	All four roles (owner, admin, member, viewer), on the Heatmaps page and through the API. Access tokens and agent tools cannot read it.

Access tokens and agents

An access token is the first Sequential credential that is not public. Ingest keys are public.

• Sequential shows a token once, when you create it: "This token is shown once. Copy it now, and treat it like a password."
• Sequential stores only a hash of the token. The list on the Access tokens tab shows its last 4 characters.
• That list can also show "It identified itself as" and a name. The agent's MCP client sends this name. Sequential does not check it, so treat it as a hint.
• Every token expires after 30, 90 or 365 days. The token that an agent gets with a trial expires 3 days after setup. An owner or admin can revoke it at any time.
• An agent uses the token at /mcp, or calls one tool at a time with POST /api/agent/<tool>. Both accept only a token. They do not accept a signed-in session.
• claude.ai connects with a sign-in, not with a token that you copy. An owner or admin allows it on a consent page, for one project and with the scopes chosen there. It works only at /mcp. It works only while that person is still an owner or admin of the organisation and meets its 2FA rule. Sequential checks this on every call. It can never get releases:write. The connection shows under Agents, and an owner or admin can disconnect it there. See Connect claude.ai.

Scope	What an agent can get with it
findings:read	Findings, the sessions of a finding, and fix briefs
sessions:read	A summary of one session (get_session)
sessions:explore	The Watch list, the latest sessions, one person's sessions in order (get_user_journey), one session with its judgment and DevTools counts, one session event by event (get_session_timeline), JS errors and failed requests (list_errors), judged friction by page, device, operating system, browser or country (get_struggle_by_segment), the rubric, calibration, and from 15 October 2026 heatmap counts by page and element (list_heatmap_pages, get_heatmap)
releases:write	Record a release
findings:link	Add a pull request, commit or issue link to a finding (link_fix). It cannot remove a link: that needs a signed-in person
insights:propose	Propose a change to the Insights questions (propose_rubric). It stores a proposal only; an owner or admin applies it. Sequential checks the texts that the agent writes. See Proposals from an agent
findings:verify	A finding's measurement after its fix release (get_verification)
ask:use	Ask with ask_sessions: the sessions that match a description, with the matched moment and the session's judgment. It spends the agent allowance of the project
analytics:read	A briefing (get_overview), event counts, histograms, breakdowns, funnels, flows, retention, and lists of users and accounts by id. See Analytics below

The Access tokens tab and Custom… on Agents offer all ten scopes. No preset includes findings:draft or insights:propose. claude.ai never gets findings:draft. It gets insights:propose only when the person ticks it on the consent page. A claude.ai connection gets analytics:read with either access choice. Agent: read everything, plus Ask ticks sessions:explore, ask:use, findings:read, findings:verify, sessions:read and analytics:read. It never ticks releases:write or findings:link, so an agent with this token cannot record a release or add a fix link. It can spend the agent allowance through ask:use. For each tool, see Limits and Agent tools.

Treat a token like a password. If you use Add an agent access token to this prompt on Setup, or in the setup checklist on Dashboard, the install prompt contains the token. The panel then says "This prompt now contains an access token. Treat it like a password: paste it only into your own agent, and never into a shared chat, ticket or committed file." The token stays in that page only until you reload or leave it.

The endpoint /mcp/readonly does not stop ask_sessions. A read-only connection with an ask:use token can spend the agent allowance. To stop an agent from running Ask and spending the agent allowance, give it a token without ask:use. Other agent tools still spend the screening allowance.

An owner or admin can read the activity of the tokens of a project with GET /api/projects/:id/agent-activity. It gives counts for each token and the newest 50 calls, for the last 1 to 30 days. Each call has the tool name, the token id and counts. It has no visitor text. The answer also names the tokens: the name that each token got when it was created, and identified_as, the name that the agent's MCP client sent. Sequential does not check identified_as. The endpoint needs a signed-in session. The Agents page shows the same activity for the last 7 days. It shows token names and tool names, not visitor text. See Limits.

Names, emails and phone numbers

From 10 October 2026, Sequential removes the names, email addresses and phone numbers of known people from what an agent or an access token receives. This is best effort. The agent's instructions say: "Best effort: names, emails and phone numbers your app sent to Sequential are removed from what the agent receives; identity fields are never returned or filterable; element text is withheld. Your own site's hosts, as you list them in Allowed origins, stay readable in URLs, even when a known person's value matches your domain word. Nothing else is exempt. A host that your visitors send is never added."

It cannot remove:

• a name that your app never sent as a property, for example a contact in a CRM, a customer of your customer, or a name in a support ticket title
• a name that your app sends only under a property that Sequential does not read as a name, for example note or comment. An agent can also filter and group by such a property. From 10 October 2026, a name under a dotted key whose last part is a name or email key, such as billing.name or profile.email, is a known value, and Sequential removes it. From 11 October 2026, a name under a compound name key, such as billing_name, billingName or owner_name, is a known value too
• a nickname or a misspelling
• a first name that is a common word, outside that person's own sessions
• a name of only common words, such as Will Smith, when its words are not next to each other
• a person identified in the last 5 minutes, in another person's session
• a person past the 50,000 most recently seen
• a developer's user name in a stack frame or a file path, such as /Users/ada/…, unless the developer is a member of your organisation
• a name in an encoding that Sequential does not decode: HTML entities, base64 or punycode
• an id that is an email or a name: ids come as your project sends them
• old text, such as a finding title, about a person who is no longer in your data
• a guess that an agent checks with a part of a name, such as the first few letters in a prefix or wildcard filter. Sequential refuses only a filter value that holds a known value. See Filters below

How it works:

• Filters. From 11 October 2026, an agent cannot filter on a known value. Otherwise, the count of a filter such as url = /users/ada-lovelace would confirm a guessed name. Sequential checks every filter value of a call before the query runs, in the same way as the text that it removes. If a value holds a known value, the call fails with one sentence that does not name the value: "This filter value cannot be used. Use a shorter value or a different field." A call with too many values for one check fails with the same sentence. If Sequential cannot check, a value on a text field, such as a URL, a page or a property value, fails: "Sequential could not check this filter value for personal data just now. Try again in a minute, or filter on an id or a structural field." Filters on ids are not checked. Filters on structural fields, such as the event type, country, browser or operating system, still work.
• Where. Every agent tool, the findings tools and the findings REST routes for tokens, fix briefs for agents and Draft a fix, and the judge's input when an agent runs Ask. From 11 October 2026, also the fix brief in the app: Copy fix brief, Show brief and Open a GitHub issue use the copy that an agent gets. Other parts of the app, such as a finding's evidence, still show the raw text to a signed-in person.
• Who is known. The people and accounts of your project: the values of their identity properties that your app sent, such as name, first_name, email or phone, from identify events and from visitor and account properties. An account's name counts only as a whole value. The name and email of each member of your organisation are known too.
• What it removes everywhere. Each known email, each known full name in either order and with any separator, each name word of 3 or more letters that is not a common word, and each phone number of 7 or more digits.
• What it removes in a person's own sessions. All of that person's values, read at the time of the call. This includes a first name that is a common word, such as Grace or Will. For such a word, Sequential withholds the whole text, so the words around it cannot give the name back.
• The forms. Inside observed text, [person] or [account] marks a removed value. {"withheld": "person"} is a text that held only such values. In the findings tools and routes, such a text reads [person].
• Your own sites. From 10 October 2026, the hosts in your project's list of allowed websites stay readable, for example in a URL. This is also true when a known person's value has the word of your domain in it. Sequential keeps only the whole host, such as shop.example.com, with or without www.. It still removes a name next to the host: a known email jd@example.com becomes [person]@example.com. It never keeps a host with no dot, such as localhost. Nothing else is exempt. Sequential never adds a host that your visitors send. If it cannot read the project's settings, it keeps no host. Set the list under Settings → Projects → your project → Sources & keys → Allowed websites. See Organisations and projects.
• If Sequential cannot check. If the list of known people is not available, for example for a new project or a new token in its first minute, free text comes as {"withheld": "not checked"}. If the lookup of the people of a session fails or takes more than 1 second, the text of that session comes as {"withheld": "not checked"}. A fix brief for an agent, and Draft a fix, are refused then. Ids and counts still come. From 11 October 2026, the fix brief in the app is not shown then either. The card says "The fix brief is not shown: its privacy check is not available now. Try again in a minute.", with Retry, and Copy fix brief, Show brief and Open a GitHub issue do not work.
• Updates. Sequential adds new people every 5 minutes and rebuilds the list every night. It keeps the 50,000 most recently seen people of a project, and the 50,000 most recently seen accounts.

Secrets in links

From 11 October 2026, Sequential also removes secrets in links from the text that an agent receives. This applies to every agent tool, to findings and fix briefs, and to Draft a fix. The secret reads [token]. The text around it stays.

• A long random token. A run of 20 or more letters, digits, - and _ that is not made of words, such as the token in a sign-in link: /claim/[token]. A long hex secret of 48 or more characters is a token too. Readable parts next to the token stay: CheckoutPage-[token].js.
• A secret parameter. The value of a parameter whose name ends in token, secret, sig, signature, password, pwd, code, key, auth, otp or jwt: ?reset_token=[token], ?oobCode=[token]. This is also true when the link is percent-encoded.
• A link word. A path part of 16 or more characters after a word such as reset, verify, confirm, magic, invite, claim, erase, unsubscribe or login: /reset/[token].

These stay: UUIDs, ids, release names, md5 and sha1 hex values outside such a link, slugs such as /blog/How-We-Built-Our-Data-Pipeline, and code names such as isUserLoggedInAndHasAccess. Id fields, such as a user id, never pass through this rule. Some ids in text, such as a Firebase uid, can read [token]. A short or readable secret can still pass. The rule recognises shapes, not meaning.

From 11 October 2026, Sequential also uses this rule when it stores new data: page URLs, referrers, URL and path properties, and the page address of a recording. Data that it stored before keeps its secrets. See What Sequential keeps from page URLs.

Findings and fix briefs

• Sequential redacts text from your users' sessions and flattens it to one line.
• Sequential removes quoted passages that read like instructions to an AI. The fix brief states its screening state.
• In a token's list of findings, a title is only the kind of finding, for example Exception. For a click finding (a dead click, a rage click or a dead end), a token never gets the element text, and the selector is masked. The list gives scope and page_route apart from the title. Sequential cuts each to 200 characters and screens it like visitor text. Each comes as {"observed": …} or a withheld form, or as "" if the finding has no page. FINDINGS_SCREEN_REQUIRED=false does not change this.
• The fix brief has a Steps before it happened section: the last steps of up to 2 sample sessions before the finding, such as the pages and the error messages. In the copy that a token, an agent, a webhook or Draft a fix gets, a click or a form step has no text: it reads "(element text withheld)". Each step is a quoted block of up to 60 characters, redacted and screened. It never has custom-event properties. A replay link in it contains the session id. From 14 October 2026, a dead end's brief also has the line "- How they came back (sessions): with Back ×N, sent by the app ×N, not known ×N." It holds only these fixed words and counts. See Findings and fixes.
• Sequential logs each fix brief delivery and keeps the log for 400 days. See Retention and deletion.
• For a token without findings:verify, a finding's stage shows only what was done: new, handed_off, fix_linked or dismissed. measuring and every result come back as {"withheld": "needs findings:verify"}. (fix_released is also allowed, but the list and one finding never show it.)
• A finding's newest verdict, latest_verdict, can have a reason that someone on your team typed. For a token, Sequential redacts the reason, puts it on one line and screens it like visitor text. The reason comes as {"observed": …}, {"withheld": "removed by screen"} or {"withheld": "not screened"}. The name of the person who gave the verdict, user_name, always comes as {"withheld": "person name"}. This applies to the findings list and one finding, through REST, POST /api/agent/<tool> and MCP.
• If the screen cannot run, the reason comes as {"withheld": "not screened"}. A reason that the screen could not check does not make the call fail.
• In one finding's evidence, each sample's session_id comes as {"id": "…", "source": "observed"}. So does each session_id in a finding's sessions list: GET /api/findings/:n/sessions and list_finding_sessions.
• In a finding's sessions list, a release name comes as {"withheld": "not screened"}, because Sequential does not screen it there. get_session gives the screened release. With FINDINGS_SCREEN_REQUIRED=false, the release name comes as plain text: redacted, on one line and cut to 200 characters, but not screened.
• In the answers of link_fix and get_verification, fix link addresses, release names, environments and commit SHAs are screened like visitor text. With a token, GET /api/findings/:n/verification runs get_verification, so it gives the same screened answer. Only the app, with a signed-in person, gets these values as stored. See Findings and fixes.

Fix briefs and findings fail closed for a token. If Sequential cannot screen every quoted passage of a finding, a token does not get the fix brief or the finding:

• GET /api/findings/:n and /api/findings/:n/brief answer 503 screen_unavailable, with Retry-After: 60.
• Through MCP, get_fix_brief and get_finding answer a tool error. Through POST /api/agent/<tool>, they answer 400 tool_error.
• This is the default. An operator can turn it off with FINDINGS_SCREEN_REQUIRED=false. Then a token gets the brief, and the brief says that it was not screened. Any other value, or no value, keeps the default.
• The app, with a signed-in person, always gets the brief. The brief states its screening state.
• A paused screen is not refused. A token gets the brief and the finding with every quoted passage withheld. But if the finding has more quoted passages than the screen reads, Sequential refuses the token as above. See Screening in fix briefs below.

Sessions

Visitor text is text that a visitor's browser or app sent to Sequential, for example a page path, a release name, or a browser name. In the answers of the session tools, visitor text and ids reach the agent in one of these forms:

Form	Meaning
{"observed": "…"}	Sequential redacted the text and put it on one line. The screen found no instruction to an AI in it.
{"id": "…", "source": "observed"}	An id that a visitor's app or your team set. Sequential did not screen it (see below).
{"withheld": "removed by screen"}	The screen found text that reads like an instruction to an AI.
{"withheld": "not screened"}	Sequential could not screen the text.
{"withheld": "identifier format"}	An id that does not have the id format (see below).
{"withheld": "person"}	The text held only names, emails or phone numbers of known people. See Names, emails and phone numbers above.
{"withheld": "not checked"}	Sequential could not check the text for known people. See Names, emails and phone numbers above.

A withheld value means that Sequential removed the value, could not check it, or does not give it to this token. The findings tools also use {"withheld": "needs findings:verify"} and {"withheld": "person name"}. get_overview uses {"withheld": "needs sessions:explore"} and {"withheld": "needs findings:read"} for a section that the token cannot read. get_verification uses {"withheld": "unknown confound"} for a kind of confound that the server does not know.

• The screen fails closed. If the screen is not available, the agent gets {"withheld": "not screened"}. Sequential never gives the agent visitor text or custom rubric labels that it did not screen. Ids are the exception: they come marked, not screened. The tool call still succeeds.
• Sequential's own words are plain text. If a session reported no release, the agent gets "release": "not reported". If a visitor's app sent a release with the name "not reported", the agent gets {"observed": "not reported"}, or a withheld form if the screen did not pass it. So the agent can tell the two apart.
• Error samples name the person. Each sample of list_errors has user_id. From 12 October 2026, it is the person of that session, resolved as on a session row. Only when Sequential resolves no person for the session is it the id that the error was stored with. It comes marked.
• Ids are marked, not screened. A session id, user id or event id with the id format comes as {"id": "…", "source": "observed"}. The id format is 1 to 128 letters A–Z or a–z, digits or the characters . _ @ + : -. The mark tells the agent that a visitor's app or your team set the id, and that it is not a value of Sequential. The screen is a third-party model, and Sequential does not send your users' ids to it. So Sequential does not screen ids.
• Ids are not redacted. If your user ids are email addresses, the agent gets the email addresses.
• The person behind a session. In the session tools and in ask_sessions, user_id is the person after Sequential links their ids. anonymous_id is the id that the session sent, when it is different. In search_events, an event's person gives the linked person when it is different from the event's own user_id. If Sequential cannot look up the person in time, user_id or person comes as {"withheld": "not resolved"}. All of these ids come marked.
• Replay links carry the id without the mark. replay_url, and the url of each moment, are plain text with the session id in them. If the session id does not have the id format, the link comes as {"withheld": "identifier format"}.
• Sequential's own ids are plain text. A fix link's id and added_by, and a finding's id such as F-12, are values of Sequential. They have no mark.
• Custom rubric labels are screened. Your team types them, so Sequential screens them like visitor text. This applies to question, option and level labels, and from 11 October 2026 to the question text, criteria and phrases that get_rubric gives. They come as {"observed": …} or a withheld form. This applies to get_rubric, list_watch, list_sessions, get_user_journey, get_session_full, get_session, get_calibration and ask_sessions, through POST /api/agent/<tool> and MCP.
• Default rubric labels are plain text. Only the shipped default rubric is Sequential's own text. A customised rubric is screened, also when it keeps the default ids. The labels of sessions judged under an earlier custom rubric stay screened after Reset to default. After a reset, Sequential can also screen the labels of sessions judged under the default, because it reads them from its saved copy of the rubric.
• One flagged label withholds them all. Sequential screens the custom labels of one answer together. If the screen flags one of them, every custom label in that answer comes as {"withheld": "removed by screen"}.
• Rubric ids and option keys are marked too. Your team types them, so they come as {"id": "…", "source": "observed"}, like a visitor's id. Sequential does not screen them. This applies also to the shipped default rubric. It covers question ids, option keys, the value of a verdict, signal keys, the kind of a moment and the id of worth_watching. Other ids come as {"withheld": "identifier format"}. The rubric editor accepts only lowercase letters, digits and _, up to 40 characters, so a saved id always has the id format.
• ask_sessions screens the label of each matched moment. The label is visitor text, for example an error message. The label of a click, a form submit or an event of another kind comes as {"withheld": "element text"}. For an agent, the judge also reads the sessions with that text replaced by element. In ask_sessions, a moment's kind is an event kind of Sequential, such as click or error, and comes as plain text. This is not the rubric moment kind of the other session tools, which comes marked. Session and user ids come marked, as in the other session tools. The answer does not repeat the description.
• get_session_timeline gives the events of one session. For each event, it gives the page path and a label: the page, the name of the custom event, or the error message. From 9 October 2026, the label of a click, a rage click, a dead click, a form submit or an event of another kind comes as {"withheld": "element text"}, because element text can name a person. A label has up to 60 characters. An error also has its type. An error type and a path have up to 80 characters. Sequential removes hosts, query strings and fragments from this text. It does not give the properties of custom events. Sequential redacts and screens the labels, types and paths as visitor text. Event ids, such as E001, are Sequential's own values, so they come as plain text.
• list_errors gives errors in groups. For an exception, it gives the type, the message and the top stack frame. Before Sequential groups a message, it replaces email addresses, UUIDs, hex ids and quoted values with …. For a failed request, it gives the method, the host, the route template of the address and the HTTP status. It does not give the query of the address. Sequential redacts and screens all these values as visitor text. Console messages are not included.
• get_struggle_by_segment groups judged sessions by a fixed field. A group is a page route template, an operating system or browser name, a country code of two capital letters, or a device class: mobile, desktop or unknown. Sequential redacts and screens page routes and operating system and browser names as visitor text. The country code and the device class come as plain text. It never groups by a person's or account's name, email or IP address. The labels of signals, outcomes and friction levels follow the rubric rules above.
• From 11 October 2026, get_rubric gives the agent your rubric in full: each question's text, criteria and phrases, so that the agent can read your Insights questions. Sequential screens the text of a custom rubric. The history of changes never names the person who made a change.
• A session row never includes IP addresses, visitor or account properties, referrers or event names. get_session_timeline is different: it gives the name of each custom event. From 10 October 2026, it also gives the session's person as an id (user_id, and anonymous_id when it differs), as get_session does. Of a page address, the agent gets only the path.

Analytics

The analytics:read tools give counts and ids. They never give a person's or account's name, email, IP address or properties.

• Ids come as the project sends them. User ids and account ids come as {"id": "…", "source": "observed"}, like session ids. Sequential does not redact them. If your user ids or account ids are email addresses, the agent gets the email addresses. An id that does not have the id format comes as {"withheld": "identifier format"}.
• Your team (internal traffic). From 10 October 2026, a project can mark its team as internal: user ids, email domains, or the members of your organisation. The agent tools then give the team's share as counts only, never an id, an email, a domain or a name. The domains and the members' emails reach the database only as hashes. See Analytics from an agent.
• Traits never leave. A person's or account's name and email are in visitor and account properties. The list tools and the events of search_events do not read properties or IP addresses. In their answers, props comes as {"withheld": "custom event property names and fill rates: get_event_types; values: get_breakdown by event_prop:, visitor_prop: or account_prop:<key>"}.
• No element text. From 9 October 2026, an agent never gets the text of an element. A selector keeps only its structure: tag names, combinators and positions. Its ids, classes, attribute values and text become …. An element-text property, such as $el_text, and PostHog's $set, $set_once and $unset take only is set and is not set in a filter, and get_breakdown and suggest_property_values refuse them. A filter on the selector takes only an exact structure.
• Ids from retention. From 10 October 2026, retention_analysis with include_ids: true gives the ids of cohort members and of members who came back, at most 50 of each per call. It needs sessions:explore as well as analytics:read. Each id is the person after identity resolution, and it comes marked, as above.
• Event text is screened. Event names, property names, page addresses, referrers, selectors, browser and operating system names, breakdown keys and property values are visitor text. They come as {"observed": …} or a withheld form, as in the session tools.
• Identity fields are refused. An agent cannot filter or break down by a person's or account's identity, or list its values. A filter, a funnel or flow step, a retention event, a breakdown or a suggest_property_values call that names one gets the tool error "Agents can't filter or break down by a person's or account's name, email or other identity fields." This covers:
  • user_ip;
  • the property keys name, email, $email, distinct_id, $distinct_id, $device_id, $user_id, $anon_distinct_id, $session_id, $window_id, $pageview_id, $prev_pageview_id, user_id, account_id and session_id, also in capitals;
  • keys that name an email, a phone or mobile number or an IP address, for example user_email, phone_number or client_ip;
  • name-like keys: username, surname, nickname, mail, and name after a word for a person or an account, for example user_name, given_name, family_name, customerName or company_name. plan_name, product_name and page_name stay allowed.
• compound names: from 11 October 2026, name or names after any other word, or run together with it, is refused. For example, billing_name, billingName, owner_name and ownername are refused. Only a word for a thing keeps name allowed, for example event_name, page_name, screen_name, file_name, plan_name, product_name, hostname and filename. Sequential does not read what a word means. A word that is not on its list of thing words is refused, also when it is harmless, for example v2_name or top_names.
• the same words with digits or run together: digits never hide a name, so phone2, ipv4 and first_name2 are refused, and so are firstname, orgname and user_fullname. screen_name, hostname and filename stay allowed.
• keys with dots: from 10 October 2026, Sequential also checks the last part of a key after its last dot. So billing.name, profile.email and owner.name are refused.
• The id fields user_id, account_id and session_id stay filterable. A user_id filter matches the whole person.
• An agent can list the names and values of ordinary properties, such as plan, with suggest_property_values. It can filter by them, and group events by one of them with get_breakdown. This includes event properties, for example plan or the campaign tag $utm_source.
• Each tool reads only the project of the token. Data older than the events that Sequential keeps is not available. See Limits.

For what Sequential sends to AI providers, see AI and third parties.

Agent trials

A coding agent can set up a trial for an email address before anyone has an account. See Let your agent set up a trial.

Data	What happens to it
The email address that the agent gave	Kept with the trial. If you claim the trial, it is your own account's address. If nobody claims it, Sequential erases it with the trial
The network address of the request	Used only for the trial limits. Cleared when you claim the trial
The agent's client name (its User-Agent, at most 200 characters)	Cleared when you claim the trial
The platform that the agent chose: web, iOS, Android or React Native	Kept with the trial
Events	Only from your own computer for web, and no recordings from mobile apps, until the claim. Kept 7 days

• No AI before the claim. Sequential does not judge the trial's sessions, and it sends no visitor text to the judge. The agent tools withhold it.
• Two emails at most. One when the trial is set up, and a reminder after 48 hours if nobody claimed it. Both are fixed texts. They contain nothing from the agent's request, not even the project name. Sequential sends at most one setup email an hour to an address.
• Not you? The link in the first email erases the trial and blocks the address from trials that agents create. Sequential keeps only a hash of the address for this.
• No claim, no trial. Sequential erases an unclaimed trial after 72 hours, as when you delete an organisation.

What Sequential removes automatically

Data	What happens
Page URLs in events	Keeps the scheme, host and path. Replaces every query value with [redacted], except campaign and ad-click parameters. Drops the #fragment. From 9 October 2026, it keeps a hash route, such as #/orders, and cleans its parts like the path.
DevTools data	Replaces JWTs, Bearer and Basic credentials, email addresses and card numbers before storage. Console message text is off by default, but Sequential keeps JavaScript error messages even with console text off. Under Strict, a file that the page loads keeps only its domain, an API call keeps its route with id-like parts masked, and ids after a / in error and console text are masked.
Click text (Sequential SDK)	Replaces emails, tokens and card numbers. Leaves out the text of an element marked data-sq-mask or data-sq-private. From 10 October 2026, also leaves out the text of a click in account UI, or that names the signed-in person. See Sequential SDK.
What recordings show	Default Strict masking masks all text, inputs and most attribute values, and blocks images, SVG, video, audio and iframes. It cuts link and image addresses to their domain, and the page address to its route. Both presets mask what users type, checkbox and radio values, file names and hidden fields.

These rules catch common patterns only. They are not a guarantee. Names, addresses, phone numbers and custom tokens match no pattern, so Sequential keeps them. The one exception is click text with the signed-in person's own name or email, which the Sequential SDK leaves out. On recorded page text, masking in the visitor's browser is the only protection.

Consent

Sequential does not ask your visitors for consent or check whether they gave it. If your product needs consent before analytics or recording, load the SDK and the recorder only after your own consent check.

With sequential.js, you can load the SDK at once and wait:

1. Add data-opt-out to the SDK's <script> tag. Every visitor starts opted out.
2. When the visitor agrees, call sequential.optIn().
3. If a visitor has already agreed, call sequential.optIn() on each page.

Related

• What Sequential keeps from page URLs
• Masking and redaction
• AI and third parties
• Retention and deletion
• DevTools in replays
• Recording settings
• Roles and permissions
• Audit log