# Key security
> LMU AI API key IP whitelist / blacklist guide: restrict which IPs can call your key to stop a leaked key being abused; supports single IPs and CIDR ranges.
URL: https://docs.lmuai.ai/docs/guide/key-security
If a key leaks, others can use it to consume your quota. An **IP whitelist** is the most direct protection — only IPs you trust are allowed to use the key.
## Where to configure it [#where-to-configure-it]
Go to **console → API Keys → Edit (or Create)** and find the two fields, **IP whitelist** and **IP blacklist**.
One rule per line, in either of two formats:
| Format | Example | Description |
| ---------- | ---------------- | ---------------------------------------------- |
| Single IP | `203.0.113.10` | Matches exactly one IP |
| CIDR range | `203.0.113.0/24` | Matches a whole range of IPs (`/24` = 256 IPs) |
Both IPv4 and IPv6 are supported (IPv6 example: `2001:db8::/32`).
## How it takes effect [#how-it-takes-effect]
* **Whitelist empty** → no source restriction; any IP can use the key
* **Whitelist non-empty** → only IPs on the list can use it; all others are rejected
* **Blacklist** → matching IPs are rejected, **taking priority over the whitelist**
* You can use both at once (the blacklist is checked first, then the whitelist)
When rejected, the API returns `403 ACCESS_DENIED`.
## Find your real egress IP (important!) [#find-your-real-egress-ip-important]
**This is the easiest mistake to make**: the IP you configure on the key must be the **public egress IP** that LMU AI's servers see, not the private address shown by `ipconfig` / `ifconfig` on your computer.
```bash
# Command line
curl https://ifconfig.me
# or
curl https://ip.sb
```
Or open [ip.sb](https://ip.sb) / [ifconfig.me](https://ifconfig.me) in your browser.
Your egress IP changes when you turn on a VPN or a company proxy, or when your mobile device switches Wi-Fi networks. Confirm it with the command above before configuring the whitelist.
## Common scenarios [#common-scenarios]
**Scenario 1: A fixed office IP**
```
Whitelist:
203.0.113.10
```
**Scenario 2: Working from both home and the office**
```
Whitelist:
203.0.113.10 # Company egress
198.51.100.20 # Home broadband
```
**Scenario 3: Running on your own cloud server**
```
Whitelist:
```
Allow only your server to call the API, and use a separate key (with no whitelist) for local development.
**Scenario 4: You just want to temporarily block a suspicious IP**
```
Blacklist:
1.2.3.4
```
Everything else works as usual, with no impact on normal use.
## Troubleshooting [#troubleshooting]
**Q: My call returns 403 ACCESS\_DENIED — is it an IP restriction?**
Most likely. Check in order:
1. Use `curl https://ifconfig.me` to confirm your current real egress IP
2. Compare it against the key's whitelist to see if it matches
3. If it doesn't match, add the current IP to the whitelist, or temporarily clear the whitelist to test
4. If it's still rejected, check whether it's on the blacklist, whether the key is disabled, and whether the quota is exhausted
**Q: I put an IP on the whitelist but I'm still rejected?**
* Did you enter a **private IP** (`192.168.x.x` / `10.x.x.x` / `172.16-31.x.x`)? Replace it with your public egress IP.
* Did you enter an IPv6 address but go online over IPv4 (or vice versa)? Enter both.
* Did you enter a CIDR with a malformed format (such as `1.2.3.4/33`)? Invalid rules are silently ignored.
## Recommended practices [#recommended-practices]
* For **production keys**, we strongly recommend configuring an IP whitelist to minimize the attack surface
* For **development / debugging keys**, you can skip the whitelist, but you must set a **total quota cap** as a backstop
* If you're especially worried about leaks, combine it with [**rate limiting**, **total quota**, and **model whitelist**](/docs/guide/how-to-use-token) for layered defense
* The moment you suspect a key has leaked, **reset or delete** it in the console right away