Network Working Group S. Faibish Internet-Draft Independent Intended status: Informational 24 July 2026 Expires: 25 January 2027 The Case for an IETF Working Group on Large Language Model Security and Interoperability draft-faibish-llm-security-interop-00 Abstract Large Language Models (LLMs) are now accessed as network services by a large and growing number of applications, yet the way they are invoked, secured, described, and attributed has coalesced around vendor-specific and de facto interfaces rather than open, neutral standards. The most consequential gap is in security: there is no common, analyzable model for authenticating to an LLM service, authorizing tool invocation, protecting and attributing output, or reasoning about the trust boundary an LLM sits on. These models also sit directly on top of network storage: LLM training data, model checkpoints, and retrieval corpora are routinely served from NFSv4 and pNFS, so the security, provenance, and access-control questions raised here have concrete NFSv4-facing consequences. This document argues that uniting the multitude of competing LLMs behind a common, secure, interoperable interface is fundamentally the kind of problem the IETF exists to solve, and it makes the case for chartering a new IETF Working Group. It sets out the problem with security as the central motivation, describes the interaction with NFSv4 and network storage, records the initial expressions of interest that any such effort must be able to show, proposes a candidate scope with concrete deliverables and explicit non-goals, addresses the principal objections, and describes the intended path to chartering through a Dispatch presentation or a Birds-of-a-Feather (BOF) session. This document is Informational and defines no protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 25 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction 2. Terminology 3. Problem Statement 3.1. Security Is the Central Gap 3.2. Fragmentation of the Inference Interface 3.3. Absence of Neutral Capability Description 3.4. Weak and Proprietary Output Provenance 3.5. Aggregate Cost 4. Why This Belongs in the IETF 5. Interaction with NFSv4 and Network Storage 6. Expressions of Interest 7. Existing Work and the Gap 8. Proposed Scope and Candidate Deliverables 8.1. Deliverable 1: Interoperable Inference API and Wire Format 8.2. Deliverable 2: Security and Trust Framework 8.3. Deliverable 3: Model Capability and Metadata Description 8.4. Deliverable 4: Output Provenance and Integrity Signaling 9. Non-Goals 10. Objections and Responses 11. Relationship to Other Standards and IETF Working Groups 12. Path to Chartering 13. Why Now 14. Security Considerations 15. IANA Considerations 16. References 16.1. Informative References Author's Address 1. Introduction Over a short period, Large Language Models (LLMs) have become infrastructure. Applications invoke them over the network for generation, classification, extraction, retrieval augmentation, tool orchestration, and agentic control. In architectural terms an LLM is now a widely deployed network service accessed by many independent clients across administrative and organizational boundaries -- the canonical setting in which interoperability and security matter, and in which the IETF has historically produced standards. Despite this, the interfaces to LLMs have not been standardized in an open, vendor-neutral venue. A handful of provider-specific HTTP APIs dominate; one of them has become a de facto reference that other providers emulate with partial and inconsistent fidelity. Each provider secures, describes, and attributes its service in its own way. There is no common way to authenticate to a model service, to authorize the tools a model may invoke, to bind output to the invocation that produced it, or to reason about the trust boundary an LLM sits on. These services also do not sit above an empty storage layer. The data LLMs are trained on, the checkpoints they emit, and the corpora they retrieve from are increasingly served from network file systems, NFSv4 and pNFS prominent among them; recent NFSv4 work is explicitly motivated by machine-learning checkpointing and high-performance- computing pipelines. The security and provenance questions raised here therefore meet the file-access protocol at several concrete seams, developed in Section 5. The motivation for this document is twofold and, in the author's view, primarily about security: to unite the multitude of competing LLMs behind a common, interoperable interface, and to standardize the security properties of that interface so that relying parties can reason about them uniformly. The topic is already under active discussion in the wider community, and the position taken here is that the IETF should be part of that discussion rather than inheriting whatever single-vendor conventions emerge by default. This document does not propose a protocol. It argues that the fragmentation described above is an interoperability and security problem within the IETF's remit and competence, and it proposes that the IETF charter a Working Group -- referred to here by the placeholder name LLM Security and Interoperability (LLMSI). It offers a candidate scope, deliverables, and non-goals as a starting point for a Dispatch presentation or a BOF. 2. Terminology Large Language Model (LLM): A machine-learning model that accepts a sequence of tokens as input and produces a sequence of tokens as output, typically exposed to clients as a network service. The term is used broadly to include multimodal models. Inference API: The application-layer interface, typically carried over HTTP, by which a client submits a request to an LLM service and receives a response, including streaming, tool-invocation, security, and error semantics. Capability description: A machine-readable description of a model's identity, version, supported modalities, context limits, exposed controls, and security properties relevant to a client's decision to use it. Output provenance: Verifiable information associating a span of generated content with the model, service, or invocation that produced it. Relying party: An entity that consumes an LLM's output, or a security or provenance signal about that output, and makes a decision on the basis of it. The terms are used descriptively; a chartered Working Group would define normative terminology in its own documents. 3. Problem Statement 3.1. Security Is the Central Gap Each LLM provider today defines its own authentication scheme, its own authorization model for tool and function invocation, its own handling of the trust boundary between prompt content and instructions, and its own (or no) mechanism for attributing and integrity-protecting output. A relying party integrating several providers must therefore reason about several distinct and largely undocumented security models, with no common vocabulary and no interoperable controls. The consequences are concrete. Authentication and credential handling differ per provider, so uniform policy enforcement is not possible. Tool-invocation ("function calling") crosses a privilege boundary -- model output causes actions -- yet there is no standard authorization model for it, and prompt-injection attacks exploit exactly this boundary. Output cannot be bound to its origin in a verifiable way, undermining accountability and abuse mitigation. And because none of this is specified in an open venue, none of it receives the adversarial, cross-vendor review that security mechanisms require. Standardizing these properties is the primary motivation for the proposed Working Group. 3.2. Fragmentation of the Inference Interface Clients that wish to remain portable across LLM providers write and maintain per-provider adapters, or depend on a single provider and accept the resulting lock-in. Even where providers advertise compatibility with a common de facto interface, the compatibility is partial: request and response fields, streaming framing, tool-calling schemas, error taxonomies, rate-limit signaling, and content-part representations diverge in ways that surface as runtime failures rather than clean negotiation. There is no versioned, extensible, independently specified wire contract and no capability-negotiation mechanism. 3.3. Absence of Neutral Capability Description A client selecting among models, or a gateway routing among them, needs to know each model's identity, version and deprecation status, modalities, context limits, exposed controls, and security properties. This information is published today in prose and provider-specific JSON of inconsistent shape. There is no interoperable, machine-readable capability description a client can fetch and reason about, and hence no basis for automated portable model selection or reproducible cross-party references. 3.4. Weak and Proprietary Output Provenance As generated content propagates through documents, messages, storage, and downstream systems, relying parties increasingly need to determine whether, and by what, a span of content was produced. Existing provenance efforts are either media-format specific or operate outside the invocation path, and no open, interoperable, integrity-protected signal binds an LLM invocation to its output in a way a relying party can verify -- least of all after the output has been written to durable storage and read back. 3.5. Aggregate Cost Individually these gaps are inconveniences; in aggregate they impose a structural tax and, more importantly, a diffuse security liability. Integrators duplicate adapter and security-glue engineering across the industry; portability accrues only to those able to build abstraction layers, entrenching incumbents; tooling must special-case each provider; and trust decisions are pushed onto out-of-band, non- interoperable channels. These are the recognizable symptoms of a missing, and insecure, interoperability layer. 4. Why This Belongs in the IETF The problems in Section 3 are security and interoperability problems at and above the application layer: a request/response protocol with negotiation and error semantics, an authentication and authorization model, a machine-readable description format, and verifiable signaling. This is the IETF's core competence. The IETF has repeatedly standardized the secure, interoperable interface to a diverse and competitive set of implementations without standardizing the implementations themselves -- mail transfer, the Web's transport and security protocols, real-time media, network file systems, and authorization are examples where a common protocol coexists with vigorous implementation competition. A secure LLM inference API is directly analogous: the goal is a common and secure way to talk to models, not a common model. The IETF also offers properties this problem needs: a vendor-neutral process with an established intellectual-property and change-control regime; a culture of running code, interoperability testing, and adversarial security review; and existing, reusable building blocks -- HTTP, TLS, structured data formats, media types, URIs, network file-system protocols, and established authentication and authorization machinery -- on which a secure LLM interface would be built rather than reinvented. 5. Interaction with NFSv4 and Network Storage LLMs are among the most demanding consumers and producers of data on network file systems. Training corpora, model checkpoints, retrieval- augmentation (RAG) corpora, and inference inputs and outputs are routinely stored on and served from NFSv4 [RFC7862] and Parallel NFS (pNFS) [RFC8881] deployments; recent NFSv4 work, including the pNFS flexible-file layouts [RFC8435], is explicitly motivated by machine- learning checkpointing and high-performance-computing pipelines. The interface this document proposes therefore sits directly on top of NFSv4, and several of its deliverables have concrete NFSv4-facing consequences. This section is not a proposal to change NFSv4; it identifies the seams at which the two efforts meet and would need to coordinate. Data integrity and provenance. The output-provenance and integrity signal (Section 8.4) is most useful if it survives storage: a provenance binding produced at inference time should remain verifiable after the content is written to and re-read from an NFSv4 file, and should compose with the file system's own integrity mechanisms rather than duplicate them. Coordinating the provenance signal with NFSv4 data-integrity work -- for example, the per-chunk checksum and repair mechanisms being developed for pNFS flexible-file layouts -- would let a relying party reason about content authenticity end to end, from model output through durable storage and back. Access control and the agentic trust boundary. Agentic and tool- invoking LLMs increasingly perform file operations on a user's behalf, which turns the tool-invocation authorization model (Section 8.2) into a file-access authorization question. When an LLM service reads or writes NFSv4-served files as a proxy for a user, it raises the same forwarded-credential and trust-boundary problems that pNFS already confronts in its control and data planes, and it must compose with NFSv4 access control, including Mandatory Access Control via Labeled NFS [RFC7204]. A security model that ignores the storage layer would leave a gap precisely where model-triggered actions become durable side effects. Data description and locality. Capability description (Section 8.3) and NFSv4 data-placement and layout mechanisms both describe where and how data lives; AI data pipelines that span model services and pNFS storage benefit when the two descriptions can be reasoned about together rather than bridged by bespoke glue. For these reasons the NFSv4 Working Group is a natural early audience and coordination partner for this work, and this draft is being raised there. The intent is coordination, not overlap: the proposed Working Group would standardize the model interface and its security, while the NFSv4 Working Group continues to own the file-access protocol; the two would liaise on the integrity, provenance, and access-control seams where they meet. 6. Expressions of Interest A recurring and reasonable first question about any such effort is whether the LLM providers themselves have any interest in it; if the answer is no, the work will not progress. The proposal recorded here arises from discussion in the community in which the need was raised and the standard chartering paths -- convincing the responsible Area Directors, requesting a BOF, or bringing a problem-and-solution draft to a Dispatch session -- were identified. At the time of writing, preliminary and informal expressions of interest have been received from participants associated with LLM providers, including Claude.ai (Anthropic) and DeepSeek, both of which responded positively to the idea of open standardization in this space. These are early signals rather than commitments, and a central objective of a Dispatch presentation or BOF would be to test the breadth of provider and integrator interest before a Working Group is chartered. Broadening this base of support -- across model providers, gateway and tooling vendors, large integrators, and the network- storage community whose deployments carry AI data -- is an explicit prerequisite the author intends to pursue. 7. Existing Work and the Gap Considerable relevant work exists, which is a strength rather than an argument against standardization; it demonstrates demand and supplies prior art. De facto inference APIs are widely emulated but are single- vendor artifacts under unilateral change control. Emerging conventions for tool and context exchange address the model-to-tool direction but not a negotiated, authenticated client-to-service contract. Model-exchange formats and model-card conventions address packaging and documentation but not a live capability-description protocol. Content-provenance and content-credential frameworks address media authenticity but are not bound to the LLM invocation path or to the storage layer. Broader governance and risk frameworks address policy and process rather than wire security and interoperability. The gap is specific and consistent: none of these is an open, vendor- neutral, versioned, independently specified security and interoperability standard for invoking an LLM, securing that invocation, describing the model, and attributing its output. That gap is what a chartered Working Group would fill, referencing and profiling existing work wherever possible rather than displacing it. 8. Proposed Scope and Candidate Deliverables The following is a starting point for charter discussion, not a fixed program. A prudent Working Group would sequence these, with the inference API and the security framework as the leading items. 8.1. Deliverable 1: Interoperable Inference API and Wire Format A versioned, extensible, HTTP-based protocol for submitting an inference request and receiving a response: request and response structure, streaming framing, multimodal content representation, tool-invocation request/response semantics, a common error taxonomy, and a capability-negotiation mechanism so that client and service agree on a supported feature set before exchanging payloads. 8.2. Deliverable 2: Security and Trust Framework The central deliverable. A common security model for the interface, including: authentication of clients to services and of services to clients; an authorization model for tool and function invocation that treats model-triggered actions as privilege-boundary crossings, and that composes with the access control of any resources those actions reach, including network-file-system access control and Labeled NFS [RFC7204]; transport-security profiles and requirements; integrity protection of requests and responses; a documented trust model distinguishing instruction content from data content to give injection resistance a place to attach; and machine-readable expression of a service's security posture so relying parties can enforce policy uniformly. 8.3. Deliverable 3: Model Capability and Metadata Description A machine-readable format and retrieval mechanism by which a service describes a model's identity, version and deprecation status, modalities, context limits, exposed controls, and security properties, enabling portable and automatable model selection and stable cross-party references. 8.4. Deliverable 4: Output Provenance and Integrity Signaling An interoperable, verifiable, integrity-protected signal binding a span of generated content to the model, service, or invocation that produced it, usable by a relying party independent of media format, designed to remain verifiable after the content is written to and read back from durable storage such as NFSv4, and profiling existing content-provenance work where applicable. 9. Non-Goals Explicit non-goals are as important as scope for a tractable charter. The proposed Working Group would NOT attempt to: * standardize model internals, architectures, weights, or training data or process; * define or adjudicate model quality, safety policy, acceptable-use policy, or content-moderation rules; * establish benchmarks or certify or rank models; * regulate pricing, commercial terms, or business models; * redefine or extend network file-access protocols such as NFSv4, which remain with the NFSv4 Working Group and with which this effort would coordinate; or * mandate that any provider expose any particular model. The effort is confined to the secure, interoperable interface to LLMs, not to the models, the storage systems beneath them, or the policies governing their use. 10. Objections and Responses In the interest of an evenhanded case, the principal objections are stated with the responses their proponents would give; the Working Group discussion should weigh them on the merits. "It is premature; the field changes too quickly." The response is that the interface has already stabilized enough to be emulated industry-wide; an extensible, versioned protocol absorbs change rather than freezing the field, and standardizing the security and negotiation envelope is compatible with rapid evolution of what is negotiated. "De facto standards already suffice." The response is that a single- vendor interface under unilateral change control is not a standard in the interoperability sense, offers no neutral security review, and structurally advantages its owner. "This is an application concern, not a networking concern." The response is that the IETF's application-layer, security, and storage remit is long-established, and the deliverables are protocol, security, and signaling work of exactly the kind the IETF produces. "The IETF lacks machine-learning expertise." The response is that the work requires protocol, interoperability, and security expertise, not model-building expertise; the non-goals deliberately exclude ML- internal questions, and subject-matter input would be sought through liaisons and participation. "Do the providers care?" The response is Section 6: early positive signals exist, and demonstrating broader interest is treated as a prerequisite rather than an afterthought. 11. Relationship to Other Standards and IETF Working Groups The proposed scope complements, not competes with, work elsewhere. Within the IETF, the NFSv4 Working Group is the most immediate coordination partner, for the storage seams described in Section 5; groups working on HTTP, authentication and authorization, and content provenance own building blocks the effort would reuse. Outside the IETF, model-packaging and documentation conventions, content- provenance frameworks, and AI governance and risk-management frameworks each address adjacent concerns. A chartered Working Group should establish liaisons as appropriate, reference external specifications where they are stable and suitable, and coordinate boundaries so that the secure inference interface, capability description, and provenance signal fit cleanly against neighboring work -- in storage and elsewhere -- rather than overlapping it. 12. Path to Chartering This document is intended to support the standard routes to forming a new Working Group: engaging the responsible Area Directors, requesting a BOF at an upcoming IETF meeting, and presenting a problem-and- solution draft at a Dispatch session. The author intends to bring this draft to Dispatch and, in parallel, to raise it in the NFSv4 Working Group as a first technical audience and to broaden the base of provider and integrator interest described in Section 6. Feedback on scope, deliverables, and non-goals is explicitly solicited and will be folded into subsequent revisions ahead of any charter proposal. 13. Why Now The conditions for successful standardization are present at once: broad deployment across organizational boundaries creates genuine interoperability and security demand; enough convergence has occurred that a common contract is feasible; multiple independent implementations exist to validate interoperability; AI workloads are already reshaping the network-storage layer that carries their data; early provider interest has been expressed; and the costs -- and security liabilities -- of continued fragmentation are compounding. Acting while the interface is convergent but not yet ossified around a single vendor's artifact is more tractable than acting after lock-in has hardened. 14. Security Considerations This document defines no protocol and so introduces no direct protocol security considerations. Security is, however, the primary motivation for the proposed work, and a chartered Working Group would treat it as a first-order concern throughout. On the improvement side, a common interface enables consistent application of transport security and mutual authentication, a shared authorization model for tool invocation, uniform and analyzable error and rate-limit signaling, and a neutral, integrity-protected output- provenance mechanism supporting accountability and abuse mitigation. On the risk side, a widely adopted interface is a widely adopted attack surface; authentication, capability-description, and provenance mechanisms are attractive targets for spoofing and must be designed with explicit threat models, verifiability, and appropriate use of authentication and integrity protection. Prompt-injection and tool- invocation pathways raise authorization concerns that any tool-calling semantics must address at the trust boundary between instruction and data content -- especially where those actions read or write data on network file systems and thereby become durable side effects that must honor the storage layer's own access control, including Labeled NFS [RFC7204]. Provenance signaling carries privacy implications whose unlinkability, minimization, and misuse properties require deliberate design. These considerations argue for, rather than against, doing the work in an open venue with adversarial review. 15. IANA Considerations This document has no IANA actions. Protocol work undertaken by a chartered Working Group would be expected to define its own registries -- for example, media types, authentication and capability identifiers, error codes, and provenance signal types -- in the relevant protocol documents. 16. References 16.1. Informative References This Informational document does not rely on normative references. The IETF network-file-system specifications below are cited because Section 5 discusses the interaction with NFSv4 directly; other prior art is referenced descriptively rather than by citation, and a chartered Working Group would supply precise references as part of its deliverables. The categories referenced descriptively are: de facto vendor inference APIs; model-to-tool and context-exchange conventions; model-exchange formats and model-card documentation conventions; content-provenance and content-credential frameworks; and AI governance and risk-management frameworks. [RFC7204] Haynes, T., "Requirements for Labeled NFS", RFC 7204, DOI 10.17487/RFC7204, April 2014, . [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, November 2016, . [RFC8435] Halevy, B. and T. Haynes, "Parallel NFS (pNFS) Flexible File Layout", RFC 8435, DOI 10.17487/RFC8435, August 2018, . [RFC8881] Noveck, D., Ed. and C. Lever, "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 8881, DOI 10.17487/RFC8881, August 2020, . Author's Address Sorin Faibish Email: sfaibish@comcast.net