Replicate token pattern appears in public content
ShipReady found a non-placeholder string matching its supported Replicate token pattern in scanned page or script content.
Why it matters
A real Replicate token should be kept in server-only configuration rather than included in a public client asset.
How ShipReady detects it
What it inspects
ShipReady scans fetched page content and discovered script content for its supported Replicate r8_ token format and applies its placeholder guard.
What triggers a finding
The rule triggers when a non-placeholder string matches the supported Replicate token pattern.
What the evidence shows
The scanner observed a string matching its Replicate-specific token format and retains only a redacted prefix in the report.
Limits of this check
ShipReady does not authenticate to Replicate, inspect permissions, view models or prediction history, or run a model. The observed format alone does not prove a token is valid, usable, or associated with a particular account.
How to fix it
Locate the build source
Trace the matched public asset to the source file, environment substitution, or build step that introduced it.
Keep confirmed tokens server-side
Remove real tokens from browser-delivered code and supply them only to trusted server-side code through secret storage.
Review a confirmed credential
If the token is confirmed as real, use the account owner's process to review and replace it.
How to verify the change
Reinspect the deployed assets
Search the deployed HTML and JavaScript after remediation.
Expected: No unintended string matching the supported Replicate token pattern remains in public content.