Agent-Substrate Slope Entanglement: Binding Every Mutation Step to Its Execution Host

Mechanism

Slope entanglement is the process by which an agent's successor identity is bound to the identity state of the host device that executed the agent's mutation. The disclosure defines it as the process by which an agent's successor Dynamic Agent Hash is bound to the executing host's contemporaneous Dynamic Device Hash via a host mutation token and a signed entanglement trace. A mutation event performed by an agent is entangled with the identity state of the host executing the mutation, creating a verifiable coupling between device identity and agent identity evolution.

A host node maintains a current Dynamic Device Hash (DDH) computed under the substrate's identity update rules, derived either from a hardware anchor plus a volatile salt, from a local state vector processed by an extractor, or from both. When a semantic agent carrying a prior Dynamic Agent Hash (DAH) is admitted to the host's execution context, the host prepares to entangle any mutation the agent initiates with its current DDH. The agent here is a cryptographically signed, memory-bearing data object: a protocol operand with a unique identifier, payload, memory field, transport header, and signature, extended in the semantic case with an intent field and cognition-compatible structure.

The two slopes are not symmetric. The device's slope advances under its own update rule; the agent's slope advances by consuming a value derived from the host's device identity. The coupling flows from host to agent through the host mutation token, and the entanglement is what a verifier later checks, not a single shared value that both parties compute the same way.

The Mutation Step

When the agent initiates a mutation, such as a role change, delegation, policy commit, or semantic state transition, the host computes a mutation class indicator and derives a host mutation token bound to its current DDH. The host mutation token may be calculated as a hash of the DDH, the mutation class, and an epoch identifier, and in some embodiments includes additional stability-tuned features of the host's entropy inputs.

The agent's successor identity is then computed as a hash of its prior identity, the host mutation token, an optional agent-side extractor output derived from agent memory and semantic context, a volatile per-epoch agent salt, and a domain-separating tag. In embodiments where the agent lacks its own extractor, the successor identity is computed without the agent-side token. Because the host mutation token is an input to the agent's successor, the agent cannot advance its slope through that mutation without a value that only the executing host, in possession of its current device entropy inputs, could have produced.

The Entanglement Trace

The host records an entanglement trace entry containing the prior agent identity, the host's current device identity, the mutation token, the resulting successor identity, and the mutation class. The host signs the entanglement entry, or authenticates it with a message authentication code derived from the host's DDH, and the agent appends the entry to its memory field. The agent then updates its cumulative commitment chain by hashing the prior commitment with the new entanglement entry, which gives the lineage forward-secure tamper evidence: omission, modification, or reordering of any entry causes the terminal cumulative value to diverge.

The entanglement trace is also called a lineage entry. Authenticating it does not require a persistent keypair. The host may use an ephemeral signing key minted per epoch and destroyed upon rotation, or a message authentication code keyed by a value derived from the host's current DDH under a domain-separated key derivation function, with that key scoped to a single host epoch. Either way, no long-lived secret material is retained, which is the sense in which the identity remains keyless.

Validation

A validator accepts the agent's successor identity only if the entanglement trace opens to the host's device identity under policy and the successor is a valid descendant of the prior identity. The verifier replays the mutation by checking that the successor identity is a valid derivation from the prior identity using the disclosed mutation token and salt, by verifying the host's signature or message authentication code, and by confirming that the mutation token corresponds to a DDH consistent with policy.

Verification fails closed. It is rejected if the host's signature or code is invalid, if the mutation token cannot be reconciled with a valid host DDH under policy, or if the successor identity is not a valid derivation from the predecessor. A purported successor that lacks a coherent entanglement trace, or that references an invalid host device identity, is rejected, and policy may require trust degradation or quarantine. A monitoring module may additionally detect invalid entanglement, cadence anomaly, neighborhood mismatch of extractor outputs, and stale salt, and act on any of those conditions.

Provenance Across Hosts

Agents that execute across multiple hosts accumulate a sequence of entanglement trace entries, forming a provenance path that links each agent-side identity transition to the host on which it occurred. Each entangled step records the prior identity, the resulting successor identity, the executing host's device hash, the mutation class, and a timestamp, with a host-generated signature or message authentication code. The accumulated steps form a cross-substrate slope that preserves forward-only progression regardless of network topology or administrative boundaries.

Each step is hashed into a cumulative chain value. In size-bounded deployments, periodic anchors are emitted after designated intervals by hashing the cumulative chain with the prior anchor, which enables compact proofs over long migrations. To validate a cumulative slope, a verifier requests a lineage proof window that opens against a previously trusted anchor, checks each host signature, verifies that each mutation token opens to the disclosed device hash under local policy, recomputes each successor from the disclosed materials, and folds the per-entry digests into the cumulative chain. Acceptance occurs when the recomputed chain value matches the trusted anchor. Optional scope tags may record policy domains, zones, or administrative boundaries, allowing a verifier to require that certain steps be corroborated by designated host roles or quorum attestations.

Independence From the Unpredictability Source

The entanglement mechanism is independent of whether the host uses hardware-anchor entropy, local-state extractor entropy, or a hybrid of both. In the hardware-anchor embodiment the host's DDH derives from a keyed function over a static hardware identifier and a fresh volatile salt. In the local-state embodiment it derives from a stability-tuned local state vector processed by a strong extractor. In the hybrid embodiment both contributions are combined in the same update step, and an anomaly in either source is sufficient to trigger rejection.

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. This holds across all three entropy sources, since the validator's checks operate on hashes, signatures or codes, and policy-bounded continuity rather than on any particular unpredictability primitive.

Policy Governance and Keylessness

A semantic agent may carry a policy reference to a policy agent that specifies quorum roles, voting weights, and eligibility for mutation validation. In that embodiment, entangled mutations are accepted only when the quorum roles, voting weights, and eligibility are consistent with the referenced policy. This places the acceptance of an entangled successor under governance that is itself memory-resolved, without introducing any persistent credential.

By coupling agent identity evolution to host device identity through verifiable entanglement traces, the system prevents off-substrate mutation, detects tampering, and ensures that each agent identity transition is anchored to a trusted and policy-validated device identity. None of this depends on a long-lived signing key. Entanglement traces are authenticated either with ephemeral signing keys destroyed upon rotation or with message authentication codes keyed from the host's current DDH, preserving the property that no persistent long-lived keypairs are required.

Disclosure Scope

Slope entanglement, comprising the host-derived mutation token, the agent successor computed from its prior identity and that token, the signed or message-authenticated entanglement trace recording the prior agent identity, host device identity, mutation token, successor identity, and mutation class, and the validator that accepts a successor only when the trace opens to the host's device identity under policy and the successor is a valid descendant of the predecessor, is disclosed in U.S. Application No. 19/388,580. This article describes that disclosed mechanism. The scope includes accumulation of entanglement traces into a cumulative chain hash with periodic anchors for cross-host provenance, authentication of traces by ephemeral signing keypairs minted per epoch and destroyed upon rotation or by DDH-derived message authentication codes scoped to a host epoch, and policy-agent governance of entangled mutations.

The scope extends across the hardware-anchor, local-state, and hybrid unpredictability sources, since the entanglement property is preserved across them. Constructions in which an agent advances its slope without consuming a host-derived mutation token, or in which a successor is accepted without an entanglement trace opening to the executing host's device identity, fall outside the disclosure because they do not produce the entanglement property.