Protocol-Native Carriers: Agents as the Fundamental Unit of Transmission

Mechanism

A protocol-native carrier is a self-contained unit that combines a payload with a governance section in a single serialization. The serialization defines a small fixed-format prefix that names the carrier type and version, followed by a length-tagged governance section, followed by the payload. The governance section holds policy references, lineage hashes, eligibility descriptors, and any cryptographic commitments required by the policies under which the payload was produced. The payload follows immediately and is described by a manifest contained within the governance section, so that a recipient cannot interpret the payload without first consulting the governance metadata.

The carrier is opaque to the underlying transport. Whether transmitted over a stream socket, a datagram, a message queue, a shared memory segment, or a file, the carrier remains a single contiguous bytestring that can be hashed, signed, replicated, and replayed without the transport observing or modifying its internal structure. Routing, fragmentation, and reassembly occur at the transport layer; the governance section is never consulted by the transport and is never rewritten by intermediate hops.

Because the governance section is part of the payload from the transport's perspective, no firewall, proxy, or load balancer can strip it without producing a malformed carrier that the recipient will reject. Conversely, no recipient can interpret the payload while ignoring the governance section, because the manifest required to parse the payload lives inside the governance section. The two are inseparable by construction.

The carrier is also self-describing with respect to its own integrity. A trailing commitment section holds a hash that covers the prefix, the governance section, and the payload in a single canonical encoding; senders compute the commitment after composing the carrier, and recipients verify the commitment before consulting any field within the governance section. This ordering guarantees that an attacker who modifies any byte of the carrier in transit produces a commitment mismatch, and the recipient rejects the carrier without exposing its parser to attacker-chosen content. The commitment is part of the carrier's serialized form, not a side-channel envelope, so a transport that delivers the carrier necessarily delivers the commitment along with it.

Operating Parameters

Carriers are parameterized by maximum size, maximum governance section size, and maximum payload size. The size limits are chosen to fit within the transport's maximum transmission unit when transport-level fragmentation is undesirable, and to fit within the recipient's working memory when the recipient is resource-constrained. When a carrier exceeds the maximum size, it is split into a sequence of carriers with shared lineage, each carrying a contiguous segment of the original payload and a copy of the governance section that references the segment. Segmented carriers are reassembled at the recipient by lineage matching rather than by transport-level reassembly, so that segmentation is visible to the governance layer.

The carrier serialization is parameterized by the cryptographic primitives in use: the hash function for content commitments, the signature scheme for authority assertions, and the encoding of policy references. These primitives are named in the version prefix so that recipients can refuse carriers whose primitives they do not support, rather than misinterpreting them. Primitive agility is supported by versioning the prefix; primitive substitution is not supported within a single carrier.

Throughput parameters include the rate at which a sender may emit carriers, the rate at which a receiver will admit them, and the depth of any intermediate buffer. These parameters are negotiated by the governance layer rather than by the transport, because admission of a carrier depends on its governance section and not on its transport envelope. A receiver under backpressure rejects carriers with a governance-level transient code; the transport is not asked to retry, because the rejection is a governance decision and not a transport failure.

Alternative Embodiments

The carrier has been reduced to practice in several embodiments. In the framed embodiment, the carrier is wrapped in a transport-specific frame that carries only routing information; the governance section and payload are entirely within the frame's payload field. In the embedded embodiment, the carrier is placed inside an existing application protocol's message body, allowing the protocol-native carrier to traverse infrastructure that recognizes the outer application protocol but does not need to recognize the carrier itself.

A further embodiment uses a content-addressed transport, in which the carrier is published to a store keyed by the hash of the carrier and recipients pull it by hash. This embodiment exploits the carrier's self-contained nature: because the governance section travels with the payload, the carrier can be retrieved from any replica of the store without losing the metadata that conditions its interpretation.

In an embodiment optimized for small payloads, the governance section is compressed using a dictionary of policy references known to both sender and receiver. The dictionary is itself a governed resource, distributed by carriers under the same mechanism, so that compression does not introduce an out-of-band dependency. Recipients that lack the dictionary version named in the carrier reject it with a code that prompts the sender to retransmit using a dictionary the recipient holds, or to send the dictionary as a preceding carrier.

A streaming embodiment supports payloads whose total size is unknown at the moment the sender begins emission. The carrier prefix names a streaming variant in which the governance section is fixed at carrier start and the payload is delivered as a sequence of length-tagged chunks terminated by a sentinel chunk carrying a final commitment. Each chunk's bytes are folded into a running hash; the sentinel carries the final hash, and the recipient verifies that the running hash matches before admitting the payload. The streaming embodiment preserves the property that governance is consulted before payload interpretation, because the governance section is fully present before the first payload chunk arrives, while accommodating senders whose payload size is bounded only by run-time computation.

Composition

The carrier composes with the cryptographic governance framework by carrying the descriptors that the framework's admission gates require. A region that gates writes on policy eligibility receives, with each write, a carrier whose governance section names the policy under which the payload was generated; the gate evaluates the policy and admits or rejects the write according to the predicate described in the governance documentation.

The carrier composes with the content anchoring system by carrying lineage hashes that match the anchors recorded in the content registry. A recipient that receives a carrier can verify, without consulting the sender, that the payload's lineage is consistent with the registry's record. The carrier composes with audit logs by being itself a unit of record: a node that processes a carrier records the carrier hash in its log, and the log entries are directly comparable across nodes because the hash covers both governance section and payload.

The carrier composes with execution environments by serving as the input format for memory-bearing agents. An agent receives a carrier, evaluates the governance section against its local policy state, and admits the payload into its working memory only if the carrier's eligibility holds. The carrier therefore functions as both transport unit and admission unit; the agent does not need a separate ingestion pipeline to apply governance to inbound data.

Prior Art

Conventional networking protocols separate metadata from payload by placing metadata in headers. Headers are subject to rewriting at every hop: NAT translates addresses, proxies rewrite hostnames, load balancers rewrite paths, and middleboxes routinely alter or strip header fields they do not recognize. Governance metadata placed in headers is therefore not durable across the network path, and recipients cannot distinguish metadata that the sender intended from metadata that an intermediate hop introduced or removed.

Application-layer wrapper formats such as JOSE, COSE, and signed envelope formats place metadata in a payload-resident structure, but they do not bind the metadata to a manifest required for interpreting the inner payload, and they do not encode lineage or policy references in a form that downstream governance can consume without translation. They establish that a payload was signed by a key; they do not establish that the payload was generated under a known policy with a known history.

Capability-based networking systems carry credentials with messages but typically encode capabilities as opaque tokens whose interpretation depends on a server-side store. The carrier described here differs by encoding policy references that resolve to verifiable policy objects in a governed registry, so that a recipient can interpret the governance section without trusting the sender's server, and by binding the carrier's payload to the manifest within its governance section.

Self-describing data formats such as Protocol Buffers, Avro, and CBOR provide schemas for parsing payload bytes but treat governance and lineage as out-of-band concerns. A consumer of an Avro record must obtain the schema separately and trust the registry that supplied it; nothing in the record commits the producer to the policy under which the data was produced. Payload-anchored governance, as disclosed here, is distinct in that the governance section cannot be substituted, omitted, or trusted independently of the payload, and the manifest required to parse the payload is itself a governed object.

Mobile-code and active-network systems transmitted executable fragments along with data, but they did not separate governance metadata from the executable payload and did not establish an admission predicate that recipients evaluated before invoking the code. The carrier described here carries data and governance, not code, and its admission semantics are determined entirely by the predicate evaluation in the recipient's governance layer, distinguishing it from active-network proposals that delegated execution decisions to the network nodes themselves.

Disclosure Scope

The disclosure applies to any transmission unit whose serialization combines a governance section with a payload such that neither can be interpreted in isolation and neither can be detached from the other without invalidating the unit. The disclosure is not limited to a particular transport, a particular cryptographic primitive, or a particular policy language. It specifies that the governance section is encoded in the payload from the transport's perspective, that the section is consulted before payload interpretation, and that lineage and eligibility metadata travel with every carrier; any concrete instantiation of those properties is within scope.

The disclosure further extends to embodiments in which the carrier is itself produced by an agent operating under the same protocol, so that the production of carriers is recursively governed and the lineage chain extends from the data's origin through every transmission to its eventual consumption. The disclosure covers both the carrier format and the methods by which carriers are produced, transmitted, admitted, and consumed within the memory-native protocol stack.