Ash Agents
Disposable browser agents that represent you as strangers, not as a persistent identity sites can profile.
- Source repo
- EthanXiang777/ash-agents
- Stars
- ★ 437
- Last updated
- 3mo ago
- License
- MIT
- Primary language
- Python
- FA score
- 34/100 · Major gaps
At a glance
- How it runs
- Works with
- Portable with changes
- Setup effort
- High · needs real infrastructure
- You'll need
- Typical use
- A privacy-focused researcher collecting public information across many sites without those visits being merged into one profile.
- Not a fit if
- Teams that need a turnkey tool without building browser isolation and identity teardown themselves
- Workflows that must run fully offline with no network egress
- Users who rely on a single persistent logged-in session across tasks
- Source review
- 34/100 · Major gaps
What does this agent do, and when should you use it?
Ash Agents is a design for unattributable web interaction: instead of visiting sites yourself, you state intent in plain language and the system delegates the work to one or more agents. The repository is organized into four layers — isolation (a separate, disposable browser context with its own fingerprint per agent), reasoning (live page-by-page inference of the next action), orchestration (task decomposition, fan-out and result reconciliation inside your trust boundary) and identity (created on task start, destroyed on completion). Its stated principles are delegation over exposure, disposability over concealment, and multiplicity over singularity. It is MIT licensed. Crucially, the README documents architecture and philosophy only: there is no install command, dependency list, entry point or usage example, so adoption currently means building much of the machinery yourself. It targets privacy-sensitive browsing, anti-correlation testing and one-off web tasks rather than durable logged-in sessions.
A user submits an intent in natural language; the orchestration layer decomposes the task and fans it out across agents. Each agent runs inside an isolated browser context from the isolation layer, with its own fingerprint, device characteristics and network egress, and the reasoning layer observes each page as it loads to decide the next action rather than replaying a fixed script. When the task ends, the identity layer destroys that agent and its state in a single event, with no archive or fallback copy, so an observer sees a series of unrelated participants. Coordination stays within the user's trust boundary and is never exposed to any site. The repository does not publish concrete commands, APIs or output formats.
- A privacy-focused researcher collecting public information across many sites without those visits being merged into one profile.
- A security or anti-fraud team simulating unrelated visitors to test whether its own site can detect correlated behavior.
- Completing a one-off web task such as a form, a price check or a flow validation without leaving persistent state in your own browser.
- An automation engineer who wants task decomposition plus parallel agents to handle unstable, changing pages instead of brittle scripts.
- A developer evaluating privacy-agent architecture who wants a reference for browser isolation and identity-lifecycle layering.
How do you install or deploy this agent?
The repository documents no installation. The README lists no runtime, package manager, dependency manifest (for example a Node.js or Python version), browser driver or start command, and does not say how the isolation, reasoning, orchestration and identity layers are invoked. No copyable install steps can be given. Before adopting, you would need to decide on a runtime, a browser engine and fingerprint-isolation approach, a reasoning model and its API credentials, and how network egress (proxies or VPN) is provisioned — none of which the source specifies.
How do you use this agent?
No entry command, configuration file or invocation example is recorded, and the README contains no code blocks. What is documented is the intended flow: the user submits intent in plain language → orchestration decomposes the task → work is dispatched to separate browser contexts in isolation → reasoning decides actions page by page → identity is destroyed on completion. The actual call path must be implemented or read from the code; the available material cannot support a first working invocation.
What are this agent's strengths and limitations?
- Non-linkability is structural: each task gets its own browser context and fingerprint rather than hiding a persistent identity more cleverly.
- Explicit refusal to keep a durable profile — identity destruction coincides with task completion, with no archive or backup copy.
- Coordination lives only inside the user's trust boundary, so a site observer sees separate participants and no central entity.
- The four-layer split (isolation, reasoning, orchestration, identity) gives clean seams for replacing or implementing each part.
- MIT licensed, with a separate notice placing compliance responsibility on the user.
- No installation, dependency, configuration or usage documentation — adoption means designing and building most of the system yourself.
- Page-level decisions depend on a reasoning model whose cost and latency, and the credentials required, are never stated.
- Running many isolated browser contexts implies significant memory and network-egress resources, with no capacity guidance in the repo.
- Fingerprint evasion and egress choices carry compliance risk tied to target-site terms and local law, with no guarantees from the project.
- There are no published tests, releases or benchmarks, so effectiveness and stability cannot be verified from the source.
How does this agent compare with similar options?
The README explicitly contrasts Ash with VPNs (which hide where you connect from but not who you are on arrival), private browsing (which clears local state but not fingerprinting or behavioral correlation) and anti-tracking extensions (which cut some third-party collection but leave first-party identification intact), arguing each only narrows the surface while Ash removes the persistent identity.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Ash Agents This agent | 34 · Major gaps | Framework | ★ 437 | 3mo ago | Python | — |
| Invisible Browser Agent | 57 · Major gaps | MCP serverFree + model costs | ★ 882 | 14d ago | Python | Codex · Claude Code |
| Camoufox CLI | 60 · Some gaps | CLIFree | ★ 360 | 22d ago | Python | Codex · Claude Code |
| Xiaobei | 56 · Major gaps | CLIFree + model costs | ★ 8.7k | 6d ago | Python | — |
How does FollowAgents rate this agent?
Why each dimension lost points
The README claims per-agent isolated browser contexts, fingerprints, network egress, and identity destruction on completion, but the repository evidence contains only README, LICENSE, CI, and a few tests; the isolation/identity implementation is absent, so least privilege, user confirmation, data-flow transparency, sensitive-data handling, dependency security, external effects, and rollback cannot be verified. The test referencing BuyAssistDispatcher.reject_mass_buy hints at a bulk-purchase guard, a positive but thin signal. Scores are deducted for claims without implementation evidence.
CI installs orchestrator dependencies and runs pytest, with tests covering notification parsing, metering, mass-buy rejection, identity proof format, and delegate 400/503 branches, showing some self-consistency. However, requirements.txt is not in evidence, so dependency availability is unconfirmed, and failure messaging is limited to HTTP status codes without user-facing error detail.
The README describes privacy-oriented web interaction and plain-language intent triggering, but gives no capability boundaries, trigger-precision rules, or environment-fit guidance (proxy pools, browser versions, network requirements). PRESETS and ASH_DEMO_MOCK in tests hint at presets and a mock mode, but these are undocumented.
The README is well structured with a directory tree and design principles, but lacks install steps, examples/FAQ, known limitations, versioning, and changelog. The LICENSE is a complete MIT text and earns a higher score. Maintenance responsibility is unclear and publisher identity is unverified; treated as unknown without extra deduction or credit.
The README claims non-attribution, non-linkability, and no persistent profile, but provides no runnable examples, output format description, or cost model, so output usability, marginal value, and cost-benefit cannot be assessed. Tests only verify interface shapes, not real task outputs.
README claims such as unique fingerprints and identity destruction are only weakly tested via differing fingerprint_seed and proxy_url; there is no traceable evidence for destruction, isolation, or coordination privacy. Facts and inferences are mixed, e.g., 'no two agents share a signature' has no corresponding test or code support.
- Repository evidence contains only README, LICENSE, CI, and a few tests; the core isolation/identity/orchestration implementation is absent, so privacy and isolation claims cannot be verified.
- The claimed non-attribution and non-linkability capabilities lack traceable evidence and may be used to circumvent service terms; users must assess compliance themselves.
- requirements.txt is not in evidence, so dependency security and availability cannot be confirmed.
- Publisher identity is unverified, and maintenance responsibility and update path are unclear.