context safety score
A score of 69/100 indicates minor risk signals were detected. The entity may be legitimate but has characteristics that warrant attention.
credential harvesting
The page presents two login forms (email and phone) that collect usernames/emails, phone numbers, and passwords. The forms POST credentials to /login?action=email and /login?action=phone on the domain console.a5idc.net. The domain uses a non-standard TLD subdomain (a5idc.net) that could be used to harvest credentials from users who confuse it with a legitimate provider. Client-side password encryption is applied via encryptPass() before submission, but credentials are still transmitted to a third-party controlled server. (location: page.html:143,183 — form action='/login?action=email' and form action='/login?action=phone')
credential harvesting
A hardcoded token value 'e98671dafb78af3f85d34a04b3076c8e' is embedded as a hidden field in both login forms. This CSRF token is static and visible in page source, which weakens CSRF protection and may facilitate replay attacks against the credential collection endpoint. (location: page.html:143,183 — <input type='hidden' name='token' value='e98671dafb78af3f85d34a04b3076c8e'>)
hidden content
A variable 'mk' is assigned a 32-character hex string ('b66d56142d4a7cd8fd1022de1fda9ab8') in an inline script block with no visible purpose documented in the page. This pattern is consistent with a tracking key, fingerprinting token, or session marker used for backend correlation of collected credentials or user sessions. (location: page.html:81-82 — var mk = 'b66d56142d4a7cd8fd1022de1fda9ab8')
hidden content
The page loads crypto-js.min.js and a custom public.js, then calls encryptPass() on password fields before form submission. Without inspecting those scripts, it is not possible to confirm that encryption is client-side only; these scripts could also exfiltrate credentials to an additional endpoint before form submission. (location: page.html:55-56 — crypto-js.min.js and public.js loaded; encryptPass() called on submit)
social engineering
The page is titled '登录 | A5互联' (Login | A5 Internet) and presents a professional-looking hosted control panel login interface (IDCSmart platform: 'Powered by 智简魔方'). The 'console.' subdomain prefix mimics the naming convention of legitimate cloud/hosting provider consoles (e.g., AWS Console, GCP Console), increasing the likelihood that users will trust and submit credentials. (location: page.html:7 — <title>登录 | A5互联</title>; page.html:773 — Powered by ©智简魔方)
curl https://api.brin.sh/domain/console.a5idc.netCommon questions teams ask before deciding whether to use this domain in agent workflows.
console.a5idc.net currently scores 69/100 with a caution verdict and medium 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.