When your application relies on API keys to authenticate requests, a leaked or compromised key can pose a significant security risk. Rotating the key is still the right remediation if it is already being abused. Network Firewall adds a second layer: even a valid key is rejected when the request does not come from a network you expect.
That work lives on the application in the Edlink dashboard as Network Firewall. It applies to API requests authenticated with that application's secret or with an integration access token. It does not replace the district firewall or the team's dashboard-access firewall.
IP allowlists and blocklists, geofencing, and VPN/Tor controls are available now. User-agent validation, cryptographic fingerprinting, velocity limits, and impossible-travel detection are still on the roadmap. The longer product direction is covered in Securing Your Integrations.
What you can enforce today
On the application's Network Firewall page you can:
- Add known IP addresses for the servers (and CI egress, if it is stable) that should be allowed to use the key.
- Block all traffic from unknown IP addresses once that list is accurate, so a key pasted into a public repository fails from the attacker's network.
- Block specific IP addresses you already know are unwanted.
- Block VPN or Tor traffic when your callers do not use those networks.
- Filter by country, either denying a few countries or allowing only the countries where you host.
Changes take effect immediately. Add your real egress IPs before you enable unknown-IP blocking.
What is still coming
The original API Request Hardening plan also included controls that look at the client, not just the network:
- User-agent validation and cryptographic fingerprinting, so a key used from an unexpected HTTP client can be flagged even if the IP is allowed.
- Endpoint velocity limits, so a sudden scrape from a compromised key is throttled before it becomes a full export.
- Impossible-travel detection, so the same key cannot show up in two distant networks seconds apart.
None of those are in the dashboard yet. Until they are, a key that is used from an allowed network will still succeed — rotate it if you believe it has leaked.
Defense in depth
Network Firewall does not replace storing secrets off the client, rotating them when they leak, or using sharing rules to limit what a key can see. It makes a leaked key much less useful from a random laptop or proxy. For how to handle the secrets themselves, see Safely Handling API Secrets.