--- name: ipgeolocation-io-mcp-server-ip-threat-triage description: Judge whether one suspicious IP address or a batch of IPs is a proxy, VPN, Tor exit, bot, hosting range or abuse source, and turn that into a block, challenge, allow or watch recommendation with stated reasons. Use when the user asks whether an IP is safe, suspicious, a VPN or proxy, from a data centre, should be blocked, or wants a list of risky addresses from signups, logins, checkouts or logs. --- # Triage IP threat risk This job ends in a **decision per address**: block, challenge, allow or watch. It is a risk call, not a description. The question is "what would I do with this request, and how sure am I?" An IP that is merely unusual is not a threat. Read the flags together, weigh them against the context of the traffic, and say how confident you are. ## 1. Confirm the scope and the decision it feeds Before any lookup, establish three things with the user: - **What the decision is for.** Blocking a login, challenging a checkout, or flagging a signup each tolerate a different false-positive rate. A checkout block costs revenue; a login block costs a locked-out customer. - **How many addresses.** One address gets a full read. Ten or more get a batch read with a summary table. - **Whether a shared network is in play.** Corporate offices, mobile carriers and universities put many real users behind one address. Ask whether the traffic is a single account, a burst, or broad. If the user only wants to know what an IP is (its location or owner), this is not a triage job. Hand that to enrichment, not a verdict. ## 2. Check the connector and the quota first Run `get_my_ip` only if the user needs to confirm the account is reaching the API. Check whether the requested security check is covered by the plan before running a large batch. Use `check_security` for a single address. For a list, use `bulk_security_check` in chunks rather than one call per address, and report how many were checked and how many failed. See the essentials skill for quota and error handling. ## 3. Read the security flags as a set, not one by one For each address, record every flag the response gives: proxy, VPN, Tor, bot or crawler, spam source, hosting or cloud provider, and any threat score. Then reason about combinations: - **Tor exit plus a login attempt burst:** strong signal. Tor exits are shared by very many people, so block or challenge rather than ban permanently. - **Hosting or cloud range with no proxy flag, on a signup:** often a script or a headless browser, but it can also be a legitimate developer. Challenge rather than block. - **VPN only, on a consumer checkout:** weak signal on its own. Many real customers use VPNs. Allow with a watch flag unless paired with another risk. - **Residential proxy flag:** more serious than a datacentre proxy, because the traffic comes from a real home connection and is harder to tell apart from a customer. Treat as high risk when it co-occurs with account takeover patterns. - **Threat score high but no flags:** report the score and say the flags do not explain it. Do not invent a reason. ## 4. Test the verdict against the context A flag is an input, not a verdict. Before recommending a block, check: - **Volume and timing.** Ten requests from one address in a minute is different from one request an hour. - **Account behaviour.** Did the same address reach several accounts, or one? - **Geography versus the account's usual location.** A mismatch matters more when paired with a flag. - **Whether the address is a known shared network.** If the flagged address serves a large customer base, prefer challenge to block. If the context is missing, say so and downgrade the recommendation one step (block becomes challenge). ## 5. Map the evidence to one recommendation per address Use these bands and state the reason in one sentence: - **Block:** multiple strong signals (Tor, residential proxy, or high score) plus abuse pattern in the logs. - **Challenge:** one strong signal or a hosting range on a sensitive action. Step-up verification, CAPTCHA or one-time code. - **Watch:** a weak signal such as a VPN on a low-value action. Allow, but log and re-check if volume rises. - **Allow:** no meaningful flags, or flags that the context explains. Never recommend a permanent block on the strength of a single flag. ## 6. Summarise the batch For multiple addresses, count by recommendation and list the top risks with their flags. Include the counts so the user can see the shape of the problem: a few addresses hitting hard, or many addresses hitting lightly. ## Common patterns and traps - **The shared-network trap.** Mobile carrier and corporate NAT addresses carry many real users. A block here can lock out a whole office. Check whether the address serves many accounts before blocking. - **The VPN over-reaction.** VPN and privacy-tool users are often legitimate. A VPN flag alone should rarely drive a block on a consumer product. - **The hosting-range assumption.** Cloud and hosting ranges are used by bots, but also by customers' own servers, monitoring, and integrations. Confirm the action type before acting. - **The stale-verdict trap.** IP reputation changes. A flagged address from last month may now be clean, and a clean address may now be compromised. State when the lookup ran. - **Score without explanation.** A high threat score with no supporting flag is a reason to investigate, not a reason to block. - **Confusing location with risk.** A country code does not make an address risky. Only use geography as context against the account's expected behaviour. - **Batch fatigue.** Large lists invite rubber-stamping. Spot-check the top ten by risk and the boundary cases before trusting the bulk result. ## Output ``` Decision scope: Summary: — block , challenge , watch , allow ; failed Per address (highest risk first) - — Flags: Context: Reason: Confidence: — Not established: Looked up at: