Browser Tokens

Give agents and headless browsers format-preserving tokens, and reveal plaintext only over the wire

Browser Tokens let you use sensitive data in browser automation workflows without exposing that data to your application code, your agent, or your browser infrastructure. They're designed for agentic workflows and headless browser automations that need to enter payment cards, passwords, account credentials, API keys, or other sensitive values into third-party websites.

You send sensitive values to Evervault and receive format-preserving token values along with proxy credentials. Only those tokens are passed to your agent or browser. When the browser submits a request through Evervault's browser proxy, Evervault replaces the token values with the original plaintext over the wire.

Why use Browser Tokens

Browser automations increasingly act on behalf of customers in real websites by logging into accounts, buying products, filling forms, and completing workflows. These flows often need sensitive data, which leaves three unappealing options.

• Give the sensitive data to the agent

  Your application, prompt context, model provider, and browser automation code all become part of the sensitive data handling path.

• Give the sensitive data to the browser platform

  Headless browser providers are strong at browser infrastructure, but they're rarely designed to handle PCI, credentials, or other regulated data.

• Use network or issuer-specific agentic payment tokens

  These carry issuer, country, and card brand availability constraints. Each one needs its own integration and user experience.

Browser Tokens are a compatibility layer instead. They work with any browser platform, and with any site where the sensitive value is ultimately submitted over the network. For payment flows, that value is usually a card number or CVV. For account access flows, it can be a password, recovery code, API key, or any other credential that shouldn't reach your agent, browser platform, logs, or automation code.

Comparison to alternatives

How Browser Tokens work

Your service hands token values to the browser agent. The agent fills them into the page, and Evervault's browser proxy swaps them for plaintext on the way to an allowed hostname.

1. 1.

   Collect and encrypt sensitive data

   Use Card Collection, a client-side or server-side SDK, or Relay to collect and encrypt sensitive values. Encrypted values are non-sensitive, so you can store them in your existing database. You can also provide plaintext values directly when that suits your integration.

2. 2.

   Create Browser Tokens

   Send the sensitive values to POST /browser-tokens with policies that define where the values can be revealed, and optional egress configuration.

3. 3.

   Pass token values to your browser automation

   Evervault returns format-preserving tokens that look like the original data, so card tokens are Luhn-valid and preserve the original BIN.

4. 4.

   Launch your browser through Evervault's proxy

   Route the session through the browser proxy using the returned credentials. This works with platforms such as Browserbase, Browserless, Kernel, and Steel, as well as local Chromium and Playwright flows.

5. 5.

   Evervault replaces tokens over the wire

   Your browser enters token values into the page. Evervault scans requests sent through the proxy and replaces tokens with the original plaintext, but only for allowed destinations.

Evervault doesn't control, inspect, or interfere with the browser session itself beyond the proxy boundary.

Security model

Browser Tokens are designed so that sensitive data never needs to be exposed to:

• your application logic after token creation
• your agent
• your prompt context
• your browser automation script
• your browser platform

This applies to credentials as well as card data. The browser automation can fill a password token into a login form. The agent, model provider, browser platform, and workflow logs only ever see the token value.

Evervault never stores the plaintext or a server-side token mapping. Instead, the encrypted payload is embedded in a time-bound JSON Web Encryption (JWE) token, which is used as the authentication value for the browser proxy. The proxy uses the JWE to determine:

• which token values exist for the session
• what plaintext values they map to
• which hostnames can receive decrypted values
• when the token expires
• what egress configuration to use

If a request is sent to a hostname that isn't allowed by policy, the proxy behaves like a normal forward proxy and doesn't reveal the sensitive value.

PCI scope reduction

When implemented correctly, Browser Tokens can keep your browser automation platform, agent, and backend automation infrastructure out of PCI scope. Those systems never transmit, process, or store cardholder data.

In this flow, cardholder data is collected and encrypted using Evervault-controlled collection surfaces before it reaches your automation stack. Your backend creates short-lived Browser Tokens from encrypted card data, receives format-preserving token values, and passes only those tokens to the agent or browser automation platform. The important boundary is that the systems driving the browser only ever handle tokens.

• Your agent

  Sees and reasons over token values, not the card number or CVV.

• Your browser automation code

  Fills token values into the page, not cardholder data.

• Your browser automation platform

  Renders, stores, logs, and transmits token values through the browser session, not plaintext cardholder data.

• Your backend infrastructure

  Stores encrypted values and creates scoped tokens. It doesn't need to store, log, or transmit plaintext cardholder data as part of the browser workflow.

Plaintext cardholder data is revealed only inside Evervault's browser proxy, and only when a request is sent to a destination hostname allowed by policy. The merchant or PSP receives the original cardholder data over the network. The agent, browser platform, and automation backend stay outside the cardholder data environment because they never touch the plaintext value.

To preserve this scope reduction, production integrations should:

1. Collect card data with Card Collection, an Evervault SDK, or Relay.
2. Store only Evervault-encrypted card data in your systems.
3. Create short-lived Browser Tokens immediately before the automation session.
4. Pass only token values to the agent, browser runtime, logs, queues, and workflow systems.
5. Route the browser session through Evervault's browser proxy using the returned proxy credentials.
6. Scope reveal policies to the exact merchant or PSP hostnames the workflow needs.
7. Avoid logging, persisting, screenshotting, or otherwise exposing plaintext cardholder data anywhere in the automation stack.

Create Browser Tokens

Create Browser Tokens just in time for a specific browser automation session.

1curl -X POST 'https://api.evervault.com/browser-tokens' \
2  -H 'Content-Type: application/json' \
3  -u '<app_id>:<api_key>' \
4  -d '{
5    "data": [
6      { "category": "card.number", "value": "ev:encrypted:...", "id": "user-5577e072-primary-card-pan" },
7      { "category": "card.cvv", "value": "ev:encrypted:...", "id": "user-5577e072-primary-card-cvv" },
8      { "category": "credential.password", "value": "ev:encrypted:...", "id": "user-5577e072-merchant-login" }
9    ],
10    "ttl": 300,
11    "permissions": [
12      { "action": "decrypt", "target": "www.example-merchant.com" },
13      { "action": "decrypt", "target": "api.payment-gateway.com" }
14    ],
15    "proxySettings": {
16      "type": "custom",
17      "scheme": "https",
18      "username": "egress-proxy-user-1ef0172b",
19      "password": "egress-proxy-password",
20      "hostname": "egress-proxy.example.com",
21      "port": 443
22    }
23  }'

The response contains a token for each value you sent, along with the proxy credentials for the session.

1{
2  "sessionId": "browser_3eecefc9ac41",
3  "data": [
4    { "category": "card.number", "value": "4242424242424242", "id": "user-5577e072-primary-card-pan" },
5    { "category": "card.cvv", "value": "123", "id": "user-5577e072-primary-card-cvv" },
6    { "category": "credential.password", "value": "uG7q9vK2pL", "id": "user-5577e072-merchant-login" }
7  ],
8  "proxyConfiguration": {
9    "hostname": "us-va.browser.relay.evervault.app",
10    "port": 443,
11    "username": "app_...",
12    "password": "eyJ..."
13  }
14}

The proxyConfiguration.password is a time-bound encrypted JWE. Evervault doesn't store the mapping between token values and plaintext values.

Token formats

Browser Tokens are format-preserving where applicable, so they pass browser and merchant-side validation.

Permissions

Permissions define where token values can be revealed as plaintext. Scope each policy as tightly as possible.

1{
2  "action": "decrypt",
3  "target": "payments.example.com"
4}

• A token is revealed only when the browser request is routed through Evervault's browser proxy, and the destination hostname matches an allowed policy.
• Multiple policies allow multiple destinations. Treat them as an allowlist.
• If a merchant checkout posts card data to a PSP, gateway, or embedded payment iframe, include the hostnames that actually receive the cardholder data.
• If the browser navigates or redirects to a hostname that isn't allowed, Evervault doesn't reveal the plaintext value to that hostname.
• Keep policies environment-specific. For example, use separate hostnames for sandbox and production payment flows.

Targets

A target can take one of three forms. Matching ignores case.

Only a leading *. is treated as a wildcard. A * anywhere else in the target, such as checkout.*.example.com or *.*.example.com, never matches a hostname, so Evervault rejects it when you create the tokens. The same applies to targets that include a scheme, port, or path, such as https://checkout.example.com or checkout.example.com:443. A subdomain wildcard also needs at least two labels after *., so *.com is rejected.

If any target in the request is invalid, POST /browser-tokens returns a 400 and no tokens are created.

Subdomain wildcards are useful when a payment provider spreads card capture across several hosts. For example, a checkout might post card data to checkout.pci.payments.example.com in one region and vault.payments.example.com in another. A single *.payments.example.com target covers both, without allowing the parent domain.

Avoid broad policy rules. The intended production posture is to reveal only to the exact merchant, PSP, or gateway endpoints the workflow needs.

Token lifecycle

Token values are useful only with the matching proxy credentials and policy context. After expiry, the proxy credentials can no longer be used to reveal the underlying plaintext.

1. Store the underlying sensitive value as Evervault-encrypted data.
2. Create Browser Tokens immediately before launching or attaching to the browser session.
3. Pass token values and proxy credentials only to the systems that need them for that session.
4. Use the shortest ttl that gives the automation enough time to complete.
5. Discard token values and proxy credentials once the workflow finishes or the ttl expires.

A workflow can take longer than expected because of login, multi-factor authentication (MFA), queueing, or human takeover. Set the ttl to cover that expected session duration rather than creating long-lived reusable tokens.

Browser proxy

Browser Tokens use Evervault's browser proxy, which is exposed as an HTTP CONNECT proxy.

1us-va.browser.relay.evervault.app # US Proxy
2eu-ie.browser.relay.evervault.app # EU Proxy

When launching your browser, configure the platform's proxy settings with the credentials returned by the Browser Tokens API.

Trust the Evervault CA

Because the browser proxy replaces token values with plaintext over the wire, the browser session must trust Evervault's certificate authority. Download the Evervault CA certificate from https://ca.evervault.com, then install it as a trusted root CA in the browser runtime before routing traffic through the proxy. The exact setup depends on the browser provider.

• For local Chromium or Playwright, add the CA certificate to the operating system or browser trust store used by the automation runtime.
• For hosted browser platforms, configure the session to trust the Evervault CA if the platform supports custom root certificates.
• If the platform doesn't support custom root certificates, confirm whether it offers an equivalent certificate trust or proxy configuration path.

Launch a browser session

The safest production pattern splits collection, token creation, and browser automation into separate steps. Your database stores encrypted card data, and your backend creates short-lived tokens. The agent and browser see only token values, so Evervault reveals plaintext to the allowed payment hostname alone.

1import { chromium } from "playwright-core";
2
3// 1. Retrieve Evervault-encrypted card data from your database.
4// Your application shouldn't store plaintext card numbers or CVVs.
5const encryptedCard = await db.cards.findById(cardId);
6const cardNumberId = `number_${encryptedCard.id}`;
7const cardCvvId = `cvv_${encryptedCard.id}`;
8
9// 2. Create short-lived Browser Tokens just before starting automation.
10const response = await fetch("https://api.evervault.com/browser-tokens", {
11  method: "POST",
12  headers: {
13    "Content-Type": "application/json",
14    Authorization: "Basic " + btoa("<app_id>:<api_key>"),
15  },
16  body: JSON.stringify({
17    data: [
18      { category: "card.number", value: encryptedCard.number, id: cardNumberId },
19      { category: "card.cvv", value: encryptedCard.cvv, id: cardCvvId },
20    ],
21    ttl: 300,
22    permissions: [
23      {
24        action: "decrypt",
25        target: "payments.example-merchant.com",
26      },
27    ],
28  }),
29});
30
31const { data, proxyConfiguration } = await response.json();
32
33const cardNumberToken = data.find((item) => item.id === cardNumberId).value;
34const cvvToken = data.find((item) => item.id === cardCvvId).value;
35
36// 3. Launch the browser through Evervault's proxy.
37const browser = await chromium.launch({
38  proxy: {
39    server: `https://${proxyConfiguration.hostname}`,
40    username: proxyConfiguration.username,
41    password: proxyConfiguration.password,
42  },
43});
44
45// 4. Fill only token values into the checkout.
46const page = await browser.newPage();
47await page.goto("https://www.example-merchant.com/checkout");
48await page.fill("[name='cardnumber']", cardNumberToken);
49await page.fill("[name='cvc']", cvvToken);
50await page.click("button[type='submit']");

Hosted browser platforms

Most browser platforms let you provide proxy configuration when creating or connecting to a session. The exact launch configuration depends on your platform.

For example, using Browserbase the integration would look like this:

1const session = await browserbase.sessions.create({
2  projectId: process.env.BROWSERBASE_PROJECT_ID,
3  proxies: [
4    {
5      type: "external",
6      server: `${proxyConfiguration.hostname}:${proxyConfiguration.port}`,
7      username: proxyConfiguration.username,
8      password: proxyConfiguration.password,
9    },
10  ],
11});

Connect your automation to the session, then use the token values returned by Evervault in your browser steps.

Credential and account access flows

Browser Tokens aren't limited to payment data. The same pattern works anywhere a browser automation needs to submit a secret to a third-party website without exposing that secret to the agent or browser platform. Common credential use cases include:

• logging into a customer account with a password
• entering a recovery code or one-time backup code
• submitting an API key into a developer portal
• filling tax IDs, identity numbers, or other sensitive form fields
• completing internal admin workflows that need privileged credentials

The flow is the same as a payment flow. Collect or store the credential as an Evervault-encrypted value, then create a short-lived Browser Token scoped to the destination hostname. Give the agent and browser automation only the token value, and route the browser session through the browser proxy. Evervault reveals the plaintext credential over the wire to the allowed hostname.

For example, if an automation needs to log into accounts.example.com, the agent can navigate the site and fill a password token into the password field. The browser platform sees a browser-compatible token string, and Evervault reveals the original password only when the login request is sent through the proxy to the allowed hostname. This keeps credentials out of prompts, traces, screenshots, session recordings, browser-provider logs, and application logs, provided those systems only receive token values.

Egress configuration

By default, the browser proxy sends traffic to destination hostnames from Evervault's own IP addresses. To route a session through your own egress proxy instead, set the proxySettings object when creating tokens. Evervault then tunnels the session's egress through your proxy.

1{
2  "proxySettings": {
3    "type": "custom",
4    "scheme": "https",
5    "username": "egress-proxy-user-1ef0172b",
6    "password": "egress-proxy-password",
7    "hostname": "egress-proxy.example.com",
8    "port": 443
9  }
10}

Browser Tokens only handle network egress. If your browser automation also needs timezone, locale, viewport, or geolocation alignment, configure those settings in your browser platform.

Test from your own IP address

To test a sandbox flow from your own IP address instead of Evervault's, we've built a Tailscale based proxy you can run on your machine. Run the Browser Tokens sandbox proxy and use it as your session's proxySettings. It's for sandbox apps only.

Anti-bot compatibility

Evervault's proxy is designed to preserve compatibility with real browser traffic. It uses TLS and HTTP client impersonation techniques, so network fingerprints such as JA4 match expected browser behavior.

Evervault doesn't attempt to solve browser-level automation challenges such as CAPTCHAs, MFA, 3D Secure, or human-in-the-loop flows. Browser platforms often provide session takeover or human intervention features for those cases.

Limitations

Browser Tokens are a network-layer compatibility layer. They don't replace browser automation, fraud controls, or checkout orchestration.

• Client-side encryption can require site-specific handling

  Some sites encrypt sensitive values in the browser before sending them over the network. Browser Tokens still work where the site accepts raw values, but some PSP-specific flows need shims, which Evervault manages on your behalf.

• 3D Secure and MFA remain application and browser concerns

  Frictionless 3D Secure works normally, but challenge flows usually require user interruption or browser-platform session takeover.

• Spending controls aren't enforced at the network layer

  Browser Tokens can restrict where values are revealed, but transaction authorization stays with the issuer or payment processor.

• Tokens are time-bound rather than single-use

  A token can be used more than once within its ttl, so keep the ttl as short as the workflow allows.

• The browser session is outside Evervault's security boundary

  Evervault doesn't drive or inspect the browser session beyond proxying network traffic. Policies still ensure that sensitive data is never decrypted and revealed to a hostname you haven't explicitly allowed.

Recommended integration pattern

Use this checklist before taking a Browser Token integration to production.