Summary

  • ARIN says actions can be traced to specific API keys, yet its current guide says the key-management table identifies a key only by its prefix and creation date.
  • ACSP suggestion 2023.15 has remained open since October 2023 after ARIN agreed that user-supplied descriptions would help customers manage multiple keys.
  • A description would not restrict authority, prove custody, impose expiry or prevent compromise. It would record intended purpose so operators could compare declaration with observed use.
  • ARIN should make the label the first field in a versioned credential-purpose receipt joining the non-secret key identifier, issuing principal, observed service class, review owner and deactivation evidence.

The thinnest row in the security inventory

The consequential line in ARIN’s API-key documentation is not a warning about an attack. It is an ordinary description of a table. After a customer creates a key and sees the secret for the only time, the key remains visible in ARIN Online, but “will only be identifiable by the Key Prefix and date of creation.”

That is enough to point at a credential. It is not enough to explain it.

A prefix separates one row from another. A date tells an operator when the row began. Neither says whether the key feeds an RPKI process, updates network records through Reg-RWS, manages reverse DNS, writes IRR objects or downloads a restricted report. ARIN’s own guide lists all of those uses. It also says that multiple interactions may be performed with one key, that customers may create multiple keys to track work, and that a key does not expire automatically, although it can be deactivated.

The resulting inventory has identity in the database sense but not in the operational sense. It can answer “which row?” while leaving “which job?” to a vault label, a configuration file, a ticket, a former colleague’s memory or a lucky search through logs. That difference becomes more important, not less, as automation matures. Long-lived authority is easiest to govern when the reason for its existence remains attached to the authority.

ARIN has already received that request. ACSP 2023.15, submitted on 25 October 2023, asks ARIN to let a user specify a description for an API key. The submitter connected the request to the absence of fine-grained permissions and named service roles, but did not confuse those functions: a description would help track what each key was intended to do; permissions would limit what it could actually do. Two days later ARIN agreed that descriptions would be useful for customers with multiple keys, said the work would enter its deployment schedule, and kept the suggestion open until implementation.

The page and the current ACSP index still show it as open, without a later public tracking note.

That status does not prove ARIN has done no internal design or scheduling. Nor does the wording of the public guide prove that no private test interface contains another field. It establishes a narrower point: the public commitment remains unresolved, and the documented customer inventory still stops at prefix and date.

Traceability begins after purpose

ARIN’s August 2025 advice on team key management makes the gap unusually clear. It warns that sharing one person’s credential hands over broad control and breaks traceability. The recommended pattern is to combine Role Points of Contact with unique keys. ARIN says a key has the permissions of the user who created it, that specific actions can be traced back to specific keys, and that a compromised key can then be replaced with a smaller affected set.

That is a meaningful control improvement. It separates activity by credential. But action attribution is not purpose attribution.

Suppose an organization sees that key prefix API-7F2…, created eighteen months ago, changed an IRR object last week. The log may answer which credential acted and when. It may even reveal the authenticated principal. The inventory row still does not say whether IRR maintenance was the key’s intended job, a temporary migration use that was never retired, or an unexpected expansion from its original purpose. A trace is evidence of what happened. A description is a declaration of what should have happened. Governance requires the comparison.

The distinction matters in both directions. An active key whose stated purpose matches repeated, expected work is easier to defend at review. An active key that has never been used may be a failed deployment, an emergency spare or an abandoned credential; the label gives the reviewer somewhere to begin, not an automatic verdict. A key whose observed service differs from its purpose deserves investigation, but the mismatch is not by itself proof of misuse. And a key whose purpose is vague—“automation,” “production,” “do not delete”—has disclosed that the organization has not yet made a reviewable claim.

The field therefore should not be sold as a security lock. Free text cannot stop a key from performing an authorized operation. It cannot make the secret expire, bind it to a source network, prove who copied it, require a second factor or narrow its POC authority. ARIN has separate public records for those questions. ACSP 2011.17 asks for per-key restrictions by action and POC. ACSP 2024.1 asks for stronger controls such as source-network limits or expiry. A 2024 consultation addressed header transport and IP-range bounding. Those are enforcement and exposure controls. Purpose labeling is evidence for inventory, review and decision.

Calling the label “only metadata” would miss how operational risk is managed. A register is useful because it makes a later decision cheaper and more defensible. When purpose is absent, deactivation becomes a wager: remove the credential and perhaps interrupt a service; retain it and perhaps preserve unnecessary authority. The uncertainty rewards delay. A description cannot resolve the decision alone, but it can turn an archaeological exercise into a testable question.

ARIN has moved the surrounding control plane

The open description request has not sat beside a frozen system. On 28 July 2026, ARIN shipped two adjacent changes. It began accepting API credentials in an authorization header as the preferred alternative to putting them in a URL, and it removed the account-creation restriction that had prevented non-human service accounts. The first change closed a credential-transport suggestion. The second closed ACSP 2022.11.

Both are material. Keeping a secret out of a URL reduces avoidable exposure in logs and intermediaries. Accepting a non-human principal lets an organization stop pretending that a durable automation identity is a particular employee. ARIN’s current Reg-RWS quick-start guide now marks the header method as recommended, while still documenting the URL method as supported.

Neither change supplies purpose evidence.

A service account answers who or what authenticates, at least at the account layer. It does not distinguish the intended job of two keys issued by that account. Header transport answers where the secret travels inside a request. It does not say why the credential exists. A Role POC shapes the authority inherited by the creating user. It does not record which automation was meant to exercise that authority. These controls are complementary precisely because they solve different questions.

This separation is also why the description request deserves more than a one-line text box. If ARIN adds a label but does not preserve its history, display it at review or join it to activity, the interface will collect prose without producing much evidence. A mutable label could be rewritten after an incident or staff change, leaving no way to tell what purpose was declared when a credential was issued or used. A label that appears only on the creation screen would disappear from the very decisions it is meant to support. A label that cannot be searched or exported would leave larger organizations rebuilding an inventory by hand.

The useful product is not a prettier row. It is a small lifecycle record.

A credential-purpose receipt

ARIN should turn the key description into the first field of a versioned credential-purpose receipt. The receipt need not expose the secret and need not reveal a customer’s internal system names to the public. It should remain inside the authenticated management surface and be available to the people who can govern the relevant account or organization.

At minimum, the record would contain:

  1. the key prefix or another stable, non-secret identifier;
  2. a required purpose label, with optional structured tags for Reg-RWS, RPKI, IRR, DNSSEC, reverse DNS or report access;
  3. the issuing human or service principal and the POC or organization context from which authority is derived;
  4. creation time, last-used time and the last observed service or action class, where ARIN can report them safely;
  5. the person or role responsible for the next review, and a review date chosen by the customer;
  6. a history of label changes, with actor and timestamp;
  7. deactivation time, reason and confirmation; and
  8. an explicit notice that descriptive purpose does not grant, remove or constrain permission.

The last-used and service-class fields matter because declarations decay. A key labeled “monthly report download” that has recently modified a network record presents a different review question from one that downloaded the expected report. The system need not declare either use malicious. It only needs to make the divergence visible to an authorized reviewer.

Change history matters for the same reason. If a key begins as a migration credential and later becomes routine production automation, the right response may be to issue a new key, or it may be to document an approved change. Either way, overwriting “migration” with “production” destroys the evidence needed to understand the transition. An append-only history preserves the difference between an original purpose and a later decision.

Deactivation evidence closes the loop. ARIN already documents how to deactivate a key. A mature receipt would show when the action occurred and which purpose was retired, so an organization could match the registry-side decision to removal from its secret store and software. It would not claim the secret has vanished from every copy. It would prove that ARIN will no longer accept that credential.

ARIN could let organizations keep sensitive deployment detail in their own systems. A label such as “RPKI publication—primary” may be enough on the registry side if the internal inventory holds the host, repository and on-call team. The important join is the stable key identifier. Without it, the two inventories can describe the same authority in terms that cannot be reconciled.

What a public disposition should say

ACSP pages are more valuable when closure states the observable product result. For suggestion 2023.15, a useful disposition would say more than “implemented.” It would identify where the description is entered and displayed; whether it is required for new keys and optional for existing ones; whether it can be edited, searched and exported; whether history is retained; which roles can view or alter it; and whether activity views expose the same stable key identifier.

If ARIN decides not to build the feature, the public record should say that as well and explain the operational alternative it expects customers to use. Perhaps ARIN concludes that descriptions belong in customer credential managers, with its interface providing only an immutable identifier and activity export. That would be a defensible boundary if the identifier and export make the external join reliable. Silence is less useful because it leaves customers unable to tell whether the public promise remains queued, has changed shape or has been displaced by surrounding work.

The evidence in this article does not establish a breach or a population of stale ARIN keys. It does not measure how many customers operate multiple credentials, how often they are rotated or whether anyone has delayed deactivation because a purpose was unknown. The risk mechanism is institutional: an inventory that cannot state purpose makes review more expensive, and expensive review tends to be deferred. The remedy is to make the intended use reviewable without pretending that intent is enforcement.

Sources