Built to act carefully.

Last reviewed August 21, 2026

Tab can do more than answer a question. It can open websites, use connected accounts, call businesses, remember credentials, and prepare payments. That requires stronger boundaries than a normal chat product. Our system is designed so the AI receives only the access and information needed for the current job, sensitive secrets stay in separate control boundaries, and uncertain actions stop safely.

Secrets stay out of chat Passwords, card numbers, security codes, access tokens, and browser authority are kept away from Messages and the AI’s ordinary working context.

Access stays scoped Credentials and capabilities are tied to a user, task, website, or connected account. Tokens can expire, rotate, and be revoked.

Important actions are bound Payments and other sensitive actions are checked against the exact approved target and terms before execution.

Uncertainty stops the flow If Tab cannot confirm what happened, it does not treat the action as a success or automatically repeat a potentially irreversible step.

Your identity and workspace

• Verified phone access. Account access starts with a code sent to the verified mobile number connected to Tab.
• Safer browser sessions. Sign-in sessions use secure, HttpOnly, SameSite cookies. The browser receives a random session token, while Tab stores a keyed hash rather than the reusable token itself.
• User isolation. Each person’s tasks, conversations, browser contexts, credentials, and runtime capabilities are bound to that user in the control plane.
• Task-scoped authority. Sensitive capabilities are issued for a specific user and runtime, checked again at execution, and rotated or revoked when they should no longer work.
• Default-deny controls. Unknown tools and connected-app write actions are rejected unless the exact action has been explicitly enabled.

Passwords and website credentials

Tab can create a strong random password or remember a credential when you ask it to. The password is encrypted before storage using AES-256-GCM, an authenticated encryption mode that protects confidentiality and detects tampering.

1 Encrypt
The credential is encrypted inside the private browser control boundary before it is written to storage.

2 Reference
The AI receives an opaque credential ID, the account label, and the permitted website origin. It does not receive the password.

3 Match
Before use, Tab verifies the current user and requires the browser to be on the exact saved website origin.

4 Fill privately
The password is decrypted only inside the filling boundary, inserted into the page, and removed from the working variable immediately afterward.

Passwords are not placed in Messages, ordinary task files, or durable action receipts. Password, one-time-code, token, secret, and payment inputs are masked before browser screenshots are captured.

Connected accounts

Connected accounts use provider authorization flows. The provider shows the account or workspace access being requested before the connection is completed. Provider credentials and raw access tokens stay in server-side or provider-managed systems, outside the AI’s ordinary runtime.

The AI works through typed, scoped actions and receives bounded results. Secret-shaped fields, provider credential data, cookies, authorization headers, and unsafe provider URLs are removed before results return to the AI. Write actions are denied by default and require an exact approved action, not a broad wildcard.

You can revoke a connected account through the provider or ask Tab to disconnect it.

Cards, the vault, and checkout

Limited beta

Wallet and automated checkout are enabled only when Tab’s private vault and checkout services are healthy and available for the user. If a required boundary is unavailable, Tab fails closed. It does not issue a usable enrollment link or attempt a remote payment.

Adding a card

• Private link: Tab creates a single-purpose enrollment link that expires after 10 minutes.
• Not through Messages: Full card and billing details are entered on the private card page, never sent in the chat thread.
• Direct vault boundary: The card page sends the details to the isolated vault endpoint. Tab’s core application is designed not to proxy or retain the plaintext card payload.
• Safe metadata only: The control plane accepts an opaque card reference and a restricted set of display fields: label, brand, last four digits, and whether billing information is complete.
• No stored security code in Tab’s records: The control plane rejects wallet responses containing card number, security code, expiry, billing address, ciphertext, or vault keys.

Using a saved card

Before an eligible checkout can receive card data, Tab creates a short-lived transaction obligation that binds the user, task, merchant, cart, recipient, currency, exact total, payment-frame origins, saved card, browser session, and deadline. The isolated checkout boundary rechecks those terms before filling anything.

• Opaque references: The main agent and runtime pass card and checkout IDs, not raw payment details.
• Masked observation: Payment fields are masked before any checkout screenshot or private visual check.
• Security code last: The fill boundary requires card number, expiry, then security code in that order.
• One submit claim: Tab claims the charge-bearing action once. A timeout, changed target, processing state, or unknown outcome blocks an automatic retry.
• Human verification: 3-D Secure, passkeys, bank challenges, and one-time codes can require you to take over.
• Verified result: A purchase is treated as complete only after the merchant shows a matching confirmation on a distinct same-origin page.
• Cleanup: Temporary browser and payment authority is revoked, payment fields are cleared, and the browser session is released after the attempt.

Data protection and minimization

• Encryption in transit: Tab’s web and private service connections use HTTPS. SMS and iMessage delivery are also subject to the transport and security properties of your carrier, device, and messaging provider.
• Encryption for stored website credentials: Saved website credentials use AES-256-GCM with a 256-bit key held outside the AI runtime.
• Hashed authority: Session, capability, connection, and one-time-link tokens are stored as hashes where Tab only needs to verify them.
• Server-side secrets: Provider API keys, connection credentials, vault authority, and control-plane secrets are kept outside client code and the AI’s workspace.
• Masked evidence: Sensitive input fields are masked before screenshots. Raw screenshot bytes are excluded from durable database receipts.
• Bounded results: Results are filtered for secret-shaped keys and payment-like values before they can cross a sensitive boundary.
• Fail-closed behavior: Missing authority, mismatched identity, expired links, changed transaction terms, unhealthy private services, or uncertain outcomes stop the action.

What you can do

• Keep your phone and device protected, since your verified number is part of account access.
• Never send a password, full card number, or security code in Messages. Use the private flow Tab provides.
• Review the website, merchant, recipient, amount, and subscription terms before approving an action.
• Complete bank or cardholder verification yourself when prompted.
• Revoke connected accounts you no longer use and tell us immediately if you suspect unauthorized access.

Report a security concern

Email privacy@tab.bot with the subject line "Security." Please do not include passwords, card numbers, security codes, access tokens, or private keys in your report.

Security is a continuing process. This page describes the controls implemented in the current Tab architecture and may be updated as the private beta changes.