What is BLA (Blind LLM Agents)?
BLA hardens software you ship against automated reverse engineering by AI agents, with REA (Reverse Engineer Anything) as its named target. It works in three layers: it plants format-valid decoys and canary credentials that look like real evidence, inflates the artifact past the resource limits REA documents (header sizes, nesting depth, export counts) so the analyser fails or truncates, and adds a runtime guard that returns synthetic data when it detects an inspector such as Chrome DevTools Protocol or Frida. The aim is that your users see identical behaviour while an agent burns time and tokens.
It covers JavaScript and TypeScript bundles, Electron .asar archives and fuses, WebAssembly, Python and .pyc, SQLite, Safetensors and GGUF model files, Go, Erlang BEAM, EVM bytecode, PCAP, and several formats it calls designed-for but untested. One command, bla harden, finds build outputs and runs audit, protect and verify.
It is MIT licensed, written in TypeScript, published on npm as bla-agents (3.1.0 on 7 November 2026) and installs as an MCP server and skill for Claude Code, Codex, Cursor, Gemini CLI and others. The repository was created on 25 October 2026; the site is bla.tools.
Is BLA (Blind LLM Agents) worth it?
BLA is best understood as a counter to one program. Its strongest results come from pushing files past limits that REA itself documents, and the README is careful about how far those results go. With 2,676 stars in under two weeks, it has clearly struck a nerve among developers worried about agents that can read their shipped code.
The measured part is narrow and real. Running the real REA against hardened samples on Node v24.22.1, the project records 12 formats where REA returned a capacity or budget error, with the actual error strings: an Electron .asar header pushed past its 16 MiB cap, Safetensors and GGUF metadata past 32 levels of nesting, Go build info past 1 MiB. The README says "empirically verified" means only that REA's analyser path failed in that environment, and lists what was not tested: Ghidra decompilation, Frida, LLDB and Rizin live sessions, JADX on full Android APKs, firmware and GPU objects. Python and .pyc support is marked designed-for, not verified.
The headline benchmark is a different kind of number. The 14-target showcase reports an aggregate of about 639.5 times the tokens and 304.4 times the cost for an attacking agent, but the README labels the token and dollar columns internal estimates derived from BLA's own catalogue of REA limits, not measurements. The 14/14 runtime result checks that inputs and outputs match the unprotected build. Speed overhead is not published beyond a claim that the guards are constant-time checks.
The catch: size and durability. Exhaustion works by making files much larger; in the project's own samples a 607-byte .asar became 16.9 MiB and a 54-byte WebAssembly module 6.56 MiB, which you ship to every user. Because it targets REA's current limits, a future REA release that raises or handles them can undo the effect. The runtime guard also returns synthetic data whenever an inspector attaches, including your own team's. And the disclaimer is plain that no client-side scheme can guarantee secrecy against a dedicated human analyst with time and a debugger; it advises keeping real secrets on a server. There have also been 27 tagged releases and two major-version jumps in the 13 days since the repository was created.
Our take: obfuscation raises the cost of looking, it does not lock the door. BLA is a reasonable extra layer for an Electron or WebAssembly app whose authors mainly fear cheap, automated agent analysis, and no substitute for keeping licence checks and keys off the client.
Where it earns its place
An indie developer selling a paid Electron note-taking app
Make it harder for someone to point an AI agent at the app and copy a signature feature
Run npx bla-agents harden . on the built .asar and check the verify report before release. The package is free; expect a much larger .asar, and keep the licence check on your server.
A small team distributing a WebAssembly image-processing kernel
Slow automated recovery of the exported interface
BLA adds decoy exports so REA's Wabt-based interface decoding exceeds its budget and returns a partial result; the project's sample grew from 54 B to 6.56 MiB, so measure load time in your own app.
A security engineer at a mid-sized SaaS company
Assess how exposed our desktop client is to agent-driven reverse engineering
Run bla audit for the 16-vector exposure report, then npm run redteam:rea against a hardened copy to see which REA paths actually fail. Treat the token-cost figures as estimates.
Before you commit
- Setup
- npx bla-agents setup registers the MCP server and skill with your agent; npx bla-agents harden . runs audit, protect and verify. Needs Node.js ^22.23.4 or 24+.
- Integrations
- Claude Code, Cursor, Codex, Gemini CLI, Windsurf, Google Antigravity, OpenCode, VS Code and GitHub Copilot CLI; optional Wabt and tshark for red-team runs.
- Data and privacy
- Runs locally on your own build outputs; writes a random per-project seed to .blarc or bla.config.json; the optional .bla-manifest.json is unsigned unless you add an ed25519 key.
- Cost at scale
- Free; the real cost is larger downloads and the time to verify each release, since exhaustion adds megabytes per protected artifact.
- Limits
- Verified only against REA's own analyser paths; Ghidra, Frida, JADX, firmware and GPU objects untested; APK re-signing unsupported; speed overhead not published.
What’s good
- Measured results against the real REA, with error strings
- README separates verified, designed-for and estimated claims
- One-command harden with runtime equivalence checks
- Risky LLM-bait text is off by default
- MCP and skill setup for most coding agents
What’s not
- Token and cost multipliers are internal estimates
- Inflates shipped artifacts by megabytes
- Tuned to REA's limits, which can change in any REA release
- Does not stop a determined human analyst
- Very new, with fast-moving major versions
Best for
Developers shipping Electron, JavaScript or WebAssembly products who want to make automated agent reverse engineering more expensive and can accept larger builds.
BLA (Blind LLM Agents): common questions
- Is BLA (Blind LLM Agents) worth it?
- BLA is a clever, unusually candid answer to one specific tool, REA, and your release builds pay for it in megabytes while a determined human analyst can still get through. We rate it 3.3 out of 5.
- How much does BLA (Blind LLM Agents) cost?
- Free under the MIT licence. No paid tier; optional Wabt and tshark are only needed to rerun the red-team checks.
- What are the downsides of BLA (Blind LLM Agents)?
- Token and cost multipliers are internal estimates; inflates shipped artifacts by megabytes; tuned to REA's limits, which can change in any REA release; does not stop a determined human analyst; very new, with fast-moving major versions.
- Who is BLA (Blind LLM Agents) best for?
- Developers shipping Electron, JavaScript or WebAssembly products who want to make automated agent reverse engineering more expensive and can accept larger builds.
- How much does BLA (Blind LLM Agents) cost for a team or in production?
- Free; the real cost is larger downloads and the time to verify each release, since exhaustion adds megabytes per protected artifact.
- Is BLA (Blind LLM Agents) safe for company data?
- Runs locally on your own build outputs; writes a random per-project seed to .blarc or bla.config.json; the optional .bla-manifest.json is unsigned unless you add an ed25519 key.
Answers checked Nov 7, 2026.