Network Working Group A. Pelov Internet-Draft IMT Atlantique Intended status: Informational 2 November 2026 Expires: 6 May 2027 RICH: RESTful Interface for the Control-plane of Harnesses draft-pelov-rich-architecture-01 Abstract This document specifies the RICH (RESTful Interface for the Control- plane of Harnesses) architecture and information model. RICH provides a protocol-neutral governance, contract, qualification, and binding layer for RPC-based agent capabilities. It establishes a REST-addressable control plane for managing capability lifecycles while preserving native protocol execution in the data plane. It defines immutable capability and contract revisions, evidence provenance, connector transformation classes, compiled binding lockfiles, admission of bindings against an authorization, and runtime validation rules designed to contain drift and prevent confused deputy attacks in agentic systems. RICH does not make model behavior deterministic: it bounds what each admitted call can do, and makes every step on the connector path checkable and refusable. 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 6 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Pelov Expires 6 May 2027 [Page 1] Internet-Draft RICH Architecture November 2026 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Architectural Model . . . . . . . . . . . . . . . . . . . . . 5 3.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Evidence Adapters . . . . . . . . . . . . . . . . . . . . 7 4. Resource Identity, Digests, and Canonicalization . . . . . . 7 4.1. Stable Identifiers and ni URIs . . . . . . . . . . . . . 7 4.2. JSON Canonicalization and I-JSON Constraints . . . . . . 7 5. Capability and Contract Information Model . . . . . . . . . . 8 5.1. Capability Revision . . . . . . . . . . . . . . . . . . . 8 5.2. Contract Revision . . . . . . . . . . . . . . . . . . . . 9 5.2.1. Structural Domain . . . . . . . . . . . . . . . . . . 9 5.2.2. Representation Domain . . . . . . . . . . . . . . . . 10 5.2.3. Semantic Domain . . . . . . . . . . . . . . . . . . . 10 5.2.4. Error Domain . . . . . . . . . . . . . . . . . . . . 11 5.2.5. State Domain . . . . . . . . . . . . . . . . . . . . 11 5.2.6. Operational Domain . . . . . . . . . . . . . . . . . 12 5.2.7. Model Mediation . . . . . . . . . . . . . . . . . . . 12 6. Contract Provenance and Evidence Roles . . . . . . . . . . . 13 6.1. Provenance Kinds . . . . . . . . . . . . . . . . . . . . 13 6.2. Mapping to RATS Trust Roles . . . . . . . . . . . . . . . 13 7. Composition and Graph Closure . . . . . . . . . . . . . . . . 14 7.1. Edge Kinds . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Graph-Closure Status . . . . . . . . . . . . . . . . . . 14 7.3. Bounded Model Steps . . . . . . . . . . . . . . . . . . . 15 8. Qualification Records and SCITT Integration . . . . . . . . . 15 8.1. Lifecycle States . . . . . . . . . . . . . . . . . . . . 15 8.2. Qualification Record Format . . . . . . . . . . . . . . . 16 8.3. SCITT Attestation Profile . . . . . . . . . . . . . . . . 16 9. Connectors . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Connector Definition . . . . . . . . . . . . . . . . . . 17 9.2. Transformation Classes (T0-T4) . . . . . . . . . . . . . 18 9.3. Restricted T1 Transformation Profile (Informative Sketch) . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Binding and Lock Artifacts . . . . . . . . . . . . . . . . . 19 10.1. Binding Requirements . . . . . . . . . . . . . . . . . . 19 Pelov Expires 6 May 2027 [Page 2] Internet-Draft RICH Architecture November 2026 10.2. Lockfile Schema and Example . . . . . . . . . . . . . . 19 11. Compilation and Runtime Validation . . . . . . . . . . . . . 20 11.1. Conforming Compiler Duties . . . . . . . . . . . . . . . 20 11.2. Conforming Runtime Enforcer Duties . . . . . . . . . . . 21 12. Authorization and Admission . . . . . . . . . . . . . . . . . 21 12.1. Referencing Contracts from Authorization . . . . . . . . 22 12.2. Worst-case Bound and Admission . . . . . . . . . . . . . 22 12.3. Bounded and Dynamic Capabilities . . . . . . . . . . . . 22 13. Relationship to Workload Identity . . . . . . . . . . . . . . 23 14. Drift and Containment . . . . . . . . . . . . . . . . . . . . 23 14.1. Drift Event Schema . . . . . . . . . . . . . . . . . . . 23 14.2. Drift Policies . . . . . . . . . . . . . . . . . . . . . 24 15. Compatibility and Migration . . . . . . . . . . . . . . . . . 24 15.1. Compatibility Outcomes . . . . . . . . . . . . . . . . . 24 15.2. Migration Records . . . . . . . . . . . . . . . . . . . 25 16. Relationship to Other Work . . . . . . . . . . . . . . . . . 25 17. Security and Privacy Considerations . . . . . . . . . . . . . 25 17.1. Scope of the Guarantee . . . . . . . . . . . . . . . . . 25 17.2. Confused Deputy and Prompt Injection . . . . . . . . . . 26 17.3. Evidence Poisoning and Sandbox Execution . . . . . . . . 26 17.4. Schema Complexity Attacks . . . . . . . . . . . . . . . 26 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 19.1. Normative References . . . . . . . . . . . . . . . . . . 27 19.2. Informative References . . . . . . . . . . . . . . . . . 27 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29 Changes since -00 . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction Large Language Models (LLMs) and Small Language Models (SLMs) are increasingly composed into multi-agent systems and workflows that interact with external resources and services, termed "capabilities". These interactions occur via protocols like the Model Context Protocol [MCP], gRPC, JSON-RPC, or proprietary WebSockets and HTTP. However, capabilities evolve independently, and their published descriptors (such as OpenAPI schemas or MCP tool catalogs) provide inconsistent or incomplete evidence. Errors are frequently success- shaped payloads, schemas lack representation formats for nested strings, and models are allowed to dynamically map fields at runtime without validation. Most importantly, dynamic tool-list mutations can silently occur at runtime, exposing the execution harness to unpredicted behavior, prompt injections, and privilege escalations. Pelov Expires 6 May 2027 [Page 3] Internet-Draft RICH Architecture November 2026 RICH addresses this gap by defining a protocol-neutral, design-time qualified, and digest-pinned binding architecture. It introduces a REST-addressable control plane for managing capability lifecycles while leaving the data plane native to the underlying protocol. Crucially, RICH relocates authority from the model to the execution harness: all capability connections are compiled and validated ahead of time, and every invocation passes deterministic checks that can refuse it. The guarantee concerns the connector path, not the model. RICH bounds what each admitted call can do, but not which admitted calls a model chooses to make (Section 17.1). The underlying gap — that agent tool declarations are not contracts — is stated as a set of open questions in [I-D.pelov-bounded-agent-capabilities]. This document sketches one concrete architecture in response. Its organizing distinction is between design-time binding (compilation, qualification, and pinning, performed once when a composition is assembled) and runtime binding (validation and enforcement, performed on every invocation). Classic distributed applications resolve this binding at build time against a fixed contract; agentic systems, in which a model re-interprets a prose interface on each call, have no equivalent step. RICH reintroduces one. Agent protocols are narrowing some of these gaps. The 2026-07-28 revision of MCP [MCP] removes protocol-level sessions, recommends a deterministic tool-list order, and deprecates Sampling, suggesting that servers integrate directly with model providers instead. That last change moves model calls behind the tool interface, where a client cannot see them; Section 5.2.7 lets a contract declare them. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The following terminology is defined for the RICH architecture: Harness: The local execution environment containing the reasoning model. The Harness serves as the Reference Monitor, retaining sole authority to validate, authorize, execute, and record actions. Capability: An invocable operation exposed through a native protocol. Pelov Expires 6 May 2027 [Page 4] Internet-Draft RICH Architecture November 2026 Capability Revision: An immutable description of one interface and behavioral revision of a capability. Contract Revision: An immutable set of structural, representation, semantic, operational, and error assertions associated with a capability revision. Deployment: A concrete, addressable instance of a capability. Evidence: A declaration, source artifact, sandbox observation, test result, or signature relevant to a contract assertion. Qualification: A recorded decision, supported by evidence, that a contract or connector matches a specific profile and policy. Connector: An explicit, deterministic artifact that transforms a qualified producer output into a qualified consumer input. Binding: An immutable compile-time relationship among capability, contract, deployment, connector, qualification, and policy. Lockfile: The canonical serialized representation of a compiled set of bindings, content-addressed and digest-pinned. Drift Event: An audit record generated at runtime when a payload or endpoint violates a locked capability or contract digest. Native Protocol: The execution transport used by the capability data plane (e.g., gRPC, MCP, HTTP/REST). Bounded Model Step: A composition node in which a model selects among a closed set of declared successors, under a closed output contract (Section 7.3). Worst-case Bound: The set of operations, arguments, and effects a compiled binding can produce under any model output, computed from the pinned graph (Section 12). Admission: The decision, made before a binding is enforced, that its worst-case bound is included in the scope an authorization grants. 3. Architectural Model RICH separates capability composition and governance (the Control Plane) from native execution (the Data Plane). Pelov Expires 6 May 2027 [Page 5] Internet-Draft RICH Architecture November 2026 3.1. Control Plane The RICH Control Plane manages the metadata, schemas, and bindings governing capability interactions. It exposes resources as REST- addressable, HTTP-cacheable entities. The Control Plane consists of six core resource types: /capabilities: Capability registers and identity records. /contracts: Content-addressed contract revisions. /qualifications: Records of evaluated evidence and trust decisions. /connectors: Stored deterministic mapping functions. /bindings: Pinned binding configurations and lockfiles. /drift-events: Audit logs of runtime policy violations. All immutable resources MUST be content-addressed via digests. Mutable resources, such as deployment selectors, aliases, or promotion pointers, MUST reference immutable resource digests rather than modifying their representations in place. 3.2. Data Plane The RICH Data Plane remains native to the underlying protocol (e.g., MCP, gRPC, WebSocket). RICH does not introduce a proxy or wrapper layer for execution, preserving native streaming, cancellation, backpressure, and transport characteristics. Before an invocation is routed, the Harness intercepts the native payload to perform validation and transformation according to the locked binding. The execution path is: native producer result -> verify producer binding and deployment expectation -> validate producer output vs representation/structural contract -> execute the compiled deterministic connector -> validate connector postconditions -> validate consumer input contract -> invoke the consumer through its native protocol Pelov Expires 6 May 2027 [Page 6] Internet-Draft RICH Architecture November 2026 Some native protocols return interim outcomes that are neither a result nor an error. For example, an MCP server may answer a tool call with resultType: "input_required", asking the client for further input before the call is retried [MCP]. Output contracts apply only to complete results. An interim outcome MUST NOT be passed to a connector. The Runtime Enforcer MUST either handle it as the binding's runtime policy permits (for example, by routing the requested input to a human) or treat it as an error. Input supplied on the retry is validated against the consumer input contract like any other input. 3.3. Evidence Adapters Framework outputs, OpenAPI specs, static analyzers, and sandbox monitors serve as evidence adapters. Their output enters the RICH control plane as candidate evidence. Adapters MUST NOT qualify records directly; they simply record provenance, which is later submitted to a Qualification Service. 4. Resource Identity, Digests, and Canonicalization 4.1. Stable Identifiers and ni URIs Every RICH resource MUST be uniquely identified by a stable URI. Immutable resources SHOULD use the "ni" URI scheme as specified in [RFC6920] to bind the resource's identity directly to its cryptographic hash. For example: ni:///sha-256;UyaQV-gqtCHdOdgDnyT1b_0O2_A5w3_A9_aaaaaaaaa Where the "ni" URI scheme is not supported, RICH references MUST pair a stable location URI with a separate, mandatory "digest" field. 4.2. JSON Canonicalization and I-JSON Constraints To guarantee identical cryptographic digests across different implementations and platforms, all JSON representations of RICH resources MUST satisfy the constraints of the I-JSON format defined in [RFC7493]: * Object member names MUST be unique. * All string data MUST be encoded as valid UTF-8. * Numeric values MUST satisfy double-precision IEEE 754 limits. Integers outside the safe range from -(2^53)+1 to (2^53)-1 MUST be represented as strings. Pelov Expires 6 May 2027 [Page 7] Internet-Draft RICH Architecture November 2026 Before computing a cryptographic digest, the JSON representation MUST be canonicalized using the JSON Canonicalization Scheme (JCS) specified in [RFC8785]. The default digest algorithm is SHA-256, represented as: sha-256:<64-lowercase-hexadecimal-digits> 5. Capability and Contract Information Model 5.1. Capability Revision A Capability Revision describes the administrative metadata and native bindings of a capability. It MUST contain: id: The stable identifier (e.g., an ni URI or HTTPS URL). capabilityId: The parent capability identifier. revision: The provider-declared revision string (e.g., semver). protocol: The identifier of the native protocol (e.g., "mcp", "grpc"). operation: The native method or tool name. contract: An object referencing the contract URI and digest. provenance: The provenance record for this revision. lifecycle: The lifecycle state (e.g., "candidate", "qualified"). residualUnknowns: An array of material facts that cannot be resolved by available evidence. Example representation: Pelov Expires 6 May 2027 [Page 8] Internet-Draft RICH Architecture November 2026 { "id": "ni:///sha-256;...", "capabilityId": "https://registry.example/capabilities/weather", "revision": "2.1.0", "protocol": "mcp", "operation": "get_forecast", "contract": { "uri": "ni:///sha-256;...", "digest": "sha-256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" }, "provenance": { "kind": "provider-declared", "issuer": "https://weather.example" }, "lifecycle": "candidate", "residualUnknowns": [] } 5.2. Contract Revision A Contract Revision represents the structural, semantic, operational, and representation constraints of a capability. It MUST describe, or explicitly mark unresolved, the following six domains. Absence of a domain descriptor MUST NOT be treated as a default assumption; unsupported or unverified properties MUST be marked "unknown". 5.2.1. Structural Domain The structural domain defines the constraints on payload shapes. The default schema language is JSON Schema Draft 2020-12 [I-D.bhutton-json-schema]. A structural schema MUST declare its dialect. Implementations checking schema compatibility MUST define a schema validation subset that excludes undecidable constructs (such as unrestricted recursive dynamic references). A compiler MUST NOT infer semantic equivalence solely from identical structural shapes. Example success-envelope mapping: Pelov Expires 6 May 2027 [Page 9] Internet-Draft RICH Architecture November 2026 { "oneOf": [ { "type": "object", "required": ["status", "data"], "properties": { "status": {"const": "success"}, "data": {"type": "object"} } }, { "type": "object", "required": ["status", "error"], "properties": { "status": {"const": "error"}, "error": {"$ref": "#/$defs/errorDetails"} } } ] } 5.2.2. Representation Domain A representation contract describes constraints on serialization, encoding, and parsing that are not captured by standard JSON typing. For example, when a payload contains a JSON string that encapsulates an XML document, a plain JSON Schema validates the type only as a string. The representation contract MUST define: * The media type of the nested payload (e.g., "application/xml"). * The character encoding (e.g., "UTF-8"). * The grammar or parser revision (e.g., "XML 1.0"). * Parser preconditions and postconditions. When applicable, representation contracts SHOULD leverage the "contentEncoding", "contentMediaType", and "contentSchema" keywords defined in JSON Schema Draft 2020-12. 5.2.3. Semantic Domain Semantic contracts express assertions about the meaning of data, reusing vocabularies from the Semantic Definition Format (SDF) [RFC9880], W3C Hydra, or JSON-LD. They include: * Vocabulary and term URIs. Pelov Expires 6 May 2027 [Page 10] Internet-Draft RICH Architecture November 2026 * Units and coordinate systems. * Identifier namespaces. * Invariants (e.g., "input value must be greater than zero"). Semantic metadata is not self-proving; it represents assertions that require qualification against evidence before being trusted by the compiler. 5.2.4. Error Domain An error contract MUST distinguish, at minimum, the following categories or mark them "unknown": * Transport failure. * Protocol failure. * Authentication or authorization failure. * Domain failure. * Partial success. * Payment or quota required, including HTTP status 402 (Payment Required) [RFC9110] where it is used. * Retryability and compensation availability. Prices and quotas are not part of a contract: a contract revision is immutable, and prices change. The contract only declares that this failure category can occur. HTTP-based realizations SHOULD align error contracts with Problem Details for HTTP APIs [RFC9457]. A compiler MUST NOT classify a success-shaped payload as an error unless such mapping is explicitly defined in the error contract. 5.2.5. State Domain A state contract declares session, transaction, or stream consistency properties required across sequential invocations. If a capability is stateless, the contract MUST declare "state": "not-applicable". A compiler MUST NOT assume a capability is stateless from the absence of a state schema. Pelov Expires 6 May 2027 [Page 11] Internet-Draft RICH Architecture November 2026 Protocols without protocol-level sessions carry cross-call state as explicit handles in ordinary arguments, as MCP does since revision 2026-07-28. A state contract SHOULD identify such handle parameters, so that the structural domain describes them. 5.2.6. Operational Domain The operational contract defines execution constraints, including: * Side-effect class (e.g., "read", "idempotent", "write"). * Idempotency key header requirements. * Retry safety. * Timeout and deadline behaviors. * Expected data residency and external dependencies. * Reversibility of effects (e.g., "reversible", "compensable", "irreversible", "unknown"). * Whether effects cross a trust boundary, for example when data leaves the administrative domain of the deployment. * Model mediation (Section 5.2.7). Side-effect class, reversibility, and trust-boundary crossing together give a partial order of authority, which admission uses (Section 12). This document does not define a numeric score. 5.2.7. Model Mediation A capability may call a language model internally while exposing a structured interface. Its output schema then bounds the syntax of the result, not whether a model chose it. A contract MUST declare model mediation as one of: none: No model is invoked between input and output. bounded: A model is invoked only to select among options under a closed output contract. unbounded: A model produces or transforms result content. Pelov Expires 6 May 2027 [Page 12] Internet-Draft RICH Architecture November 2026 unknown: Evidence is insufficient. A declaration of "none" is an assertion like any other and requires qualification before it is trusted (Section 6). 6. Contract Provenance and Evidence Roles 6.1. Provenance Kinds Every contract assertion MUST identify its provenance. The base provenance kinds are: provider-declared: Assertions signed by the capability provider. generated-from-typed-source: Parsed from IDLs or OpenAPI schemas. statically-inferred: Generated by code scanners. sandbox-observed: Recorded from test executions. community-authored: Sourced from shared databases. model-proposed: Generated by a reasoning model. manually-authored: Written by local operators. unresolved: No provenance available. Model-proposed provenance MUST be marked non-authoritative. A compiler MUST NOT qualify model-proposed assertions without independent static or runtime evidence. 6.2. Mapping to RATS Trust Roles RICH maps contract and connector provenance to the Remote ATtestation procedureS (RATS) architecture specified in [RFC9334]: * The Evidence Adapter acts as the Attester, collecting raw measurements of capability behavior. Pelov Expires 6 May 2027 [Page 13] Internet-Draft RICH Architecture November 2026 * The qualification profile rules act as the Appraisal Policy. * The Qualification Service acts as the Verifier, evaluating evidence against policies to issue signed Attestation Results (Qualification Records). * The Compiler acts as the Relying Party, consuming Qualification Records to produce binding lockfiles. 7. Composition and Graph Closure Compositions are sets of bound capabilities and their connections. RICH standardizes the metadata required to verify composition boundaries. 7.1. Edge Kinds When compiling a composition, the Compiler MUST distinguish the following edge kinds: data: Application data flow. tool: The attachment of a capability as a tool to an agent. model: The attachment of a model to a harness step. control: Routing, branching, or scheduling dependencies. state: Shared or transferred state. error: Failure or compensation flows. An importer MUST NOT flatten these distinct edges into a single data- connector class. 7.2. Graph-Closure Status A composition MUST declare its closure status: closed: All nodes, edges, revisions, and connector dependencies are immutably known at compile time. Pelov Expires 6 May 2027 [Page 14] Internet-Draft RICH Architecture November 2026 parameterized: The topology is fixed, but declared parameters may vary within bounded spaces. runtime-generated: The topology or nodes are constructed dynamically at runtime. unknown: Evidence is insufficient to verify closure. Only in "closed" compositions is every connector on every path pinned at compile time. This is a property of the connector path: it does not make the behavior of models attached by "tool" or "model" edges deterministic. Runtime-generated subgraphs MUST be explicitly bounded; they MUST NOT inherit qualified connector claims. 7.3. Bounded Model Steps A model attached by a "model" edge may be used to choose among paths rather than to transform data. A bounded model step is a node whose model output is constrained by a closed output contract (an enumeration, or a closed schema with finite value sets) and is consumed only by "control" edges, each selecting one declared successor. A bounded model step is a path selection, not a data transformation, and does not conflict with the prohibition of T4 connectors in enforced bindings. A composition whose only model involvement is bounded model steps MAY declare closure status "parameterized": the topology is fixed, and each model choice is a parameter in a finite space. The Compiler MUST verify that every successor of a bounded model step is a bound capability with a pinned contract. Under that condition, the behavior reachable through the step is contained in the union of its successors' contracts. The guarantee is containment of reachable behavior, not determinism of the model's choice. If any successor is unbound, the step MUST be treated as unbounded. 8. Qualification Records and SCITT Integration 8.1. Lifecycle States Contracts and connectors follow a strict lifecycle path: observed -> candidate -> qualified -> enforced -> drifted -> deprecated Pelov Expires 6 May 2027 [Page 15] Internet-Draft RICH Architecture November 2026 Failed qualification attempts terminate at a "failed" state. All lifecycle transitions MUST be recorded as auditable events and MUST NOT rewrite existing resources. 8.2. Qualification Record Format A Qualification Record is the signed attestation of a Qualification Service. It MUST contain: subjectUri: The URI of the capability or connector. subjectDigest: The SHA-256 digest of the canonical subject representation. profile: The identifier and version of the qualification profile. evidence: An array of references (URIs and digests) to evaluated evidence. scope: The declared evaluation scope. findings: A list of resolved and unresolved findings. decision: The outcome ("qualified", "failed", "indeterminate"). qualifier: The identity of the qualification service. expiry: The validity window. Regime specifics, such as holdout sizes or test coverage parameters, are profile-defined and MUST NOT be standardized in the base record. 8.3. SCITT Attestation Profile Qualification records SHOULD be signed and registered with a Supply Chain Integrity, Transparency, and Trust (SCITT) registry conforming to the [RFC9943] architecture. The qualification record SHALL be carried as the signed statement payload of a SCITT envelope. The SCITT registry receipt serves as transparency evidence for the Compiler. Pelov Expires 6 May 2027 [Page 16] Internet-Draft RICH Architecture November 2026 9. Connectors 9.1. Connector Definition A Connector transforms a qualified source contract into a qualified target contract. A Connector MUST bind exact source and target contract digests. It MUST contain: id: Unique identifier. sourceDigest: Pinned digest of the source contract. targetDigest: Pinned digest of the target contract. class: The transformation class (T0-T4). purpose: The declared purpose taxonomy. transform: The executable code or expression. preconditions: Pre-execution checks. postconditions: Post-execution validations. qualification: Reference to the connector's qualification record. Example Connector representation: Pelov Expires 6 May 2027 [Page 17] Internet-Draft RICH Architecture November 2026 { "id": "ni:///sha-256;...", "sourceDigest": "sha-256:bbbbbbbb...", "targetDigest": "sha-256:cccccccc...", "class": "T1", "purpose": "structural-adaptation", "transform": { "lang": "jmespath", "expr": "{ message: results[0].text }" }, "preconditions": {}, "postconditions": {}, "qualification": "ni:///sha-256;..." } 9.2. Transformation Classes (T0-T4) RICH defines five connector transformation classes: T0 - Pass-through: No structural or representation modification is performed. T0 does not assert semantic compatibility. T1 - Restricted structural mapping: The transform consists of deterministic operations defined by a restricted profile. T2 - Semantically annotated mapping: A T1 mapping supported by ontological, unit, or namespace translation evidence. T3 - Generated or arbitrary-code candidate: Program code (e.g., Python or WebAssembly) generated to bridge components. T3 requires isolation and sandbox qualification. T4 - Live model mediation: An LLM dynamically maps values in the execution path. T4 is non- deterministic and MUST NOT be used in enforced deterministic bindings. 9.3. Restricted T1 Transformation Profile (Informative Sketch) A restricted T1 profile defines a safe, non-Turing-complete mapping language (e.g., JMESPath or a subset of JSONata). A T1 profile MUST define: * Null and missing-field semantics. Pelov Expires 6 May 2027 [Page 18] Internet-Draft RICH Architecture November 2026 * Numeric coercion and precision rules. * Evaluation resource limits (maximum steps, memory limits). A T1 profile MUST prohibit: * Network and filesystem access. * System calls, current time, and randomness. * Dynamic code execution and recursion. 10. Binding and Lock Artifacts 10.1. Binding Requirements A production binding MUST reference: * Capability revision and digest. * Contract revision and digest. * Deployment expectations: a workload identity (Section 13), endpoint identity, or public key. Pinning a TLS certificate digest is NOT RECOMMENDED, since it breaks on certificate rotation. * Protocol binding profile. * Qualification record digest. * Connector digest (if applicable). * Runtime drift, error, and timeout policies, including the handling of interim outcomes (Section 3.2). * Where the deployment requires admission, a reference to the authorization the binding was admitted against (Section 12). 10.2. Lockfile Schema and Example A compiled lockfile represents the locked graph closure. It is written as canonical JSON to generate its digest, though it MAY be authored in YAML. Pelov Expires 6 May 2027 [Page 19] Internet-Draft RICH Architecture November 2026 { "richVersion": "0.1", "bindingId": "https://reg.example/bindings/weather-sms/12", "graphClosure": "closed", "worstCaseBoundDigest": "sha-256:iiiiiiii...", "capabilities": { "weather": { "revision": "https://reg.example/weather/rev/1.0.0", "revisionDigest": "sha-256:dddddddd...", "protocol": "mcp", "operation": "get_forecast", "contractDigest": "sha-256:eeeeeeee...", "deployment": { "identity": "https://deployments.example/weather", "endpointSelector": "dns:weather.internal" }, "qualificationDigest": "sha-256:ffffffff..." } }, "connections": [ { "id": "weather-to-sms-edge", "source": "weather", "target": "sms", "edgeKind": "data", "connectorDigest": "sha-256:gggggggg...", "connectorProfile": "https://prof.example/t1-jmespath", "connectorQualificationDigest": "sha-256:hhhhhhhh...", "runtime": { "onDrift": "fail-closed", "onError": "route-to-error", "timeout": "PT10S" } } ] } 11. Compilation and Runtime Validation 11.1. Conforming Compiler Duties A conforming Compiler MUST: 1. Resolve all capability and contract revisions, rejecting missing or mismatched digests. 2. Determine the graph-closure status. Pelov Expires 6 May 2027 [Page 20] Internet-Draft RICH Architecture November 2026 3. Preserve edge kinds, preventing tool edges from being flattened into data flows. 4. Evaluate source-output and target-input compatibility using a defined JSON Schema validation subset. 5. Verify that all connectors are qualified. 6. Record all material assumptions and residual unknowns. 7. Compute the worst-case bound of the composition (Section 12), or record that it cannot be computed. 8. Emit a reproducible canonical JSON lockfile. 11.2. Conforming Runtime Enforcer Duties A conforming Runtime Enforcer MUST: 1. Verify the integrity of the lockfile. 2. Validate the deployed endpoint's identity against binding expectations, for example by verifying a workload identity credential (Section 13) or the peer identity of a mutually authenticated TLS connection. 3. Validate producer payloads against the structural contract _before_ executing the connector. 4. Execute the connector in its isolated runtime. 5. Validate the connector's output against the target contract _before_ invoking the consumer. 6. Route all error outcomes according to the bound error policy. 7. Handle interim outcomes as described in Section 3.2; never pass them to a connector. 8. Where the deployment requires admission, refuse to execute a binding that has not been admitted against the authorization presented. 12. Authorization and Admission RICH contracts give an authorization decision a stable object to refer to. This section describes how. It does not define a token format. Pelov Expires 6 May 2027 [Page 21] Internet-Draft RICH Architecture November 2026 12.1. Referencing Contracts from Authorization An opaque scope string can name a permission class, but it cannot carry the structured object a resource server needs to verify at call time. A structured authorization object fits better, for example an authorization details type under Rich Authorization Requests [RFC9396]. The authorization request identifies a contract revision by digest, and the issued token carries that digest. The resource server, or the harness acting as enforcement point, then checks that the invoked capability and its contract digest match what was authorized. [I-D.zehavi-oauth-rar-metadata] defines metadata for authorization details types and signaling for insufficient authorization details, which such a type could use. This document does not define the type. 12.2. Worst-case Bound and Admission A compiled binding has a worst-case bound: the operations, arguments, and effects it can produce under any model output. The Compiler computes it from the pinned graph, the structural contracts, and the operational domain of each capability. The bound is computable at compile time for a closed composition, and for one whose only model involvement is bounded model steps (Section 7.3). A binding is admitted only if its worst-case bound is included in the scope the authorization grants. Inclusion is decidable over a restricted fragment: enumerations, numeric ranges, finite sets, and closed schemas. Inclusion between arbitrary JSON Schemas is not tractable in general. Outside that fragment an admission check can be sound but incomplete: it may refuse a binding that is in fact within scope, and it MUST NOT admit a binding it cannot show to be within scope. When a model may call any capability the harness exposes, the worst- case bound is the authorization itself, and admission adds nothing. Stating this makes the cost of open agentic operation explicit. 12.3. Bounded and Dynamic Capabilities Not every capability can be bounded. For dynamic capabilities [I-D.pelov-bounded-agent-capabilities], authorization remains over an envelope (purpose, actor, data sources, permitted tools, budget, logging obligations, and human approval requirements) rather than over a contract. RICH does not force capabilities into the bounded class. It makes the boundary explicit: closure status, model mediation, and edge kinds record where a workflow crosses from bounded components into dynamic ones, so that policy can apply to the crossing. Pelov Expires 6 May 2027 [Page 22] Internet-Draft RICH Architecture November 2026 13. Relationship to Workload Identity Workload identity [I-D.ietf-wimse-arch] establishes which workload is calling. RICH establishes what the called capability has committed to, pinned by digest. Neither decides what is authorized; that is the role of the authorization layer (Section 12). In RICH, the harness is the workload: it holds the workload credentials and acts as reference monitor. The model is not a workload and holds no credentials. A binding's deployment expectation SHOULD name a workload identifier and trust domain rather than a certificate digest, and the Runtime Enforcer verifies the peer's credential on each invocation. Compositions are chains of invocations, and each hop may run under a different delegation. Expressing per-hop delegation in a lockfile edge is left for future work. This document defines no workload identity mechanism. 14. Drift and Containment 14.1. Drift Event Schema A violation of any contract, schema, validation, or identity assertion MUST produce a Drift Event. The Drift Event is a structured JSON record containing: eventId: Unique identifier. timestamp: Time of detection. bindingId: Pinned binding identifier. traceId: W3C Trace Context trace identifier. expectedDigest: Pinned digest that was expected. observedIdentifier: Observed endpoint identity. violationLocation: Path of the schema or contract boundary violated. Pelov Expires 6 May 2027 [Page 23] Internet-Draft RICH Architecture November 2026 category: The category of drift (e.g., "structural", "identity"). evidenceDigest: SHA-256 digest of the offending payload. actionTaken: Action executed (e.g., "blocked", "notify"). diagnostics: Disclosure-safe diagnostic details. Drift Events MUST NOT contain raw payloads or sensitive parameter data. 14.2. Drift Policies Enforced bindings MUST specify a drift policy: fail-closed: Refuse execution immediately; abort the call chain. quarantine: Redirect the payload to an isolated storage bucket for offline inspection. qualified-fallback: Redirect execution to a pre-qualified backup capability revision. notify: Emit a Drift Event and continue execution. This policy MUST NOT be used in high-assurance environments. 15. Compatibility and Migration 15.1. Compatibility Outcomes A Compiler or registry comparing two contract revisions MUST yield one of: compatible: The target contract accepts all payloads of the source. compatible-with-connector: Compatibility is achievable via a qualified T1/T2 connector. breaking: Payloads will cause structural or semantic violations. Pelov Expires 6 May 2027 [Page 24] Internet-Draft RICH Architecture November 2026 unknown: Schemas contain constructs outside the validation subset, or evidence is insufficient. 15.2. Migration Records A Migration Record documents the transition from a source contract revision to a target contract revision. It SHOULD include: * Source and target contract digests. * The compatibility outcome. * The compiled migration connector. * A list of dropped or lossy fields. * Coexistence and sunset dates. * Rollback instructions. If a migration is lossy or breaking, the Compiler MUST require explicit administrative approval before generating a new lockfile. 16. Relationship to Other Work [I-D.mih-scitt-agent-action-capsule] defines a SCITT statement profile that records each action an agent took and its verdict, including refusals. It is complementary to RICH: qualification records and drift events describe what was admitted and what diverged before execution, while an action capsule records what was executed. A refusal or drift event raised by a RICH Runtime Enforcer could be recorded as such a capsule. Authorization is discussed in Section 12, and workload identity in Section 13. 17. Security and Privacy Considerations 17.1. Scope of the Guarantee RICH bounds what each admitted call can do: every invocation is checked against pinned contracts, and every connector on the path is qualified and refusable. RICH does not bound which admitted calls a model chooses to make, in what order, or why. A model attached through "tool" edges may still pursue a goal its operator did not intend, using only admitted calls. Admission (Section 12) limits the effect of such behavior to the worst-case bound; it does not prevent Pelov Expires 6 May 2027 [Page 25] Internet-Draft RICH Architecture November 2026 it. Model mediation declarations (Section 5.2.7) are claims made by providers. A capability that declares no model mediation but calls a model internally presents a structured output schema over content a model chose. Qualification evidence, not the declaration alone, is needed before such a claim is trusted. 17.2. Confused Deputy and Prompt Injection Reasoning models are susceptible to prompt injection, where malicious payloads are interpreted as instructions. By enforcing authority boundaries at the Harness level, RICH prevents the model from acting as a confused deputy. The Harness does not trust the model's output as an administrative command. All proposed actions are validated against the schema and the list of admissible transitions. If a model proposes an action outside the authorized set, the enforcer blocks execution. 17.3. Evidence Poisoning and Sandbox Execution Qualification depends on evidence (test results, static analyses). If an attacker influences the evidence repository, they can trick the qualification service into certifying a malicious connector. Qualification profiles MUST isolate test environments, mount file systems as read-only, and limit network access. 17.4. Schema Complexity Attacks A malicious provider can publish schemas designed to trigger resource exhaustion during validation (e.g., deeply nested JSON Schemas or ReDoS-prone regular expressions). Runtime enforcers MUST apply limits on schema parsing depth, computation time, and memory usage. 18. IANA Considerations This document makes no IANA requests. Future profiles may request registrations in the following registries: * Media Types Registry: e.g., "application/rich+json" * RICH Provenance Kinds Registry * RICH Connector Profile Registry * RICH Drift Action Registry Pelov Expires 6 May 2027 [Page 26] Internet-Draft RICH Architecture November 2026 19. References 19.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . 19.2. Informative References [I-D.bhutton-json-schema] Wright, A., Andrews, H. H., Hutton, B., and G. Dennis, "JSON Schema: A Media Type for Describing JSON Documents", Work in Progress, Internet-Draft, draft-bhutton-json- schema-01, 10 June 2022, . [I-D.ietf-wimse-arch] Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft- ietf-wimse-arch-08, 6 July 2026, . [I-D.mih-scitt-agent-action-capsule] Mih, S., "An Agent Action Capsule Profile for SCITT", Work in Progress, Internet-Draft, draft-mih-scitt-agent-action- capsule-05, 26 September 2026, . Pelov Expires 6 May 2027 [Page 27] Internet-Draft RICH Architecture November 2026 [I-D.pelov-bounded-agent-capabilities] Pelov, A., "Bounded Capabilities for Agent Tool Interfaces: Problem Statement", Work in Progress, Internet-Draft, draft-pelov-bounded-agent-capabilities-00, 3 July 2026, . [I-D.zehavi-oauth-rar-metadata] Zehavi, Y., "OAuth 2.0 RAR Metadata and Error Remediation", Work in Progress, Internet-Draft, draft- zehavi-oauth-rar-metadata-06, 9 August 2026, . [MCP] Model Context Protocol contributors, "Model Context Protocol Specification, revision 2026-07-28", July 2026, . [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, . [RFC9880] Koster, M., Ed., Bormann, C., Ed., and A. Keränen, "Semantic Definition Format (SDF) for Data and Interactions of Things", RFC 9880, DOI 10.17487/RFC9880, January 2026, . Pelov Expires 6 May 2027 [Page 28] Internet-Draft RICH Architecture November 2026 [RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, . Acknowledgments This work draws on discussions in the AGENTPROTO and WIMSE communities, and at the IETF 126 side meetings on AI agent authorization and on a proposed agentic AI research group. Changes since -00 * Updated the MCP reference to revision 2026-07-28. * Scoped the determinism claims: RICH bounds what each admitted call can do, not model behavior (abstract, introduction, graph closure, and Section 17.1). * Added handling of interim outcomes such as MCP "input_required" (Section 3.2). * Operational domain: added reversibility, trust-boundary crossing, and model mediation (Section 5.2.7). State domain: added explicit state handles. Error domain: added payment or quota required. * Added bounded model steps (Section 7.3). * Added authorization and admission: contract references in authorization, worst-case bound, admission by inclusion, and bounded versus dynamic capabilities (Section 12). * Added the relationship to workload identity (Section 13); deployment expectations now prefer workload identity to certificate digests. * Added the relationship to the SCITT Agent Action Capsule profile. Author's Address Alexander Pelov IMT Atlantique Email: alexander.pelov@imt-atlantique.fr Pelov Expires 6 May 2027 [Page 29]