# IP access list
Atlas blocks every IP until you allow it. A fresh cluster with a correct user and string still refuses connections until the client IP is listed. This is the number one agent connectivity failure.
## Setup
1. Atlas UI: Security, Network Access, Add IP Address.
2. Add the egress IP of wherever the agent runs. For a laptop, use Add Current IP Address.
3. Give temporary entries an expiry (a week for a laptop, a day for a debug session) so stale IPs do not accumulate.
## Rules for agents and CI
- CI runners and agent sandboxes usually have ephemeral egress IPs. Options: a NAT gateway with a static IP, adding the runner IP range as a CIDR, or managing entries through the Atlas Admin API as part of the pipeline.
- The "allow access from anywhere" entry (the all-zeros CIDR) is a development convenience. It puts the cluster on the public internet behind only a password. Never ship it to production; prefer VPC peering or a private endpoint there.
- When connections suddenly stop working after working fine, the IP access list is the first suspect: the ISP rotated the IP, the runner moved regions, or someone deleted the entry. Check the list before debugging the driver.
- Database users and the IP access list are independent gates. You need both: a valid user AND a listed IP.
## Verify
Connect from the target network with mongosh or the startup ping. If it works from your laptop but not from CI, the difference is the egress IP.