BLA, short for Blind LLM Agents, is a new open-source tool that tries to make AI reverse-engineering agents fail on your shipped software. The qybaihe/bla repository was created on October 25, 2026, is MIT licensed, and showed 1,981 stars on November 3. Its tagline is "Make reverse engineering bankrupt again."
The target is an agent skill called REA, short for Reverse Engineer Anything, which we covered in our REA install guide. BLA is a counter-measure. You point it at a build, and it rewrites the artifact so an analyzing agent hits caps, chases decoys and burns tokens. Some of the README's numbers are measured. Others are estimates, and the difference matters.
TL;DR: BLA at a glance #
| Question | Answer |
|---|---|
| What does it protect? | JavaScript bundles, Electron .asar files, WebAssembly, SQLite, Safetensors and GGUF model files, Go, Erlang BEAM, EVM bytecode, PCAP and more |
| What is it up against? | REA-style AI reverse-engineering agents, not human analysts |
| Is it free? | Yes. MIT license, npm package bla-agents |
| How do I run it? | npx bla-agents harden . afternpx bla-agents setup |
| Does it change runtime behavior? | The author says no, and reports 14 of 14 benchmark targets with exact input and output equivalence |
| What is measured? | Byte-level REA failures such as header, nesting and chunk limits, recorded with real REA |
| What is only estimated? | The token and dollar multipliers, including the headline aggregate of about 612.5x tokens and 292.2x cost |
| Main limit | No client-side protection stops a determined human with a debugger, per the project's own disclaimer |
Agents that act on your behalf need rules. See how explainx helps secure your agents →
What does BLA actually do to a build? #
The README describes three layers: poison, exhaust, hallucinate.
- Poison. It plants format-valid canaries, honey metadata and decoy control flow that look like real evidence to an analyzer.
- Exhaust. It pushes the artifact past REA's documented resource budgets. Examples are an oversized Electron ASAR header, deeply nested model metadata, or a huge export table in a WASM module.
- Hallucinate. It leaves the analyzer with truncated inventories, redaction failures and ambiguous rabbit holes, while the real runtime stays equivalent.
One sentence to your coding agent is enough in the intended flow. After npx bla-agents setup registers an MCP server and a skill with Claude Code, Cursor, Codex, Gemini CLI, Windsurf and other agents, you can say "Harden my software against REA." The tool auto-discovers dist, build, .asar, .wasm, .sqlite and model files and runs audit, protect and verify. If you want background on the protocol that connects the tool to your agent, see our MCP guide.
Protections are described as format-native, with no commercial packer or LLVM needed. The stated red line is to never break program behavior, export surface, section integrity or format validity.
Claimed vs verified: which numbers can you trust? #
The README separates two kinds of evidence, which is to its credit.
Measured against real REA
The author ran real REA against hardened samples on commodity hardware under Node 24 (npm run redteam:rea) and recorded the error each analyzer path returned. Selected rows from the README:
| Format | Before to after | REA outcome |
|---|---|---|
| Go build info | 50 KiB to 1.16 MiB | Capacity error: string length over the 1 MiB limit |
| Erlang BEAM | 84 B to 262 KiB | Capacity error: over the 64-chunk budget |
| Electron ASAR | 607 B to 16.9 MiB | Capacity error at the 16 MiB header limit |
| WASM with Wabt | 54 B to 6.56 MiB, 251 exports | Interface decoding only partial |
| SQLite | 12 KiB to 56 KiB | Column evaluation failure on honey columns |
| Safetensors | 128 B to 10.1 KiB | Capacity error: JSON nesting over 32 levels |
| GGUF | 24 B to 7.7 KiB | Capacity error: metadata nesting over 32 array frames |
| PCAP | 24 B to 1.29 MiB | Budget rejected, with tshark present |
These are narrow claims, and the README states them narrowly: the analyzer path "actually returned the listed budget, capacity or redaction failure in this environment." It adds that this "is not a claim" about Ghidra, Frida, LLDB, Rizin or JADX sessions it did not run. Only the author has reproduced these numbers so far. We did not run them. The recorded report is in the repository under docs/redteam.
Internal estimates
The 14-target benchmark table shows exposure scores, estimated tokens and estimated dollar cost for an analyzing agent. The headline is an aggregate of about 612.5x tokens and 292.2x cost with 14 of 14 targets runtime-exact. The README itself says the token and dollar columns are "internal estimates derived from BLA's catalog of REA limits" and "not the same as" the empirical measurements. Example rows claim 2,822.7x tokens for a small JavaScript target and 2,532.3x for an Electron app.
Treat those multipliers as the author's model of what an agent would spend, not as measured spend. No real agent run with real token billing backs them in the README.
Designed for but not verified
The README is also open about gaps. Ghidra-depth native decompilation, Frida and LLDB live sessions, the full Android APK pipeline, firmware containers, and SPIR-V and CUDA fatbinary paths are listed as not empirically verified. Firmware and GPU-object formats are skipped.
Why would anyone want this? #
AI agents have made reverse engineering faster. Our Snowboard Kids 2 write-up looked at how far agents get on game decompilation, and the limits they hit. If an agent can pull readable logic out of a bundle for a few dollars, then licensing checks, feature gates and proprietary model weights in a shipped client are easier to copy.
BLA bets that agents have fixed budgets, and that it is cheaper to exceed those budgets than to defend each function. It is the same cost-asymmetry thinking that drove classic obfuscation, adapted to analyzers with token limits.
That bet has an obvious weakness. REA's limits are public and can change. A new REA release can raise a cap, handle nesting differently or ignore decoys, and the shield stops working for the tested path. The README ties its figures to specific versions for that reason, and the tool's own disclaimer calls it "defense-in-depth."
What are the risks and gray areas? #
- Dual use. The same techniques that frustrate an analyst also frustrate legitimate security researchers, malware responders and your own auditors. The disclaimer restricts use to your own software.
- LLM-facing bait is optional. Per the README, the
--llm-directivesflag, which adds text aimed at AI analyzers such as fake notices and in-band AI chat markers, is off by default. That resembles prompt injection against whatever agent reads your artifact. Our explainer onindirect prompt injection shows why that is a contested tactic. Leave it off unless you have reviewed the legal and terms-of-service side. - Per-project seed. The tool writes a random seed into
.blarcorbla.config.jsonon first use, replacing shared fingerprints. Do not commit that file if you do not want it public. - Manifest. The optional
.bla-manifest.jsonis an unsigned attestation, not a cryptographically signed one, and is off by default. - A tool that edits your build. It rewrites binaries and bundles. Run it on a copy, run your full test suite, and use its
verifystage. The author's equivalence check covers the author's 14 targets, not your app. - Young project. It is days old, and trending badges in a README are the author's own. Read the code before giving a new tool write access to your release artifacts.
What developers should do #
- Decide what you are protecting. Server-side secrets belong on a server. BLA's disclaimer says the same.
- Try it on a throwaway copy. Run
npx bla-agents harden .on a branch, then run tests and compare behavior. - Test against your own REA. Install REA from ourguide and see whether the hardened build changes its output. That is a better signal than the README's estimates.
- Keep the tool pinned. A new REA version may change the result, so re-test on each upgrade of either tool.
- Treat agent access as a risk surface. BLA registers an MCP server and a skill with your coding agent. Review those permissions as you would for any agent tool. Platforms such asAgentBeam , built by the explainx.ai team, stop AI agents before they take dangerous actions, and ouroverview of AI agent security platforms compares the field.
Where this fits #
The repo sits in a growing set of tools built around coding agents, from skills that read code to shields that confuse them. Our Claude Code commands reference covers the agent surface BLA hooks into. The pattern is the same as in other agent-security stories: as agents get cheaper, both attackers and defenders automate.
Related reading #
Details are accurate as of November 3, 2026 and come from the repository README and disclaimer. We did not run BLA or reproduce its benchmarks. Star counts and version numbers change quickly.