# Multi Account Isolation

> Verifica que los perfiles de navegador estén realmente aislados: timezone coherente con la IP, WebRTC sin fugas, canvas/WebGL estables, y sin persona, cookie jar o dirección compartida entre perfiles.

Fuente: https://skillsagentes.com/skills/antibrow/anti-detect-browser-skills/multi-account-isolation
Markdown: https://skillsagentes.com/skills/antibrow/anti-detect-browser-skills/multi-account-isolation.md

Repositorio: https://github.com/antibrow/anti-detect-browser-skills
Autor: antibrow
Licencia: MIT
Actualizado: el mes pasado
Coste de contexto: 255 tok instalada, 2.9k tok al activarse, 2.9k tok con todos los archivos del bundle
Bundle: 1 archivo, 11 KB
Permisos que pide: ninguno declarado

## Instalación

Un skill son archivos markdown: los mismos archivos valen para cualquier agente y lo único que cambia es el directorio de destino, es decir la bandera `--agent`. Añade `-g` para instalarlo en todos los proyectos de la máquina.

```bash
# Claude Code
npx -y skills add antibrow/anti-detect-browser-skills --skill multi-account-isolation --agent claude-code
# Cursor
npx -y skills add antibrow/anti-detect-browser-skills --skill multi-account-isolation --agent cursor
# Codex
npx -y skills add antibrow/anti-detect-browser-skills --skill multi-account-isolation --agent codex
# Gemini CLI
npx -y skills add antibrow/anti-detect-browser-skills --skill multi-account-isolation --agent gemini
# Windsurf
npx -y skills add antibrow/anti-detect-browser-skills --skill multi-account-isolation --agent windsurf
# Cline
npx -y skills add antibrow/anti-detect-browser-skills --skill multi-account-isolation --agent cline
```

## Qué hace

- Comprueba que los perfiles de navegador estén realmente aislados en vez de asumirlo
- Verifica que el timezone coincida con la IP de salida del proxy
- Confirma que WebRTC solo expone el proxy y que los hashes de canvas/WebGL se mantienen estables
- Detecta si dos perfiles comparten persona, cookie jar o dirección de salida
- Da un orden de diagnóstico para leer un fallo empezando por lo más barato de revisar

## Cuándo usarla

- Varias cuentas propias o identidades de prueba corren desde una sola máquina y hay que verificar el setup
- Un perfil pasó las pruebas pero algo se ve raro
- Hay que elegir qué suites de detección correr (CreepJS, whoer, browserleaks WebRTC, pixelscan, liarjs)
- Se audita qué hace un runtime de terceros con credenciales de API y proxy

## Qué la activa

- "Verifica que mis perfiles de anti-detect-browser estén realmente aislados"
- "¿Por qué el canvas hash de este perfil cambia entre lanzamientos?"
- "Audita qué hace el kernel con mis credenciales de proxy y API"
- "Revisa si dos de mis perfiles comparten persona o cookie jar"

## Antes de instalar

- Requiere el SDK anti-detect-browser (o antibrow) configurado con perfiles y proxies ya lanzados para poder verificarlos.
- Necesita en el PATH: python
- Variables de entorno: ANTI_DETECT_BROWSER_KEY, PROXY_DE_1, PROXY_US_1, PROXY_US_2
- needs API credentials

## Archivos

- SKILL.md — 11 KB

## SKILL.md

Reproducido tal cual desde antibrow/anti-detect-browser-skills bajo MIT. Esta sección es el documento original y está en inglés.

# Profile Isolation - verifying it, not assuming it

A profile that *looks* isolated usually is not. The failures are boring and mechanical: a timezone that does not match the exit IP, a WebRTC candidate carrying the real address, a canvas hash that changes on every read, two profiles that ended up on the same persona. This skill is the check list for catching those before they matter.

> **Authorized use only.** This is for identities you own or are authorized to operate: your own accounts, your own test fixtures, your own QA fleet, and your own anti-fraud stack. It is not for accessing systems without authorization, for accounts that are not yours, or for creating fake accounts or engagement. Comply with the terms of the sites you automate and with applicable law - see [Acceptable use](#acceptable-use).

**What this does not claim.** Passing every check below means the browser layer is internally consistent. It does not mean a given site will treat two profiles as unrelated: things entirely outside the browser - a shared payment instrument, a shared contact detail, identical activity patterns - are not something any browser setting reaches. Treat a clean result as "the technical layer is not the problem", not as a guarantee.

For the SDK that creates and launches these profiles, see the **anti-detect-browser** skill.

## The configuration invariant

One identity gets one of everything. Any cell shared between two identities is a defect to find:

```
identity  →  profile  →  persona  →  proxy  →  timezone
   1      :     1     :     1     :    1    :     1
```

Profiles are unlimited and free on every antibrow plan, so there is never a reason to reuse one. "Log out and log back in as the other identity" inside one profile defeats the entire setup - the cookie jar and `localStorage` are the point.

## Setup under test

```typescript
import { AntiDetectBrowser } from 'anti-detect-browser'

const ab = new AntiDetectBrowser({ key: process.env.ANTI_DETECT_BROWSER_KEY })

const identities = [
  { profile: 'fixture-us-01', proxy: process.env.PROXY_US_1, tags: ['Windows 10', 'Chrome'] },
  { profile: 'fixture-us-02', proxy: process.env.PROXY_US_2, tags: ['Apple Mac', 'Safari'] },
  { profile: 'fixture-de-01', proxy: process.env.PROXY_DE_1, tags: ['Windows 10', 'Edge'] },
]

for (const id of identities) {
  const { browser, page } = await ab.launch({
    profile: id.profile,              // isolated cookies, storage, login state
    proxy: id.proxy,                  // from the environment, one per identity
    fingerprint: { tags: id.tags },   // drawn once, frozen, replayed after
    label: id.profile,                // address-bar tag drawn by the kernel, unreadable from the page
  })
  // ... run the checks below, then ...
  await browser.close()
}
```

Python, same on-disk profile format:

```python
import os
from antibrow import launch

with launch(
    profile="fixture-us-01",
    proxy=os.environ["PROXY_US_1"],   # from the environment, never a literal
    geoip=True,            # timezone + WebRTC follow the proxy exit
    label="fixture-us-01",
) as browser:
    page = browser.new_page()
    print(browser.timezone, browser.public_ip)
```

## The checks

Run each profile **through its own proxy**, and assert rather than eyeball.

| # | Check | How | Fails when |
|---|---|---|---|
| 1 | Timezone matches the exit IP | `browser.timezone` vs the country of `browser.public_ip` | `geoip` was disabled, or `timezone` was forced to something the IP contradicts. This is the single most common defect. |
| 2 | WebRTC exposes only the proxy | [browserleaks.com/webrtc](https://browserleaks.com/webrtc) | ICE candidates still carry a local or real public address |
| 3 | Canvas hash is stable across launches | Read it, close, relaunch the same profile, read again | The two reads differ - a value that changes every read is itself an anomaly, and it means the persona is not frozen |
| 4 | Worker and main thread agree | [CreepJS](https://abrahamjuliot.github.io/creepjs/) | UA, `languages`, `hardwareConcurrency`, timezone or GPU differ when re-read inside a Web Worker |
| 5 | One GPU across three interfaces | CreepJS, or read WebGL / WebGL2 / WebGPU directly | `adapter.info.vendor` does not match the unmasked WebGL renderer family |
| 6 | No two profiles share a persona | Diff `browser.persona` across the fleet | Two profiles report the same UA, screen geometry and seeds |
| 7 | No two profiles share an address | Collect `browser.public_ip` for the fleet | Two identities came out of the same exit, or the same /24 |
| 8 | Cookie jars are separate | Compare `browser.profile_dir` across the fleet, then inspect `user-data/` inside each | Two identities resolve to one directory, or one directory holds state belonging to another identity |
| 9 | One identity, one profile tree | Confirm every launch of a name passes the same `temporary` value | A managed `gmail` and a temporary `gmail` are two different profiles with two personas and two cookie jars. A script that disagrees with itself about `temporary` is running two identities under one name and will look like a logged-out session, not like a bug |
| 10 | Whole-stack coherence | [whoer.net](https://whoer.net), [pixelscan.net](https://pixelscan.net) | IP, timezone and locale disagree at a glance |
| 11 | Consistency rules in CI | `npx liarjs` ([liarjs.dev](https://liarjs.dev)) | Any of ~40 open-source cross-layer rules fail - this is the one that runs unattended |

Checks 1, 3 and 7 are the ones worth wiring into CI: they are cheap, deterministic, and they catch the defects that actually recur.

## Reading a failure

Work down in this order, cheapest first - a fingerprint is almost never the actual cause:

1. **Profile name reused?** `list_profiles`, or compare `browser.profile_dir` per identity. Two identities in one directory explains everything else. Directories are named after the profile's id, not its name, so match on `profile.json` inside rather than on the folder name.
2. **Same address twice?** Confirm each `public_ip` is distinct.
3. **Clock disagrees with the address?** Print `browser.timezone` and `browser.public_ip` together.
4. **Persona regenerated?** If the canvas hash moved between launches, the profile is not frozen - check whether `profile_dir` or the cache directory changed under it.
5. **Only then** the fingerprint itself, verified with the suites above rather than assumed.

## What the runtime touches, and how to check it

Any tool that drives logged-in sessions receives cookies and proxy credentials, so it is fair to ask what it does with them. For antibrow:

| Artifact | Where it lives | Who sees it |
|---|---|---|
| Cookies, `localStorage`, login state | `~/.anti-detect-browser/profiles/<id>/user-data/` on your disk, or `profiles-temp/<id>/` for a temporary profile | Local. Cloud sync is opt-in per profile: a launch never creates a cloud profile by itself, and `sync: true` is what puts one there. Check which profiles sync before assuming they stay on the machine |
| Persona (`persona.json`) | same profile directory, written once and frozen | Local |
| Profile identity record (`profile.json`) | same profile directory; the id it holds is what names the directory | Local. It is why a rename does not cost a persona, and why the folder name is not the profile name |
| Proxy URL and its credentials | passed to the kernel at launch; answered in the network stack (HTTP 407 / SOCKS5 RFC 1929) so no extension holds them | The kernel process and your proxy provider |
| API key | your environment, or `~/.antibrow/license.key` | Exchanged with `antibrow.com` for a short-lived license token, roughly once a day |

The kernel is a closed-source Chromium build - that is the tradeoff for the spoofing living in C++ rather than in an injectable script - so verify behaviour rather than take it on faith:

```bash
python -m antibrow info          # kernels, profiles, license state, cache dir
```

```python
browser.plan.redacted_args()     # exact kernel command line, secrets masked - safe to paste in a bug report
```

Point it at a proxy whose logs you can read, or at a local MITM proxy, and watch what leaves the machine during a launch. Pin the SDK version and check the published hash (`npm view anti-detect-browser@2.8.0 dist.integrity`) so the code you audited is the code that runs. If a deployment must not phone home at all, this is the wrong tool: license verification is compiled into the kernel and there is no offline mode.

## What isolation cannot cover

Worth stating plainly, because a clean check list invites the wrong conclusion:

- **Anything outside the browser.** A shared payment instrument, a shared contact detail, a shared payout destination - no browser setting touches these, and they are the strongest correlators that exist.
- **Activity patterns.** Identical timing, identical content, identical interaction targets. Not a technical property.
- **Identity verification.** A document check is not a fingerprint problem.
- **A platform's own decision.** Nothing here changes how a site chooses to treat an account.

If every check passes and something still looks wrong, the cause is in this list, not in the browser layer.

## Acceptable use

**Intended:** verifying isolation between identities you own; running client accounts with the account holder's authorization; building QA fixtures that emulate distinct devices; testing your own anti-fraud and correlation logic; auditing what a browser runtime does with your credentials.

**Out of scope, and not supported:** accessing any system without authorization; logging into accounts that are not yours; credential stuffing or account takeover; creating fake accounts, reviews or engagement; circumventing an authentication, payment or authorization control; scraping personal data in violation of applicable law; working around a platform's enforcement decision.

Complying with the terms of the platforms being used, and with applicable law, is the operator's responsibility. Report abuse or a security issue via the contact at `https://antibrow.com`.

## Related Skills

- **anti-detect-browser** - the SDK, profiles, personas, proxies and REST API that create the setup being verified here
- **browser-mcp-agent** - MCP server mode, for letting an AI agent drive a single profile itself

## Dónde encaja

- Categoría: [Seguridad](https://skillsagentes.com/categorias/seguridad.md) — Auditorías, revisión de dependencias, manejo de secretos y modelado de amenazas.
- Creador: [antibrow](https://skillsagentes.com/creators/antibrow.md) — 3 skills en el directorio
- [Todas las skills](https://skillsagentes.com/skills.md)
- [Ranking de instalaciones](https://skillsagentes.com/ranking.md)

## Otras skills del mismo repositorio

- [Anti Detect Browser](https://skillsagentes.com/skills/antibrow/anti-detect-browser-skills/anti-detect-browser.md): Controla Chromium con las APIs estándar de Playwright, con fingerprint de dispositivo real a nivel de kernel, un perfil aislado persistente por identidad y proxy por perfil que fija timezone y WebRTC.
- [Browser Mcp Agent](https://skillsagentes.com/skills/antibrow/anti-detect-browser-skills/browser-mcp-agent.md): Da a un agente su propio navegador real vía llamadas MCP -lanzar, navegar, clicar, rellenar, capturar, extraer texto, ejecutar JS- con fingerprint real a nivel de kernel y perfil persistente.

## Skills relacionadas

- [Anti Detect Browser](https://skillsagentes.com/skills/antibrow/anti-detect-browser-skills/anti-detect-browser.md): Controla Chromium con las APIs estándar de Playwright, con fingerprint de dispositivo real a nivel de kernel, un perfil aislado persistente por identidad y proxy por perfil que fija timezone y WebRTC.
- [Browser Mcp Agent](https://skillsagentes.com/skills/antibrow/anti-detect-browser-skills/browser-mcp-agent.md): Da a un agente su propio navegador real vía llamadas MCP -lanzar, navegar, clicar, rellenar, capturar, extraer texto, ejecutar JS- con fingerprint real a nivel de kernel y perfil persistente.
- [Authoring Skills](https://skillsagentes.com/skills/vercel/next.js/authoring-skills.md): Cómo crear y mantener skills de agente en .agents/skills/. Úsalo al crear un SKILL.md, escribir descripciones, elegir campos de frontmatter o decidir qué va en un skill y qué en AGENTS.md.
- [Backport Pr](https://skillsagentes.com/skills/vercel/next.js/backport-pr.md): Lleva un pull request fusionado de Next.js desde canary a una rama de release anterior como next-16-2: localiza el commit, crea la rama, hace cherry-pick, valida y abre el PR.
- [Create Pr](https://skillsagentes.com/skills/vercel/next.js/create-pr.md): Crea ramas, commits, pushes y pull requests de GitHub para Next.js. Cubre la plantilla de PR, el formato de --body, las ramas codex/ y las directivas de git de la app Codex.

---

Skills Agentes · [Índice de páginas en markdown](https://skillsagentes.com/sitemap.md) · [Inicio](https://skillsagentes.com/index.md)