What AI Companies Should Know About IP Address Governance
The AI infrastructure conversation is dominated by compute.
GPUs.
Power.
Cooling.
Data centres.
Memory.
Storage.
Interconnect.
All of these matter.
But there is another infrastructure layer that receives far less attention:
Internet number resources.
An AI company can own GPUs, secure power contracts, deploy high-capacity fibre, and build sophisticated model-serving infrastructure.
But if customers cannot reliably reach that infrastructure, none of the compute matters.
Public-facing AI systems still depend on Internet infrastructure.
Model APIs need endpoints.
GPU clouds need customer connectivity.
Data centres need routed networks.
Enterprise AI platforms need stable integrations.
Security systems may depend on known network identities.
Multi-region services may require independent routing.
Behind these systems sit IPv4 and IPv6 addresses, Autonomous System Numbers, routing policies, registry records, and security assertions.
For AI companies, IP addresses should therefore not be treated as an afterthought.
They are part of the infrastructure stack.
And once a number resource becomes operationally embedded, IP address governance becomes a business-continuity question.
AI Infrastructure Is Also Internet Infrastructure
An AI company may think of itself primarily as a software or compute company.
Operationally, however, many AI businesses increasingly resemble infrastructure companies.
Consider an AI platform operating:
- Public model APIs
- GPU cloud services
- Enterprise inference infrastructure
- Training clusters
- Customer-facing dashboards
- Private networking
- Multi-region data centres
- Cloud gateways
- Partner integrations
Each of these systems eventually interacts with network identifiers.
At a basic level, public IP addresses tell the Internet where services can be reached.
At a deeper level, those addresses can become connected to:
- DNS
- Customer allowlists
- Firewalls
- VPNs
- API security
- Routing
- Geolocation
- Abuse-management systems
- Monitoring
- Reputation databases
An IP address may begin as capacity.
Over time, it can become identity.
That distinction matters enormously for AI companies scaling infrastructure quickly.
The First Thing AI Companies Should Understand: IP Addresses Are Coordinated Resources
Public Internet number resources do not exist as independent numbers chosen by individual companies.
They sit within a global coordination framework.
The Internet Assigned Numbers Authority (IANA) maintains the global registries for IPv4, IPv6, and Autonomous System Numbers, while number resources are administered through the Regional Internet Registry system.
The architecture exists for an important technical reason:
Internet identifiers must remain globally unique.
RFC 7020 describes the Internet Numbers Registry System used for globally unique IP address space and AS numbers.
For AI companies, uniqueness itself is not controversial.
Two unrelated production networks cannot both rely on incompatible exclusive claims to the same globally routed prefix.
The more important governance question begins after uniqueness is established:
How much authority should the coordination layer have over the commercial and operational life of an already-running number resource?
That is where the problem becomes more complicated.
A Registry Record Is Not the Same Thing as a Running Network
One of the most important distinctions an AI infrastructure team should understand is the separation between:
Registry information
and
operational Internet reality.
A registry may maintain information about an IPv4 block.
But a database entry does not itself move packets.
BGP moves routing information between networks.
Routers apply policies.
Upstream providers propagate announcements.
RPKI can provide security information about which ASN is authorized to originate a prefix.
Applications and customers then depend on the resulting connectivity.
This is why I have argued that:
A registry record describes reality; it does not create it.
The registry should help keep the ledger accurate.
It should preserve uniqueness.
It should record legitimate changes.
It should support security and operational coordination.
But the existence of a database should not be confused with ownership of the economic and operational reality built around the resources recorded inside it.
This distinction is developed further in The Bill of Rights of Uniqueness Coordination, where I argue that the common number-resource layer should remain focused on uniqueness, accurate records, proof of control, security assertions, auditability, and operational continuity.
For AI companies building expensive infrastructure around IP resources, that distinction is not philosophical.
It is risk management.
IPv4 Scarcity Changes the Governance Question
IPv4 is different from an ordinary software resource.
A company can create another database.
It can provision additional virtual machines.
It can manufacture or purchase more hardware if supply permits.
It cannot manufacture another globally unique IPv4 Internet.
IPv4 is finite.
Once scarcity becomes economically meaningful, number resources stop looking like administrative tokens.
They become operational assets.
This is particularly relevant to AI infrastructure.
Suppose an AI cloud company needs thousands of public IPv4 addresses for:
- Customer workloads
- Public gateways
- APIs
- Management infrastructure
- Dedicated endpoints
- Security appliances
- Regional services
Its IPv4 strategy may involve:
- Existing allocations
- Purchased resources
- Transfers
- Leasing
- Provider-assigned addresses
- Bring-your-own-IP arrangements
Those structures create different dependencies.
The question is therefore not simply:
“How many IP addresses do we need?”
The better question is:
“Under what governance structure will those addresses remain usable?”
AI Companies Should Separate Capacity From Identity
This may be the most important infrastructure distinction.
Not every IP address has the same value to a business.
Some addresses are disposable.
A temporary development workload may move from one address to another with little consequence.
Other addresses gradually become deeply embedded.
Imagine an AI API provider.
Its enterprise customers allowlist specific source addresses.
Banks and regulated customers configure security controls around them.
Partners document them.
Monitoring systems establish years of history around them.
Firewalls depend on them.
Internal compliance systems reference them.
At that point, the address is no longer merely capacity.
It has become part of the company’s network identity.
I developed this distinction in On LARUS One — The Economics of Network Identity, Customer Continuity, and Provider Revenue. The central idea is simple: the real cost of an important address is often not the price of the number, but the cost of changing it.
AI companies should identify early which addresses are merely capacity and which are becoming identity.
They should not govern both categories in the same way.
Ask the Right Question: What Would It Cost to Renumber?
Infrastructure teams frequently ask:
How much does IPv4 cost?
That is a procurement question.
For critical infrastructure, another question can matter more:
What would it cost to replace these addresses?
Consider a mature AI platform with customers around the world.
Changing a core public prefix could require updates to:
- DNS records
- Firewall policies
- Customer allowlists
- Partner allowlists
- API security settings
- VPN configurations
- BGP
- RPKI
- Monitoring
- Reverse DNS
- Geolocation records
- Compliance documents
Some changes can be automated.
Others require customers or partners to act.
That creates external dependency.
The more outside systems recognize an address, the more expensive renumbering becomes.
For AI companies growing quickly, this should be modeled before infrastructure becomes deeply embedded.
Your ASN Matters Too
IP addresses are only one part of network identity.
Large AI infrastructure operators may also use Autonomous System Numbers.
An ASN becomes particularly relevant when a company operates independent routing policies or connects through multiple providers.
A simplified architecture could look like:
AI infrastructure → own IPv4 prefix → own ASN → multiple upstream networks
This can provide more routing independence than relying entirely on provider-assigned addressing.
But independence also creates responsibilities.
An operator must understand:
- BGP policy
- Route announcements
- Prefix filtering
- RPKI
- IRR information
- Upstream relationships
- Incident response
An AI company does not need to become an Internet governance specialist merely because it operates an ASN.
But someone inside the organization needs to understand the dependency.
An ASN should not become a forgotten number sitting in a spreadsheet until the day routing fails.
AI Companies Need to Understand RPKI
RPKI is one of the most important routing-security mechanisms connected to Internet number resources.
A Route Origin Authorization, or ROA, allows a resource holder to state which ASN is authorized to originate a prefix.
RIPE NCC describes a ROA as a signed RPKI object authorizing an origin ASN to announce one or more prefixes, potentially including a maximum prefix length.
For an AI infrastructure operator, this matters whenever routing architecture changes.
Suppose your AI company:
- Acquires an IPv4 block.
- Deploys it from ASN 64500.
- Creates the appropriate ROA.
- Later changes to ASN 64501.
- Updates BGP but forgets the ROA.
The route may be operationally legitimate.
But the security assertion is stale.
Networks performing Route Origin Validation may see the new route as invalid.
The lesson is simple:
RPKI must follow running-network reality.
Network changes and registry/security changes should therefore be part of the same operational process.
Security Infrastructure Should Not Become Governance Leverage
RPKI is valuable precisely because it addresses a narrow technical question:
Is this ASN authorized to originate this prefix?
That narrowness is a strength.
Security infrastructure becomes dangerous when it is turned into a general mechanism for enforcing unrelated disputes.
A disagreement about:
- Commercial structure
- Leasing
- Customer geography
- Business model
- Institutional politics
is not automatically a routing-security problem.
RPKI should reflect legitimate technical authorization.
It should not become a punishment layer for unrelated institutional disagreement.
This principle follows the larger framework I describe in Running-Code Primacy: coordination systems should be interpreted according to the minimum technical function that running networks actually require.
The IETF’s own mission statement is useful context here. RFC 3935 describes the tradition of rough consensus and running code, grounding technical legitimacy in engineering judgment and real-world implementation.
For AI companies, the practical translation is:
Security should secure the network. Governance should not turn security infrastructure into an unrelated choke point.
Buying IPv4 Does Not Automatically Eliminate Governance Risk
An AI company may respond to IPv4 dependence by deciding:
We should just buy our addresses.
Ownership-like control can provide important benefits.
But buying does not make the registry layer disappear.
After acquiring IPv4, the company may still depend on:
- Registry records
- Transfer procedures
- RPKI services
- Reverse DNS
- Account access
- Administrative contacts
- Registry contracts
- Institutional continuity
This means the company has changed the location of risk.
It has not necessarily eliminated it.
That does not mean buying IPv4 is wrong.
It means procurement should distinguish between:
commercial acquisition
and
continuity architecture.
A signed transaction can establish a commercial position.
It does not automatically answer every question about future routing, registry continuity, security services, or institutional dependency.
Leasing IPv4 Also Creates Governance Questions
The same applies to leasing.
An AI company may lease IPv4 because it wants:
- Lower upfront cost
- Rapid deployment
- Flexible capacity
- Multi-region expansion
- Temporary address requirements
That can be completely rational.
But the company should know:
- Who actually controls the address resource?
- Is the provider first-party or brokered?
- Which ASN may originate the prefix?
- Who creates the ROA?
- Who controls reverse DNS?
- What happens if reputation deteriorates?
- Who handles abuse?
- What happens at renewal?
- What happens if the upstream resource relationship fails?
The worst time to discover these dependencies is after the addresses have become critical network identity.
The Broker Question Is Really a Risk Question
This is why ordinary procurement language can be misleading.
The market asks:
Who can get us IPv4?
An AI infrastructure operator should ask:
Who carries the risk behind the IPv4?
A marketplace can show inventory.
A broker can introduce a counterparty.
A contract can describe terms.
But AI companies building production infrastructure need to understand what happens after the transaction.
If the addresses become embedded in customer systems, their value increasingly depends on continuity.
That is why I argued in Why i.LEASE Exists — and Why the Broker Question Is Really a Registry-Risk Question that IPv4 execution should be evaluated according to the risk structure beneath the visible transaction.
For AI companies, the same principle applies.
Do not evaluate IPv4 sourcing only by:
Price per address.
Also evaluate:
Continuity per address.
Portability Should Matter to AI Infrastructure Teams
One of the largest structural weaknesses in Internet number-resource governance is the absence of a universal resource-level portability mechanism.
I distinguish resource portability from ordinary corporate or membership migration.
The question is not:
Can the company move offices?
It is not:
Can the company join another organization?
The question is:
Can the specific number resource preserve its registry administration, proof of control, security assertions, and operational continuity if the current administrative structure fails?
That distinction matters to AI infrastructure.
Imagine an AI company has built a major customer platform around a stable IPv4 block.
If the surrounding registry institution experiences:
- Governance breakdown
- Insolvency
- Legal paralysis
- Technical failure
- Serious conflict
should the company have to renumber its infrastructure simply because the administrative provider became unstable?
My position is no.
A running network needs a continuity path.
This is why The Bill of Rights of Uniqueness Coordination includes portability as a fundamental design principle.
Protect the Registry Function, Not Institutional Immortality
This distinction is especially relevant to AI companies because AI infrastructure is becoming more expensive and more operationally significant.
A company may spend billions building compute capacity.
It would be irrational to design the network-identity layer so that it depends on the permanent institutional health of one organization.
Registry functions matter.
They include:
- Number uniqueness
- Accurate records
- RDAP/WHOIS
- Reverse DNS
- RPKI
- Transfer history
- Security metadata
But continuity of these functions does not logically require institutional immortality.
I develop this argument in The Registry Continuity Fallacy — Protect the Ledger, Not the Gatekeeper.
The principle is straightforward:
Protect the ledger.
Protect the security chain.
Protect the running network.
Protect the customers.
The institution administering those functions should remain replaceable.
For AI companies, this is basic infrastructure engineering.
We demand failover from compute.
We demand failover from power.
We demand failover from storage.
We demand failover from connectivity.
Why would the number-resource layer be exempt?
AI Companies Should Treat Registry Risk Like Other Infrastructure Risk
A mature AI infrastructure risk register may already include:
- GPU supply
- Power availability
- Data-centre concentration
- Transit failure
- Cloud concentration
- Cybersecurity
- Hardware failure
- Supplier risk
Add:
Internet number-resource risk.
That risk includes several categories.
Administrative Risk
Who controls the accounts and credentials needed to manage the resources?
Registry Risk
What institutional dependencies surround the resources?
Routing Risk
Which ASNs announce the prefixes?
RPKI Risk
Do security assertions match routing reality?
Provider Risk
Does the network depend on provider-assigned addresses?
Renewal Risk
Could leased addresses disappear at contract expiry?
Identity Risk
How many customers and partners rely on specific addresses?
Portability Risk
What happens if the administrative service needs to change?
These questions are small compared with an AI company’s compute budget.
Their consequences may not be.
AI Infrastructure Teams Need Their Own Number-Resource Inventory
Every serious AI infrastructure company should be able to answer:
Which Internet number resources do we depend on?
That inventory should include:
- IPv4 prefixes
- IPv6 prefixes
- ASNs
- Resource holder
- Registry
- Origin ASN
- RPKI status
- Reverse DNS authority
- Lease or ownership structure
- Renewal date
- Upstream providers
- Critical customers
- External allowlists
- Administrative account owners
Do not keep this information only in the head of one network engineer.
Treat it as infrastructure metadata.
The company should be able to survive personnel changes without losing control of its number resources.
AI Companies Should Classify IPs by Criticality
Not every address needs maximum continuity protection.
Create categories.
Disposable Capacity
Examples:
- Development environments
- Temporary testing
- Short-term experiments
Renumbering cost is low.
Production Capacity
Examples:
- Customer workloads
- General application infrastructure
- Regional cloud services
Continuity matters, but replacement may remain manageable.
Business-Critical Identity
Examples:
- Main API endpoints
- Partner-facing gateways
- Regulated infrastructure
- Security allowlist addresses
- Payment-related systems
- Core customer networks
Renumbering can create significant external coordination.
Non-Renumberable or Extremely High-Cost Identity
This category should be rare.
But where an address has become embedded across customers, security systems, partners, compliance environments, and multiple providers, the cost of changing it may exceed the cost of maintaining a dedicated continuity architecture.
Infrastructure spending should follow that classification.
The IPv6 Answer Is Not Enough
AI companies should deploy IPv6 where it makes technical and commercial sense.
But IPv6 does not make the IPv4 governance question disappear overnight.
An AI platform may still interact with:
- IPv4-only customers
- Legacy enterprise networks
- Security products
- Partner systems
- External services
- Customer allowlists
The relevant planning question is not:
“IPv4 or IPv6?”
It is:
“Which workloads still require IPv4, which can operate over IPv6, and what continuity does each identity require?”
That is an infrastructure decision.
It should not be reduced to ideology about one protocol replacing another.
Geography Should Not Become Ownership
AI infrastructure is inherently global.
A model may be trained in one country.
Its API may run in another.
Customers may be located everywhere.
Traffic may traverse networks across multiple continents.
IP address administration may historically be associated with a particular Regional Internet Registry.
But service-region geography should not be confused with ownership of the economic destiny of the resource.
This becomes especially important for global AI companies.
The Internet routes globally.
A prefix does not acquire a political nationality simply because a particular database historically administered it.
The coordination layer needs accurate records.
It does not need to determine whether an AI company’s customers are sufficiently local to deserve access to a scarce resource.
That distinction is part of a wider point developed throughout my notes:
Thin coordination works. Thick governance creates unnecessary risk.
What Should Thin IP Address Governance Look Like?
A useful number-resource coordination layer should answer a narrow set of questions.
Is the Resource Unique?
There should not be incompatible duplicate registrations.
Who Demonstrates Control?
The system should maintain credible proof.
Are the Records Accurate?
Contacts and resource information should reflect reality.
Are Security Assertions Valid?
RPKI and related mechanisms should reflect legitimate routing authorization.
Can Changes Be Audited?
Transfers and updates should have reliable history.
Can Disputes Be Isolated?
A disagreement should not unnecessarily destroy a running network.
Is There a Replacement Path?
The registry function should survive institutional failure.
That is enough to support a globally interoperable Internet.
Everything else should face a higher test before becoming mandatory.
The question should always be:
Does running code actually require this rule?
Running-Code Primacy for AI Infrastructure
AI companies are unusually well positioned to understand this principle.
Software engineers already distinguish between:
what the specification says
and
what the system actually does.
Internet infrastructure should be approached with the same discipline.
The running network is real.
Customers are real.
Routes are real.
Security dependencies are real.
A policy document is useful when it helps coordinate that reality.
It becomes dangerous when it begins pretending to sit above reality.
This is why Running-Code Primacy matters beyond traditional telecom companies.
AI companies are becoming Internet infrastructure operators.
They should inherit the technical discipline that made the Internet work:
coordinate what must be coordinated; decentralize everything that does not need a central decision.
A Practical IP Governance Checklist for AI Companies
Before scaling AI infrastructure, ask these questions:
- Which IPv4 and IPv6 resources support production?
- Which ASNs are part of our network?
- Who is recorded as the resource holder?
- Which registry administers each resource?
- Who controls administrative access?
- Which ASN originates each production prefix?
- Are our ROAs correct?
- Who can modify RPKI?
- Who controls reverse DNS?
- Are WHOIS/RDAP contacts accurate?
- Which resources are leased?
- Which resources are directly held?
- Which resources come from providers?
- What are the renewal dates?
- What happens if a lessor fails?
- What happens if a registry becomes unavailable?
- Which customers have our addresses allowlisted?
- What would it cost to renumber each critical prefix?
- Is the resource merely capacity or has it become identity?
- Is there a credible continuity or replacement path?
If the company cannot answer these questions, its number-resource infrastructure is not yet fully governed.
What the Board Should Understand
IP address governance should not remain exclusively inside the network engineering team once the company reaches sufficient scale.
Boards and senior executives do not need to understand BGP configuration.
They should understand the risk model.
The relevant questions are:
Are critical network identities stable?
Can customers remain reachable if a provider changes?
Can a registry issue become a business interruption?
How much would renumbering cost?
Where are the single points of institutional dependency?
These are governance questions because they affect continuity, capital, customer relationships, and strategic flexibility.
What Investors Should Ask
Investors conducting infrastructure diligence on an AI company should also examine number resources.
A useful diligence question is not simply:
“Do you have enough IP addresses?”
Ask instead:
- How are they sourced?
- How much is leased?
- How much is directly held?
- Who carries registry risk?
- Which addresses are business-critical?
- Is routing controlled internally?
- Are RPKI and registry processes documented?
- What happens if key address relationships terminate?
An AI company with extraordinary compute but fragile network identity still has infrastructure concentration risk.
The risk is simply less visible.
The Larger Governance Question
AI may become one of the largest new consumers of global infrastructure capital.
That makes it an important constituency in the future of Internet governance.
But AI companies should not enter that conversation asking for more centralized control.
They should ask for better engineering.
The number-resource layer should be:
- Accurate
- Auditable
- Secure
- Portable
- Replaceable
- Resistant to capture
- Focused on continuity
The Internet does need coordination.
It does not need unnecessary sovereignty over identifiers.
The distinction will matter more as the economic value built on top of number resources continues to increase.
Final Thoughts
AI companies are learning to think strategically about chips, power, cooling, land, fibre, and data centres.
They should add Internet number resources to that list.
IPv4 addresses, IPv6 addresses, ASNs, BGP, RPKI, reverse DNS, and registry records may look like details deep inside the infrastructure stack.
They are not.
They help determine whether customers can reach the infrastructure the company has spent so much money building.
As AI companies scale, some IP addresses will remain disposable capacity.
Others will become deeply embedded network identity.
The governance model should recognize the difference.
The right questions are not only:
How many IP addresses do we have?
How much do they cost?
Ask:
Who controls them?
Who can route them?
Who can change the security assertions?
What institutional dependencies surround them?
Can they survive a provider change?
Can they survive a registry failure?
What happens when running reality and administrative reality diverge?
This is the deeper meaning of IP address governance.
The registry should protect uniqueness.
It should protect accuracy.
It should protect legitimate security assertions.
It should make transfers and control changes legible.
But it should not become the owner of the operational destiny built around the numbers it records.
AI infrastructure will increasingly depend on stable network identity.
That infrastructure deserves the same design discipline applied to every other critical layer:
No unnecessary single points of failure.
No irreplaceable administrator where failover is technically possible.
No confusion between coordination and sovereignty.
Protect the ledger.
Protect the running network.
Protect the customer.
That is what AI companies should know about IP address governance.
Internal Reading on Heng.lu
- The Bill of Rights of Uniqueness Coordination
- Running-Code Primacy: The Patch Needed to Preserve the Internet’s Original Design
- The Registry Continuity Fallacy — Protect the Ledger, Not the Gatekeeper
- On LARUS One — The Economics of Network Identity, Customer Continuity, and Provider Revenue
- Why i.LEASE Exists — and Why the Broker Question Is Really a Registry-Risk Question
Authoritative External Reading
FAQs
AI companies operating APIs, GPU clouds, data centres, enterprise platforms, and other Internet-facing infrastructure can become dependent on public IP addresses and ASNs. Governance affects how those resources are registered, routed, secured, transferred, and kept operational.
At minimum, companies should maintain inventories of production IPv4 prefixes, IPv6 prefixes, Autonomous System Numbers, registry relationships, routing origins, RPKI configuration, reverse DNS, and resource contracts.
An IP address begins as a technical identifier. It can become network identity when customers, partners, firewalls, APIs, security systems, and compliance processes rely on that specific address remaining stable.
Buying may make sense for predictable long-term requirements, but commercial acquisition does not eliminate registry, routing, RPKI, and administrative dependencies. The decision should therefore include continuity analysis.
Leasing can provide flexible capacity and lower upfront cost. Companies should evaluate the resource source, provider structure, routing authority, RPKI, reverse DNS, reputation, renewal, and continuity before production depends on the block.
