What AI Companies Should Know About IP Address Governance

AI infrastructure discussions usually begin with compute: GPUs, power, cooling, data centres, storage and interconnects. Those are visible investments. The network identity underneath them is easier to overlook.

A public AI service still needs reachable endpoints. Its customers may allowlist specific addresses. Its routing may depend on an Autonomous System Number. Its security systems may rely on RPKI, reverse DNS and a history attached to the same network identity.

That leads to the question this guide answers: how can an AI company keep its network reachable when an address, provider or registry becomes part of the risk?

First, separate capacity from identity

An IP address can begin as capacity. A temporary development environment may move to another address with little disruption. A production API is different once customers, partners, firewalls, monitoring systems and compliance records depend on that exact address.

At that point, the address has become part of the company’s network identity. The cost is no longer the price of an address. It is the cost of changing every outside system that has learned to trust it.

This distinction gives an infrastructure team a better starting point than asking only how many addresses it needs. It should ask which addresses are disposable, which support production, and which have become difficult to replace.

Four layers that are easy to confuse

AI teams can make better decisions when they keep four different layers separate:

• The resource. IPv4 and IPv6 prefixes, plus Autonomous System Numbers, give networks globally unique identifiers.
• The registry record. A registry records who holds or controls a resource and helps the wider Internet avoid conflicting claims.
• The running network. BGP announcements, routers, upstream providers and applications determine whether traffic actually reaches a service.
• The security assertion. RPKI and a Route Origin Authorization help other networks check whether an ASN is authorized to originate a prefix.

A registry record does not move a packet by itself. A correct record is still valuable because other networks use records and security assertions when deciding what to recognize. The point is precision: recording a resource is a coordination function, not ownership of the business built around it.

Why this becomes a business continuity problem

Imagine an AI platform whose main API prefix is used in customer allowlists, partner firewalls, VPNs, abuse controls, monitoring and regional routing. The company may have bought the resource, leased it or received it from a provider. Each arrangement creates different dependencies, but all of them become more expensive to change after the prefix is deeply embedded.

A provider outage is only one kind of failure. The surrounding administrative service could also become unavailable, enter a legal dispute, lose access to its systems or make a decision that leaves the running network with no practical way to preserve its identity.

The company’s compute cluster may still be healthy. Its customers may still be paying. Yet the cost of renumbering can turn an administrative problem into a service and revenue problem.

Buying or leasing an address does not remove the dependency

Buying can be sensible when an AI company needs predictable, long-term capacity. Leasing can be sensible when it needs flexibility or rapid expansion. Neither transaction answers every continuity question.

Before production depends on a prefix, the team should know:

• Who is recorded as the resource holder?
• Which registry administers the record?
• Which ASN may originate the prefix?
• Who can create or change the ROA?
• Who controls reverse DNS and administrative access?
• What happens if a provider, broker or lessor disappears?
• What happens when a lease ends or a registry becomes unavailable?

Price per address is therefore only one procurement measure. For a critical prefix, the more useful measure is continuity per address.

RPKI must follow the network that is actually running

Suppose a company moves a prefix from one ASN to another. Its BGP configuration may be correct, but the old ROA may still authorize only the previous origin. Networks performing Route Origin Validation can then see the new announcement as invalid.

The operational rule is simple: a routing change and its security assertion belong in the same change process. RPKI should answer the narrow technical question it was designed to answer, which ASN is authorized to originate this prefix.

It should not become a general punishment mechanism for unrelated commercial disputes or institutional disagreements. Security should secure the running network. It should not create an extra, unreviewable choke point over the company’s business.

For the technical background, see the RPKI architecture and IANA’s number-resource references.

The solution is thin coordination with a real exit path

AI companies do need coordination. Addresses must remain unique. Records must be accurate. Routing security must be verifiable. Transfers and control changes must be auditable.

Those functions do not require one administrator to become irreplaceable. A stronger design would let a resource holder prove control, carry an independently verifiable record to another service and keep the network operating if one administrator fails.

This is the practical meaning of portability. It is not the ability to move an office or join another membership organisation. It is the ability to preserve the resource record, proof of control, security assertions and operational continuity when the current administrative arrangement must change.

Changing the name on the gate does not solve the structural problem if the company still cannot leave. The replacement path has to be part of the system before a crisis makes it necessary. The argument is developed in The Bill of Rights of Uniqueness Coordination and The Registry Continuity Fallacy.

A practical inventory for an AI infrastructure team

Before scaling a public AI service, keep one current inventory that answers:

• Which IPv4 and IPv6 prefixes support production?
• Which ASNs are used, and which ASN originates each prefix?
• Who controls the registry account, reverse DNS and RPKI keys?
• Which resources are leased, provider-assigned or directly held?
• Which customers and partners have the addresses allowlisted?
• What would it cost to renumber each critical prefix?
• What is the replacement path if a provider or registry fails?

Classify the result into disposable capacity, production capacity and business-critical identity. The last category deserves the same failover thinking already applied to power, storage, transit and cloud providers.

Why the work starts before anything breaks

IPv6 can reduce pressure on IPv4, and companies should use it where it fits their customers and systems. It does not make every IPv4 dependency disappear overnight. Many enterprise networks, allowlists and external services still depend on stable IPv4 identity.

Waiting until a provider or registry is already failing removes the time needed to test records, compare alternatives and coordinate customers. The urgency is operational rather than theatrical: the more systems that learn one identity, the more expensive an unplanned change becomes.

AI companies are building infrastructure with long lives and large external dependencies. They should apply the same discipline to number resources that they apply to compute and power: remove unnecessary single points of failure, document the dependency, and make replacement possible before it is needed.

The board-level question

Senior leaders do not need to configure BGP. They do need to ask whether the company’s most important network identities can survive a provider change, a stale security assertion or an institutional failure.

The right question is not only “Do we have enough IP addresses?” It is:

• Who can change them?
• Who can route them?
• Who can change the security assertions?
• Which customers depend on them?
• Can the company preserve them if the administrator cannot continue?

That is what IP address governance means at infrastructure scale. Protect uniqueness, accuracy, legitimate security assertions and the running network. Keep the administrator replaceable.

Continue with the underlying argument

This guide explains the operational question. The wider argument is developed in Lu Heng’s Notes: network identity and customer continuity, Running-Code Primacy, and the proposed rights of uniqueness coordination.

For the sourcing question, read Why i.LEASE Exists. The common thread is simple: a transaction can give a company access to a resource, but only a continuity design can make that access durable.