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.
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.
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:
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.
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:
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.
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.
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 |
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.
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.
Looking again at 94.243.8.249:
/24 over the last 30 days, with scanner and abuse activity present.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.
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.
]]>FraudGuard solves a different problem: affordable, API-first IP reputation for production systems that need to decide whether traffic should be allowed, challenged, or blocked.
If you are looking for a GreyNoise alternative because you need IP risk decisions inside a login flow, signup form, checkout system, API gateway, WAF workflow, fraud queue, or customer-specific policy engine, FraudGuard is the better fit.
| Need | Better Fit |
|---|---|
| Scanner context, SOC triage, threat hunting | GreyNoise |
| Dynamic scanner-informed firewall blocklists | GreyNoise |
| App/API request-path decisions | FraudGuard |
| Lower-cost IP reputation API | FraudGuard |
| No mandatory sales call or annual contract for standard plans | FraudGuard |
| Custom security workflows built around IP risk data | FraudGuard |
Both products are useful. They are not the same tool.
GreyNoise helps answer:
FraudGuard helps answer:
That distinction matters. Analyst context is valuable, but production systems need a decision.
Checked July 11, 2026, GreyNoise’s public pricing page lists GreyNoise Block at $9,999/year for organizations under 2,500 employees. Broader platform access is positioned through sales-led plans for larger organizations, MSSPs, and enterprise buyers. Pricing and offers can change; verify the vendor page during evaluation.
FraudGuard pricing is public and API-focused:
| Plan | Monthly Cost | Annualized | Includes |
|---|---|---|---|
| Starter | $29/mo | $348/year | 1M requests/month and core IP reputation |
| Professional | $99/mo | $1,188/year | ACE v2 single lookup, customer lists, geoblocking, rate limiting, 5M requests/month |
| Business | $299/mo | $3,588/year | ACE v2 bulk, ThreatWatch, daily offline data, 25M requests/month |
| Enterprise | $599/mo | $7,188/year | 100M requests/month, higher throughput, Attack Stream and advanced delivery workflows |
That means FraudGuard Starter is roughly 3.5% of the listed GreyNoise Block annual price. Even FraudGuard Enterprise is below the listed GreyNoise Block annual price while listing 100M monthly API requests.
FraudGuard has operated for more than a decade and publishes its standard-plan pricing. That makes it easier for teams to model costs before a procurement conversation.
FraudGuard standard plans also avoid the common buying friction:
Custom engineering, dedicated data delivery, or customer-specific architecture work may require a separate agreement. But if you want the standard IP reputation API, you should not need a sales process just to find out whether it is affordable.
GreyNoise documentation describes scanner-intelligence classifications such as benign, malicious, suspicious, and unknown. GreyNoise also provides tags, Visualizer workflows, RIOT/business-service context, CVE-related intelligence, API access, feeds, and GreyNoise Block.
That is useful for:
If those are your primary use cases, GreyNoise may be the right tool.
FraudGuard is built for teams that need IP intelligence to drive production controls:
allow, challenge, and block recommendationsThis matters because not every risky request should become a permanent firewall block. Some traffic should be challenged, rate limited, routed to review, allowed because of a customer whitelist, or handled differently based on business rules.
FraudGuard is built for that app/API policy layer.
GreyNoise Community API examples are useful for scanner context: noise, riot, classification, name, Visualizer link, and last-seen date.
FraudGuard ACE v2 is designed to return an enforcement-ready decision with risk, evidence, customer policy context, infrastructure context, network data, and geography in one response. This is the full example response from the FraudGuard ACE v2 IP Intelligence documentation:
{
"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"
}
}
GreyNoise output helps explain scanner context.
FraudGuard output helps enforce customer policy.
FraudGuard is a small technical team. For customers that need flexibility, that is an advantage.
If your use case requires a custom feed, WAF workflow, offline database format, enrichment pipeline, abuse-review process, MSP workflow, or application-specific enforcement pattern, FraudGuard can work directly with you to design a practical solution around FraudGuard data.
That does not mean every custom request is automatically included in standard pricing. It means you can have a technical conversation with the people building the product instead of being forced into a rigid package.
GreyNoise is a strong product for scanner intelligence, SOC triage, threat hunting, CVE context, RIOT/business-service context, and scanner-informed perimeter blocklists. If that is the job, it is worth evaluating.
FraudGuard is the better choice when the job is production IP reputation: app and API decisions, allow, challenge, and block outcomes, customer-specific policy controls, honeypot-observed attack evidence, public pricing, no mandatory sales call, and no annual contract for standard plans.
It is also the more practical option for teams that want flexibility. If your security workflow needs a custom feed, WAF pattern, offline data format, enrichment pipeline, MSP workflow, or other architecture around IP risk data, FraudGuard can work with you directly.
Try FraudGuard free - use the public lookup tool, start a trial, integrate the API directly, or email hello@fraudguard.io to talk through a custom security workflow built around FraudGuard data.
Looking for more competitive comparisons? Read FraudGuard vs AbuseIPDB, FraudGuard vs IPinfo, and FraudGuard vs CrowdSec.
]]>FraudGuard answers a different question: has this source IP shown malicious behavior, and should this request be allowed, challenged, or blocked?
Both products are useful. They are not substitutes.
The interesting overlap is honeypots. Shodan helps you find what is exposed on the internet. FraudGuard intentionally operates exposed decoy infrastructure so attackers reveal themselves, then ACE v2 converts those observations into IP risk decisions customers can use at the edge.
Shodan is an internet scanning and search platform. Its developer API supports host search, count queries, facets, filters, and host data across the internet exposure dataset.
That makes Shodan valuable for:
If your question is “what is exposed on this IP or across this query,” Shodan is the right kind of tool.
Shodan does not primarily exist to decide whether an incoming request to your login page should be blocked. An open SSH port, a banner, or an exposed service fingerprint does not prove that the source IP is attacking your application.
That difference is critical.
An IP can run an exposed service and still be harmless to you. Another IP can have no interesting public services and still be part of a credential-stuffing campaign. Asset discovery and source reputation are different security problems.
FraudGuard ACE v2 is built for real-time allow, challenge, and block decisions using verified FraudGuard honeypot observations, attack behavior, infrastructure enrichment, network context, geography, and customer-specific controls.
The product value comes from the findings. FraudGuard’s honeypots observe source IP behavior against decoy services, then ACE v2 correlates recency, attack family, repeated activity, infrastructure context, confidence factors, and recommended action. That lets customers benefit from a sensor network they did not have to deploy.
Instead of asking “what is open on this IP,” FraudGuard asks:
A real ACE v2 response:
{
"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"
}
}
That response is designed for enforcement and logging, not asset discovery.
Shodan pricing and quota details can change over time, so the safer comparison is use-case based: Shodan packages access around internet search, monitoring, and data access.
FraudGuard pricing is tied to API usage and product access. Public plans run from $29/month to $599/month, with ACE v2 included on Professional and higher plans.
The buying decision should follow the use case:
That second use case is where FraudGuard’s pricing matters. ACE v2 starts on the $99/month Professional plan with 5 million monthly requests. For teams that need high-volume source-IP decisions, this is a direct way to buy honeypot-backed evidence without building a research operation.
Shodan finds exposed assets. FraudGuard evaluates source IP behavior.
If your current problem is internet asset discovery, Shodan is a strong category leader. If your current problem is real-time IP reputation for login, API, WAF, or fraud workflows, FraudGuard is built for that job because ACE v2 turns honeypot findings into a decision your systems can enforce.
Review FraudGuard ACE v2, test IP Lookup, or compare plans.
]]>That context is useful. It can help a security team understand how a connection is reaching an application and whether the traffic is coming from infrastructure that deserves closer review.
But infrastructure labels are not the same thing as attack evidence.
A VPN flag, proxy label, hosting classification, or shared-exit indicator can support a risk decision, but those labels are usually strongest when combined with behavioral evidence: what the IP actually did, how recently it did it, how often it appeared, and whether the activity matches known abuse patterns.
FraudGuard ACE v2 is built around that broader model.
A proxy or VPN flag can mean many things:
If a security system treats “VPN detected” as the only reason to block, it can create avoidable false positives. If it treats “not VPN” as safe, it can miss attackers using ordinary hosting, cloud, residential, or compromised infrastructure.
Proxy detection is useful context. It is not the full case file.
FraudGuard ACE v2 uses infrastructure attributes as part of a broader risk decision. A VPN, proxy, Tor, hosting, residential proxy, shared-exit, ASN, or provider signal can change how an IP is interpreted, but it is not automatically the main reason an IP becomes high risk.
The stronger signals are behavioral:
Infrastructure answers: “How does this IP connect?”
ACE v2 answers: “What did this IP do, how strong is the evidence, and what should my application do now?”
This real ACE v2 response shows the distinction. The IP includes hosting infrastructure context, but the block recommendation is not based on the provider label alone. It is based on observed Jenkins probing, HTTP/WAF attack activity, honeypot interaction, recency, repeated activity, and confidence factors.
{
"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"
}
}
That is materially different from relying on a single infrastructure label. The infrastructure field is present, but the decision is driven by observed abuse.
For many applications, the useful output is not just an enrichment label. Security teams need enough context to decide whether to allow, challenge, monitor, or block traffic.
That is why ACE v2 combines:
This approach helps teams avoid treating every masked connection as malicious while still identifying IPs with real evidence of abusive behavior.
Proxy intelligence is an attribute. Attack evidence is a stronger decision foundation.
FraudGuard tracks Tor exits, open public proxies, VPNs, residential proxies, hosting providers, shared exits, ASN context, geography, and related infrastructure. ACE v2 uses those labels as context around observed behavior, not as the only basis for risk scoring.
The reason to use FraudGuard is not simply that it can identify masked or unusual infrastructure. The reason is that ACE v2 can show what an IP did, how recently it did it, how confident the evidence is, and whether your application should allow, challenge, or block.
Test FraudGuard IP Lookup, review ACE v2, or compare plans.
]]>That breadth is useful. It also makes the comparison with FraudGuard more specific than “which vendor is better?”
If you need an all-in-one fraud scoring suite with email, phone, transaction, and proxy tools, IPQualityScore may be a fit. If you need a focused IP reputation API that shows observed attack evidence and returns an allow, challenge, or block recommendation, FraudGuard is the cleaner alternative.
The strongest FraudGuard argument is not breadth. It is depth in one valuable category: first-party honeypot observations converted by ACE v2 into explainable IP decisions at a fair, published price.
IPQualityScore’s proxy detection documentation says its API can analyze IP reputation, detect proxies, VPNs, and Tor connections, and estimate the probability of fraudulent activity. Its example response includes fields such as:
fraud_scoreproxyvpntorrecent_abusefrequent_abuserhigh_risk_attacksabuse_velocitybot_statusconnection_typeIPQS also publicly says it uses proprietary honeypots, traps, crawlers, and live-site threat intelligence network signals.
That means the issue is not that IPQS lacks data. The issue for some buyers is that the public response model is oriented around fraud and proxy scoring fields, while FraudGuard is oriented around showing the attack evidence and decision context behind an IP verdict.
FraudGuard ACE v2 is built to explain why an IP recommendation was made. The documented response model can include:
recommendation.actionrecommendation.evidence_summaryThat is the core difference: FraudGuard is optimized for teams that need to defend a production traffic decision later.
Honeypot data is valuable because it catches behavior before a customer has to experience the attack directly. A source IP that probes decoys, hits multiple services, repeats patterns across time windows, or targets AI and web endpoints is leaving evidence that can be used in production enforcement.
ACE v2 is the layer that makes those findings usable. It does not just say “high risk.” It can expose the observed activity, attack families, recency, confidence factors, and a direct action. That is the gap many teams feel with generic fraud scores: they get a number, but not the case file.
Here is a real ACE v2 single-lookup response:
{
"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 field is evidence_summary. It turns an automated risk decision into something support, fraud, engineering, and security teams can understand.
Checked July 11, 2026, IPQualityScore’s public pricing page lists Startup from $99/month with 5,000 lookups per month, SMB Basic from $499/month with 10,000 lookups per month, and SMB+ from $999/month with 75,000 lookups per month. Pricing and quotas can change; verify the vendor page during evaluation.
FraudGuard pricing lists:
If your buying need is broad fraud validation across many identity fields, compare the full product scope carefully. If your buying need is high-volume IP reputation with explainable threat decisions, FraudGuard is priced much more directly for that use case.
This is where FraudGuard is unusually strong: Professional includes ACE v2 at $99/month with 5 million monthly requests. That gives teams access to honeypot-derived evidence and direct IP decisions at a cost that fits real production experiments, not only enterprise procurement cycles.
IPQualityScore is a broad fraud scoring suite. FraudGuard is a focused, evidence-based IP reputation and threat-decision platform.
For email, phone, and multi-attribute fraud validation, evaluate IPQualityScore on its breadth. For IP-based traffic enforcement where your team needs to explain and tune every allow, challenge, and block decision, evaluate FraudGuard. The reason to choose FraudGuard is the combination of honeypot findings, ACE v2 evidence, and fair high-volume pricing.
Review ACE v2, test IP Lookup, or compare plans.
Related comparison: FraudGuard vs Shodan.
]]>Some events are obvious attacks. Some are automated internet background radiation. Some come from compromised devices. Some come from researchers, broken scripts, misconfigured services, or tools that scan without understanding what they reached.
If every connection becomes a high-confidence reputation signal, the database gets loud and false positives rise. If too much is ignored, real attackers slip through.
That is why FraudGuard uses AI-assisted intent verification inside the ingestion pipeline before honeypot events become high-confidence ACE evidence.
A honeypot event tells you something happened. It does not automatically tell you how much weight the event deserves.
Consider three examples:
/v1/chat/completions paths with model enumeration and jailbreak prompts.All three are observable. They should not be scored the same way.
Intent verification helps answer:
That context is what separates useful intelligence from a noisy blocklist.
FraudGuard’s ingestion process is built around evidence quality.
At a high level:
The model does not replace evidence. It helps decide how much signal the evidence carries.
Some payloads reveal clear intent. Credential lists, exploit paths, command injection strings, suspicious API prompts, and service-specific probes all carry more signal than a bare connection.
The model helps classify what the payload is trying to accomplish so the IP profile can say more than “connected to port 80.”
Attackers often start with a harmless-looking probe, then escalate if the target responds. AI endpoint abuse is a good example. FraudGuard looks for that kind of sequence: liveness test, model inventory, capability test, abuse attempt. The escalation pattern is often more meaningful than any single request.
An IP that touches one sensor once is different from an IP that hits multiple honeypots, services, or regions. Multi-honeypot reach is a confidence factor because it shows a broader pattern.
ACE v2 exposes this concept through observed activity, rolling windows, and confidence factors rather than hiding it behind a single score.
Infrastructure is not proof, but it is context. Hosting providers, VPNs, Tor exits, residential proxies, shared exits, mobile networks, and corporate networks all change how a signal should be interpreted.
The same payload from a disposable VPS and from a residential IP may deserve different review paths. AI-assisted intent verification helps combine behavior with infrastructure context without making infrastructure the entire verdict.
The end result is visible in the ACE v2 response model.
FraudGuard’s documentation describes ACE v2 as returning allow, challenge, and block decisions with observed attack families, attack volume over 24-hour, 7-day, and 30-day windows, targeted services, protocols and ports, infrastructure classification, confidence factors, and human-readable reasons.
That means a production integration can make decisions like:
The API is not just saying “bad IP.” It is explaining why the recommendation exists.
False positives often come from overweighting weak signals:
Intent verification helps FraudGuard avoid treating every signal equally. A recent high-intent credential attack across multiple honeypots should carry more weight than a stale one-off probe. A proxy flag may justify a challenge, but not necessarily a block. A cloud provider label should enrich the profile, not condemn the whole range.
That distinction is essential for fraud and platform teams because the business cost of a wrong block can be high.
AI-assisted does not mean “unquestioned.” The point is to make the pipeline more accurate and scalable, not to turn raw model output into final truth.
FraudGuard uses structured evidence, confidence factors, and ongoing feedback so detections can improve as attack behavior changes. New patterns can be reviewed, labeled, and folded back into scoring. Known noisy patterns can be downweighted.
This is especially important for AI endpoint abuse, where attacker behavior is changing quickly and keyword-only detection is easy to evade.
Customers do not need to understand the whole ingestion pipeline to benefit from it. They see it in the response:
recommendation.action for enforcementevidence_summary for explanationrisk.confidence and confidence_factors for tuningA real ACE v2 response shows how those fields come together:
{
"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"
}
}
That is the practical value of AI-assisted ingestion: better evidence in the API response, fewer blind blocks, and a clearer path from detection to decision.
Honeypots are only as useful as the intelligence pipeline behind them. Raw events need context, weighting, and intent verification before they should influence production traffic decisions.
FraudGuard uses AI-assisted analysis to turn noisy attack observations into explainable ACE v2 evidence. The goal is not a black-box score. The goal is a decision your team can understand, log, and defend.
Review ACE v2, test FraudGuard IP Lookup, or compare plans.
]]>But if you are evaluating IP data for security, fraud prevention, WAF decisions, login protection, or API abuse controls, geolocation is not enough.
FraudGuard already includes reliable geography, ASN, ISP, organization, network, and infrastructure context in its APIs. ACE v2 then adds the part a geolocation product cannot provide by itself: observed attack behavior, honeypot evidence, confidence factors, reason codes, and a direct allow, challenge, or block recommendation.
That is the real comparison. IPinfo tells you where an IP is and what network it belongs to. FraudGuard tells you that too, then tells you whether the IP has been observed doing something hostile.
IPinfo’s API overview describes its services as a mix of geolocation, ASN, privacy, carrier detection, and confidence metrics across API tiers. Paid tiers add city, region, postal code, timezone, latitude/longitude, ASN details, privacy flags, named privacy providers, carrier data, and residential proxy or anonymizing-service signals.
That data is useful for:
If your only job is “give me a dedicated geolocation dataset,” IPinfo is a natural fit.
The problem starts when teams treat geography or ASN data as a security decision.
An IP geolocated to the United States can still be part of a credential-stuffing campaign. A residential ISP address can still be a compromised device or proxy exit. A cloud provider address can be a legitimate customer webhook or a disposable scanner. A VPN flag may justify extra scrutiny, but it does not prove an attack.
Threat intelligence needs behavior:
That is the layer FraudGuard adds on top of the geo and network data already returned by its APIs.
FraudGuard ACE v2 is designed for real-time allow, challenge, and block decisions using verified FraudGuard honeypot observations, attack behavior, infrastructure enrichment, network context, geography, and customer-specific controls.
This is where the product becomes more than enrichment. Honeypot findings give FraudGuard a behavioral record: attack families, targeted services, repeated events, recency, and cross-sensor reach. ACE v2 turns that record into confidence factors and a direct action.
The same response also includes geography and network context. In this real ACE v2 single-lookup response, FraudGuard returns country, state, city, timezone, latitude, longitude, ASN, ISP, organization, prefix, connection type, infrastructure type, provider, and threat evidence together:
{
"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"
}
}
That is the point: you do not need to call a separate geolocation API just to understand where this IP is from before making a security decision. FraudGuard gives you the context and the evidence in one response.
For security buyers, the valuable part is not merely knowing that an IP belongs to a cloud provider or appears to use a proxy. The valuable part is knowing that the IP was observed doing something hostile, recently, with enough context to justify an action.
That is what FraudGuard packages. A customer gets the benefit of a sensor network without deploying one: decoys that attract scanners and attackers, ingestion that separates meaningful behavior from noise, reliable geo and network context, and ACE v2 responses that show why the recommendation exists.
Many teams start with a rule like this:
if ip.country in BLOCKED_COUNTRIES:
deny_request()
elif ip.company.type == "hosting":
deny_request()
else:
allow_request()
This is simple, but it breaks quickly. It blocks legitimate customers who happen to be in the wrong country or on hosting infrastructure, and it misses attackers who route through allowed geographies or residential proxies.
A better pattern is to make the security decision from the same response that already contains the geo and network context:
fg = fraudguard.lookup(ip)
action = fg["recommendation"]["action"]
if action == "block":
deny_request(reason=fg["recommendation"]["evidence_summary"])
elif action == "challenge":
require_step_up_verification()
else:
continue_request(
country=fg["geography"]["country"],
asn=fg["network"]["asn"],
provider=fg["infrastructure"]["provider"]
)
FraudGuard decides whether the request is risky and returns the geo/network fields needed for routing, logging, analytics, support, and investigation.
The buyer question is not “which vendor has geolocation?” FraudGuard already has reliable geo data in its APIs. The buyer question is whether geolocation is all you need.
For teams whose main problem is IP threat decisioning, the FraudGuard value is direct: $99/month gets Professional access with ACE v2 and 5 million monthly API requests. That is a low barrier for putting honeypot-derived evidence, geo data, network context, and enforcement recommendations into a real production control.
IPinfo is a good geolocation and network enrichment product. FraudGuard includes reliable geo data and goes further: ACE v2 adds observed attack behavior, honeypot evidence, risk confidence, reasons, and an enforcement recommendation.
Try FraudGuard IP Lookup, review ACE v2, or compare FraudGuard pricing.
Related comparisons: FraudGuard vs AbuseIPDB and FraudGuard vs CrowdSec.
]]>That is valuable. It is also a different job from making real-time production decisions on login attempts, API calls, checkout flows, and customer traffic.
The short version:
The commercial difference is bigger than the API shape. With FraudGuard, a customer is buying access to first-party honeypot findings and ACE v2’s decision layer at published prices that start in small-team territory. That combination is rare: direct attack observations, explainable evidence, and production-friendly pricing in the same IP reputation product.
AbuseIPDB is a community reporting system. Its own documentation describes the blacklist as a list of the most reported IP addresses, ordered by abuse confidence score and recency of the last report. Its public pricing page also makes the tool easy to test, with a free individual tier that includes 1,000 IP checks and reports per day.
That makes AbuseIPDB useful for:
For a sysadmin investigating suspicious SSH attempts, AbuseIPDB is a practical starting point.
Community data has a structural limitation: it is only as complete, timely, and accurate as the reporting network.
If an attacker is using fresh infrastructure, there may be no reports yet. If an IP was reported for stale behavior, the score may not reflect what that IP is doing today. If the report context is thin, your application still has to decide what to do with the number.
That does not make the data useless. It means the data should be treated as one signal, not the entire production gate.
The core question for automated enforcement is not “did someone report this IP?” It is “what evidence supports blocking this request right now?”
FraudGuard ACE v2 starts from verified FraudGuard observations: honeypot activity, attack behavior, infrastructure enrichment, network context, geography, and customer-specific controls. The API is designed to explain why a recommendation was made, including observed attack families, rolling-window attack volume, targeted services, protocols, ports, confidence factors, and human-readable reasons.
That creates a different workflow:
allow, challenge, or block.Community reports answer “who has complained about this IP?” FraudGuard’s honeypot infrastructure answers a different question: “what did this IP do when it reached systems designed to observe attacker behavior?”
That distinction is the core value. Honeypot findings can show attack family, recency, service targeting, repeated behavior, multi-sensor reach, and infrastructure context before a customer has to learn the hard way in their own logs. ACE v2 turns those findings into an operational decision instead of leaving customers with a pile of raw events.
For many teams, building comparable coverage internally is not realistic. Running decoys, normalizing events, filtering noisy scans, correlating behavior by IP, keeping infrastructure fresh, and serving decisions through an API is an entire threat intelligence program. FraudGuard makes that program available as a product.
An AbuseIPDB lookup can provide community report context such as confidence, report counts, categories, and timestamps.
An ACE v2 lookup is built around enforcement context. Here is a real single-lookup response:
{
"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"
}
}
This response shows the documented ACE v2 model in practice: recommendation, classification, risk, observed activity, confidence factors, reasons, infrastructure context, network context, geography, and metadata.
AbuseIPDB is best treated as community context. It can tell you whether other administrators have reported an IP and what categories they associated with it. That is useful during manual investigation, firewall enrichment, or low-risk workflows where a community signal is enough.
FraudGuard is built for production decisions. ACE v2 gives your application the evidence behind the recommendation: observed behavior, recency, attack type, infrastructure context, confidence factors, reason codes, and an explicit action. That matters when a block can affect real customers, revenue, support, or compliance review.
The practical split is simple: use community reports as supporting context, but use observed evidence when the decision needs to stand on its own.
High-quality threat intelligence should not be available only to large enterprises with security budgets and long procurement cycles. FraudGuard is priced to make serious IP intelligence available to the masses: startups, small teams, growing SaaS companies, fraud teams, platform operators, and enterprises that want transparent costs instead of a custom quote before they can even test the product.
FraudGuard pricing starts at $29/month for 1 million monthly requests, with ACE v2 available on Professional plans at $99/month for 5 million monthly requests. That means a team can put honeypot-derived IP evidence into a real login, API, or WAF workflow without first committing to a large enterprise contract.
That is the value story: AbuseIPDB is inexpensive community context; FraudGuard is affordable first-party attack evidence.
AbuseIPDB is useful community reputation infrastructure. FraudGuard is a production threat-decision API.
Community reports can help with investigation and low-stakes enrichment. If your application needs to decide whether to allow, challenge, or block a real customer request, FraudGuard’s evidence-based model is the stronger foundation because it exposes the honeypot findings, recency, confidence, and ACE v2 reasoning behind the decision.
Start with FraudGuard IP Lookup, compare plans at fraudguard.io/pricing, or review the ACE v2 API.
Related comparisons: FraudGuard vs IPinfo and FraudGuard vs CrowdSec.
]]>FraudGuard solves a different problem. It gives applications, gateways, WAF workflows, and fraud systems an external IP reputation decision backed by FraudGuard’s own honeypot and attack telemetry.
The distinction matters:
FraudGuard’s value is not just that it returns an IP verdict. The value is that the verdict is backed by FraudGuard honeypot infrastructure and processed through ACE v2, so customers can use attack findings they did not have to collect, operate, normalize, or correlate themselves.
CrowdSec’s documentation describes a Security Engine made of a Log Processor and Local API. The Log Processor detects threats from logs using parsers, collections, scenarios, and AppSec rules. The Local API stores alerts and decisions. Remediation Components, or bouncers, consume those decisions and enforce them through firewalls, reverse proxies, CDN integrations, CAPTCHA flows, or similar controls.
That architecture is useful when you control the environment producing the logs.
Good CrowdSec fits include:
If your goal is “my servers should learn from their own logs and enforce locally,” CrowdSec belongs on the shortlist.
Application-layer fraud and abuse often happens before a clean server log exists.
A login request reaches a CDN, then an edge proxy, then a load balancer, then an API gateway, then one of many application services. The business decision may need to happen at the first boundary, not after individual hosts parse logs.
That is where an IP reputation API fits better:
CrowdSec and FraudGuard can both reduce malicious traffic, but they sit at different parts of the stack.
FraudGuard ACE v2 returns real-time allow, challenge, and block guidance using verified FraudGuard honeypot observations, attack behavior, infrastructure enrichment, network context, geography, and account-specific controls.
FraudGuard’s honeypots act as an independent sensor layer. They are not waiting for your application to be attacked before a signal exists. If an IP has been probing decoys, brute-forcing services, touching AI endpoints, scanning web targets, or repeating behavior across multiple sensors, ACE v2 can carry that evidence into your edge decision before the same IP reaches your production path.
A real ACE v2 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 recommendation.action field is important. Production fraud controls are rarely binary. A host firewall can ban an IP, but an application often needs more nuance: deny obvious attackers, challenge ambiguous traffic, and allow clean users.
A single server can see attacks against itself. A honeypot network sees attacker behavior across decoys, services, providers, and time windows. That matters because production teams want to know whether a source IP is a repeat offender elsewhere before it becomes their incident.
Building that internally is expensive. It requires decoy infrastructure, collection pipelines, payload parsing, enrichment, scoring, analyst review, false-positive handling, API serving, and uptime. FraudGuard turns that into a simple lookup with evidence attached.
FraudGuard pricing also keeps the value accessible: Starter begins at $29/month for 1 million requests, and Professional includes ACE v2 at $99/month for 5 million requests. For teams that cannot justify a custom threat-intel contract but still need better source-IP evidence, that pricing is the point.
CrowdSec is a strong host-level security and remediation platform. FraudGuard is an evidence-based IP reputation API for production traffic decisions.
For self-hosted firewall remediation tied to local logs, CrowdSec is a practical option. For request-level risk, login protection, API abuse, WAF enrichment, checkout protection, and fraud workflows, FraudGuard is the stronger fit. ACE v2 gives teams external honeypot evidence and a decision before suspicious traffic reaches the application.
Review FraudGuard ACE v2, compare FraudGuard pricing, or test an IP at fraudguard.io/iplookup.
Related comparisons: FraudGuard vs AbuseIPDB and FraudGuard vs IPinfo.
]]>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.
Production teams need more than “risky” or “suspicious.” They need to know:
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 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.
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.
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:
This is the difference between blocking an active campaign and punishing an address for stale history.
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:
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.
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:
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.
If you are evaluating an IP reputation provider, ask these questions before wiring it into production enforcement:
If the answer is mostly “trust the score,” treat the signal as enrichment, not as a primary gate.
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.
]]>