Summary

  • At ARIN 57, ARIN said generative AI was authorised only for limited drafting uses, with responsibility retained by the drafter and a second human review before publication.
  • ARIN also drew a firm boundary around confidential and sensitive information. Its public SOC 3 report lists a Generative AI Usage policy, but neither public surface describes the audit receipt joining those controls to a released version.
  • The proportionate answer is a private, audit-ready receipt and privacy-safe aggregate reporting—not an allegation that ARIN used AI on a particular page or a demand for public prompts and reviewer identities.

The most interesting sentence in ARIN’s April security discussion was not about a model. It was about custody.

Asked at ARIN 57 what role AI played in its security systems and which tools staff could use, Chief Information Security Officer Christian Johnson first said ARIN was not using AI security systems. He then described a narrow internal allowance for generative AI: authorised use cases could create drafts, but the person generating the draft had to review it and remain responsible for the content. A second person—normally a manager or cowriter—would then review it. Before something became public, Johnson said, it needed more than one set of eyes.

That is more precise than the familiar promise that a human remains “in the loop”. It specifies two review events and places responsibility on the first reviewer. It also sets a data boundary. Johnson said organisationally confidential or sensitive information was not to be used in a generative-AI system, and that no large language model should see material that was neither public nor intended for publication.

The example he offered was hypothetical: communications staff might use the tool to draft a blog before human review and eventual posting. It was not confirmation that any identifiable ARIN blog, policy document, code change or decision had been written with AI. John Curran added a related distinction between public responses, which are public data, and private ARIN or customer information, whose exposure to an external model creates a different risk. He also said ARIN had not engaged AI tools for defence.

The policy is visible; its execution record is not

ARIN’s information-security page links to a SOC 3 report as the publicly releasable version of its SOC 2 report. That report covers the RPKI Platform control period from 1 October 2024 to 30 September 2025. Its list of policies and procedural documents includes “Generative AI Usage”, says those documents are reviewed and updated annually, and describes data classification by sensitivity and impact.

The dates and scope matter. The report’s opinion concerns a period that ended months before the ARIN 57 answer, and the described system is the RPKI Platform. The report does not certify every future AI-assisted draft, nor does the live answer amend the audit report. Their legitimate connection is narrower: one public surface shows that a generative-AI policy sits within ARIN’s control environment; the later public answer explains part of the intended workflow.

What neither surface names is the receipt.

For a two-person rule to be auditable, an examiner must be able to join at least four decisions. Was the input classified as public or on a genuine path to publication? Which prompt, output or protected draft reference was reviewed? Did the responsible drafter perform the first review? Did a distinct second reviewer approve, reject or return the same version that was ultimately released?

A policy can answer what should happen. A receipt answers what did happen to this item. Without that join, assurance becomes reconstruction: version history in one system, model activity in another, comments in a third and the public release somewhere else. Each fragment may be sound while the chain remains difficult to prove.

This is not evidence that ARIN lacks such a record. Internal controls and SOC 2 evidence are often private for good reasons. Publishing prompts could reveal sensitive working material; naming reviewers could turn a control record into a personnel file; exposing model or security details could create new attack surfaces. Nor would a public “AI-assisted” badge on every document solve the problem. A badge says little about data classification, the extent of machine contribution, the quality of review or whether the labelled version matches the published one.

A receipt can stay private and still improve accountability

The useful control is compact and mostly internal. For each authorised AI-assisted draft, ARIN could retain the use-case class; the data-classification decision; protected fingerprints or references for source material, prompt and output; the tool or model boundary; the responsible drafter’s review event; the independent second-review event; material corrections; approval or rejection; the fingerprint of the released version; the retention period; and any exception.

The public layer can be aggregate. A periodic report could state how many authorised drafts entered the workflow by use-case class, how many completed second review, how many were rejected or materially revised, and how many exceptions were opened and closed. Small counts could be grouped or delayed. No confidential text, personal reviewer data or security-sensitive model detail needs to leave the control environment.

ARIN’s oral rule already contains the right instinct: responsibility should not dissolve into the tool. The next useful step is to make responsibility joinable—from permitted data, to machine-assisted draft, to two human decisions, to the version the public actually received.

Sources