LLM API Key Security In A Bank: A Worked Example With IP Allowlists, Usage By Key And Approvals

1,000 - IP addresses or CIDR ranges allowed per organisation on Anthropic's IP allowlist (beta, 5 November 2026)  ·  29 Oct - Release of the Usage and Cost Analytics API with grouping by API key (beta)  ·  0 - Places outside the bank where a leaked key should still work

LLM API key security has two halves. Prevention makes a leaked key useless outside the places you expect. Detection spots a key being used by the wrong service or at the wrong volume. Two Anthropic releases in the last week give a bank both, if the engineering around them is careful.

What is the worked example?

A composite bank runs operations agents in a restricted network segment. They reach the model provider through a small set of fixed egress addresses. Model risk has approved two service accounts, one for reconciliations and one for onboarding files, each with its own key. The bank wants a leaked key to fail everywhere else, and odd use to reach a person within the day.

What did Anthropic release on 29 October and 5 November?

On 5 November 2026 Anthropic released an IP allowlist in beta in the Claude Console. Requests to covered services from addresses not on the list are refused, which limits where a leaked API key can be used. It takes IPv4 and IPv6 addresses or CIDR ranges, up to 1,000 per organisation. The same day it added an Admin API call, in beta, to sign a Claude Enterprise member out everywhere, ending their sessions, trusted devices and OAuth tokens for the organisation.

On 29 October 2026 it launched the Usage and Cost Analytics API in beta. Its usage and cost endpoints can filter and group results by model, workspace, API key and the user or service account behind each request. The Python SDK 2.6.0, released on 5 November, added error codes for External Key validation failures.

What does LLM API key security look like in the bank?

How do you keep the allowlist and the network in step?

"""Check that the bank's egress addresses and the provider's IP allowlist agree, before and after change.

Anthropic's IP allowlist (beta, 5 November 2026) refuses requests from addresses not on the list,
limiting where a leaked API key can be used. It takes IPv4 and IPv6 addresses or CIDR ranges, up to
1,000 per organisation. Python 3.14 standard library only (ipaddress). Sample addresses only.
"""
from __future__ import annotations

import ipaddress

ALLOWLIST = ["203.0.113.16/29", "2001:db8:5::/64"]  # what the provider has, documentation ranges
EGRESS = {"agent-host-a": "203.0.113.18", "agent-host-b": "203.0.113.21", "dr-site": "198.51.100.7",
          "agent-host-v6": "2001:db8:5::12"}
MAX_ENTRIES = 1000


def check(allow: list[str], egress: dict[str, str]) -> list[str]:
    nets = [ipaddress.ip_network(a, strict=True) for a in allow]
    issues = [f"{len(nets)} entries exceed the {MAX_ENTRIES} limit"] if len(nets) > MAX_ENTRIES else []
    for host, ip in egress.items():
        if not any(ipaddress.ip_address(ip) in n for n in nets):
            issues.append(f"{host} ({ip}) is not covered: its requests will be refused")
    for n in nets:
        if n.num_addresses > 256:
            if not any(ipaddress.ip_address(ip) in n for ip in egress.values()):
                issues.append(f"{n} is broad and covers none of our egress addresses")
    return issues


if __name__ == "__main__":
    for i in check(ALLOWLIST, EGRESS):
        print("-", i)
    print("after CHG-4410 adds the DR site:", check(ALLOWLIST + ["198.51.100.7/32"], EGRESS) or "no issues")

The disaster recovery site's address is missing from the allowlist, so its requests would be refused on the day it is needed. Change CHG-4410 adds it and the check passes. Run this check in the pipeline for every network or allowlist change, and on a schedule.

How do you spot a key used by the wrong service?

"""Spot API key use that does not match its owner, from a usage export, and propose revocation for approval.

Anthropic's Usage and Cost Analytics API (beta, 29 October 2026) can group usage by API key and by the user
or service account behind each request. This works on an exported sample, proposes action and waits for a
named approver. Python 3.14 standard library only. Sample rows only.
"""
from __future__ import annotations

import csv
import io
import statistics

EXPORT = """day,api_key,service_account,model,input_tokens
2026-11-02,key-recs,svc-recs,claude-sonnet-5-5,410000
2026-11-03,key-recs,svc-recs,claude-sonnet-5-5,395000
2026-11-04,key-recs,svc-recs,claude-sonnet-5-5,402000
2026-11-05,key-recs,svc-recs,claude-sonnet-5-5,2350000
2026-11-05,key-kyc,svc-recs,claude-opus-5-5,120000
"""
OWNER = {"key-recs": "svc-recs", "key-kyc": "svc-kyc"}
PROPOSALS: list[dict[str, str]] = []


def scan(text: str) -> None:
    rows = list(csv.DictReader(io.StringIO(text)))
    by_key: dict[str, list[int]] = {}
    for r in rows:
        if OWNER.get(r["api_key"]) != r["service_account"]:
            PROPOSALS.append({"key": r["api_key"], "why": f"used by {r['service_account']}, owned by {OWNER.get(r['api_key'])}"})
        by_key.setdefault(r["api_key"], []).append(int(r["input_tokens"]))
    for key, vals in by_key.items():
        if len(vals) >= 4 and vals[-1] > 3 * statistics.median(vals[:-1]):
            PROPOSALS.append({"key": key, "why": f"latest day {vals[-1]:,} tokens, over 3x the median"})


if __name__ == "__main__":
    scan(EXPORT)
    for p in PROPOSALS:
        print(f"propose revoke {p['key']}: {p['why']} -> waiting for a named approver")

The onboarding key was used by the reconciliation service account, and the reconciliation key used more than three times its median daily tokens on 5 November. Both become revocation proposals that wait for a named approver, because revoking a key stops a workflow.

What does the dev team have to learn?

• **Legacy data.** Usage exports join to the bank's own service catalogue to find owners. Keep that catalogue current.
• **Change control.** Allowlist entries are network changes. Raise them through the same change process as firewall rules.
• **Audit log.** Every allowlist change, revocation proposal and decision goes to a log the agent hosts cannot write to.
• **Approvals.** A person approves every revocation and every allowlist addition.
• **Latency.** The allowlist adds no hop of its own, but a single egress route can become a bottleneck. Measure it.
• **Evaluation.** After any key rotation, run the evaluation set to prove the workflow still behaves the same.
• **Restricted network.** No route to the provider except through the listed egress addresses.

What breaks in production?

• **Forgotten sites.** Disaster recovery, developer VPNs and CI runners all need either an entry or a deliberate refusal.
• **Broad ranges.** A wide CIDR that covers none of your egress addresses quietly widens where a key works. The sample flags it.
• **Shared keys.** One key for several services makes usage by key meaningless. One key per service account.
• **Beta features.** Both releases are in beta. Pin your process to the documented behaviour and re-test after changes.

What are the alternatives to provider allowlists?

Our playbook on self-hosted LLM security in a bank covers the on-premises route, and keeping tokens out of CI logs covers another leak path. Our blog on AI cost reporting uses the same usage data for the MI pack.

Where should a bank start?

List every place a request to the model provider can come from, then compare that list with the allowlist. Our case studies include systems for a global investment bank, and our Workflow Automation London team can run this review in a 14-day Proof Run.