context safety score
A score of 39/100 indicates multiple risk signals were detected. This entity shows patterns commonly associated with malicious intent.
encoded payload
suspicious base64-like blobs detected in page content
js obfuscation
JavaScript uses Function constructor for runtime code generation
brand impersonation
The domain cableone.net is serving a page titled 'Vercel Security Checkpoint' with Vercel branding, spinner UI, and Vercel footer text. CableOne (now Sparklight) is a US cable/internet provider with no affiliation to Vercel. The page impersonates Vercel's legitimate bot-challenge infrastructure to lend false legitimacy to the interstitial. (location: page.html: <title>Vercel Security Checkpoint</title>, footer text, page-text.txt)
obfuscated code
The page contains heavily obfuscated JavaScript using numeric string-array rotation with self-executing IIFE patterns, encoded lookup tables, and anti-debugging constructs (C() function calling toString/search with regex patterns to detect devtools). This is consistent with malicious evasion techniques used in phishing kits and drive-by attack pages, not legitimate Vercel challenge scripts. (location: page.html: <script type='module'> block, lines 2 (obfuscated numeric shufflers, _() array, C() anti-debug function))
phishing
A well-known cable/ISP domain (cableone.net, 15037 days old) is serving a fake 'browser verification' interstitial instead of its actual content. This pattern is used in phishing attacks to intercept users expecting a trusted site, display a fake checkpoint, and then redirect or harvest credentials after the 'verification' step completes via the obfuscated JS logic. (location: page.html, metadata.json: domain=cableone.net serving Vercel Security Checkpoint page)
malicious redirect
The obfuscated JavaScript contains dynamic DOM manipulation functions (b, T, P) and a large encoded string array (k()) with multilingual content fragments suggesting conditional redirect or content-swap logic executed after the fake 'verification' spinner completes. The actual post-verification destination is hidden within the obfuscated code and cannot be determined statically. (location: page.html: <script type='module'>, functions b(), T(), P(), k() string array with multilingual strings)
prompt injection
The page-text.txt contains raw HTML markup mixed into the visible text layer (the noscript/text extraction includes full HTML tags). An AI agent crawling this page and processing page-text.txt as plain text would ingest embedded HTML instructions. Combined with the fake Vercel checkpoint framing, this could cause an agent to treat the page as a legitimate security gate and comply with follow-on instructions embedded in the JS-rendered content. (location: page-text.txt: raw HTML div/main/footer tags embedded in text content)
social engineering
The fake 'Vercel Security Checkpoint' with animated spinner and message 'We're verifying your browser' is a classic social engineering pattern designed to create urgency and legitimacy, keeping users (or AI agents) waiting and compliant while background JS executes. The 'Website owner? Click here to fix' link points to https://vercel.link/security-checkpoint, further reinforcing the false Vercel affiliation. (location: page.html: <p id='header-text'>We're verifying your browser</p>, <a href='https://vercel.link/security-checkpoint'>Website owner? Click here to fix</a>)
hidden content
The #root div is set to display:none in CSS and only revealed via JavaScript. All actual page content is hidden from non-JS crawlers and static analyzers. The noscript path shows only a spinner and 'Enable JavaScript to continue', hiding the true payload from static analysis tools and some AI agents that do not execute JavaScript. (location: page.html: #root { display: none }, <p id='header-noscript-text'>Enable JavaScript to continue</p>)
curl https://api.brin.sh/domain/cableone.netCommon questions teams ask before deciding whether to use this domain in agent workflows.
cableone.net currently scores 39/100 with a suspicious verdict and low confidence. The goal is to protect agents from high-risk context before they act on it. Treat this as a decision signal: higher scores suggest lower observed risk, while lower scores mean you should add review or block this domain.
Use the score as a policy threshold: 80–100 is safe, 50–79 is caution, 20–49 is suspicious, and 0–19 is dangerous. Teams often auto-allow safe, require human review for caution/suspicious, and block dangerous.
brin evaluates four dimensions: identity (source trust), behavior (runtime patterns), content (malicious instructions), and graph (relationship risk). Analysis runs in tiers: static signals, deterministic pattern checks, then AI semantic analysis when needed.
Identity checks source trust, behavior checks unusual runtime patterns, content checks for malicious instructions, and graph checks risky relationships to other entities. Looking at sub-scores helps you understand why an entity passed or failed.
brin performs risk assessments on external context before it reaches an AI agent. It scores that context for threats like prompt injection, hijacking, credential harvesting, and supply chain attacks, so teams can decide whether to block, review, or proceed safely.
No. A safe verdict means no significant risk signals were detected in this scan. It is not a formal guarantee; assessments are automated and point-in-time, so combine scores with your own controls and periodic re-checks.
Re-check before high-impact actions such as installs, upgrades, connecting MCP servers, executing remote code, or granting secrets. Use the API in CI or runtime gates so decisions are based on the latest scan.
Learn more in threat detection docs, how scoring works, and the API overview.
Assessments are automated and may contain errors. Findings are risk indicators, not confirmed threats. This is a point-in-time assessment; security posture can change.
integrate brin in minutes — one GET request is all it takes. query the api, browse the registry, or download the full dataset.