[Use Case] Silent model substitution by an intermediary

1. Identification

Title: Silent model substitution by an intermediary
Submitting organization: Himalogic Software Pvt. Ltd. (Lalitpur, Nepal)
Contact name: Justin Philip Flores
Contact email: justin@himalogic.com.np
Sector:

• [ ] Education
• [ ] Health
• [ ] Financial services
• [ ] Telecom
• [ ] Logistics
• [ ] Energy
• [ ] Critical infrastructure
• [ ] Smart home / IoT
• [x] Other (specify): Cross-sector. General-purpose inference services are consumed in every sector listed; the documented instances involved government, public-security and enterprise users [1].

2. The situation

Plain language description (required, 3 sentences max): A user sends a request to a provider they believe is serving model X, through a client they control. An intermediary in the path forwards the request to a different provider serving model Y and returns Y's output presented as X, in one documented case only for requests matching a fingerprint of the user's client software. The user has no independent means of detecting this, and a public report dated 2026-09-10 documents three instances involving two model developers and one reseller [1].

Actor: An end user, human or automated, issuing inference requests through a client or agent harness under their control, to a provider whose model they have selected.

Action: The user submits a request containing task content, which in documented cases included live credentials, internal corporate data, and surveillance material, expecting it to be processed by the named provider's model.

Problem encountered: An intermediary (in two documented cases the advertised provider itself, in one a reseller acting in the provider's name) relayed the request to a different provider under credentials the user never supplied, returned that provider's output as its own, and in some cases retained the exchange. Roughly 300,000 requests were relayed by one developer over ten days [1, GTG-16002]. A second developer inspected inbound requests for string patterns identifying the user's harness and relayed only matching traffic [1, GTG-16001]. A reseller sold discounted access to a named model while proxying to a different one [1, GTG-50021]. Documented consequences include live credentials for a government database and surveillance analysis of a tracked individual reaching a foreign provider without the user's knowledge [1, GTG-16001, GTG-16002]. The serving provider states it does not know whether the users were informed [1, GTG-16002].

Current mitigation: Transport security, which authenticates the intermediary's endpoint and nothing about the payload's origin. Provider-side abuse detection on the serving provider's traffic (account metadata heuristics and classifiers), which acts after the fact by account ban and cannot see the user's belief about origin. Terms of service and disclosure obligations, which bind the intermediary.

Residual gap: The only party able to attest to a response's origin is the serving provider, and today it attests to nothing that survives a hop. No published record states which endpoints are authorized to serve which models. A client therefore cannot distinguish a response served by the provider it contacted from one relayed through that provider from somewhere else, and the disclosure obligation on the intermediary is unverifiable by the party it protects. Because one documented instance conditioned its behavior on the identity of the calling software [1, GTG-16001], no sampling-based check of the advertised provider can close this gap: any probe that does not present the fingerprint the intermediary is keyed to sees honest service, and the serving provider sees only relayed traffic with no view of what the user was told. Detection must therefore be available on every response, at the client, without the path's cooperation.

3. Actors and context

Taxonomy roles involved

• [ ] Builder
• [x] Deployer / Owner
• [x] Agent instance
• [x] User
• [x] Infra provider
• [x] Attestor: no party performs this role today; the use case is that it is unfilled. Requirement 2 assigns it to the serving provider.
• [x] Other (specify): Intermediary (proxy, router, reseller, or the advertised provider relaying to another).

Cross-border?

• [x] Yes — jurisdictions involved: Documented instances relayed requests originating from users in the PRC, Russia, and, via third-party routing services, the US and EU to a US-based serving provider without the users' knowledge [1].
• [ ] No

Embodied (physical actuation or sensing)?

• [ ] Yes — physical context:
• [x] No

Agent action type (required)

• [ ] Read-only
• [ ] Consequential (reversible)
• [x] Irreversible

Disclosure of request content to an unintended party, and its retention for training or resale [1, GTG-16002, GTG-16003, GTG-16008], cannot be recalled.

Crosses organisational boundary? (required)

• [x] Yes (specify): The request leaves the advertised provider's organization for the serving provider's. In the reseller variant it leaves the reseller's for the serving provider's. In the shell-company variant [1, GTG-16003] the boundary was deliberately concealed.
• [ ] No

Risk level (required)

• [ ] Low
• [ ] Medium
• [x] High

4. Theme relevance

5. Requirements

6. Assessment criteria

Success criteria: A client that asked provider A for model X can, from the response and published material alone, reach one of four determinations before rendering: (a) served by A from a registered endpoint; (b) served by A, relayed through an unregistered endpoint, endpoint reported; (c) served by a provider or model other than the one requested, substitution on the face of the response; (d) no attestation present where policy expects one. Today none of the four is reachable; all 300,000 relayed exchanges in [1, GTG-16002] were indistinguishable from case (a) to the user.

Measurable metric: Fraction of responses for which a conforming verifier reaches a determination without contacting the provider (target: 1.0). False-attribution rate on frozen negative test cases (target: 0; three candidate cases in Supporting notes below). At population scale, per-provider rate of relayed and downgrade findings, which is the observable that makes the documented behavior visible in aggregate rather than one account ban at a time.

7. Duplication check

Existing standards or SDOs:

ITU-T SG17, directly overlapping:
- XSTR.llmp-tip, Technical Report: LLM token-level inference provenance (Q16/17; under study, Agreement track; registered 2026-06-10).

ITU-T SG17, adjacent:
- X.aaia-sec, Security framework and technical requirements for autonomous AI agents (Q16/17).
- X.S-AIAI, Security framework and requirements for invocation by AI agent (Q16/17).
- X.Max-trust, Multi-party, agentic and extensible trust framework for agentic-AI-enabled telecommunication networks (Q16/17).
- XSTR.magAI-behavior, Technical Report: Capabilities for agentic AI security and trust controls (Q16/17).
- X.rg-dis, Data interaction security in training and inference stages of generative AI (Q16/17).
- X.LLMCC, LLM data security based on confidential computing (Q16/17; liaisons IETF RATS, TEEP).
- X.fr-SGAI, Functional requirements for security gateway for AI application services (Q7/17).
- X.2213 (ex X.sg-GenAI), Security guidelines for generative AI application service (Q7/17; determined 2026-06).
- X.dpidm-aAI, Terminology and design guidelines for agentic AI identity management (Q10/17).
- X.aiidm, Canonical agentic AI identity data model (Q10/17; liaisons include W3C DID/VC, IETF OAuth, Linux Foundation A2A).
- XSTR.id-AA-dis, AI agent identity management using DIDs and VCs (Q10/17); X.AIA-dii-req, DLT-based decentralized identity interoperability across AI agents (Q10/17).
- X.AIssc-sm, AI system supply chain security management for telecommunications organizations (Q10/17).
- X.te-consent, Framework for trust enhancing consent management (Q1/17).

ITU-T SG17, background: X.2211 (ex X.sr-AI), Security requirements for AI systems (Q16/17; determined 2026-06); X.1254rev, Entity authentication assurance framework (Q10/17).

Other SDOs:
- IETF, draft-flores-airp-provenance-00 (proposer's own; see Section 9). Specifies rows 2 to 7 with test vectors.
- IETF RFC 9421, HTTP Message Signatures.
- IETF RFC 6376 (DKIM) and RFC 7208 (SPF), electronic mail authentication.
- IETF RFC 9334, RATS architecture.
- C2PA, content credentials.
- W3C Verifiable Credentials; W3C PROV-DM.

Overlap notes:

XSTR.llmp-tip is the nearest item. On its public summary it specifies token-level provenance primitives, an inference provenance graph, token genesis records, and inference attestation procedures for verifiable presentation to relying parties, anchored to EU AI Act Article 50, C2PA, W3C PROV-DM and ISO/IEC 42001 Annex A.7. It answers how an output was produced, at token granularity, for a relying party the provider presents it to. This use case asks a prior and coarser question, whether the response reached the client from the provider and model the client asked for, and answers it from the client's position with three things llmp-tip's summary does not describe: a published register of authorized serving endpoints (row 3), verification that needs no cooperation from any party in the path (row 4), and named non-refusing findings for relay and downgrade (rows 5 and 6). A provenance graph does not establish that the contacted endpoint was authorized to serve the model and does not address an honest attestation relayed by a dishonest intermediary. Where an llmp-tip attestation is detached from content, survives relay, and is checkable against a register, it would satisfy row 2. The proposer treats the two as a layering question, not a conflict, and will raise it with the llmp-tip editor.

Of the adjacent items, X.aaia-sec and X.S-AIAI are the natural homes for rows 2 to 6 should SG17 take them up; the fingerprinted variant described in Section 2 is an invocation-path attack in X.S-AIAI's terms. X.fr-SGAI specifies a gateway, which is an intermediary in this use case's terms, and row 8 belongs there if the group agrees it is needed. X.2213 covers the application services the reseller and relaying developers described in Section 2 operate; row 1's disclosure obligation is a candidate guideline there, and X.te-consent is the consent counterpart. X.LLMCC and RFC 9334 attest the serving platform; that composes with row 2 (platform attestation says the provider runs what it claims, response binding says this response came from that provider) and neither alone addresses relay. X.Max-trust, XSTR.magAI-behavior and X.rg-dis are system-level trust, control-plane and inference-data texts to which the findings in rows 5 and 6 are inputs. X.dpidm-aAI and X.aiidm fix terminology and an identity data model; "serving provider", "advertised provider" and "intermediary" as used here will be reconciled with them, and register identifiers should be expressible in the X.aiidm model. XSTR.id-AA-dis and X.AIA-dii-req establish who an agent is and what it may do, which this use case assumes; identity is a precondition for attribution of output, not a substitute for it. X.AIssc-sm covers the operator-side supply-chain view of the shell-intermediary pattern [1, GTG-16003]. X.2211 and X.1254rev are foundational texts the requirements here are intended to be consistent with.

RFC 9421 signs HTTP messages between adjacent parties and does not bind model identity or survive a hop through a relaying intermediary; the proposer's draft addresses this relationship in its Section 5. DKIM and SPF are the direct design ancestors (detached signature over content; published list of authorized senders) and are cited as such; they do not apply to inference responses. C2PA binds provenance to media assets, not to inference responses, and its manifests are routinely stripped by intermediaries. Verifiable Credentials attest claims about a subject and do not bind an output to the party that produced it; PROV-DM is a data model, not a binding mechanism.

No identified SDO work specifies a client-verifiable, relay-surviving binding of an inference response to provider, model, and authorized serving endpoint with named findings for relay and downgrade. The SG17 list above was compiled from the public work programme on 13 September 2026 and does not cover every Q16/17 and Q10/17 item; the proposer will amend this section if FG-TIDA participants identify overlapping items.

8. Maturity

Pilot status

• [ ] Hypothetical
• [x] Pilot in progress
• [ ] Deployed in production

Reference implementation: https://github.com/AIRP-spec/inference-advocate (Apache 2.0); public verifier instance at https://tryairp.com

9. IP and confidentiality

Confidentiality level

• [x] Public
• [ ] FG-internal only
• [ ] Redact before publication

IP notes (optional): The referenced Internet-Draft carries an IPR disclosure. The specification is offered royalty-free. The reference implementation is Apache 2.0. A provisional patent held by the proposer covers client-side delivery-gating mechanisms not required by rows 2 to 7 and is disclosed in the draft. Requirements in Section 5 are derived from the documented incident and are intended to stand independently of the proposer's specification.

10. Assets

Link to assets:

• [ ] Dataset
• [x] Code: https://github.com/AIRP-spec/inference-advocate
• [x] Protocol: draft-flores-airp-provenance-00, "The AIRP Provenance Seal and Serving Register," IETF Internet-Draft, August 2026
• [x] Other: Incident basis, Anthropic, "Detecting and countering misuse of AI: September 2026," 2026-09-10, cyber operations section (GTG-50021) and illicit distillation section (GTG-16001, GTG-16002, GTG-16003, GTG-16008). https://www.anthropic.com/threat-intelligence-report-september-2026

IP notes (optional): As Section 9.

Supporting notes (supplementary, not part of the template)

Why rows 5 and 6 are both needed. Given a client that asked A for X, a dishonest intermediary holding a response B sealed honestly has three options, and each is visible under rows 2 to 6:

Only the third path is available to an honest intermediary, and only the third path exposes a dishonest one. A verifier that refuses relayed attestations leaves the intermediary with nothing to relay and the substitution undetectable.

Candidate frozen negative test cases (for the test-vector work in the themes repo):

1. Response from endpoint E, E not in A's register, no attestation, policy expects one. Expected: downgrade finding, response unattributed.
2. Response from endpoint E, E not in A's register, attestation claims entry B while the client contacted A. Expected: refusing finding (seal_entry_mismatch) reporting the claimed entry, no attribution, endpoint E reported. The verifier never attributes from the response; the entry is selected from the provider the client intended to contact.
3. Response from endpoint E, E in A's register, attestation validates against A, request digest differs from the request sent. Expected: attribution to A, request-modified finding, distinct from all other findings.

Out of scope for this use case. A compromised client (the credential harvester in [1, GTG-50021] is an example): if the user's own software is the adversary, no wire-level mechanism helps. An operator who knowingly routes through an intermediary to evade provider controls: not the principal this use case protects, though rows 2 and 3 make that routing visible to the serving provider as a side effect. Content evaluation: whether a response is safe or accurate is a separate question from whether it came from where the user believes. Retention and resale of relayed exchanges: documented in [1] and consequential, but a distinct use case with a distinct requirement set; row 8 is the seam between the two.

[1] Anthropic, "Detecting and countering misuse of AI: September 2026," published 2026-09-10.