Built to act carefully.

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.

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

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.