context safety score
A score of 39/100 indicates multiple risk signals were detected. This entity shows patterns commonly associated with malicious intent.
brand impersonation
The site is a fully crafted replica of the official UPS Billing Center portal, hosted on a Google Cloud Run domain (ups-ebc-764603794666.us-central1.run.app) with no affiliation to ups.com. It reproduces UPS branding assets (ups-logo.svg, UPS color scheme: ups-brown, ups-beige, ups-gold), navigation elements (Shipping, Tracking, Products & Services, The UPS Store), footer links, and copyright notice 'Copyright © 1994-2026 United Parcel Service of America, Inc. All rights reserved.' The title is 'UPS - Billing Portal' with meta description 'UPS Billing Portal'. (location: page.html: <title>, <header>, footer, ups-logo.svg, metadata.json domain field)
credential harvesting
The page presents a fake 'Billing Center Login' form designed to harvest UPS account credentials. It contains a username dropdown pre-populated with real-looking email addresses (john.doe@example.com, jane.smith@example.com) and a password field with a masked value ('••••••••••••'), creating a convincing login flow. The 'Continue' button is present but no legitimate form action or API endpoint is defined in the static HTML, indicating credential capture is handled by the dynamically loaded JavaScript chunks. (location: page.html: <h1>Billing Center Login</h1>, <select> with pre-filled emails, <input type='password'>, <button>Continue</button>)
phishing
The entire page is a phishing site impersonating UPS's legitimate billing portal at ups.com. The domain 'ups-ebc-764603794666.us-central1.run.app' is a randomly-generated Google Cloud Run subdomain with no relationship to UPS. The site clones the visual layout, branding, navigation, footer, and legal language of the real UPS website to deceive users into believing they are logging into a legitimate UPS service. TLS certificate is valid (DV, issued by Google Trust Services) which provides false legitimacy. (location: metadata.json: domain, url; page.html: full page structure; .brin-context.md: URL)
social engineering
The login form uses pre-populated victim email addresses in the username dropdown (john.doe@example.com and jane.smith@example.com), suggesting the page may be personalized per target with harvested email addresses to reduce friction and increase credibility. The presence of a pre-filled 'selected' email address implies the attacker already knows the target's email and is prompting only for their password. The masked password field further implies an existing account session to manipulate users into entering their credentials. (location: page.html: <select> with <option value='john.doe@example.com' selected=''>john.doe@example.com</option>)
hidden content
The page contains a hidden div element at the top of the body ('div hidden') used by Next.js for server-side rendering hydration. Additionally, the RSC (React Server Component) payload embedded in inline script tags contains the full page structure including the login form definition, rendered invisibly before client-side hydration. While standard Next.js behavior, the inline RSC payload duplicates all credential harvesting form structure in non-visible script tags. An HTML comment token 'KXufpXZJkyzvkfLkUuf_j' appears both in the DOCTYPE comment and in the RSC build ID, which is a standard Next.js build identifier but could serve as a session/target tracking token. (location: page.html: line 1 (HTML comment KXufpXZJkyzvkfLkUuf_j), <div hidden>, inline script tags 9-22)
curl https://api.brin.sh/domain/ups-ebc-764603794666.us-central1.run.appCommon questions teams ask before deciding whether to use this domain in agent workflows.
ups-ebc-764603794666.us-central1.run.app 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.