Skip to main content
When a public exposure path ends at an AWS load balancer, each path can include originReachability. Use it to check whether the origin itself accepts traffic from outside Cloudflare, based on security-group ingress compared to pinned Cloudflare IP ranges. This is origin-control evidence on the path. It does not change the overall exposure verdict, and it is not a traffic-path failure.

Try it

Or with Graph Query Language:
The same field is available from graph.exposure() in the Graph SDK and from the Graph MCP get_exposure tool.

Field shape

paths[].originReachability is either an object or JSON null. null means the path was not evaluated for origin reachability (for example, no ALB or NLB origin was present on that path). When present:

Verdicts

Incomplete evidence never becomes restricted_to_cloudflare. Prefer reading unknown plus missingEvidence when inventory is partial.

What this is not

originReachability answers a different question from DNS proxy state: A hostname can be orange-cloud (PROXIES_TO) and still be directly_reachable at the origin if the security group allows 0.0.0.0/0. Conversely, restricted_to_cloudflare does not mark the exposure path as failed. Annie CLI prints origin reachability separately from traffic gaps so it never looks like a missing hop.

Supported origins

Evaluated today:
  • Internet-facing AWS Application Load Balancer with security-group ingress
  • Internet-facing AWS Network Load Balancer with attached security groups
Still not_applicable or unknown without enough preservation evidence:
  • NLB shapes without attached security groups, or target-SG-only analysis
  • Gateway Load Balancer
  • Kubernetes NetworkPolicy source-IP analysis (needs observed client-IP preservation)
Connect Cloudflare and AWS inventory so exposure paths and security-group evidence are present before you treat a restricted verdict as conclusive.