A PlanReview link opens someone else’s HTML document. We treat every plan as untrusted and contain it so that opening one is closer to reading a page than running a program. Here is exactly what that containment does — and what it does not promise.
01
What a plan can and cannot do
Plans are self-contained HTML. Most are inert documents; some carry small scripts for things like copy buttons and tabs.
A plan can
Render HTML and CSS, and run small self-contained scripts inside a sandboxed frame.
Update the page it is drawn in — toggle tabs, copy text to your clipboard, reveal sections.
Open a link you click in a new tab when the plan has external-links capability.
A plan cannot
Reach the network through the ordinary channels — fetch, XHR, WebSocket, and beacon are all blocked.
See other sites, your cookies, or any PlanReview account or session.
Navigate the top window or embed another site, form, or frame.
Persist anything — no local storage, no cookies, nothing left behind.
02
Why PlanReview links are contained
Containment is enforced by the browser and the server together — it does not depend on the plan behaving.
Sandboxed frame
isolated
Every plan renders inside a sandboxed iframe with no access to the surrounding page, your PlanReview session, or any other origin.
Network policy
blocked
A strict Content-Security-Policy blocks the ordinary outbound connections and external subresources, so a plan cannot phone home or pull in third-party code through the usual channels.
Rejected at upload
checked
Uploads that embed frames, forms, external resources, or other escape hatches are rejected outright — they never get a link at all.
Independent gates
least privilege
Interactive controls whether authored JavaScript executes. External links controls popup and new-tab capability. Each can be auto-granted, reviewed, approved, denied, or revoked without granting the other.
Four serving lanes
recomputed
locked-static has both gates off; static-links enables only links; interactive-locked enables only scripts; and interactive-links enables both.
03
How network access is limited — not eliminated
Keeping a plan off the network is layered work. No single layer is a guarantee; together they make outbound activity hard to reach and likely to surface for a person.
Browser policy
blocked
The page’s policy blocks the ordinary outbound channels — fetch, XHR, WebSocket, and beacon — so a plan cannot open a connection the normal way.
Upload validation
rejected
Submitted markup that references an external resource is rejected before it earns a link, so nothing loads from a third-party origin.
Risk-signal scanning
flagged
Authored JavaScript is scanned for risk signals: ways data could leave the frame (network, clipboard, messaging, popups, and navigation), code being created or reassembled from text, and — for external links — deceptive link destinations and overlays. A plan with a signal is held at the relevant capability gate for a person; everything else passes.
Unresolved code
logged
Script the scanner cannot fully resolve is not blocked for that reason alone. It is logged for monitoring, so recurring patterns can become new signals. One exception: for external links, authored CSS too large or complex to finish checking for link overlays still holds that version for a person. Containment — the sandboxed frame and the policy above — is what actually limits a plan.
These layers reduce network risk; they do not prove its absence. A covert or residual channel is always conceivable, so approval is risk mitigation and human judgement — not a mathematical guarantee of zero network activity.
04
What a human reviewer may inspect
Interactive and external-links reviews are separate decisions about separate browser capabilities.
The reviewer may read the plan’s HTML, CSS, and JavaScript to assess authored code, overlays, and destinations. The review tool never executes uploaded code. During review, the other capability may still be active — for example, a plan can serve in interactive-locked while external links are withheld. The review concerns the document, not the person who opened it.
05
What approval means — and doesn't
Approval is a human judgement, not a guarantee.
✓
Approved
A person judged one requested capability acceptable inside the sandbox. Approval may attach to a stable behaviour fingerprint or to one exact version. Granting interactive never grants external links, and granting external links never grants interactive.
!
Not a safety promise
Approval means a human judged the plan acceptable — it is not a guarantee that the plan is safe or correct. The containment above is what actually limits what any plan can do; use your own judgement about the content, as you would with any link.
↺
Reversible
Either approval can be revoked at any time, and the serving lane is recomputed. Revoking interactive may yield static-links; revoking external links may yield interactive-locked. Conservative fallback withholds only the capability that is not granted.
This page describes current behaviour and is not a warranty. If you believe a plan is abusing a link, report it and we will review it.