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. 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 "AI-proof" 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.