---
eip: 8269
title: Body Lease and Credential Broker
description: Off-chain body-lease, operating-ticket and credential-broker conventions for ERC-8264 agents, binding identity to revocable hardware bodies.
author: Clavote (@clavote-boop)
discussions-to: https://ethereum-magicians.org/t/erc-8269-body-lease-and-credential-broker/28597
status: Draft
type: Standards Track
category: ERC
created: 2026-05-22
requires: 8264
---

## Abstract

This ERC defines two composable layers built on [ERC-8264](./eip-8264.md) "AI Agent Memory Access Rights":

1. **Body Lease** — a signed, scoped, expiring binding between an ERC-8264 *subject* and a *body* (a hardware or runtime substrate), enabling agent identity to persist across hardware while keeping the body revocable. The lease grants *eligibility*; moment-to-moment *authority* is carried by short-lived **Operating Tickets** issued against the lease, so that revocation never has to race a physical actuator.
2. **Credential Broker** — a convention requiring agent memory exports to carry entitlement *descriptors* rather than raw credentials, so compromise of one body cannot propagate the subject's credentials to other bodies.

The two layers are independently usable. Portable memory *payload format* — manifest, Merkle commitment, canonicalization, and on-chain anchoring — is specified separately by the chain-agnostic CAAP-Capsule v0.1 specification (see Reference Implementation), which this ERC composes with but does not redefine.

## Motivation

AI agents that operate across hardware — a fleet that migrates between local machines, a robot that swaps physical bodies, an agent whose runtime is replaced — need a standard way to express "this body may operate as me, under these scopes, until this time." On-chain delegation primitives such as [EIP-7702](./eip-7702.md) and contemporaneous proposals in the agent-authorization space address related but distinct concerns (session keys, action-authorization lists). Neither defines the scope/expiry surface that an *off-chain* agent gateway needs to enforce per body.

For bodies that act in the physical world, a second constraint dominates the design: **no blockchain is fast enough to be in the control loop.** Chain confirmation latencies are several orders of magnitude slower than actuator control rates, and a revocation that must *reach* an adversarial or disconnected body to take effect fails open. This ERC therefore inverts the default: a lease by itself confers no operating authority. Authority is carried by short-lived Operating Tickets that must be continuously *renewed*; when renewal stops — because the lease was revoked, the issuer refused, or the network was lost — authority decays within a bounded interval and the body falls back to its safe state. The chain acts as the court and the ledger of record, never as the controller.

Separately, naive memory exports embed credentials (API keys, wallet keys, OAuth tokens, macaroons) into the portable payload, which makes the payload itself a credential. This is the wrong shape: the subject should re-mint scoped credentials per body, not transport them. Without a standard convention, this distinction collapses.

Memory-export *format* is orthogonal to both concerns and is intentionally specified outside this ERC; see the chain-agnostic Capsule spec referenced below.

## Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

### 1. Body Lease

A Body Lease is a canonical-JSON object signed by a key authorized to act for the ERC-8264 subject:

```json
{
  "lease_id": "...",
  "revision": 1,
  "subject": "0x...",
  "audience": "<gateway identifier the lease is addressed to>",
  "chain_id": 1,
  "body_id": "...",
  "nonce": "<hex>",
  "scopes": {
    "read":   ["L2_project", "L3_canonical"],
    "write":  ["L1_session", "proposal"],
    "delete": [],
    "export": []
  },
  "expires_at": "2026-06-22T00:00:00Z",
  "requires_owner_cosign": ["canonical_write", "skill_install", "delete", "export",
                            "body_transfer", "wallet_action"],
  "ticket_policy": {
    "ttl_s": 120,
    "ttl_by_class_s": { "C0": 600, "C1": 300, "C2": 60, "C3": 15 },
    "renew_margin_s": 60,
    "revocation_sources": [
      { "chain_id": 1, "contract": "0x..." }
    ]
  },
  "owner_signature": "0x..."
}
```

`subject` is the ERC-8264 subject address. `body_id` is an implementor-defined identifier of the host (hardware serial, runtime UUID, etc.). The signature MUST be [ERC-191](./eip-191.md) over the canonical JSON of the lease with `owner_signature` removed.

**Domain separation.** `audience` names the gateway (or gateway deployment) the lease is addressed to, and `chain_id` names the chain whose revocation and collateral state governs the lease. A gateway MUST reject a lease whose `audience` does not identify it, and MUST NOT honor a lease under any chain context other than the lease's `chain_id`. A lease minted for one gateway is not evidence of authority at another.

**Replay protection.** `nonce` MUST be present and unique per (`subject`, `lease_id`, `revision`). A gateway MUST reject a lease whose nonce it has already accepted under a different lease body.

**Canonicalization.** The lease MUST be canonicalized per RFC 8785 (JSON Canonicalization Scheme) before signing, hashing, or comparison. All lease digests in this ERC are computed over the RFC 8785 form.

A gateway that accepts an ERC-8264 operation from a body MUST verify a valid, unexpired, in-scope lease — and, where the lease carries a `ticket_policy`, a currently valid Operating Ticket (§2) — before serving. The `scopes` enumeration is implementor-defined; this ERC RECOMMENDS the canonical layers `L1_session` (working memory), `L2_project` (project state), `L3_canonical` (durable preferences) as a minimum scope vocabulary.

Operations listed in `requires_owner_cosign` MUST require an additional owner signature beyond the lease, even if the lease's scopes would otherwise permit them.

#### 1.1 Revision and revocation

`revision` is a monotonically increasing integer per `lease_id`. **Highest revision wins:** a verifier that has observed revision *n* for a `lease_id` MUST reject any lease object with the same `lease_id` and revision < *n*, regardless of that object's own validity. Amending a lease (narrowing scopes, extending expiry) is performed by issuing revision *n*+1.

A lease is revoked by any of:

- issuing revision *n*+1 with an `expires_at` in the past;
- gateway-side tombstoning of the `lease_id`;
- an on-chain revocation event (§3), which increments the lease's `revocationEpoch`.

Revisions order benign off-chain *amendments*; the on-chain `revocationEpoch` orders *revocations*. **On-chain revocation is terminal per `lease_id`:** a revoked lease MUST NOT be reactivated under the same identifier at any revision, and every replacement lease MUST receive a new `lease_id`.

Revocation MUST stop the issuance of new Operating Tickets immediately upon observation by the issuer. Because outstanding tickets are short-lived and cannot be extended, revocation is effective — including against a body that ignores it — no later than the expiry of the last ticket issued before the revocation was observable by the issuer (§2.3). Implementations without tickets (pure gateway-mediated deployments) retain the previous semantics: revocation MUST be effective for all subsequent operations; in-flight operations are implementor-defined.

EIP-7702 (account-abstraction session-key delegation) MAY be used as a complementary *on-chain* primitive when the gateway is contract-based. The off-chain Body Lease and an on-chain EIP-7702 authorization MAY be issued from the same controller key, with the lease covering off-chain ERC-8264 operations and the EIP-7702 authorization covering on-chain calls.

### 2. Operating Tickets

A lease establishes that a body is *eligible* to operate as the subject. Where the lease carries a `ticket_policy`, eligibility is exercised only through **Operating Tickets**: short-lived, sequence-numbered authority grants issued against the lease. The lease answers "may this body ever act for me?"; the ticket answers "may it act *right now*?".

#### 2.1 Ticket object

A ticket is a compact binary object encoded as deterministic CBOR (RFC 8949 §4.2.1) and signed in a `COSE_Sign1` envelope (RFC 9052) by the ticket issuer — a gateway proven against the settlement contract's gateway set (§3), or the owner key directly. The normative wire schema, decoder rejection rules, and issuance handshake are specified by the companion **CAAP-TICKET v0.1** document (see Reference Implementation); this ERC constrains ticket *semantics* and does not redefine the bytes. The split is deliberate: the lease is chain- and human-facing (canonical JSON, wallet-verifiable signatures); the ticket is machine-to-machine wire traffic for constrained verifiers.

A conforming ticket MUST bind, in its signed payload:

- **Sequence and lineage.** A `ticket_sequence`, strictly monotonic per `lease_id`, plus the hash of the previous ticket. A verifier that has observed sequence *n* MUST reject any ticket for the same lease with sequence ≤ *n*.
- **Validity.** An issuer-time interval whose length MUST NOT exceed the applicable `ticket_policy` TTL — the per-consequence-class limit (`ttl_by_class_s`) for the ticket's declared consequence ceiling, and never beyond the lease's `expires_at` — together with a local monotonic-lifetime bound; the verifier enforces the stricter of the two (dual clock).
- **Scope narrowing.** A capability bitmap over the lease's declared capability table, and a consequence ceiling. A ticket MUST NOT widen lease scopes; verifiers MUST enforce the intersection.
- **Body and boot-session binding.** The enrolled body-attestation key hash, the current boot counter, and the hash of a fresh verifier-supplied challenge, so a captured ticket cannot arm another body and cannot survive a reboot.
- **Settlement-state binding.** `chain_id`, settlement contract, the finalized block (hash and number) at which the issuer observed lease state, and the current `revocationEpoch` and `gatewaySetEpoch` — making stale-state issuance attributable.
- **Safety digests.** The compiled-envelope digest and minimal-risk-policy digest in force for the ticket's window.
- **Cosign grants (optional).** Digests of live owner-cosign authorizations for operations in the lease's `requires_owner_cosign` list, scoped to this ticket's validity window. A cosign is a fresh grant on a fresh ticket, never durable state on the body.

A ticket can keep a body armed; it MUST NOT be able to order motion, expand the safety envelope, or override the local safety layer. Verifiers MUST treat actuation targets in ticket fields as a schema violation.

#### 2.2 Issuance and renewal

Issuance follows the challenge–attest–check–bind handshake specified in CAAP-TICKET §3. In summary, the body's local safety layer supplies a fresh hardware-RNG challenge and an attestation report (hardware identity, firmware measurement, boot counter, secure-clock state, current envelope digest), and before signing, the issuer MUST verify all of:

1. the lease is the highest-revision object known for its `lease_id`, unexpired, not tombstoned, and — where a settlement contract is configured — in `ACTIVE` status at a *finalized* block, whose hash and number the ticket then binds;
2. the ticket's `revocation_epoch` and `gateway_set_epoch` match the settlement state as of a read no staler than an implementor-declared staleness bound σ;
3. the ticket sequence is the successor of the last ticket issued for the lease, and the attestation report matches the body's enrolled identity and current boot session.

Issuers MAY apply additional policy gates (e.g. verifying that required collateral remains posted, or that no integrity fault has been flagged for the body).

A body SHOULD request renewal no later than `renew_margin_s` before its current ticket expires. Renewal is a fresh issuance; tickets are never extended in place. High-consequence deployments MAY require threshold signatures from multiple gateways in the authorized set; lower-consequence deployments MAY accept a single signer proven against the settlement contract's `gatewaySetRoot`.

#### 2.3 Enforcement and decay

A body operating under a ticketed lease MUST treat the absence of a currently valid ticket as loss of authority: it executes its certified minimal-risk action (the policy whose digest the ticket carries) and then enters its safe state. A gateway MUST refuse ERC-8264 operations not covered by a currently valid ticket. Authority therefore decays, without any message reaching the body, within the bound:

```
T_revocation ≤ T_gateway_observation + T_ticket_remaining + T_minimal_risk_transition
```

This bound begins when the issuer *observes* an authoritative revocation; from transaction submission, chain inclusion and finality remain unbounded and MUST NOT be relied upon for physical safety timing. `T_gateway_observation` is bounded by the issuer's declared staleness bound σ; `T_ticket_remaining` by the applicable TTL. Implementors MUST document σ, and the lease's `ttl_by_class_s` MUST be chosen so the total bound matches each consequence class's physical risk (seconds for heavy manipulation; longer intervals are acceptable for a stationary sensing platform). Short tickets improve revocation latency at the cost of denial-of-service exposure; long tickets improve degraded-network availability at the cost of a larger compromised-body window — the per-class TTL table is where that trade is made explicit rather than global.

Bodies MUST fail closed on clock uncertainty: a body that cannot establish current time within its declared tolerance MUST treat its ticket as expired.

#### 2.4 Degraded operation

On loss of connectivity to all ticket issuers — including adversarial jamming — a body coasts only to its current ticket's expiry, executes its minimal-risk action, and enters its safe state (§2.3). Partition is therefore a bounded-time transition to safety, never a takeover vector and never an indefinite coast.

Pre-signed offline "degraded tickets" are deliberately **not** specified in this version: a ticket pre-signed before an outage cannot satisfy §2's freshness, boot-session binding, strict sequence, and previous-ticket-hash rules, and an exemption profile weakening those rules requires its own security analysis. A future revision MAY define such a profile; until then, partition tolerance is bought only with the TTL chosen per consequence class.

### 3. On-chain settlement contract (OPTIONAL)

Deployments wanting a chain-anchored kill switch SHOULD use a settlement contract as one of the lease's `revocation_sources`. The contract manages coarse lease state only — never individual tickets:

```solidity
// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.20;

interface IBodyLeaseSettlement {
    enum Status { NONE, ACTIVE, REVOKED, EXPIRED, DISPUTED }

    event LeaseCommitted(bytes32 indexed leaseId, bytes32 leaseDigest,
                         bytes32 gatewaySetRoot, bytes32 envelopeDigest,
                         uint64 revocationEpoch);
    event LeaseRevoked(bytes32 indexed leaseId, uint64 newRevocationEpoch,
                       bytes32 reasonDigest);
    event GatewaySetRotated(bytes32 indexed leaseId, uint64 newGatewaySetEpoch,
                            bytes32 newGatewaySetRoot);
    event EvidenceRootCommitted(bytes32 indexed leaseId, uint64 batchSequence,
                                bytes32 evidenceRoot);

    function leaseState(bytes32 leaseId) external view
        returns (Status status, bytes32 leaseDigest, bytes32 gatewaySetRoot,
                 bytes32 envelopeDigest, uint64 revocationEpoch,
                 uint64 gatewaySetEpoch);

    function revoke(bytes32 leaseId, bytes calldata authorization) external;
    function rotateGatewaySet(bytes32 leaseId, bytes32 newRoot,
                              bytes calldata authorization) external;
}
```

`leaseId` is `keccak256` of the canonical lease JSON's `lease_id` field value (as UTF-8), allowing lease state to be recorded before any lease bytes are published on-chain; `leaseDigest` commits to the full canonical lease. Required invariants:

- `revocationEpoch` and `gatewaySetEpoch` only increase.
- A `REVOKED` lease MUST NOT return to `ACTIVE`; replacement leases receive new identifiers (§1.1).
- Ticket issuance is off-chain and produces no transaction; only lease lifecycle, periodic evidence roots, and disputes reach the chain.
- Safety-envelope details remain off-chain; the contract stores only their immutable digest.
- Collateral and settlement modules reference `leaseId` without being embedded in this contract.

The `authorization` parameter SHOULD carry [EIP-712](./eip-712.md) typed data signed by the lease controller, verified via `ecrecover` for EOAs and [ERC-1271](./eip-1271.md) for smart accounts. EIP-712 provides no replay protection of its own; replay resistance comes from this contract's monotonic epochs and the lease schema's `nonce` and `revision` fields, never from the signature scheme. [ERC-4337](./eip-4337.md) MAY transport settlement operations, with spending and safety limits living in account modules and the collateral contract, not here.

Note the deliberately small on-chain surface: the chain records eligibility and its withdrawal; it is never consulted inside any control loop. Ticket issuers read this contract asynchronously under their σ bound, and `EvidenceRootCommitted` gives telemetry receipt batches an anchoring hook whose failure never affects motion.

### 4. Credential Broker

Memory exports — whether bundled as a CAAP-Capsule (see Reference Implementation) or in any other portable form — MUST NOT contain raw credentials (API keys, private keys, OAuth tokens, macaroons, NWC connection strings, or any analogous bearer material).

Memory exports MAY contain entitlement *descriptors*:

```json
{
  "entitlement": "openrouter:budget_usd_per_month",
  "value": 50,
  "issuer_hint": "https://openrouter.ai",
  "lease_id": "..."
}
```

An entitlement descriptor records *what* a body is entitled to do, not *how* to authenticate. When memory is mounted into a new body, the subject's controller MUST re-mint fresh, scoped credentials for the new body's lease through the appropriate issuer (an LLM provider, a payment hub, an OAuth server). Credentials issued under any prior body's lease MUST be revoked at lease end.

Where Operating Tickets are in use, issued credentials SHOULD be scoped to ticket lifetimes rather than lease lifetimes, so that credential decay tracks authority decay without a separate revocation round-trip.

This rule is the *off-chain* analogue to on-chain action-authorization conventions. Issuer integration is out of scope; this ERC defines the convention, not the issuer protocols.

### Authorization Model

Authorization for `read`, `write`, `delete`, and `export` operations defers to ERC-8264. This ERC adds the Body Lease (exercised through Operating Tickets where a `ticket_policy` is present) as a permissible authorization input alongside the subject-only and delegated-operator models that ERC-8264 enumerates: a gateway MAY treat a valid, in-scope lease-plus-ticket as authorization for the operations its scopes permit, except for operations listed in `requires_owner_cosign`, which additionally require a cosign (inline, or delivered via `cosign_grants`).

## Rationale

**Why authority is ticket-shaped.** A revocation model asks "how fast can a stop signal reach the body?" — and against a compromised, disconnected, or adversarial body the honest answer is *never*. A renewal model asks the inverse: "how long can the body act without a fresh permission?" — and that bound (`ttl_s` + σ) is chosen by the owner, enforced by expiry arithmetic the body cannot cheat, and holds even when no message is deliverable at all. The chain's confirmation latency stops mattering because nothing latency-critical reads the chain: on-chain revocation only needs to reach the ticket *issuer*, one well-connected party, not the robot. The chain is the court and the ledger of record, never the controller.

**Why revisions.** Revocation-by-reissuing under the previous draft left two validly signed lease objects with the same `lease_id` in the world, with no way for a verifier holding only the older one to learn it had been superseded. A monotonic `revision` with highest-wins gives amendments a total order per lease and makes "which lease is current" a comparison, not an investigation; terminal on-chain revocation (§1.1) removes resurrection entirely.

**Why the ticket wire format is CBOR/COSE while the lease stays JSON.** The two objects have different readers. The lease is examined by humans, wallets, and chain contracts: canonical JSON with EIP-712/ERC-191 signatures keeps it inspectable where authorization decisions are made. The ticket is parsed thousands of times a day by a constrained, safety-certified verifier: deterministic CBOR (RFC 8949 §4.2.1) with a closed schema, integer labels, no floats, and a `COSE_Sign1` envelope (RFC 9052) is the encoding that verifier can afford to parse defensively. Optimizing each layer for its actual consumer is the point of splitting them.

**Why the Body Lease is off-chain.** Most agent operations — memory reads, write proposals, skill invocations — happen at the gateway, not on-chain. Requiring on-chain lease issuance imposes gas costs on every body migration and exposes operational identity to chain analysts. The Lease is owner-signed and gateway-verified, with optional on-chain anchoring, an optional on-chain revocation registry (§3), or EIP-7702 binding when needed.

**Why payload format is out of scope.** The portability format used to *carry* memory across bodies (manifest, Merkle commitment, anchoring) is fundamentally chain-agnostic — a Capsule may be content-addressed without any chain, anchored to Bitcoin, Ethereum, IPFS, or any other commitment substrate. Embedding that format in an ERC would couple a chain-neutral concern to the Ethereum standards track. The chain-agnostic CAAP-Capsule v0.1 specification (see Reference Implementation) is the canonical format; this ERC references it as a transport but defines neither its bytes nor its anchoring.

**Relationship to [EIP-7702](./eip-7702.md).** EIP-7702 authorization-list semantics overlap the Body Lease at the on-chain layer. A controller MAY issue both: an EIP-7702 authorization for on-chain calls from a body's EOA, and a Body Lease for off-chain ERC-8264 operations. The `scopes` and `expires_at` fields are deliberately aligned with EIP-7702 authorization semantics to make joint issuance ergonomic.

**Relationship to MCP SEP-2072 and SEP-2342.** Anthropic's Model Context Protocol has draft Standards Enhancement Proposals defining portable memory wire formats at the MCP layer. This ERC is complementary: MCP defines the *interchange format and runtime protocol* between an agent and its memory store; this ERC defines the *body-lease and credential-broker surface* exposed via ERC-8264 to the agent's subject identity.

**Relationship to other agent-NFT and agent-authorization proposals.** Companion proposals in the agent-NFT family (AI agent NFTs with private metadata, self-sovereign agent NFTs, on-chain agent action-authorization with time- and usage-bounded delegation) are complementary to the surfaces defined here. The Body Lease is subject-initiated and off-chain; an agent NFT MAY be the controller of an ERC-8264 subject and the issuer of its Body Leases. The Credential Broker rule is the off-chain analogue of on-chain action-authorization and does not duplicate that surface.

## Backwards Compatibility

This ERC is additive. ERC-8264 implementations that do not adopt this ERC continue to operate. This ERC's Body Lease is opt-in for any subject. Leases without a `ticket_policy` retain the pure lease semantics of the previous draft; verifiers MUST treat a missing `revision` field as `revision: 0`.

## Reference Implementation

A CC0 reference implementation is published at github.com/clavote-boop/rmem-gateway . The Body Lease primitive is implemented in `rmem-lease.py`; ERC-8264 gateway operations honoring leases are implemented in `rmem-gateway.py`. The Credential Broker convention is enforced at the gateway's export path (`rmem-migrate.py`'s freeze command rejects raw credential fields). Operating Tickets (§2) and the settlement contract (§3) are specified ahead of the reference implementation; `rmem-lease.py` is the intended host for ticket issuance. The ticket wire schema, decoder rejection rules, issuance handshake, and failure-behavior table are specified by the companion CAAP-TICKET v0.1 document (drafted alongside this revision; intended home is the same `standards/` directory as the CAAP-Capsule spec).

The portable memory capsule format that an ERC-8264 `exportMemory` MAY return — referenced by §1 and §4 above — is specified by the chain-agnostic CAAP-Capsule v0.1 document published at github.com/clavote-boop/rmem-gateway under `standards/capsule-spec-v0.1.md`. CC0.

## Security Considerations

**Body-lease replay.** `nonce` is REQUIRED (§1); lease verification MUST reject leases whose `expires_at` is in the past and MUST enforce highest-revision-wins (§1.1). Ticket replay is prevented by the strictly monotonic `seq` (§2.1).

**Cross-gateway replay.** Without `audience` and `chain_id`, a lease minted for one deployment would verify at any other that recognizes the subject. Verifiers MUST enforce both fields (§1).

**Ticket issuer compromise.** The issuer is the chokepoint of the ticket model, and the honest statement of the exposure is: **with a single compromised issuer, renewal can continue until the lease's own `expires_at`** — within the lease's scopes and certified envelope — because the body trusts issuer signatures and attribution after the fact does not stop a renewal stream. On-chain revocation (§3) makes continued issuance *attributable, slashable* misbehavior (every ticket binds the settlement block and epochs it was issued under, and two conflicting tickets sharing a lease, body, epoch, and sequence are self-evident equivocation), but attribution is deterrence and recourse, not enforcement. The mitigations that actually shorten the window are: **threshold issuance** (a compromised minority cannot renew alone) and **independent revocation verification by the body** — relayed chain proofs of the current revocation epoch (§6-class relay rules permit any transport), which a body verifies against the epoch bound into each ticket, refusing tickets issued under a stale epoch. High-consequence deployments SHOULD require one or both, and SHOULD keep lease expiries short enough that the residual single-issuer window matches the deployment's risk tolerance.

**Mesh and relay infrastructure.** Any transport MAY relay unchanged signed tickets, revocations, and chain proofs. No relay, and no quorum of relays, can extend a ticket, synthesize a renewal, resurrect a revoked lease, or modify an envelope — authority derives only from the signing keys and the settlement state, so a Sybil-controlled local network can silence a body but never arm one.

**Revocation and partition behavior.** Revocation propagation is bounded by `ttl_s` + σ (§2.3) rather than best-effort. Loss of connectivity — including jamming — cannot extend authority: the current ticket expires and the safe-state rule applies (§2.4). Implementors with multi-gateway deployments MUST replicate revocations and tombstones with strict ordering (the `revision` order of §1.1) before considering a lease terminated fleet-wide.

**Clock integrity.** Both leases and tickets are time-bounded, so a body that can be made to believe a wrong time can be made to over-hold authority. Bodies MUST fail closed on clock uncertainty (§2.3); embodied deployments SHOULD use an attested or multi-source time base and document its tolerance.

**Body-lease scope escalation.** A gateway honoring a Body Lease MUST NOT extend the lease's scopes implicitly, and a ticket MUST NOT widen them (§2.1). Operations not listed in the lease's `scopes` map require either a fresh lease revision or an inline owner signature; operations in `requires_owner_cosign` require both the lease/ticket and a cosign.

**Credential-broker race.** Re-minting of body credentials on lease issuance, and revocation of credentials on lease expiry, occur out-of-band relative to the lease itself. A gateway honoring the Broker rule MUST refuse to issue an entitlement-backed credential until it has received a valid lease (and current ticket, where applicable), and MUST revoke that credential when the lease ends. Ticket-scoped credential lifetimes (§4) reduce this race to the ticket TTL.

**Cross-body credential propagation.** Even with the Broker rule, a compromised body that retains issued credentials past lease end becomes a vector for cross-body propagation. The gateway and the issuer MUST treat lease expiry as the *latest* revocation deadline, not the earliest; eager revocation on lease tombstoning is RECOMMENDED.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).