Most IP reputation tools give you a score.

That is useful until the first real support ticket lands: a customer cannot log in, checkout conversion drops, or an enterprise integration starts failing because an IP crossed a threshold nobody can explain anymore. The security team sees risk_score: 87. The support team asks why the user was blocked. The developer who added the rule last quarter is not sure whether 87 means a recent attack, an old report, a proxy flag, or a bad neighborhood.

That is the IP reputation black box problem. Scores are easy to automate, but hard to defend when they do not show the evidence behind the decision.

A Score Is Not an Incident Record

Production teams need more than “risky” or “suspicious.” They need to know:

  • What did this IP actually do?
  • Was the behavior observed directly or inferred from another data source?
  • How recently did it happen?
  • Was it one event or a repeat pattern?
  • Did the IP hit multiple sensors or only one system?
  • Should the application block, challenge, or allow the request?

Without those answers, teams end up guessing. A score of 85 might represent fresh credential-stuffing activity across multiple honeypots. It might also represent an old abuse report, an inherited subnet reputation issue, or an infrastructure flag that should only trigger a step-up challenge.

Those are very different enforcement decisions.

The False Positive Tax

The business cost of IP reputation is not only the malicious traffic it misses. It is the legitimate traffic it blocks.

False positives create support tickets, manual reviews, lost conversions, and internal distrust of security controls. Once a fraud or security team loses confidence in the signal, the usual reaction is to raise thresholds until fewer customers complain. That reduces pain in the short term, but it also lets more real abuse through.

The better fix is not a higher or lower score. It is a clearer reason.

When an analyst can read “this IP performed 12 SSH brute-force events and 4 web probes across 3 honeypots in the last 7 days,” the decision becomes easier to defend. When the answer is just score: 87, every blocked user becomes a debate.

Static Lists Struggle With Shared Infrastructure

Attackers use the same providers legitimate users use: hyperscale cloud, cheap VPS hosts, residential proxy networks, mobile carriers, and corporate VPNs. That creates a shared-infrastructure problem.

Blocking an entire range because some addresses were abusive can catch clean customers. Trusting every address in a well-known provider can let disposable attacker infrastructure pass. The useful signal is not only where the IP sits. It is what that specific IP has been observed doing.

This is why per-IP evidence matters. Hosting provider context can be useful, but it should not be the whole decision. A clean developer VPS and a credential-stuffing node may live in adjacent address space. Treating them the same is how reputation systems turn into blunt instruments.

Recency Matters

IP behavior changes quickly. A cloud instance can be created, abused, reported, destroyed, and replaced in hours. Residential and mobile IPs can be reassigned. VPN exit nodes can rotate. Old observations should not carry the same weight as fresh behavior.

Good reputation systems need rolling windows, not only historical labels:

  • activity in the last 24 hours
  • activity in the last 7 days
  • activity in the last 30 days
  • first seen and last seen timestamps
  • whether the pattern is increasing, cooling, or recurring

This is the difference between blocking an active campaign and punishing an address for stale history.

Where ACE v1 Fit

It is worth being honest about FraudGuard’s own evolution here. ACE v1 was built for speed, scale, and simple production enforcement. For many customers, that was exactly what they wanted: a fast IP reputation decision they could plug into an application, firewall, login flow, or abuse workflow without managing a large threat-intelligence program themselves.

That kind of API still has value. Some teams do not want every field, every event, and every reason code. They want a dependable risk signal that lets them block obvious abuse and move on. For lower-risk workflows, internal tools, or teams that already have their own decisioning logic, a simpler score or classification can be enough.

But as FraudGuard moved into more sensitive production use cases, the customer needs became more varied:

  • Some customers wanted the fastest possible decision and were comfortable trusting FraudGuard’s scoring.
  • Some wanted rawer detail so they could make their own allow, challenge, or block decisions.
  • Some wanted evidence they could show support, security, compliance, or customers after a block.
  • Some wanted FraudGuard to recommend the action, but also show exactly why that action was recommended.

ACE v1 handled the first category well. ACE v2 was built for the rest.

That is the shift described in our ACE v2 release article: keep the scale and reliability of ACE v1, but add the structured evidence, confidence factors, observed activity, infrastructure context, reason codes, and recommendation model that production teams increasingly need.

What Evidence-Based Reputation Looks Like

FraudGuard ACE v2 was designed around explainable allow, challenge, and block decisions. The response can include observed attack families, attack volume across rolling windows, targeted services, protocols and ports, infrastructure classification, confidence factors, customer controls, and human-readable reasons.

Instead of forcing every customer to map a raw score into a local rule, ACE v2 returns an enforcement recommendation and the reason behind it.

A real ACE v2 single-lookup response looks like this:

{
  "ip": "8.216.12.173",
  "recommendation": {
    "action": "block",
    "evidence_summary": "This IP was observed performing 3 total attack events across 2 FraudGuard honeypots in the last 7 days, including 2 Jenkins probing events and 1 HTTP/WAF probing event, most recently on May 26, 2026 at 19:31 UTC.",
    "cache_ttl_seconds": 14400
  },
  "classification": {
    "primary": "web_scanner",
    "secondary": [
      "multi_service_scanner",
      "honeypot_attacker",
      "ai_automation",
      "hosting_provider"
    ]
  },
  "risk": {
    "level": 5,
    "label": "critical",
    "confidence": 85,
    "confidence_factors": [
      "recent_activity",
      "repeated_activity",
      "multi_honeypot_reach",
      "specific_attack_signature",
      "multiple_attack_types",
      "multiple_target_services"
    ]
  },
  "observed_activity": {
    "observed": true,
    "attack_families": [
      "web_probe"
    ],
    "activity": {
      "pattern": "burst",
      "trend": "burst",
      "attack_events_24h": 3,
      "attack_events_7d": 3,
      "attack_events_30d": 3,
      "distinct_attack_types_30d": 2,
      "distinct_target_services_30d": 2,
      "distinct_target_ports_30d": 2,
      "first_seen": "2026-05-26T15:45:54+00:00",
      "last_seen": "2026-05-26T19:31:59+00:00"
    },
    "attacks": [
      {
        "type": "jenkins_login_page_probe",
        "service": "jenkins",
        "protocol": "http",
        "destination_port": 8080,
        "attack_events_24h": 2,
        "attack_events_7d": 2,
        "attack_events_30d": 2,
        "honeypots_reached_24h": 1,
        "honeypots_reached_7d": 1,
        "honeypots_reached_30d": 1,
        "first_seen": "2026-05-26T15:45:54+00:00",
        "last_seen": "2026-05-26T15:45:57+00:00"
      },
      {
        "type": "waf_attack",
        "service": "http",
        "protocol": "http",
        "destination_port": 80,
        "attack_events_24h": 1,
        "attack_events_7d": 1,
        "attack_events_30d": 1,
        "honeypots_reached_24h": 1,
        "honeypots_reached_7d": 1,
        "honeypots_reached_30d": 1,
        "first_seen": "2026-05-26T19:31:59+00:00",
        "last_seen": "2026-05-26T19:31:59+00:00"
      }
    ],
    "last_observed_attack": {
      "event_type": "waf_attack",
      "service": "http",
      "protocol": "http",
      "destination_port": 80,
      "observed_at": "2026-05-26T19:31:59+00:00"
    }
  },
  "attributes": {
    "ai_automation_suspected": {
      "detected": true
    }
  },
  "reasons": [
    {
      "code": "abusive_activity_observed",
      "message": "Abusive activity observed by FraudGuard ACE",
      "severity": "high"
    },
    {
      "code": "scanner_activity_observed",
      "message": "Scanner or probing activity observed",
      "severity": "medium"
    },
    {
      "code": "honeypot_interaction_observed",
      "message": "Interaction observed across FraudGuard honeypot infrastructure",
      "severity": "high"
    },
    {
      "code": "waf_attack_activity_observed",
      "message": "HTTP/WAF attack activity observed",
      "severity": "high"
    },
    {
      "code": "activity_within_7_days",
      "message": "Activity observed within the last 7 days",
      "severity": "high"
    }
  ],
  "customer": {
    "ip_in_whitelist": false,
    "ip_in_blacklist": false,
    "ip_in_geoblock": false
  },
  "infrastructure": {
    "type": "hosting_provider",
    "provider": "Alibaba Cloud",
    "is_tor_exit": false,
    "is_public_proxy": false,
    "is_vpn": false,
    "is_hosting_provider": true,
    "is_residential_proxy": false,
    "is_mobile_network": false,
    "is_satellite_network": false,
    "is_shared_exit": false,
    "is_ai_agent": false,
    "first_seen": "2026-05-18T02:44:12+00:00",
    "last_seen": "2026-05-18T15:07:09+00:00",
    "updated_at": "2026-05-18T15:07:09+00:00"
  },
  "network": {
    "asn": 45102,
    "asn_org": "Alibaba US Technology Co., Ltd.",
    "isp": "Alibaba",
    "organization": "Alibaba",
    "prefix": "8.216.12.0/24",
    "connection_type": "Corporate"
  },
  "geography": {
    "country": "Japan",
    "isocode": "JP",
    "state": "Tokyo",
    "city": "Tokyo",
    "postal_code": "102-0082",
    "timezone": "Asia/Tokyo",
    "latitude": 35.6893,
    "longitude": 139.6899
  },
  "metadata": {
    "request_id": "acev2_example_single_lookup",
    "generated_at": "2026-05-27T00:47:35+00:00",
    "schema_version": "2.0.0",
    "api_version": "2.0.0",
    "engine": "ace_v2"
  }
}

The important part is not just the JSON shape. It is the operational workflow the real evidence enables:

  • Support can explain why a block happened.
  • Security can tune challenges differently from hard blocks.
  • Developers can cache decisions using the recommended TTL.
  • Analysts can review the evidence later without reverse-engineering a score.
  • Compliance and audit teams can see that automated decisions were based on specific signals.

Challenge Is Often Better Than Block

Black-box reputation pushes teams toward binary decisions: allow or deny. That is risky for business workflows where the cost of a false positive is high.

Many suspicious requests should be challenged instead of blocked outright. A login from a fresh residential proxy may deserve MFA. A checkout attempt from an IP with recent honeypot attack evidence may deserve a hard block. A clean hosting IP making authenticated API calls for a known customer may deserve an allow.

The right action depends on evidence quality, recency, and business context. A single score rarely captures that nuance.

What To Look For In An IP Reputation API

If you are evaluating an IP reputation provider, ask these questions before wiring it into production enforcement:

  • Does the API show why an IP was flagged?
  • Are observations timestamped?
  • Does it distinguish observed attacks from infrastructure enrichment?
  • Does it provide confidence factors, not only a score?
  • Can it recommend block, challenge, or allow?
  • Can your team log enough context to explain a future support ticket?
  • Does the vendor document which fields may change over time?

If the answer is mostly “trust the score,” treat the signal as enrichment, not as a primary gate.

Bottom Line

IP reputation becomes more valuable when it stops being a black box. Scores are useful, but production systems need evidence, recency, confidence, and a clear recommended action.

FraudGuard’s position is simple: if an IP decision affects customers, revenue, or security posture, the API should be able to show its work. Customers who want a simple decision can still use one. Customers who need the full case file can now get it through ACE v2.

Start with FraudGuard IP Lookup, read the ACE v2 release article, review the ACE v2 API documentation, or compare plans at fraudguard.io/pricing.