Most IP reputation APIs answer the same question: what has this IP already done?

That is useful, but it is backward-looking by definition. By the time an IP address has already triggered enough obvious malicious activity to appear in a traditional reputation feed, it may have already reached your login page, checkout flow, API, VPN, or cloud infrastructure.

Today we are introducing /ace/v2/ip/forecast, a new FraudGuard endpoint designed to answer a more proactive question: what is this IP likely to do next based on the surrounding evidence?

Forecast uses predictive modeling built from years of first-party honeypot observations, attack pattern data, nearby network activity, and ACE correlation output to estimate an IP address’s future risk trajectory. It is not meant to replace hard evidence from direct attack activity. It is meant to add a forward-looking risk signal so teams can apply smarter scrutiny before direct abuse appears, especially in environments with strict security policies.

What Forecast Does

The endpoint takes one IPv4 or IPv6 address and returns a forward-looking assessment alongside the current ACE risk state. CIDR ranges, hostnames, and arrays of IPs are not accepted by this endpoint.

{
  "ip": "94.243.8.249",
  "current_risk": 1,
  "forecast_risk": 4,
  "current_action": "allow",
  "forecast_action": "challenge",
  "outlook": "worsening",
  "confidence": 90,
  "trend": "rising",
  "time_window": "30d",
  "forecast_horizon": {
    "period": "near_term",
    "days": 7
  },
  "signals": {
    "events_24h": 0,
    "events_7d": 0,
    "events_30d": 0,
    "risk_24h_ago": null,
    "risk_7d_ago": null,
    "risk_30d_ago": null,
    "active_trackers": [],
    "active_attributes": [],
    "max_severity_30d": null,
    "distinct_sources_30d": 0
  },
  "nearby_activity": {
    "prefix": "94.243.8.0/24",
    "events_24h": 30,
    "events_7d": 96,
    "events_30d": 111,
    "distinct_ips_24h": 2,
    "distinct_ips_7d": 10,
    "distinct_ips_30d": 12,
    "active_trackers": [
      "scanner_tracker",
      "abuse_tracker"
    ],
    "active_attributes": [
      "remote_access_probe",
      "persistent_touch_pattern",
      "dense_scan_cluster",
      "command_execution_probe",
      "shell_or_downloader_artifact",
      "suspicious_command_indicator",
      "legacy_shell_probe",
      "scan_retry_pattern",
      "credential_attack_pattern",
      "login_bruteforce_behavior",
      "credential_field_submitted",
      "credential_stuffing_probe",
      "repeated_probe_pattern",
      "sustained_probe_stream",
      "telnet_login_surface_scan",
      "multi_attempt_sequence",
      "high_volume_honeypot_activity",
      "web_route_scan",
      "authentication_surface_scan",
      "known_exploit_path_scan",
      "admin_surface_probe",
      "scripted_request_pattern",
      "recently_active"
    ],
    "max_severity_30d": 4
  },
  "why": [
    "No direct malicious activity observed for this IP",
    "Recent malicious activity observed in the same prefix",
    "Prefix contains scanner or probing activity",
    "Prefix contains abuse activity"
  ],
  "recommendation": "Apply additional scrutiny; nearby ACE activity indicates elevated prefix risk."
}

This example shows why forecast-based threat intelligence matters.

In this response, IP 94.243.8.249 has no direct observed attack events in the selected window: no honeypot hits, no active trackers, and no direct ACE activity. A traditional reputation check may return a low current risk and move on.

Forecast adds context. ACE sees recent activity in the surrounding /24 prefix: 111 events over the last 30 days, 12 distinct IPs involved, scanner and abuse trackers active, and a maximum severity of 4. Based on that nearby activity and historical behavior patterns, Forecast projects the IP into a higher-risk trajectory with a forecast_risk of 4 and a recommended forecast_action of challenge.

How It Works Under the Hood

Forecast is not a static blocklist, and it should not be treated as absolute proof that an IP address is malicious. It is a predictive layer built on top of FraudGuard’s Attack Correlation Engine (ACE), using patterns observed across FraudGuard’s own honeypot network and threat intelligence pipeline.

Key signals include:

  • Historical attack patterns — Many abusive IPs do not appear at full severity immediately. They often scan, probe, test infrastructure, and move through stages before becoming obvious application-level threats.
  • Prefix-level activity correlation — Attackers rarely operate from a single isolated IP. When nearby addresses in the same network block show aggressive behavior, that activity can be predictive for other addresses in the same range.
  • Infrastructure context — Hosting provider, ASN, organization, connection type, and deployment patterns can all influence risk trajectory.
  • ACE correlation output — Forecast uses the same multi-signal intelligence model that powers ACE v2, including honeypot activity, tracker behavior, severity scoring, and recent activity windows.

The result is not a crystal ball. It is a model-based assessment grounded in observed outcomes. The confidence score helps indicate how strong the supporting signal is based on volume, recency, and correlation strength. In practice, Forecast is most valuable as a decision-support signal: useful for challenges, rate limits, watchlists, review queues, and added monitoring rather than as the only reason for a permanent block.

Built for Strict Security Policies

Predictive enforcement is not for every workflow.

Many websites and applications should start with standard ACE v2 current-risk checks, then use Forecast only for additional monitoring or review. Forecast is most valuable for organizations with stricter security policies, lower tolerance for suspicious infrastructure, and higher cost of account abuse or unauthorized access.

Examples include:

  • fintech and payments
  • banking and lending
  • government and public-sector systems
  • critical infrastructure providers
  • healthcare and insurance workflows
  • enterprise identity and access systems
  • high-value B2B SaaS platforms
  • marketplaces, exchanges, and platforms with elevated fraud risk

In those environments, the right response to a forecast signal is usually additional scrutiny: MFA step-up, CAPTCHA, BotGuard, rate limiting, queueing, manual review, tighter session controls, or a watchlist. A forecast signal should support a stricter policy decision; it should not be presented as proof that the exact IP has already attacked you unless direct ACE activity is also present.

Why This Matters Now

Catching Campaigns During Ramp-Up

Attack campaigns often begin with reconnaissance: scanning ports, testing services, mapping exposed systems, and probing authentication surfaces. During this phase, an attacker may generate activity across related infrastructure before touching your environment directly.

Forecast helps detect that ramp-up period earlier.

Use case: In a strict security environment, route IPs with forecast_action: "challenge" into additional scrutiny, such as rate limiting, CAPTCHA, BotGuard, MFA step-up, queueing, or manual review, before they generate direct abuse against your application.

Resource Prioritization

Not every IP address deserves the same monitoring or enforcement budget. Forecast combines risk trajectory and confidence so teams can make more intelligent policy decisions.

Signal Confidence Recommended Approach
outlook: "worsening" 80+ Apply stricter scrutiny where policy allows
trend: "rising" 50–79 Increase monitoring and apply caution
outlook: "stable" Any Maintain current policy
outlook: "improving" 70+ Consider relaxing restrictions where appropriate

Proactive Watchlist Building

Instead of adding IPs to watchlists only after they have already caused problems, teams can use Forecast output to build forward-looking watchlists. An IP that is low-risk today but projected to move into a higher-risk category can be flagged before direct abuse appears in application logs.

For most customer environments, the right first step is not an automatic hard block. A challenge, rate-limit, or review action gives security teams a practical middle ground: higher scrutiny without unnecessary disruption. Hard blocks based primarily on forecast signals should be reserved for the strictest policies and highest-risk workflows.

Reducing Reactive Incident Response

The most expensive moment in incident response is often the point where a team realizes an attack campaign is already active and has to scramble.

Forecast shifts that response window left. Instead of only reacting to what just happened, teams can prepare for what the data suggests is likely to happen next.

The Example Again — Why It Matters

Looking again at 94.243.8.249:

  • Current state: Risk level 1, zero direct events, no active trackers.
  • Nearby activity: 111 events in the surrounding /24 over the last 30 days, with scanner and abuse activity present.
  • Forecast state: Risk level 4, worsening outlook, rising trend, and a recommended challenge action.

That distinction matters. A current-risk-only system may allow the IP without question. A forecast-aware system can apply additional scrutiny before the IP becomes a direct problem.

If the forecast proves correct, the customer has already reduced exposure. If the forecast proves overly cautious, the customer has applied a challenge or rate limit rather than a permanent block. That is the advantage of predictive threat intelligence: it gives defenders an earlier, lower-cost decision point.

Available Now

Forecast is available as a standalone endpoint at POST /ace/v2/ip/forecast for accounts with ACE v2 Forecast access. It can be called independently or used alongside standard ACE v2 IP check responses.

The intelligence behind Forecast is built from FraudGuard’s first-party honeypot observations and ACE correlation pipeline. Forecast does not rely on crowdsourced abuse reports or community submissions. It is derived from infrastructure, sensors, and data pipelines operated by FraudGuard.

Read the API documentation at docs.fraudguard.io/#ace-v2-ip-forecast or try a public lookup at fraudguard.io/iplookup-v2.

Questions, integration guidance, or feature requests: hello@fraudguard.io.