This page explains what JSO means by AI-aware JavaScript protection, what evidence customers can review today, and what the planned Resistance Score will add later. The short version: JSO does not claim that protected JavaScript is AI-proof, and it does not claim perfect resistance against AI review. JSO focuses on release evidence, named threat models, and customer-verifiable review material.
For end users, the important question is not "does a vendor say AI-resistant?" It is "what can my team check before we publish?" Use this page as that checklist.
BYO AI key setup is available now. Add your own OpenAI or Claude key in
AI key settings; provider billing stays with your provider account. Managed JSO AI checkout appears only for accounts where managed billing is enabled.
Evidence available now
Release review artifacts
Advanced workflows can keep source-free build reports, enabled options, compatibility notes, symbolication data, runtime-defense settings, and CLI evidence checks with each release.
Runtime evidence
Runtime Defense events can route to customer-owned monitoring or the hosted incident dashboard beta when tamper activity needs first-triage visibility.
Source-free evidence command
Use the local CLI when a buyer, auditor, or internal reviewer asks what can be checked today without exposing private source code:
jso-protector --input dist --output dist-protected --report dist-protected/jso-report.json
jso-protector --ai-resistance-evidence dist-protected/jso-report.json --ai-resistance-evidence-output reports/ai-resistance-evidence.md
jso-protector --ai-resistance-evidence dist-protected/jso-report.json --ai-resistance-evidence-output reports/ai-resistance-evidence.json --require-vm-proof --json
The evidence command reads the saved API report, stays local, and does not call an AI provider. It summarizes build identity, strong protection options, optional VM proof, runtime-defense evidence, compatibility evidence, source-free review data, claim boundaries, a Review Assistant Packet, and a review decision. Use the Markdown-style text output for reviewer handoff, or add --json when release automation needs a machine-readable packet. The report also states that Resistance Score is still planned, so teams can separate current release evidence from the future benchmark.
The Review Assistant Packet is for a BYO AI key or an internal reviewer. It turns failed checks, missing review tracks, VM scope, runtime evidence, compatibility proof, and Resistance Score wording into owner actions without asking for source code, protected output, source maps, provider keys, or secrets.
Current review matrix
The evidence command also includes a non-scoring attacker-model matrix and a review decision. Required evidence failures block the packet; passed required checks with missing optional tracks become ready-for-manual-review; fully evidenced current tracks become ready. That keeps the handoff useful without pretending the planned Resistance Score is live.
| Review track |
What the packet checks today |
Reviewer action |
| Identifier recovery |
Name replacement evidence and public-contract exclusions. |
Confirm public API names stay intentional while private identifiers are harder to recover. |
| String recovery |
String movement, encoding, or encryption evidence. |
Spot-check expected public strings separately from sensitive literals. |
| Control-flow reconstruction |
Flat transform, deep obfuscation, reorder-code, or dead-code evidence. |
Pair stronger transforms with protected-build smoke tests and compatibility notes. |
| Sensitive-function extraction |
Optional VM proof for selected cold functions. |
Confirm VM-backed claims apply only to functions that passed proof checks. |
| Runtime instrumentation |
Runtime Defense summary or beacon evidence. |
Route confirmed runtime incidents to customer-owned monitoring. |
| Source-free handoff |
Fingerprint, symbol pack, identifier-map, and claim-boundary evidence. |
Share the packet without adding source code, secrets, or payment/customer data. |
What is planned
| Item |
Status |
What it will prove |
| Resistance Score |
Planned |
A per-build score against a named attacker profile, with sub-scores for identifiers, string literals, control-flow recovery, and exposed API surface. |
| Attacker fingerprint |
Planned |
The report names the model family, prompt version, deobfuscation harness version, and scoring method so results are not just generic "tested against AI" claims. |
| Recommendation output |
Planned |
The report points to practical next steps such as Maximum mode, VM protection for a cold sensitive function, runtime fingerprinting, or compatibility exclusions. |
| Review decision |
Available now |
The CLI evidence packet says whether the current release evidence is blocked, ready for manual review, or ready based on required checks and missing review tracks. |
| Current customer evidence |
Available now |
Use the AI evidence CLI report, VM proof pack, release reports, compatibility validation, runtime-defense records, and protected-build smoke tests for review today. |
Example Resistance Score shape
The exact format may change before release. This is the kind of source-free report JSO is designing toward:
{
"BuildID": "2026-11-18-checkout-42",
"ResistanceScoreStatus": "planned-methodology-preview",
"AttackerProfile": {
"Name": "cascade-equivalent-static-probe",
"ModelFamily": "named in the final report",
"HarnessVersion": "named in the final report",
"PromptVersion": "named in the final report"
},
"Recovered": {
"Identifiers": "low",
"StringLiterals": "none",
"ControlFlow": "partial",
"ApiSurface": "expected-public-only"
},
"CompositeResistance": 84,
"Recommendation": "VM-protect validateLicense and keep checkout public callbacks excluded for compatibility."
}
The score is a probe, not a proof. A high score means the named test harness recovered little from that build. It does not mean a determined human cannot instrument the browser or spend time reconstructing logic.
How to evaluate any vendor claim
| Question |
Why it matters |
| What attacker did you test against? |
"AI-resistant" is too broad. A useful answer names the model family, deobfuscation method, prompt/harness version, and date. |
| Can the customer run or review the same kind of probe? |
Evidence should not depend only on a marketing screenshot. The method should make sense on your own protected release. |
| Does the score drop on a deliberately weak profile? |
A useful metric should punish weak settings and improve when stronger protections are enabled. |
| Does the vendor explain runtime limits? |
Obfuscation raises offline analysis cost. Runtime observation, debugging, and browser instrumentation are separate threats. |
What JSO will not claim
- No perfect-AI-resistance claim. Client-side JavaScript can always be executed and observed by someone with enough control of the runtime.
- No anonymous benchmark claim. If a score is published, it must name what it was tested against.
- No one-profile-fits-all answer. Valuable cold paths may deserve VM protection; hot UI paths usually should stay on Maximum mode.
- No replacement for server-side authority. Anything that grants access, signs data, or stores secrets must still be enforced server-side.
Buyer checklist
- Run a protected build with the strongest profile your application can tolerate.
- Keep the release report, AI evidence CLI output file, and compatibility notes with the artifact.
- Use the VM proof pack for functions that need stronger protection than Maximum mode.
- Add runtime-defense beaconing if tamper attempts need operational visibility.
- Use BYO-key JSO AI for guided setup while managed AI checkout is not active for the account.
Frequently asked questions
What does JavaScript Obfuscator claim about AI analysis of protected code?
Less than the category usually does, and the page states the boundary directly. The position is that no JavaScript obfuscator should be treated as proof against AI review, so the product does not sell perfect resistance. What it offers instead is named threat models, release evidence a customer can inspect, and disclosure of what a given build actually did. The useful buyer question is not whether a vendor says the words AI-resistant, but what your own team is able to check before you publish.
What AI resistance evidence can we review today?
Four categories are available now. Protected-output examples, including Maximum mode and the VM proof pack, show what readable source becomes under stronger settings. Release review artifacts keep source-free build reports, the enabled option set, compatibility notes, symbolication data and runtime-defense settings alongside each release. Runtime evidence routes Runtime Defense events to your own monitoring or to the hosted incident dashboard beta. And a local command produces a source-free evidence file for a reviewer who is not entitled to see your code.
Is the Resistance Score a live number we can rely on now?
Not yet, and the distinction is deliberate. The Resistance Score is planned rather than shipped, and it is described as a later phase that will attach a per-build number to a named attacker profile and a set of recovery categories. Treat any current planning material as a roadmap statement. The evidence checklist on this page is the part that exists today and is what a review should be based on.
How does bring-your-own AI key billing work?
You add your own provider key in the AI key settings, and the provider billing stays on your own account with that provider. Both OpenAI and Claude keys are supported. Managed checkout, where usage is billed through JavaScript Obfuscator instead, appears only for accounts that have managed billing enabled, so most accounts will see the bring-your-own path.
What can we give an auditor who is not allowed to see our source?
Run the local evidence command and hand over its output. It produces a report describing the protection applied without exposing the private source it was applied to, which is the artifact designed for exactly this conversation. Pair it with the enabled option list, the compatibility notes and, for virtualized builds, the VM proof pack. A reviewer then has something specific to assess rather than a marketing claim to accept or reject.
How much does stronger protection change what a language model can recover?
It changes the cost and the completeness of the recovery rather than making analysis stop. A model reading a heavily transformed bundle can still describe behaviour, because behaviour is what the code performs; what it loses is the naming, the structure and the commentary that make the original intent obvious. That is why the honest framing here is measurement and disclosure rather than prevention, and why the evidence artifacts matter more than an adjective on a pricing page.