Workspace & request privacy · 11 October 2026

Your data.
Your choices.

This notice covers the AI workspace, supported connections and request forms in this early-access product.

Account and connection permissions

TWB supports email sign-in through Supabase Auth. Resend delivers the one-time sign-in code. We process your email, verified account identifier, necessary session cookies, and the version and time of your registration consent. We do not store your sign-in code in the TWB database. Short-lived sign-in challenges are retained for up to ten minutes and cleaned up on later sign-in requests; pseudonymous rate-limit counters are cleaned up when expired. These records can remain until a later request triggers cleanup. Signing in does not grant inbox access. Existing ChatGPT sign-in remains available; linking an email to an existing wallet requires verification of both identities and your explicit choice. We never combine wallets merely because their emails match. Connecting a mailbox is a separate, optional step: you review TWB’s explanation, explicitly agree, then choose an account and approve access on the provider’s own screen. TWB does not ask for your email or AI-service password. Receipt-import permission is not marketing consent; it does not enroll you in newsletters. A mailbox connection does not merge TWB accounts or grant another TWB user access to your wallet.

Your AI workspace

The workspace contains the profile, industry, tasks, budget, tool names, plan names, invoice totals, billing periods, seat counts, renewal dates and optional usage and usefulness information you enter. These are self-reported records, not automatically obtained from AI providers. The manual workspace does not access your prompts, conversations or bank accounts. Connections include Hugging Face account-profile and Notion workspace-metadata previews, ElevenLabs personal subscription data and OpenAI / Anthropic organization API reports as described below. New Gmail receipt-import connections are paused.

What saving does

Unsaved records remain in the current page and can be lost when you leave or reload. Signed-in edits are saved automatically; selecting Save also stores your profile and records in the site database, associated with the identifier of your signed-in TWB account. The workspace interface and API return records only for that account. Site operators and hosting infrastructure can process stored records to run the service; the database is not end-to-end encrypted. Demonstration records are separate and are not saved as your records. Your interface language is stored in your browser. For a newly verified email registration, we also retain the selected language, verified email and delivery status for a one-time account welcome. These welcome records do not currently have automatic deletion; they remain until an account-data deletion request is fulfilled. This transactional welcome does not subscribe you to marketing. Service emails are sent through Resend when delivery is configured.

Monthly wallet history

Each successful wallet save records the latest entries for the current UTC calendar month. Saving again in that month replaces that month’s record; earlier saved months are preserved. The record includes the tool and plan, recorded amount, billing period, seats, renewal date, tasks, source and optional usage assessments you saved. We show up to twelve calendar months. Older monthly records are removed on a later successful save, so inactive accounts may retain older records until saving or deletion. Missing months are not reconstructed. This is a history of your recorded subscription budget, not verified payments or realized savings. Connected provider reports remain separate.

Personal invitations

When you request a personal invitation link, TWB stores your account identifier, a random public invitation code and its creation time. Opening the link does not create an attribution. A signed-in recipient must explicitly accept; we then store the invited account identifier, the inviter account identifier and the acceptance time. An account can accept one invitation and cannot accept its own. The inviter sees only the total accepted invitations, not invitee names, email addresses or account identifiers. Public invitation pages do not disclose the inviter’s identity. These records are separate from wallet records and are not removed by deleting the saved workspace; no automatic deletion period is configured. Contact us for a data request. Invitations do not send automatic emails, grant credits or activate paid rewards.

Renewal reminders

Your saved reminder settings include the lead time, reminder time, optional time zone and whether to show notices in your wallet. Dates come only from your records or explicit next-payment dates already saved from a connected source; TWB does not invent recurring payments. Browser popups require your separate choice and browser permission. Device-local consent and a bounded record of reminder identifiers are stored separately for each TWB account in your browser. Popups contain a generic subscription-review notice, without tool names or payment amounts, and work only while your TWB wallet is open. Browser or device settings may prevent their display. Background push is not active. Email reminders require separate consent and verified service readiness, as described below.

Email reminders are off until you explicitly enable them for the server-verified email on your TWB account and email delivery is available. You cannot enter another recipient in the reminder controls. The default is one reminder per known renewal; you may separately choose daily, every-three-day or weekly repeats within your saved reminder window through the known renewal date. The system checks hourly after your saved reminder time, sends at most one digest per local day, and does not promise exact-time delivery or invent later renewal dates. Email consent is separate from calendar and browser permissions and does not subscribe you to marketing.

When enabled, Resend processes your recipient address, canonical tool names and renewal dates to send the requested summaries. Payment amounts, custom plan names, mailbox labels, passwords and API keys are not included. TWB stores the recipient address and account-bound recipient identifier, consent version and time, revision, frequency, email time zone and language, and operational records needed to process and deduplicate reminders. Provider acceptance is not confirmation that a message reached your inbox.

You may turn email reminders off in the reminder controls. Email unsubscribe links use a private token, stored as a digest, and require confirmation before changing consent. Turning reminders off or deleting the saved workspace revokes consent and cancels pending reminders. A message already submitted to the email provider may still arrive. A detected change to the verified account email suspends existing consent; the new address needs fresh consent. Deleting the saved workspace immediately clears its stored email message bodies and job date payloads. Separate deduplication hashes and processing dates remain until the 90-day cleanup described below. These records stay associated with your TWB account. Completed, cancelled or failed message text, recipient and date payloads, and email-provider receipt identifiers are otherwise cleared after 35 days during routine dispatch processing; attempt counters are cleared after 62 days, run summaries after 35 days, and reminder-occurrence records after 90 days. Cleanup does not run while dispatch processing is paused, so records may remain longer. Minimal revision, status, deduplication and unsubscribe-token digest records remain to prevent delayed requests or retries from restoring revoked reminders and to support opting out. Hosting and email providers can retain their own operational records.

Calendar synchronization is optional. After you explicitly agree, TWB creates a private subscription URL that lets your chosen calendar service read tool names and renewal dates, without payment amounts, plan names or mailbox labels. Anyone with this URL can read those details until you disconnect it; keep it private. The application database stores only a digest of the URL token, your account identifier, time zone, calendar language, consent version and relevant timestamps. The raw URL is shown only when created. Hosting infrastructure and your calendar provider can process the URL and its requests. Each calendar refresh reads the latest saved dates in TWB; refreshing provider data in TWB remains separate. Your calendar provider controls its refresh frequency, alerts and retention. TWB cannot confirm that you subscribed or received a reminder.

Disconnecting a calendar or deleting your saved workspace revokes future access through the subscription URL. A minimal account, revision and consent record remains to prevent delayed requests from recreating revoked access. Calendar services may retain cached or imported events and alerts; remove the subscribed calendar in that service to delete them there. A one-time calendar download includes only tool names and dates and does not synchronize later changes.

CSV import and export

A CSV import is parsed in your browser. The original file is not uploaded. Imported records are sent to the site database only when you save them or explicitly share a summary. Export downloads the displayed records to your device. Wallet records support their original billing currencies, including SGD. There is no automatic currency conversion.

Sharing a summary or requesting access

The early-access form stores your email, organization type, selected interest, preferred TWB payment period (when chosen), request reference and submission time. A shared AI review additionally stores the profile and records shown in the sharing flow. Sharing is a separate action from saving your private workspace. Legacy service requests can also include a company website and target exchange. The site owner can view submitted requests and explicitly shared summaries in the request inbox. We use these details to review and respond to your request; submitting a form does not subscribe you to a marketing newsletter.

Contact and product feedback

The Contact form stores your email, selected topic, message, reference, submission time and email-notification status in our private feedback inbox. The site owner can read these messages to respond and consider improvements. When email notifications are configured, Resend processes your email and message to deliver a notification to hello@thewhitebox.net. Submitting feedback does not subscribe you to marketing. Please do not include passwords, API keys, payment details or sensitive personal information.

Replies from the TWB team

When the site owner explicitly sends a reply to your website request or feedback, TWB stores its content, recipient address, subject, sender, related submission reference, sending owner identifier, attempt and update timestamps, processing status and any email-provider message identifier. Resend processes the recipient, sender, subject and message to send the reply. Provider acceptance does not guarantee inbox delivery. The private site inbox shows website submissions and outgoing team replies; it does not synchronize incoming email replies. No automatic deletion period is currently configured for these reply records; contact us for a data request. Minimal hashed attempt identifiers, mail category and attempt timestamps are also retained to prevent duplicate sends and enforce shared service limits, without message content or email addresses.

Deletion and retention

The Delete saved workspace action removes your current saved profile, records and monthly wallet history from the active workspace database. It does not delete a review summary you separately shared, an early-access request, or operational backups and logs retained by hosting infrastructure. No automatic deletion schedule is currently configured for request or feedback records. To ask for correction or deletion of a request or shared summary, email hello@thewhitebox.net or contact Sani Parizheva through her LinkedIn profile and include the request reference if available. Do not send API keys in messages.

Google connection and AI receipt import

New Gmail receipt-import connections are paused while provider configuration and Google verification remain incomplete. The interface does not direct customers through the unverified connection flow. It is a connection to Gmail for payment receipts, not a direct connection to personal ChatGPT, Claude or other AI accounts. Google sign-in for this connector does not replace your TWB account identity.

When you explicitly agree and approve Google’s consent screen, TWB requests the read-only Gmail scope. This scope permits reading mailbox messages and settings; Google does not offer a receipt-only permission. TWB limits its requests to a search of selected AI-provider sender domains and receipt-related terms over the previous 366 days, then reads matching messages. It does not request permission to send, modify or delete messages. We currently recognize selected English-language receipts from fourteen AI services. App Store / Google Play receipts, PDF attachments and unsupported formats are not parsed.

Matching message bodies and headers are processed temporarily on the server. We check the sender and Google’s authentication result, then extract an explicitly stated paid or completed-refund amount, currency, product, historical plan, billing interval, payment or refund date and next payment date where available. We also retain explicit invoice, receipt or refund reference identifiers for duplicate detection and the time the evidence was retrieved. The expanded refund and reference extraction requires renewed explicit mailbox consent; earlier saved receipts remain readable, but old consent does not authorize these new searches. Missing details are left unknown. We store the Google message identifier, extracted fields, email received date, masked mailbox label, synchronization status, and the version and time of the connection consent you accepted. Up to ten mailboxes can be linked to one TWB identity; their addresses do not need to match your TWB sign-in email. Outlook / Hotmail and Yahoo mailbox connections are not active. Raw email bodies, subjects and attachments are not stored in the application database or sent to AI models. Receipts are not bank verification, proof of an active subscription, or evidence of usage or value. We do not sum imported receipts with manually recorded subscriptions. The payment view separately shows observed receipt payments, explicit refund amounts and provider-reported next invoices. Legacy receipts without current-parser provenance remain visible for review but are excluded from subtotals. Subtotals stay in their original currencies and exclude uncertain duplicates; they are incomplete receipt evidence, not bank-verified spending or proof of a current subscription price. Repeated copies with the same document reference are collapsed only within one mailbox; uncertain cross-mailbox copies remain visible for review. At most 1,000 saved records are shown, with partial scans and truncation disclosed.

The Google refresh token is encrypted with AES-GCM and bound to your TWB identity and mailbox connection before storage. The encryption secret is stored separately. The server can decrypt it to refresh access; this is not end-to-end encryption. Tokens are not returned to the browser after connection. The connection uses an expiring, single-use authorization state and a browser-bound cookie.

We synchronize after authorization, on request and when you reopen TWB after 24 hours. A scan may be partial; you can continue it. Receipt import does not itself enable email delivery. We create reminders only from explicit next payment dates, and never use a historical paid amount as a promised next charge. Email delivery, where available, requires the separate reminder consent described above. Imported details older than 366 days are removed on a successful sync; inactive accounts retain existing records until the next sync or deletion.

Disconnect & delete removes the selected mailbox’s stored token, connection consent and imported receipt details from the active database, invalidates any pending Google connection request for your TWB account, and attempts to revoke the Google grant. If Google does not confirm revocation, we show a link to remove access in your Google account. Reconnecting the same mailbox retains its imported receipts; other mailboxes remain separate. Original single-mailbox connections stay readable until disconnected. Deleting the manual workspace does not disconnect Gmail. Hosting backups and operational records may persist separately. Contact hello@thewhitebox.net for a data request.

Google user data is used only to provide the receipt-import and subscription-review features described here. We do not sell it, use it for advertising, or use it to train generalized AI models. TWB’s use and transfer of information received from Google APIs is subject to the Google API Services User Data Policy, including its Limited Use requirements. Public availability requires completion of the applicable Google verification and security review.

Hugging Face direct connection preview

This optional connection uses Hugging Face’s official OAuth flow. You sign in on huggingface.co and authorize TWB for openid, profile and read-billing. You do not provide your Hugging Face password or API key to TWB. The connected provider account is bound to your existing TWB identity using the provider’s subject identifier, not an email match. It does not register or sign you into TWB.

We retrieve and retain your Hugging Face username, Pro status when provided, billing eligibility and prepaid/postpaid classification when provided, consent version and time, and synchronization timestamps. The read-billing scope does not promise payment amounts or invoices. TWB does not use this connection to access chats, prompts, private repositories, inference tokens, payment card details, paid subscription prices or renewal dates, and cannot infer savings from it.

OAuth access and refresh credentials are encrypted with AES-GCM and bound to your TWB identity and provider. Application infrastructure can decrypt them for synchronization; they are never sent to the browser or stored in browser storage. Consent uses S256 PKCE, a single-use state, a browser-bound Secure HttpOnly cookie and an exact callback. Requests are sent only to fixed Hugging Face token and user-information endpoints, without following redirects. Credentials refresh when needed; if renewal fails, reconnecting may be required.

Profile snapshots refresh on request or when you return after an hour. There is no background schedule. At a successful refresh, records older than 93 days are removed. Reconnecting the same provider account preserves history; connecting another Hugging Face account replaces that provider’s saved history. Disconnect & delete removes credentials, pending authorization and snapshots from TWB’s active database. Revoke TWB separately in your Hugging Face account settings to remove the provider grant. Hosting backups may persist separately. This connection is a preview: automated tests do not substitute for validation with a real authorized account.

Account-first provider connections

Supported account-connection previews use a separate authorization flow for each provider. You review the requested permissions before continuing to that provider. An account connection does not start a subscription or confirm access to every AI feature in the provider platform. These previews do not retrieve prices, plans, payments, renewal dates, prompts, documents, meetings or generated content.

After a successful provider identity check, TWB stores the provider identifier, stable user identifier, optional display name and workspace identifier/name where documented, synchronization time and consent version/time. Email and unrecognized profile fields are discarded. We store only the latest profile, not a profile-history archive. Credentials are encrypted using an account- and provider-bound context; the separate hosting key allows application infrastructure to decrypt them to perform the supported identity check. This is not end-to-end encryption. Credentials are not returned to the browser.

Provider permissions can sometimes be broader than the identity information TWB reads. Where this applies, the connection screen explains the difference and requires a separate acknowledgement. TWB restricts requests to the identity endpoints or metadata tools compiled for that provider; it does not accept arbitrary API destinations or tool commands from the browser. Only a successful identity response can create a connected account record. A catalog listing, authorization redirect or test fixture is not a verified live connection. Each preview identifies when live-account validation is still pending.

Short-lived authorization state is valid for ten minutes and bound to the signed-in TWB account, provider and browser. Expired state is removed on later connection requests, so stored expired records may remain until cleanup. The latest profile and consent record are retained until reconnection replaces them or you disconnect. Refresh runs when you request it or once when you open the connection card and the access token expires within five minutes, if saved refresh access remains usable. An interrupted or failed refresh is not automatically retried. There is no scheduled background identity scan. An expired or uncertain credential may require authorization again.

Disconnecting deletes that provider connection, encrypted credentials and pending authorization state from TWB’s active database. It does not revoke permission at the provider or cancel its subscription. Revoke provider access separately in the provider’s settings when needed. Deleting manual wallet records does not disconnect provider accounts. Provider and hosting infrastructure can retain operational records and backups separately.

Notion workspace metadata preview

This optional preview uses Notion’s official MCP OAuth flow. Before continuing, you must separately agree to TWB’s storage of encrypted credentials and metadata, and acknowledge the breadth of Notion’s permission. The requested scope is default, which can permit reading and changing workspace content. TWB’s metadata-only restriction is enforced by our application; it is not a read-only grant enforced by Notion. Review the permissions on Notion’s own consent screen before approving. You sign in with Notion, and do not give TWB a Notion password or API key. The connection is bound to your signed-in TWB identity, workspace and connected Notion identity. It does not sign you into TWB or merge accounts by email.

TWB calls only notion-get-self and notion-get-tool-access, with no content queries. We retain the connected user or bot identifier, name and type; workspace identifier and name; feature-access statuses and restricted parameter names; synchronization timestamps; and the version and time of your consent. When provided, the authorizing user and workspace identifiers are retained inside the encrypted credential record for identity checks. Email addresses, arbitrary provider response fields and permission reasons are discarded. TWB does not use this connection to search, read, create or change pages, generate content, or run other Notion tools. Feature access does not establish an exact subscription plan, billing or payment status, price, renewal date, usage or savings. Missing billing amounts remain unknown.

Access and refresh credentials are encrypted with AES-GCM and bound to your TWB identity and this provider, with the encryption secret held separately in hosting configuration. Application infrastructure can decrypt them to refresh metadata; this is not end-to-end encryption. Credentials are not returned to the browser or stored in browser storage. The authorization flow uses S256 PKCE, a ten-minute single-use state, a Secure HttpOnly browser-bound cookie and an exact callback on thewhitebox.net. Requests go only to fixed Notion authorization-metadata, token and MCP endpoints; server requests do not follow redirects. Pending authorization records are deleted on disconnect, and expired records are cleaned up on later authorization requests, so inactive records may remain until that cleanup.

Metadata is read after authorization and when you request a refresh. There is no scheduled background synchronization. We store one snapshot per UTC day and return at most 93 snapshots. Records older than 93 days are removed on a successful refresh; inactive accounts may retain older records until refresh or deletion. Every completed reconnection starts a new metadata history, preventing different identities from being combined. Failed or interrupted requests may require you to check the saved connection status or reconnect. A failed metadata refresh does not replace the last successful snapshot.

Disconnect from TWB removes the stored credentials, connection consent, pending authorization and all Notion metadata snapshots from TWB’s active database. It does not revoke the provider-side grant or cancel any Notion subscription. Revoke TWB’s access separately in your Notion settings to remove the grant. Deleting the manual workspace does not disconnect Notion. Provider and hosting infrastructure may retain operational records and backups separately. This preview has not been verified with a real authorized Notion account; automated and synthetic tests are not a live-account verification.

Read AI public client registration

Read AI first requires a separate, unchecked registration consent and review of its terms and privacy policy. TWB sends only static public application metadata: The White Box name, https://thewhitebox.net, the exact Read AI callback on that domain, openid scope, code response, authorization_code grant and public client authentication none. We never send your email, meeting data or TWB owner ID in registration. Registration creates a provider-side app but does not grant account access. You approve account authorization separately on Read AI. The identity-only preview stores an encrypted, verified account-ID snapshot; every access, refresh and identity token is discarded after verification. It does not read meetings or establish an AI plan or billing status.

For each TWB owner we retain one public client identifier, provider identifier, registration status, random attempt identifier, browser-binding hash, and consent version and time. These are kept after disconnect to reuse the same public registration and prevent duplicate provider apps; they are not account credentials. Disconnect removes the local identity snapshot and pending authorization, but does not delete the public registration or revoke a provider grant. Unknown registration outcomes are not retried automatically and require TWB support review. Registration response bodies, provider registration-access tokens and client secrets are never stored or logged. This flow has synthetic protocol tests only; real-account acceptance remains unverified.

Supermemory identity snapshot preview

If you choose to connect Supermemory, TWB requires separate, unchecked consent for public app registration and review of Supermemory’s terms and privacy policy. Registration sends the same static public application metadata described above, using the exact Supermemory callback on thewhitebox.net. It does not grant account access; you approve that separately with Supermemory. TWB requests only openid, verifies the signed account identifier with EdDSA/Ed25519 signatures using keys from the pinned official JWKS endpoint, and saves an encrypted identity snapshot. All access, refresh and identity tokens are discarded. The snapshot expires no later than the signed identity assertion and cannot be refreshed; reconnecting requires authorization again. No MCP, UserInfo, memory, content, generation or billing requests are made.

The provider-specific public client identifier and registration, consent and attempt records described above remain after local disconnect to prevent duplicate registrations; the provider-side registration and grant may also remain. Uncertain registration outcomes are not automatically retried. Provider permissions may be broader than TWB’s identity-only use, which requires a separate acknowledgement. Real registration and account authorization remain unverified; protocol tests do not establish a live connection.

ElevenLabs connection pilot

With your explicit consent on the Connections page, TWB sends your API key to the official ElevenLabs subscription endpoint, encrypts the key using AES-GCM with an account-bound context, and stores the encrypted value in the site database. The decryption secret is stored separately in hosting configuration. The operator and application infrastructure can decrypt the key to provide the service; this is not end-to-end encryption. Use the minimum User read permissions and revoke the key at ElevenLabs when no longer needed. Keys are not returned to the browser after saving.

We retain selected subscription metadata: plan, status, character usage and limit, currency, billing period, next invoice amount and date, allowance reset and synchronization time. These snapshots are associated with your signed-in account. Refresh occurs when requested or when you return after an hour; there is no background schedule. Historical records older than 366 days are removed on a successful refresh, so inactive accounts may retain older records until refresh or deletion. Disconnect and delete removes the stored key and provider snapshots from the active database. Hosting backups may persist separately. This action is separate from deleting the manual workspace.

OpenAI and Anthropic organization API connections

With your permission, TWB calls the provider’s official organization usage and cost endpoints using a dedicated organization admin API key. Standard project keys do not provide these reports. These connections do not access personal ChatGPT or Claude subscriptions, conversations, projects, prompts, payment methods or the content of model responses. OpenAI costs cover the organization, while the token breakdown covers completions; Anthropic reports cover the Console organization and Messages API. Reports are limited to USD and may be delayed or revised by the provider.

Admin keys may grant broader permissions than TWB uses. TWB only makes report-reading requests and does not run models or change subscriptions. Keys are encrypted with AES-GCM and bound to your TWB identity and provider. They are never returned by the connection API. Application infrastructure can decrypt them to synchronize reports. We store monthly reported costs, input/output/cached tokens, model identifiers, day coverage and synchronization timestamps. We fetch the current month through yesterday and two prior months; older saved months are removed when older than twelve months at a later successful synchronization. Inactive accounts can retain older records until synchronization or deletion. There is no scheduled background sync.

Each account can connect up to two providers, with one organization per API provider. Replacing a key replaces that provider’s saved history to avoid mixing organizations. Disconnect removes its encrypted key and reports from the active database; revoke the key separately in the provider console. Deleting your manual workspace does not disconnect these integrations. Exports contain reports, never keys. Provider and hosting infrastructure may retain operational logs and backups under their own policies.

Optional demo measurement

Optional demo measurement is off by default. If you expressly allow it, your browser sends a fixed “demo started” event and a random code for this tab to TWB, without account credentials or a page URL. TWB stores only a SHA-256 digest of that random code for duplicate detection, with a 48-hour validity window, plus the event’s time and UTC day. This measurement stores no IP address, browser fingerprint, account identity, raw code or full URL, and uses no external analytics vendor. Ordinary hosting/network processing is separate. Daily aggregate counts cover a rolling 90 UTC days, and a non-personal first-count timestamp is retained. Expired digests and out-of-window aggregates are deleted on the next valid count request, not by a scheduled job; physical deletion may therefore occur later than their validity window. The optional control allows you to revoke and reset your tab’s choice. It does not undo an event already received or remove an anonymous aggregate. The tab’s non-identifying “already sent” marker remains until the tab closes, preventing repeated counts after reset. Starting another tab or clearing storage can produce another session; these totals are not people counts.

Optional browser-time extension

The downloadable desktop Chrome pilot is not published in the Chrome Web Store. Tracking is disabled until you enable it. It measures approximate foreground activity on twelve supported AI domains, excluding detected idle or unfocused periods. It does not collect prompts, conversation content, page titles, full page paths, cookies or payments. Aggregate tool identifiers, UTC dates and seconds are stored in your browser profile. Records older than 366 days are removed when activity is recorded. TWB can request and display these aggregates on the Connections page, but this pilot does not upload them to the server. Pause collection or delete local history in the extension popup. Avoid shared browser profiles.

Paid plans and other providers

Paid TWB subscriptions and personal billing connections for ChatGPT, Claude, Kimi and Grok are not active. Source links take you to third-party providers with their own terms and privacy notices. Only enter a provider API key in the designated secure connection form, never in a request form. The hosting service processes sign-in and technical information needed to operate the site.

Deleting your wallet removes its contents and history. We retain an account identifier and revision marker to prevent stale tabs from restoring deleted data.

Optional public AI team links

AI team role drafts stay in the current browser tab until you explicitly approve a public preview and publish. Public links show only selected catalog tool names and fixed role labels under a generic team title, plus the link expiry date. They do not include your name, email, account identifiers, costs, plans, activity, prompts or provider credentials. Tool selections are not verified account or usage claims. Anyone with the link can view and copy the published card for 30 days. You can revoke links from your own workspace; revocation prevents future access through TWB but cannot recall copies made by others. We keep an opaque public code, your private owner identifier, a request identifier, the selected tools and roles, and creation/expiry times to operate these links. On revocation the tool and role payload is cleared; a minimal owner/code/request record remains to prevent an interrupted publication retry from restoring a revoked link. Expired links are unavailable immediately; their tool and role payload is cleared on a later team-link publication request.