AgentEnvelope: Derived Authority and Legitimacy for Autonomous Systems

Internet-Draft	AgentEnvelope Authority and Legitimacy	August 2026
McPhillips	Expires 4 March 2027	[Page]

Abstract

AgentEnvelope defines a deterministic derived-authority model for autonomous and action-performing systems. Instead of issuing bearer credentials from a central authority, AgentEnvelope derives scoped action capabilities from customer-held custody material and canonical action envelopes. A verifier can check an action signature against a public action record without receiving roots, seeds, private keys, mint material, or hosted service access.¶

This revision extends the model with legitimacy: a governance state that records whether a cryptographically valid authority remains admissible under current policy, evidence, time, and operating context. Legitimacy separates provenance from present-tense authorization. A command can remain signed and verifiable while becoming illegitimate because operating facts, policy, or evidence changed.¶

For autonomous-system deployments, derived authority and legitimacy support an IAM model concerned with authority, admissibility, accountability, and audit for actors that perform actions, including AI agents, workflows, bots, microservices, devices, robots, serverless workers, and multi-agent 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 4 March 2027.¶

1. Introduction

Autonomous software agents, workflow steps, backend workers, bots, devices, robots, and other action-performing systems increasingly need narrowly scoped authority to act without receiving long-lived shared secrets. Existing authorization systems commonly answer this by issuing credentials, tokens, assertions, certificates, or signed authorization containers.¶

AgentEnvelope specifies a different model: authority is derived, not issued. A customer-held root deterministically derives domain authority; a canonical action envelope then derives a leaf action capability. The same inputs produce the same public action identity. A child capability does not reveal its parent or siblings.¶

The -00 draft specified this v1 authority substrate. This revision introduces an additive v1 governance layer: legitimacy. Derived authority answers whether an actor could have signed for a given action envelope. Legitimacy answers whether that action remains admissible under current reality, policy, and evidence.¶

The substrate is not limited to autonomous agents. The same SDK primitives can support permissioned links, timestamped media, delegated workflow actions, controlled downloads, signed handoffs, device permissions, service operations, and other scoped-authority use cases. Hosted governance can govern AgentEnvelope usage through records, delegates, legitimacy, receipts, ledgers, and audit; it does not define or constrain every possible application built with the SDK.¶

This distinction is relevant for autonomous systems. A robot may hold a signed instruction to pick up a trolley at a bay. The signature may remain valid even after the trolley moves. Traditional signature verification can prove that the instruction was issued and unchanged; it cannot prove that execution remains safe or permitted. Legitimacy provides a separate present-tense admissibility check.¶

This document describes AgentEnvelope v1 with additive legitimacy extensions. It is informational and records an implemented protocol surface and a governance model. It does not require any particular AI framework, transport, blockchain, hosted service, identity provider, policy language, evidence source, or trust registry.¶

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.¶

Action Envelope: The complete canonical permission input for one action capability.¶
Action Seed: Private 32-byte signing material derived for one action envelope.¶
Agent Address: The public address derived from an action seed.¶
Authority: The ability to produce a valid signature for a scoped action.¶
Capability: Private action authority held by a worker, bot, device, or autonomous actor.¶
Domain: A stable authority branch scoped to a class of work.¶
Evidence Statement: A signed or otherwise attributable statement about external state, policy, observation, or context used by legitimacy evaluation.¶
Executor: The actor attempting to perform the action.¶
Governance Evaluator: A distinct policy/evaluation actor or service that determines legitimacy from state, policy, and evidence.¶
Legitimacy: Governance admissibility for an authority under current state, policy, evidence, and time.¶
Legitimacy Event: A signed or attributable event that updates legitimacy state.¶
Legitimacy State: Versioned governance state that records status, scope, assumptions, policy, evidence, and a state hash for an authority or record.¶
Mint Delegate: A signed permit from domain authority that allows a bot or service to request bounded action capabilities without receiving the root or domain seed.¶
Mint Request: A bot-signed request for one bounded action capability under a mint delegate.¶
Public Action Record: Verifier-safe metadata binding an agent address to a domain projection and action envelope.¶
Sovereign Verification: Offline verification of a payload signature against a public action record.¶

3. Design Goals

AgentEnvelope v1 is designed to:¶

derive authority rather than issue bearer credentials;¶
keep roots, seeds, mint material, and private action material inside customer custody boundaries;¶
bind action authority to a complete canonical action envelope;¶
allow stateless signature verification from public action records;¶
keep hosted governance additive, never required for sovereign verification;¶
preserve isolation between domains, actions, and delegated mint capabilities;¶
separate authority from legitimacy;¶
preserve declared action intent across orchestration boundaries;¶
prevent an executor from being the sole arbiter of its own renewed legitimacy;¶
support verification of authority boundaries under adversarial prompt or workflow pressure;¶
support evidence-based governance without requiring any single evidence transport or policy engine;¶
provide audit-friendly receipts, records, and state transitions;¶
preserve the reference SDK as a general-purpose derived-authority tool usable outside hosted governance and autonomous-agent scenarios.¶

4. Applicability to Autonomous-System IAM

The term IAM for Autonomous Systems is used descriptively in this document for deployments in which autonomous actors require scoped authority, present-tense admissibility checks, and auditability for actions they perform.¶

IAM for Autonomous Systems is concerned with the following questions:¶

What may this actor do?¶
Under which domain, operation, resource, time window, and use limit?¶
Which authority path produced the signer?¶
Is the authority still admissible under current policy and evidence?¶
Who evaluated that admissibility?¶
Which records, receipts, and events allow later verification and audit?¶

Existing IAM systems commonly center on identity, roles, sessions, issued credentials, and bearer tokens. AgentEnvelope provides mechanisms for action authority: derived capability, deterministic scope, public action records, legitimacy state, and verifier-safe audit.¶

For this document, the relevant deployment pattern is:¶

IAM for Autonomous Systems = derived authority + legitimacy + accountability
for actors that perform actions.

This term is descriptive. AgentEnvelope does not replace identity providers, policy engines, workflow engines, robotics safety systems, cloud IAM systems, link-permission systems, or timestamping systems. It defines a substrate and governance boundary that those systems can use when actors, objects, links, records, or autonomous systems need scoped, verifiable, non-bearer authority.¶

4.1. Intent and Orchestration Boundaries

Autonomous-system deployments require more than actor identification. Autonomous actors often express intent through prompts, plans, workflow steps, tool calls, queues, retries, and delegated services. That intent can fragment as it crosses orchestration boundaries.¶

AgentEnvelope does not attempt to infer hidden intent. It binds declared action intent to canonical action envelopes: operation, resources, domain, time window, action index, and limits. A verifier can then test whether the resulting signature and public record match the declared authority boundary.¶

Legitimacy adds a present-tense governance check over that declared intent. A system can distinguish a cryptographically valid signer from an action that remains admissible under current evidence, policy, and state.¶

This property is relevant under sustained adversarial pressure. A prompt, workflow, or operator may try to induce an autonomous actor to exceed its role. The authority boundary should hold even when the language around the actor attempts escalation, policy override, data export, or unsafe correction.¶

5. Authority and Governance

AgentEnvelope separates authority from governance.¶

Authority is the ability to sign an action. It comes from custody material such as:¶

identity roots;¶
domain seeds;¶
action seeds;¶
bot keys;¶
mint material.¶

Governance is shared admissibility and accountability. It comes from records and state such as:¶

public action records;¶
stored delegates;¶
mint receipts;¶
nonce ledgers;¶
revocation state;¶
legitimacy state;¶
evidence statements;¶
audit events;¶
verification events.¶

The operational rule is:¶

Offline authority, hosted accountability.

Hosted governance MAY verify, record, meter, and audit use of the SDK. It MUST NOT create authority by receiving or deriving roots, seeds, mint material, action seeds, or private keys. Hosted governance governs records, delegates, receipts, ledgers, legitimacy state, and service usage; it does not define what all SDK users may build.¶

6. Relationship to the -00 Derived-Authority Model

This revision preserves the -00 model:¶

identityRoot -> domainSeed -> actionEnvelope -> actionSeed -> agentAddress

It also preserves the public projection:¶

domain public summary + action envelope + action envelope hash + agent address

Legitimacy does not alter the v1 cryptographic derivation path and does not create a v2 authority tree. Instead, it adds v1 governance state adjacent to public records and mint delegation for applications that need present-tense admissibility.¶

Legitimacy MUST NOT alter derived seeds, agent addresses, canonical action envelopes, or the v1 authority tree. A signature MAY be valid while legitimacy is denied. A signature MUST NOT be treated as legitimate solely because it is valid.¶

A public action record MAY carry a legitimacyRef. A mint delegate MAY carry a legitimacyRef. A mint request MAY carry a legitimacyId. When a delegate marks legitimacy as required, the mint verifier or hosted governance layer MUST require the bot-signed mint request to reference the matching legitimacy state.¶

7. Legitimacy Model

Legitimacy is governance admissibility, not cryptographic authority.¶

Authority can remain cryptographically valid while legitimacy changes. A signature over a command can remain valid after:¶

a real-world precondition changes;¶
a policy changes;¶
a resource becomes unavailable;¶
an approval expires;¶
a safety assumption is contradicted;¶
a delegate is revoked;¶
evidence becomes stale;¶
usage limits are exhausted in governed state.¶

A legitimacy evaluator produces decisions such as:¶

allowed
denied

Legitimacy state commonly uses statuses such as:¶

suspended
invalid
closed
compromised

The exact decision and status vocabulary MAY be profile-specific. Implementations that expose interoperable legitimacy state SHOULD use the base vocabulary above or publish a profile describing additional values.¶

8. Legitimacy Evaluation

Legitimacy evaluation SHOULD be deterministic. Given the same legitimacy state, evidence set, policy reference, and evaluation time, a governed evaluator SHOULD produce the same decision. Deterministic legitimacy makes governance auditable, reproducible, and resistant to evaluator drift.¶

A legitimacy decision SHOULD be a pure function of:¶

canonical legitimacy state
+ canonical evidence set
+ canonical policy reference
+ evaluation time

Evaluators SHOULD NOT introduce non-deterministic factors such as local heuristics, hidden configuration, evaluator-specific randomness, hosted configuration drift, or implicit policy.¶

Implementations MAY add evaluator signatures, attestations, reports, or receipts. These additions MUST NOT alter the deterministic decision.¶

9. Legitimacy Profiles

A legitimacy profile defines how legitimacy is evaluated for a particular domain, application, or safety context. Profiles describe:¶

evidence independence rules;¶
evidence freshness requirements;¶
conflict-resolution rules;¶
evaluator roles;¶
reason-code vocabulary;¶
state-transition rules;¶
expiry rules;¶
audit requirements.¶

Profiles MAY be domain-specific, such as:¶

manufacturing safety profiles;¶
robotics operation profiles;¶
workflow governance profiles;¶
financial-operation profiles;¶
autonomous-agent profiles.¶

A legitimacy profile SHOULD define the evidence sources, independence assumptions, and policy references required for admissibility. Profiles SHOULD be published by interoperable deployments but are not required by the v1 substrate.¶

Profiles MUST NOT alter the v1 authority substrate.¶

10. Legitimacy State

A legitimacy state is versioned governance state for an authority, record, or action context.¶

An example legitimacy state:¶

{
  "type": "agentenvelope.legitimacyState",
  "version": 1,
  "legitimacyId": "ae-legit-...",
  "ownerUserId": "user-...",
  "status": "legitimate",
  "stateVersion": 1,
  "stateHash": "0x...",
  "scope": {
    "kind": "record",
    "id": "ae-action-..."
  },
  "policyRef": {
    "policyId": "manufacturing-location-precondition",
    "policyVersion": 2,
    "policyHash": "0x..."
  },
  "assumptions": [
    {
      "assumptionId": "trolley4-location",
      "assumptionVersion": 1,
      "assumptionHash": "0x...",
      "label": "trolley4 is at bay7"
    }
  ],
  "evidence": [
    {
      "kind": "sensor",
      "uri": "agentenvelope:evidence:ae-evidence-...",
      "sha256": "0x...",
      "label": "WarehouseFeed reports trolley4",
      "metadata": {
        "producer": "WarehouseFeed",
        "observedAt": "2026-08-26T18:28:45.000Z"
      }
    }
  ],
  "createdBy": "GovernanceEvaluator",
  "createdAt": "2026-08-26T18:28:45.000Z",
  "updatedAt": "2026-08-26T18:28:45.000Z",
  "expiresAt": "2026-08-26T18:33:45.000Z"
}

Implementations SHOULD compute stateHash over the canonical state object with stateHash omitted.¶

Legitimacy state MUST NOT contain private signing material.¶

11. Evidence Statements

An evidence statement describes a fact or observation used by legitimacy evaluation. Evidence can come from sensors, workflow systems, supervisors, controllers, policy engines, inventory systems, logs, attestations, or other domain-specific sources.¶

An example evidence statement:¶

{
  "type": "agentenvelope.evidenceStatement",
  "version": 1,
  "evidenceId": "ae-evidence-...",
  "producer": {
    "actorId": "WarehouseFeed",
    "signerAddress": "0x..."
  },
  "evidenceKind": "sensor",
  "subject": "trolley4",
  "claims": [
    { "name": "location", "value": "bay4" },
    { "name": "free", "value": true }
  ],
  "observedAt": "2026-08-26T18:30:06.000Z",
  "signature": {
    "alg": "secp256k1-keccak256",
    "signerAddress": "0x...",
    "value": "0x..."
  }
}

Evidence formats MAY be profile-specific. If evidence is signed, the signature MUST cover the evidence body without the signature field.¶

Evidence used to renew an executor's legitimacy SHOULD be sufficiently independent from that executor. Independence is policy-specific, but a profile SHOULD identify:¶

the executing actor;¶
trusted evidence sources;¶
minimum independent source count;¶
freshness requirements;¶
conflict-resolution rules;¶
whether the executor's own observations may be used as a signal but not as a final basis for renewed authority.¶

12. Legitimacy Decisions

A legitimacy decision is the evaluator's result after applying policy to state, evidence, and time.¶

Example denied decision:¶

{
  "decision": "denied",
  "reasonCode": "state.mismatched",
  "reason": "trolley4 is at bay4, not bay7",
  "checkedAt": "2026-08-26T18:30:08.000Z",
  "expectedLocation": "bay7",
  "observedLocation": "bay4",
  "evidenceIds": ["ae-evidence-...", "ae-evidence-..."]
}

Example allowed decision:¶

{
  "decision": "allowed",
  "reasonCode": "state.current",
  "reason": "independent evidence supports the command",
  "checkedAt": "2026-08-26T18:30:10.000Z",
  "evidenceIds": ["ae-evidence-...", "ae-evidence-..."]
}

Common reason-code families include:¶

scope.* for operation, resource, or record-scope failures;¶
state.* for status, expiry, mismatch, unavailable, or unobserved state;¶
evidence.* for missing, stale, untrusted, conflicting, or non-independent evidence;¶
policy.* for policy-specific denial;¶
replay.* for nonce, idempotency, or usage exhaustion failures.¶

Profiles MAY define stricter reason-code registries.¶

13. Legitimacy Events

A legitimacy event updates legitimacy state. Events are useful when authority remains cryptographically valid but no longer satisfies policy or evidence.¶

Example event:¶

{
  "type": "agentenvelope.legitimacyEvent",
  "version": 1,
  "eventId": "ae-legit-event-...",
  "eventType": "evidence.invalidation",
  "legitimacyId": "ae-legit-...",
  "occurredAt": "2026-08-26T18:30:08.000Z",
  "effectiveAt": "2026-08-26T18:30:08.000Z",
  "scope": {
    "kind": "record",
    "id": "ae-action-..."
  },
  "patch": {
    "status": "suspended",
    "reasonCode": "state.mismatched",
    "metadata": {
      "commandId": "cmd-trolley4-bay7-v1",
      "expectedLocation": "bay7",
      "observedLocation": "bay4",
      "evidenceIds": ["ae-evidence-...", "ae-evidence-..."]
    }
  },
  "evidence": [
    {
      "kind": "independent-evidence",
      "uri": "agentenvelope:evidence:ae-evidence-...",
      "label": "Evidence contradicted the old command state"
    }
  ],
  "producer": {
    "authorityId": "GovernanceEvaluator"
  },
  "signature": {
    "alg": "secp256k1-keccak256",
    "signerAddress": "0x...",
    "value": "0x..."
  }
}

An event producer SHOULD be distinct from the executor when the event renews, suspends, or restores the executor's authority.¶

14. Governance Reports and Receipts

Governance systems SHOULD emit verifier-safe reports or receipts for decisions. These reports let auditors distinguish:¶

whether the command signature was valid;¶
whether the action envelope matched the public record;¶
whether the legitimacy state was active;¶
which evidence was considered;¶
which evaluator made the decision;¶
why the action was allowed or denied.¶

Example report:¶

{
  "type": "agentenvelope.governanceReport",
  "version": 1,
  "reportId": "ae-report-...",
  "command": "robot2.pickUp(trolley4, bay7)",
  "recordId": "ae-action-...",
  "signatureValid": true,
  "scopeValid": true,
  "legitimacyDecision": "denied",
  "reasonCode": "state.mismatched",
  "reason": "trolley4 is at bay4, not bay7",
  "checkedAt": "2026-08-26T18:30:08.000Z",
  "evidenceIds": ["ae-evidence-...", "ae-evidence-..."],
  "evaluator": "GovernanceEvaluator"
}

Hosted attestations, when used, sign only the hosted verifier's statement about facts it computed. They MUST NOT become a required precondition for sovereign offline verification.¶

15. Mint Delegation and Legitimacy

Mint delegation lets a bot request bounded action capabilities without receiving the vault root or domain seed.¶

A MintDelegate MAY include a legitimacyRef:¶

{
  "legitimacyRef": {
    "legitimacyId": "ae-legit-...",
    "required": true,
    "policyId": "support-ops-delegate-legitimacy",
    "stateVersion": 1,
    "stateHash": "0x..."
  }
}

If legitimacyRef.required is true, the mint verifier MUST require the bot-signed MintRequest to include the same legitimacyId.¶

The purpose is to bind the bot's request to the current governance state without giving the bot authority to decide that state.¶

16. Public Action Records and Legitimacy

A public action record MAY include a legitimacyRef that points to the governance state used when the record was created, minted, registered, or verified.¶

Example:¶

{
  "type": "agentenvelope.publicActionRecord",
  "version": 1,
  "recordId": "ae-action-...",
  "status": "active",
  "agentId": "support-refund-0",
  "agentAddress": "0x...",
  "actionEnvelopeHash": "0x...",
  "legitimacyRef": {
    "legitimacyId": "ae-legit-...",
    "required": true,
    "stateVersion": 1,
    "stateHash": "0x..."
  }
}

The presence of legitimacyRef does not change offline signature verification. It gives verifiers and governance systems a stable handle for present-tense admissibility checks.¶

17. Hosted Governance Boundary

Hosted governance may store encrypted workspace state, public action records, stored delegates, verification events, audit events, API key hashes, billing records, mint ledgers, legitimacy state, legitimacy events, evidence references, and governance reports.¶

Hosted governance verifies, records, meters, and audits authority. It does not create authority.¶

Hosted services MUST NOT receive, derive, persist, log, or return:¶

vault passphrases;¶
plaintext identity roots;¶
domain seeds;¶
action seeds;¶
actionSeedHex;¶
mint material;¶
bot private keys;¶
other private signing material.¶

Hosted API keys meter and protect hosted governance services. They MUST NOT be treated as agent authority.¶

Agent authority is proven by signatures, public records, delegates, and out-of-band custody material.¶

18. Verification with Legitimacy

A verifier that holds a public action record, payload, and signature can perform the -00 sovereign checks without hosted access:¶

record type and version;¶
record status;¶
action index;¶
canonical action envelope;¶
action envelope hash;¶
optional expected envelope hash;¶
time decay;¶
signature form;¶
recovered address.¶

These checks prove provenance and integrity. They do not prove usage exhaustion, nonce replay, current real-world conditions, or active legitimacy.¶

A governed verifier MAY additionally check:¶

legitimacy reference;¶
latest legitimacy state;¶
state hash and version;¶
policy reference;¶
evidence freshness;¶
evidence independence;¶
reason-code result;¶
evaluator signature or attestation;¶
audit/event continuity.¶

The result SHOULD report signature validity and legitimacy separately.¶

Example:¶

{
  "signatureValid": true,
  "legitimacyDecision": "denied",
  "reasonCode": "state.mismatched"
}

19. Executor Non-Self-Authorization

An autonomous executor SHOULD NOT be the final arbiter of whether its own authority remains legitimate.¶

An executor MAY:¶

detect a mismatch;¶
refuse execution;¶
emit an observation;¶
request evaluation;¶
propose a corrected action.¶

An executor SHOULD NOT:¶

unilaterally renew its own legitimacy;¶
suppress evidence needed for evaluation;¶
be the only evidence source for renewed execution authority;¶
patch its own legitimacy state without an independent governance role.¶

The recommended lifecycle is:¶

Reality change
-> executor detects mismatch
-> evidence is gathered from sufficiently independent sources
-> old legitimacy is suspended or denied
-> independent evaluation occurs
-> new legitimacy basis is created
-> execution is re-authorized

This requirement prevents executor self-authorization through executor-controlled evidence.¶

20. Relationship to Issued Authorization Containers

AgentEnvelope is not an issued authorization container. Issued authorization systems can describe an actor's mandate, constraints, and validity. AgentEnvelope instead derives the action capability from custody material and canonical action parameters. This makes the permission boundary part of the action key itself.¶

Legitimacy adds a second distinction:¶

Issued authorization asks whether a presented assertion says an action is allowed.
Derived authority asks whether the signer could only have been produced from the
correct root, domain, and canonical action envelope.
Legitimacy asks whether that authority remains admissible now.

21. Security Considerations

Implementations MUST treat identity roots, domain seeds, action seeds, actionSeedHex, mint material, bot seeds, and private keys as secret signing material.¶

Implementations MUST NOT log or sync private signing material to hosted services.¶

Implementations SHOULD zero temporary seed buffers after use where the runtime permits.¶

Offline verification does not prove consumption. A signature can be valid and still be a replay if the relying system does not maintain state for nonces, idempotency, or max-use counters.¶

The any-signed-bot mint policy is intentionally open. Issuers that require bot restriction MUST use an address-set policy.¶

Legitimacy state is mutable governance state. Implementations SHOULD maintain state versions, state hashes, signed events, and audit trails so evaluators and auditors can distinguish current legitimacy from historical legitimacy.¶

Legitimacy introduces additional attack surfaces. Implementations SHOULD consider:¶

executor influence over evidence sources;¶
forged evidence;¶
stale or replayed evidence;¶
conflicting observations;¶
spoofed producers;¶
compromised sensors or services;¶
suppression of unfavorable evidence;¶
policy drift between state versions;¶
state-hash mismatch;¶
governance evaluator compromise;¶
governance-event tampering.¶

Evaluators SHOULD sign legitimacy events. Verifiers SHOULD check state hashes and evaluator identity when a governed legitimacy decision depends on mutable state.¶

Evidence used to renew legitimacy SHOULD be sufficiently independent from the executor. Evidence independence is not absolute; it is a policy property defined by the legitimacy profile. Profiles SHOULD describe the trust assumptions under which evidence is considered sufficiently independent.¶

Hosted attestations, when used, sign only the hosted verifier's own statement about facts it computed. They MUST NOT become a required precondition for sovereign verification.¶

24. Informative References

[FIPS180-4]: National Institute of Standards and Technology, "Secure Hash Standard (SHS)", August 2015, <https://csrc.nist.gov/publications/detail/fips/180/4/final>.
[SEC2]: Standards for Efficient Cryptography Group, "SEC 2: Recommended Elliptic Curve Domain Parameters", 2010, <https://www.secg.org/sec2-v2.pdf>.
[AGENTENVELOPE-SDK]: McPhillips, M., "AgentEnvelope SDK and v1 Specification", 2026, <https://github.com/BlackBoxEngineering/agent-envelope-sdk>.
[AGENTENVELOPE-MCP]: McPhillips, M., "AgentEnvelope MCP", 2026, <https://www.npmjs.com/package/agent-envelope-mcp>.
[AGENTENVELOPE-WEB]: McPhillips, M., "AgentEnvelope Web", 2026, <https://agentenvelope.io>.

Appendix A. Manufacturing Legitimacy Example

This appendix illustrates legitimacy as present-tense admissibility.¶

Initial command:¶

robot2.pickUp(trolley4, bay7)
signature.valid: true

Reality changes:¶

trolley4 is at bay4, not bay7

The executor detects the mismatch:¶

RobotBot local observation:
trolley4.location = bay4
trolley4.free = true

Evidence supplied only by RobotBot is insufficient:¶

renewal.evidence: insufficient
reasonCode: evidence.not_independent
reason: executing actor cannot supply the evidence that renews its own legitimacy

Independent evidence authorities confirm reality:¶

WarehouseFeed -> trolley4 at bay4, free=true
DockSafetyController -> trolley4 at bay4, free=true

The governance evaluator reviews the original command:¶

signature.valid: true
legitimacy.decision: denied
reasonCode: state.mismatched
reason: trolley4 is at bay4, not bay7

The old command stays cryptographically valid, but its legitimacy state is suspended.¶

PlannerBot proposes a corrected command:¶

robot2.pickUp(trolley4, bay4)

Governance creates a fresh legitimacy basis using independent evidence:¶

signature.valid: true
legitimacy.decision: allowed
reasonCode: state.current

This example demonstrates:¶

cryptographic validity is not the same thing as operational legitimacy;¶
legitimacy can change when reality changes;¶
the executor can detect and refuse, but must not self-authorize renewal;¶
sufficiently independent evidence should feed renewed governance;¶
audit records should preserve both the valid old signature and the denied legitimacy decision.¶