The direct answer
Publish integrity metadata from an independently trusted release baseline for the exact external script your console intends to load. Require the documented browser integrity and cross-origin prerequisites, and keep the dependency unavailable rather than removing the check when it fails. Matching resource bytes do not establish safe code, a trusted publisher or coverage of every script.
Keep trusted application code separate from model output
An AI console deliberately depends on one reviewed display library. The application team selects that dependency; a model answer cannot introduce executable HTML or choose its source. This is a different boundary from sanitizing generated prose: it concerns how the browser admits a script that the trusted application intentionally publishes.
Invent console release R-A, external classic script S-A, approved source reference U-A and expected-byte metadata D-A. These are symbolic labels, not a URL, script file, tag or calculated digest. A controlled HTML publisher owns the release entry. Its source, script behavior and intended use have separately passed review.
The maintained MDN SRI and script references were read for this worksheet. They do not identify a tested browser build or prove the actual console’s support. A supporting, independently verified environment remains a prerequisite; unknown environments are outside this approval scope.
Review a release entry before publishing the dependency
The proposed R-A entry records U-A, S-A’s immutable release identity, D-A’s independently established provenance, the permitted metadata algorithm/set, the cross-origin plan and the responsible release revision. Keep the page entry and expected bytes under the same controlled review. Do not overwrite D-A automatically when a host starts returning different content.
MDN’s script reference describes src as the external script URI and requires src when integrity is specified. It distinguishes classic scripts from modules. This worksheet selects one external classic script with type omitted; it includes no module imports, dynamic loader, inline executable content or additional script fallback.
The useful positive is R-A intentionally publishing only the approved S-A entry with its trusted D-A and eligible resource plan. That permits a future browser-admission verification, not authorization to accept arbitrary executable model output. If the publisher or baseline can be replaced together with the resource, a matching hash cannot independently restore trust in that changed release.
Apply the documented metadata selection rule
MDN’s SRI guide specifies whitespace-separated metadata: algorithm prefix, dash and base64 digest, with sha256, sha384 or sha512. Before execution, a supporting browser checks only the strongest algorithm’s entries. Any match within that set passes; no match produces a network error.
For the small positive plan, choose one approved SHA-384 entry represented only by D-A. Adding an accepted alternate digest expands the reviewed byte set; it is a release change. A matching SHA-384 entry cannot rescue mismatching SHA-512 entries when those stronger entries are present. Do not interpret a list as “any hash from any algorithm is enough.” No metadata value is generated here.
Make cross-origin eligibility a separate prerequisite
Cross-origin SRI requires CORS, an appropriate Access-Control-Allow-Origin response and crossorigin. MDN’s example uses anonymous, selected here without further credential-mode claims. No-cors cross-origin integrity requests fail.
Record this eligibility independently of D-A. The right bytes do not repair a missing cross-origin prerequisite. Conversely, an eligible response does not establish a byte match or approval of the script. This worksheet supplies no server header configuration, credentialed-resource branch, request implementation or browser feature-detection mechanism.
Use eight inert admission cards
| Invented condition | Proposed disposition |
|---|---|
| R-A, independently trusted D-A, approved S-A and eligible supporting environment | Permit the narrow reviewed plan for later verification; no observed browser result claimed. |
| Resource bytes differ from the selected approved digest set | Expected integrity failure under the documented contract; keep the dependency unavailable. |
| An untrusted source changes both U-A and D-A | Reject baseline substitution even if those changed values agree. |
| Changed metadata includes a weaker match and stronger mismatches | Review the changed entry; the strongest algorithm’s set determines integrity acceptance. |
| Cross-origin eligibility or actual support is missing or unknown | Do not claim enforced admission or authorize a weaker loader. |
| An additional unreviewed script entry appears | Hold that separate execution path; S-A’s metadata covers no other element. |
| S-A proposes additional unreviewed code or resources | Hold the expanded dependency graph; this single-resource review is not transitive approval. |
| Expected bytes match but behavior or release authority is unacceptable | Deny application admission independently of integrity consistency. |
Keep publisher admission, cross-origin eligibility, integrity disposition and application readiness as separate ledger fields. Otherwise an operational failure can be mislabeled as an integrity attack, or a successful comparison as proof that the entire console is safe.
Specify an unavailable state before a release fails
For this invented console, a missing dependency disables the affected rich-display feature and presents a trusted, readable unavailable notice. Any independent plain-text view must have its own reviewed implementation; this article provides none. An error handler must not strip integrity, switch to an unapproved source or inject a replacement executable merely to restore the feature.
A new S-A revision needs fresh approved bytes, provenance and release-entry review. Availability pressure is not evidence that the old check should be weakened. Integrity admission is also not a pre-request network allowlist: it compares a resource the browser obtains, rather than proving no contact with its host occurred.
Keep coverage and observed evidence narrow
One element’s metadata does not establish full-page script policy, safe behavior, isolation or permission to disclose data. No CSP, Integrity-Policy, service-worker or transitive-loading control is configured here. The publisher, intended execution graph and actual supported environment remain separate review boundaries.
For these proposed cases, no script tag, resource digest, browser, DOM, CORS request or executable fixture was created or run. Ordinary documentation reads and private editorial file handling are separate. Boundary is a prelaunch model router with planned request-path checks, not a shipped browser-integrity or script sandbox service. The synthetic action exercise and existing mock evidence do not validate this browser plan.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.