Mechanism

A semantic agent does not carry a static credential as it moves between machines. Identity is expressed as a trust slope: the cumulatively validated sequence of Dynamic Agent Hashes (DAHs) formed by successive, verifiable identity mutations. When such an agent migrates across multiple substrate nodes, each node it executes on contributes a mutation step that is cryptographically entangled to that node's own Dynamic Device Hash (DDH). The accumulated steps form a cumulative slope across substrates: a tamper-evident, multi-node provenance path that binds the agent's evolution to the device-level identity transitions of every host that ran it. The disclosure treats a substrate node as any host that processes the agent and maintains a DDH computed under the identity update rules.

Each migration step is constructed by the same mutation mechanism used for single-host evolution. The executing host derives a host mutation token from its current DDH and a mutation class, and the agent computes its next successor identity by hashing the prior identity together with the host token, a freshness input, and a domain-separating tag. The freshness input may originate from a hardware anchor combined with a volatile salt, from a local state vector processed by a strong extractor, or from a hybrid of both unpredictability sources within the same step. These embodiments interoperate within a single cumulative path, so heterogeneous devices can participate in one agent's slope without weakening verifiability.

The resulting step is recorded as a structured lineage entry that contains the previous dynamic agent hash, the newly derived successor hash, the executing host's device hash, the associated mutation class, and a timestamp. Each entry is signed by the executing host, or authenticated with a MAC derived from the host's current DDH, and is then hashed into a cumulative chain value. Because the chain advances forward only, the slope preserves monotonic progression regardless of network topology or administrative boundaries.

The Cumulative Chain and Periodic Anchors

The cumulative chain is updated by hashing the prior cumulative value with the new per-entry digest. Any omission, modification, or reordering of any entry causes the terminal cumulative value to diverge, which is how tampering is detected. This is the property that makes the migration path tamper-evident rather than merely a list of recorded steps.

In size-bounded embodiments, periodic anchors are emitted after designated intervals by hashing the cumulative chain with the prior anchor. An anchor is a periodic digest over the lineage that supports compact proofs and long-term validation across extended migrations, so a slope that has crossed many hosts over a long migration can still be validated without replaying every intervening step. Optional scope tags may be included in entries to record policy domains, zones, or administrative boundaries, enabling federation without requiring centralized coordination.

Validating a Cumulative Slope

To validate a cumulative slope, a verifier requests a lineage proof window that spans one or more entangled steps and that opens against a previously trusted anchor or one of the provided periodic anchors. For each disclosed step the verifier performs the same checks: it checks the executing host's signature, verifies that the host mutation token opens to the disclosed device hash under local policy, recomputes the successor identity from the disclosed materials, and folds the per-entry digests into the cumulative chain. Acceptance occurs when the recomputed cumulative chain value matches the trusted anchor and each step conforms to policy-defined validity. Inconsistencies result in a tamper finding recorded to local memory.

The verification process is neutral to the unpredictability source employed by each host. Hardware-anchor embodiments enforce freshness through non-repeating salts; local-state embodiments enforce freshness through stability-tuned extractor outputs; hybrid embodiments bind both contributions, and an anomaly in either is sufficient for rejection. Because validation requires only replay from a stored trusted point using bounded disclosures and periodic anchors, the mechanism tolerates disconnected, asynchronous, and delay-tolerant operation without reliance on global consensus, synchronized ledgers, or central authorities.

Why Entanglement Carries the Security

The load-bearing property is that every mutation is bound to the device identity of the host that performed it. Each successor identity transition is anchored to a policy-validated device identity through a host-signed entanglement trace whose mutation token must open to the executing host's DDH under policy. Because the host's device identity is itself derived from non-exported unpredictability under the identity update rules, an attacker lacking the host's device entropy inputs cannot synthesize a valid mutation token or forge an acceptable entanglement entry.

Verification fails closed. A purported successor that lacks a coherent entanglement trace, that references an invalid host device identity, or whose mutation token cannot be reconciled with a valid host DDH under policy is rejected, and policy may require trust degradation or quarantine. By coupling agent identity evolution to host device identity in this way, the system prevents off-substrate mutation: an agent step cannot be manufactured by a party that did not actually execute the agent on a host whose device identity is on a valid slope.

Crossing Trust and Administrative Boundaries

When agents traverse trust or administrative boundaries, the scope tags included in lineage entries allow policy-aware verification. A verifier may require that certain steps, identified by specific scope tags, be corroborated by designated host roles or by quorum attestations before those steps are accepted. This lets independent trust domains enforce their own local acceptance criteria over the parts of the slope that fall within them, while the cumulative chain and anchors maintain cryptographic interoperability across the whole path. The result is end-to-end, cross-node provenance that is verifiable, replay-resistant, and tamper-evident using only local materials and bounded disclosures.

Relationship to the Surrounding Identity Substrate

Cumulative slope validation reuses the same primitives as the rest of the memory-native identity substrate rather than introducing separate machinery. The per-step construction is the agent mutation entanglement mechanism: a host maintains a current DDH, derives a host mutation token from that DDH and a mutation class, and the agent computes a DAH successor entangled to that token. The recorded steps are the same append-only mutation lineage entries used for single-host provenance, and the cumulative chain and anchors are the same forward-secure commitments used for bounded and delayed validation. Where a verifier lacks a recent anchor, it can use the bounded slope proofs and checkpoints described for delayed and sparse validation to replay the missing portion of the migration.

The construction composes with cryptographic primitives by using them as construction tools rather than as identity-bearing artifacts. The hash used to chain entries and the signature or MAC used by hosts to authenticate entanglement traces may be any suitable scheme; entanglement traces may be authenticated either with ephemeral signing keys destroyed upon rotation or with MACs keyed from values derived from the host's current DDH. In all cases the construction preserves the property that no persistent long-lived keypairs are required.

Prior-Art Distinction

Conventional approaches to validating a principal that moves across machines anchor identity in the long-term possession of a secret: a private key carried with the workload, a certificate chain rooted at a long-lived authority, or a registry entry that must be looked up. Cumulative slope validation departs from this by validating identity strictly as monotonic progression along a trust slope formed from local unpredictability and entanglement to the hosts that executed the agent. There is no persistent secret that, once captured, reproduces the identity, because a step's validity depends on a host-signed entanglement trace that opens to that host's device identity active at execution.

Append-only ledgers and audit logs share the structural element of a forward-secure chain but differ in two respects. First, conventional logs typically assume a single honest writer and are concerned mainly with preventing retroactive editing; here each step must additionally open to an independent host's device identity, so a single compromised writer cannot fabricate a coherent multi-host path. Second, conventional logs treat the chain as a record of actions taken by an externally identified principal, whereas here the entangled, anchored chain across substrates is the identity, validated by bounded replay against trusted anchors rather than by consulting an external registry or global consensus.

Disclosure Scope

This disclosure covers the cumulative validation of a semantic agent's identity slope as it migrates across multiple substrate nodes, in which each migration step is entangled to the executing host's Dynamic Device Hash through a host mutation token, with the agent computing its successor identity by hashing the prior identity with the host token, a freshness input, and a domain-separating tag; the recording of each step as a structured lineage entry containing the prior dynamic agent hash, the successor hash, the host device hash, a mutation class, and a timestamp, signed by the host or authenticated by a DDH-derived MAC; the folding of entries into a cumulative chain with periodic anchors emitted at designated intervals to support compact proofs over long migrations; the validation of a slope by requesting a lineage proof window, checking host signatures, confirming that each mutation token opens to its disclosed device hash, recomputing successors, and opening the recomputed chain against a trusted anchor; and the use of scope tags to permit policy-aware, role- or quorum-corroborated acceptance across trust and administrative boundaries. Embodiments that vary the per-step unpredictability source (hardware anchor with volatile salt, local-state vector with strong extractor, or a hybrid of both) are within scope, provided that each agent identity transition remains entangled to a valid host device identity and that validation proceeds by bounded replay against anchors rather than by reliance on persistent keypairs, external registries, or synchronized ledgers. This subject matter is disclosed in U.S. Application No. 19/388,580.