Network Working Group A. Pelov Internet-Draft IMT Atlantique Intended status: Informational 6 July 2026 Expires: 7 January 2027 RICH: RESTful Interface for the Control-plane of Harnesses draft-pelov-rich-architecture-00 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, deterministic connector classes, compiled binding lockfiles, and runtime validation rules designed to contain drift and prevent confused deputy attacks in agentic systems. 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 7 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 Pelov Expires 7 January 2027 [Page 1] Internet-Draft RICH Architecture July 2026 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 . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Evidence Adapters . . . . . . . . . . . . . . . . . . . . 6 4. Resource Identity, Digests, and Canonicalization . . . . . . 6 4.1. Stable Identifiers and ni URIs . . . . . . . . . . . . . 6 4.2. JSON Canonicalization and I-JSON Constraints . . . . . . 6 5. Capability and Contract Information Model . . . . . . . . . . 7 5.1. Capability Revision . . . . . . . . . . . . . . . . . . . 7 5.2. Contract Revision . . . . . . . . . . . . . . . . . . . . 8 5.2.1. Structural Domain . . . . . . . . . . . . . . . . . . 8 5.2.2. Representation Domain . . . . . . . . . . . . . . . . 9 5.2.3. Semantic Domain . . . . . . . . . . . . . . . . . . . 9 5.2.4. Error Domain . . . . . . . . . . . . . . . . . . . . 10 5.2.5. State Domain . . . . . . . . . . . . . . . . . . . . 10 5.2.6. Operational Domain . . . . . . . . . . . . . . . . . 10 6. Contract Provenance and Evidence Roles . . . . . . . . . . . 11 6.1. Provenance Kinds . . . . . . . . . . . . . . . . . . . . 11 6.2. Mapping to RATS Trust Roles . . . . . . . . . . . . . . . 11 7. Composition and Graph Closure . . . . . . . . . . . . . . . . 12 7.1. Edge Kinds . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Graph-Closure Status . . . . . . . . . . . . . . . . . . 12 8. Qualification Records and SCITT Integration . . . . . . . . . 13 8.1. Lifecycle States . . . . . . . . . . . . . . . . . . . . 13 8.2. Qualification Record Format . . . . . . . . . . . . . . . 13 8.3. SCITT Attestation Profile . . . . . . . . . . . . . . . . 14 9. Connectors . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Connector Definition . . . . . . . . . . . . . . . . . . 14 9.2. Transformation Classes (T0-T4) . . . . . . . . . . . . . 15 9.3. Restricted T1 Transformation Profile (Informative Sketch) . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Binding and Lock Artifacts . . . . . . . . . . . . . . . . . 16 10.1. Binding Requirements . . . . . . . . . . . . . . . . . . 16 10.2. Lockfile Schema and Example . . . . . . . . . . . . . . 17 11. Compilation and Runtime Validation . . . . . . . . . . . . . 17 11.1. Conforming Compiler Duties . . . . . . . . . . . . . . . 17 11.2. Conforming Runtime Enforcer Duties . . . . . . . . . . . 18 12. Drift and Containment . . . . . . . . . . . . . . . . . . . . 18 12.1. Drift Event Schema . . . . . . . . . . . . . . . . . . . 18 Pelov Expires 7 January 2027 [Page 2] Internet-Draft RICH Architecture July 2026 12.2. Drift Policies . . . . . . . . . . . . . . . . . . . . . 19 13. Compatibility and Migration . . . . . . . . . . . . . . . . . 20 13.1. Compatibility Outcomes . . . . . . . . . . . . . . . . . 20 13.2. Migration Records . . . . . . . . . . . . . . . . . . . 20 14. Security and Privacy Considerations . . . . . . . . . . . . . 20 14.1. Confused Deputy and Prompt Injection . . . . . . . . . . 21 14.2. Evidence Poisoning and Sandbox Execution . . . . . . . . 21 14.3. Schema Complexity Attacks . . . . . . . . . . . . . . . 21 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 16.1. Normative References . . . . . . . . . . . . . . . . . . 21 16.2. Informative References . . . . . . . . . . . . . . . . . 22 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 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. 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, ensuring all capability connections are compiled, validated, and enforced deterministically. 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 Pelov Expires 7 January 2027 [Page 3] Internet-Draft RICH Architecture July 2026 fixed contract; agentic systems, in which a model re-interprets a prose interface on each call, have no equivalent step. RICH reintroduces one. 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. 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. Pelov Expires 7 January 2027 [Page 4] Internet-Draft RICH Architecture July 2026 Native Protocol: The execution transport used by the capability data plane (e.g., gRPC, MCP, HTTP/REST). 3. Architectural Model RICH separates capability composition and governance (the Control Plane) from native execution (the Data Plane). 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: Pelov Expires 7 January 2027 [Page 5] Internet-Draft RICH Architecture July 2026 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 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. Before computing a cryptographic digest, the JSON representation MUST be canonicalized using the JSON Canonicalization Scheme (JCS) specified in [RFC8785]. Pelov Expires 7 January 2027 [Page 6] Internet-Draft RICH Architecture July 2026 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 7 January 2027 [Page 7] Internet-Draft RICH Architecture July 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 7 January 2027 [Page 8] Internet-Draft RICH Architecture July 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 7 January 2027 [Page 9] Internet-Draft RICH Architecture July 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. * Retryability and compensation availability. 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. 5.2.6. Operational Domain The operational contract defines execution constraints, including: * Side-effect class (e.g., "read", "idempotent", "write"). * Idempotency key header requirements. Pelov Expires 7 January 2027 [Page 10] Internet-Draft RICH Architecture July 2026 * Retry safety. * Timeout and deadline behaviors. * Expected data residency and external dependencies. 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 7 January 2027 [Page 11] Internet-Draft RICH Architecture July 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 7 January 2027 [Page 12] Internet-Draft RICH Architecture July 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 "closed" compositions can be certified as fully deterministic. Runtime-generated subgraphs MUST be explicitly bounded; they MUST NOT inherit deterministic connector claims. 8. Qualification Records and SCITT Integration 8.1. Lifecycle States Contracts and connectors follow a strict lifecycle path: observed -> candidate -> qualified -> enforced -> drifted -> deprecated 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: Pelov Expires 7 January 2027 [Page 13] Internet-Draft RICH Architecture July 2026 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. 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: Pelov Expires 7 January 2027 [Page 14] Internet-Draft RICH Architecture July 2026 The executable code or expression. preconditions: Pre-execution checks. postconditions: Post-execution validations. qualification: Reference to the connector's qualification record. Example Connector representation: { "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. Pelov Expires 7 January 2027 [Page 15] Internet-Draft RICH Architecture July 2026 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. * 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 (endpoint, TLS certificate digest, or public key). * Protocol binding profile. * Qualification record digest. * Connector digest (if applicable). * Runtime drift, error, and timeout policies. Pelov Expires 7 January 2027 [Page 16] Internet-Draft RICH Architecture July 2026 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. { "richVersion": "0.1", "bindingId": "https://reg.example/bindings/weather-sms/12", "graphClosure": "closed", "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: Pelov Expires 7 January 2027 [Page 17] Internet-Draft RICH Architecture July 2026 1. Resolve all capability and contract revisions, rejecting missing or mismatched digests. 2. Determine the graph-closure status. 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. 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 (e.g., TLS certificate fingerprint or workload signature) against binding expectations. 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. 12. Drift and Containment 12.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: Pelov Expires 7 January 2027 [Page 18] Internet-Draft RICH Architecture July 2026 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. 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. 12.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: Pelov Expires 7 January 2027 [Page 19] Internet-Draft RICH Architecture July 2026 Emit a Drift Event and continue execution. This policy MUST NOT be used in high-assurance environments. 13. Compatibility and Migration 13.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. unknown: Schemas contain constructs outside the validation subset, or evidence is insufficient. 13.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. 14. Security and Privacy Considerations Pelov Expires 7 January 2027 [Page 20] Internet-Draft RICH Architecture July 2026 14.1. 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. 14.2. 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. 14.3. 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. 15. 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 16. References 16.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, . Pelov Expires 7 January 2027 [Page 21] Internet-Draft RICH Architecture July 2026 [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, . 16.2. Informative References [I-D.bhutton-json-schema] Wright, A., Andrews, 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.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, . [MCP] Model Context Protocol contributors, "Model Context Protocol Specification, revision 2025-11-25", November 2025, . [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, . [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, . [RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, . Pelov Expires 7 January 2027 [Page 22] Internet-Draft RICH Architecture July 2026 [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, . [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 at IETF 126. Author's Address Alexander Pelov IMT Atlantique Email: alexander.pelov@imt-atlantique.fr Pelov Expires 7 January 2027 [Page 23]