Individual Submission S. E. Efstathiou Internet-Draft Independent Intended status: Experimental 11 September 2026 Expires: 15 March 2027 Simple Agent Management Protocol (SAMP) draft-efstathiou-samp-agent-management-02 Abstract The Simple Agent Management Protocol (SAMP) defines a lightweight management-plane protocol for heterogeneous AI agents. SAMP allows a management system to discover agents, query their state, receive events, subscribe to event streams, and optionally configure or execute explicitly exposed operations under policy control. SAMP is inspired by operational management protocols such as SNMP, but it is designed for AI-agent-specific concepts such as dynamic profiles, autonomy classes, enrollment, trust states, and policy- gated execution. It is not an agent-to-agent communication protocol, an agent tool-use protocol, or an agent framework specification. This document defines SAMP version 0.1 as an Experimental protocol suitable for controlled environments and independent interoperability testing. 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 15 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Efstathiou Expires 15 March 2027 [Page 1] Internet-Draft SAMP September 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Relationship to Existing Protocols . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Endpoint Deployment Models and Failure Domains . . . . . 10 4. Agent Lifecycle, Trust, and Liveness . . . . . . . . . . . . 11 4.1. Trust Transitions . . . . . . . . . . . . . . . . . . . . 12 4.2. Liveness Transitions . . . . . . . . . . . . . . . . . . 14 4.3. Manager Authority and Endpoint Enforcement . . . . . . . 14 4.4. Enrollment . . . . . . . . . . . . . . . . . . . . . . . 15 4.5. Agent Bootstrap and Manager Location . . . . . . . . . . 16 5. SAMP Profile . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Required Identity Fields . . . . . . . . . . . . . . . . 16 5.2. Category and Field Model . . . . . . . . . . . . . . . . 17 5.3. Minimal Required Category . . . . . . . . . . . . . . . . 19 5.4. Profile Validation . . . . . . . . . . . . . . . . . . . 20 5.5. Profile Format . . . . . . . . . . . . . . . . . . . . . 20 5.6. Capabilities and Enablement . . . . . . . . . . . . . . . 20 5.7. Configuration Policy . . . . . . . . . . . . . . . . . . 21 5.8. Execution Policy . . . . . . . . . . . . . . . . . . . . 22 5.9. Deployment Metadata . . . . . . . . . . . . . . . . . . . 23 5.10. Network Attachment and Discovery Hints . . . . . . . . . 24 5.11. Agent Relationships . . . . . . . . . . . . . . . . . . . 25 5.12. Authenticated Profile Announcement Ordering . . . . . . . 25 5.12.1. Enrollment Isolation and Non-Rollback Recovery . . . 27 6. Autonomy Classes . . . . . . . . . . . . . . . . . . . . . . 28 7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 29 7.1. PDU Directions . . . . . . . . . . . . . . . . . . . . . 30 7.2. PDU Exchange Patterns . . . . . . . . . . . . . . . . . . 30 7.3. Authentication Requirements by PDU . . . . . . . . . . . 31 7.4. Liveness Semantics . . . . . . . . . . . . . . . . . . . 31 7.5. DISCOVER Rate Limiting . . . . . . . . . . . . . . . . . 31 7.6. SUBSCRIBE and UNSUBSCRIBE Semantics . . . . . . . . . . . 31 8. Message Format . . . . . . . . . . . . . . . . . . . . . . . 32 8.1. Common PDU Envelope . . . . . . . . . . . . . . . . . . . 32 Efstathiou Expires 15 March 2027 [Page 2] Internet-Draft SAMP September 2026 8.1.1. Field Validation Rules . . . . . . . . . . . . . . . 33 8.1.2. Request/Response Correlation . . . . . . . . . . . . 34 8.1.3. Timestamp Validation . . . . . . . . . . . . . . . . 34 8.1.4. Sequence Numbers . . . . . . . . . . . . . . . . . . 34 8.2. PDU-Specific Payloads . . . . . . . . . . . . . . . . . . 34 8.2.1. PING . . . . . . . . . . . . . . . . . . . . . . . . 34 8.2.2. DISCOVER . . . . . . . . . . . . . . . . . . . . . . 35 8.2.3. QUERY . . . . . . . . . . . . . . . . . . . . . . . . 40 8.2.4. PUSH . . . . . . . . . . . . . . . . . . . . . . . . 44 8.2.5. Runtime Evidence . . . . . . . . . . . . . . . . . . 45 8.2.6. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . 49 8.2.7. UNSUBSCRIBE . . . . . . . . . . . . . . . . . . . . . 50 8.2.8. Common CONFIG and EXEC Admission and Outcomes . . . . 51 8.2.9. CONFIG . . . . . . . . . . . . . . . . . . . . . . . 54 8.2.10. EXEC . . . . . . . . . . . . . . . . . . . . . . . . 57 8.3. Error Envelope . . . . . . . . . . . . . . . . . . . . . 60 8.4. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 61 8.5. JSON Encoding Requirements . . . . . . . . . . . . . . . 63 8.6. Behavior for Unknown Fields and Unknown PDU Types . . . . 64 9. Authentication . . . . . . . . . . . . . . . . . . . . . . . 64 9.1. Authentication Model . . . . . . . . . . . . . . . . . . 64 9.2. HMAC-SHA256 Signing . . . . . . . . . . . . . . . . . . . 65 9.3. Key Identification . . . . . . . . . . . . . . . . . . . 66 9.4. Canonical JSON . . . . . . . . . . . . . . . . . . . . . 66 9.4.1. Canonicalization Procedure . . . . . . . . . . . . . 66 9.4.2. Authentication Tag Representation . . . . . . . . . . 66 9.4.3. Verification Procedure . . . . . . . . . . . . . . . 67 9.4.4. Failure Behavior . . . . . . . . . . . . . . . . . . 67 9.4.5. Unicode Normalization . . . . . . . . . . . . . . . . 67 10. Transport Mapping . . . . . . . . . . . . . . . . . . . . . . 68 10.1. HTTP Transport . . . . . . . . . . . . . . . . . . . . . 68 10.1.1. HTTP Method . . . . . . . . . . . . . . . . . . . . 68 10.1.2. Content-Type . . . . . . . . . . . . . . . . . . . . 68 10.1.3. Endpoint Path . . . . . . . . . . . . . . . . . . . 68 10.1.4. HTTP Status Codes . . . . . . . . . . . . . . . . . 68 10.1.5. HTTPS Requirements . . . . . . . . . . . . . . . . . 70 10.2. WebSocket Transport . . . . . . . . . . . . . . . . . . 70 10.3. Retry and Backoff . . . . . . . . . . . . . . . . . . . 71 11. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 74 11.1. Mandatory Implementation Requirements . . . . . . . . . 75 11.2. Conformance Testing . . . . . . . . . . . . . . . . . . 75 12. Security Considerations . . . . . . . . . . . . . . . . . . . 76 12.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 76 12.1.1. Rogue Managers . . . . . . . . . . . . . . . . . . . 76 12.1.2. Rogue Agents . . . . . . . . . . . . . . . . . . . . 77 12.1.3. Credential Theft . . . . . . . . . . . . . . . . . . 77 12.1.4. Replay Attacks . . . . . . . . . . . . . . . . . . . 77 12.1.5. Profile Spoofing . . . . . . . . . . . . . . . . . . 78 Efstathiou Expires 15 March 2027 [Page 3] Internet-Draft SAMP September 2026 12.1.6. Unauthorized CONFIG and EXEC . . . . . . . . . . . . 78 12.1.7. Failure-Domain and Evidence-Path Confusion . . . . . 79 12.1.8. Version Downgrade . . . . . . . . . . . . . . . . . 79 12.1.9. Event and Discovery Flooding . . . . . . . . . . . . 79 12.1.10. Registry Poisoning . . . . . . . . . . . . . . . . . 80 12.2. Audit Requirements . . . . . . . . . . . . . . . . . . . 80 12.3. Rate Limiting and Back-Pressure . . . . . . . . . . . . 81 12.4. Trust Bootstrap . . . . . . . . . . . . . . . . . . . . 81 12.5. Token Rotation and Storage . . . . . . . . . . . . . . . 81 12.6. Summary: Current Requirements vs Future Work . . . . . . 81 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 82 13.1. Sensitive Metadata Exposure . . . . . . . . . . . . . . 82 13.2. Event Data Sensitivity . . . . . . . . . . . . . . . . . 83 13.3. Data Minimization . . . . . . . . . . . . . . . . . . . 83 13.4. Log Protection . . . . . . . . . . . . . . . . . . . . . 83 14. Operational Considerations . . . . . . . . . . . . . . . . . 83 14.1. Network Placement . . . . . . . . . . . . . . . . . . . 83 14.2. Scaling . . . . . . . . . . . . . . . . . . . . . . . . 84 14.3. Observability . . . . . . . . . . . . . . . . . . . . . 84 14.4. Error Handling in Practice . . . . . . . . . . . . . . . 84 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85 15.1. SAMP PDU Types Registry . . . . . . . . . . . . . . . . 85 15.2. SAMP Error Codes Registry . . . . . . . . . . . . . . . 85 15.3. SAMP Autonomy Classes Registry . . . . . . . . . . . . . 86 15.4. SAMP Trust States Registry . . . . . . . . . . . . . . . 87 15.5. SAMP Liveness States Registry . . . . . . . . . . . . . 87 15.6. SAMP Profile Namespaces Registry . . . . . . . . . . . . 88 15.7. Media Type Registration . . . . . . . . . . . . . . . . 88 16. Implementation Status . . . . . . . . . . . . . . . . . . . . 88 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 89 17.1. Normative References . . . . . . . . . . . . . . . . . . 89 17.2. Informative References . . . . . . . . . . . . . . . . . 90 Appendix A. Changes from -01 . . . . . . . . . . . . . . . . . . 91 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 92 Appendix C. Example SAMP Profile (JSON Wire Representation) . . 92 Appendix D. Example SAMP Profile (TOML) . . . . . . . . . . . . 92 Appendix E. Example PDU Flows . . . . . . . . . . . . . . . . . 95 E.1. Discovery and Liveness Flow . . . . . . . . . . . . . . . 95 E.2. Query Flow . . . . . . . . . . . . . . . . . . . . . . . 96 E.3. Event Subscription Flow . . . . . . . . . . . . . . . . . 96 E.4. Configuration Flow . . . . . . . . . . . . . . . . . . . 96 E.5. Execution Rejection Flow . . . . . . . . . . . . . . . . 96 E.6. Runtime-Evidence Flow . . . . . . . . . . . . . . . . . . 97 Appendix F. Glossary . . . . . . . . . . . . . . . . . . . . . . 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 97 Efstathiou Expires 15 March 2027 [Page 4] Internet-Draft SAMP September 2026 1. Introduction AI agents are increasingly deployed as long-running services, assistants, automation workers, coding agents, operational copilots, and autonomous or semi-autonomous control loops. These agents are commonly built with different frameworks, runtime environments, model providers, memory systems, and tool interfaces. Operators need a consistent way to observe and manage these agents without depending on framework-specific APIs. SAMP defines a management-plane interface between a SAMP Manager and a SAMP Agent. The protocol covers discovery, enrollment, heartbeat, state query, asynchronous event notification, subscription, configuration, and controlled execution. SAMP deliberately does not define how agents reason, how models are selected, how tools are invoked, or how agents communicate with each other. Those concerns belong to other layers. This document specifies SAMP version 0.1, intended for controlled environments such as private data centers, research labs, and operator networks where a management system needs visibility into and control of AI agents. SAMP v0.1 is not intended for untrusted networks without additional security mechanisms. 1.1. Scope SAMP v0.1 defines: * A JSON-based message format and common PDU envelope. * Eight PDU types covering discovery, heartbeat, query, event notification, subscription, configuration, and execution. * A profile model for agent identity, exposed fields, and policy declarations. * Orthogonal trust and liveness states, and an enrollment model. * Management-impact classes that restrict operations without granting authority. * HMAC-SHA256 message authentication. * HTTP(S) as the baseline transport. * Conformance tiers. Efstathiou Expires 15 March 2027 [Page 5] Internet-Draft SAMP September 2026 * IANA registry framework. SAMP v0.1 does NOT define: * Federation or multi-manager coordination. * Fleet-wide bulk or transactional operations. * Role-based access control (RBAC). * Mandatory mutual TLS (mTLS). * A mandatory external schema language such as JSON Schema or YANG; the minimal SAMP declaration structure is defined here. * Agent-to-agent communication. * Agent tool-use interfaces. * Model selection or inference protocols. 1.2. Relationship to Existing Protocols SAMP occupies the AI agent management plane. It is intended to coexist with existing management, telemetry, tool, and agent- communication protocols. SNMP SAMP is SNMP-inspired, but not SNMP-compatible. The SNMP architecture and protocol operations are specified in [RFC3411] and [RFC3416]. SNMP is device-centric and uses MIB objects defined through SMIv2 structure, textual conventions, and conformance statements as specified in [RFC2578], [RFC2579], and [RFC2580]. SAMP adds AI-agent concepts such as dynamic profiles, autonomy classes, enrollment, trust states, and policy-gated execution. NETCONF/YANG NETCONF [RFC6241] and YANG [RFC7950] provide strong configuration and modeling facilities for network devices. SAMP targets agent lifecycle, discovery, trust, and runtime management. A future SAMP profile model could be mapped to YANG, but that is outside this document. OpenTelemetry OpenTelemetry provides observability for traces, metrics, and logs. SAMP can export or correlate events with observability systems, but it defines management operations that observability systems do not provide. OpenTelemetry OpAMP The Open Agent Management Protocol (OpAMP) Efstathiou Expires 15 March 2027 [Page 6] Internet-Draft SAMP September 2026 [OPAMP] already provides overlapping operational capabilities, including status reporting, configuration, heartbeats, and supervisor-based management. SAMP specifies additional management semantics for framework-independent enrollment and Manager-owned trust and quarantine decisions for heterogeneous AI Agents. A second use case is policy-gated CONFIG/EXEC with typed commands, separate admission and execution outcomes, runtime-evidence binding, and failure-domain-aware enforcement. These responsibilities, rather than the kind of Agent alone, motivate SAMP. This comparison does not claim competition or equivalence. Deployments MAY compose the protocols where their responsibilities differ; the composition and authority mapping require deployment design. OpAMP is an Informative reference. MCP MCP [MCP] is a tool-use interface for applications and agents. SAMP is a management interface for operators and management systems. A2A and ACP Agent-to-agent protocols [A2A] define peer communication and collaboration. SAMP defines manager-to-agent management. Runtime verification Runtime-verification systems evaluate actions or state transitions and produce evidence. SAMP may transport or consume such evidence for management-policy and trust decisions, but it does not define verifier policy logic or require a specific evidence format. Correctover Conformance Shape (CCS) [CCS] is one possible evidence-format binding; it is not required or preferred by the SAMP base protocol. Agent transfer protocols Agent transfer environments may provide wire capabilities that overlap with SAMP. Similar names do not establish identical protocol responsibility. A SAMP binding may reuse suitable transfer capabilities while preserving SAMP's management authority, state ownership, and ability to remain independently enforceable when the managed agent or its communication substrate is impaired. Such bindings are outside this document. Efstathiou Expires 15 March 2027 [Page 7] Internet-Draft SAMP September 2026 +=====================+===============+==========================+ | Layer | Protocol | Purpose | +=====================+===============+==========================+ | Tool use | MCP | Agent-to-tool invocation | +---------------------+---------------+--------------------------+ | Agent communication | A2A / ACP | Agent-to-agent | | | | collaboration | +---------------------+---------------+--------------------------+ | Observability | OpenTelemetry | Traces, metrics, logs | +---------------------+---------------+--------------------------+ | Telemetry agent | OpAMP | Manage data-collection | | management | | agents | +---------------------+---------------+--------------------------+ | AI agent management | SAMP | Manage autonomous/semi- | | | | autonomous AI agents | +---------------------+---------------+--------------------------+ Table 1: Protocol Layer Comparison 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The following terms are defined for use in this document: SAMP Agent An AI agent that exposes a SAMP management interface. SAMP Manager A system that manages one or more SAMP Agents using SAMP. SAMP Profile A structured document that declares the identity, exposed categories, fields, capabilities, and policy-relevant properties of a SAMP Agent. PDU Protocol Data Unit. A SAMP message envelope and its payload. Autonomy Class A declaration of management impact and required safeguards in SAMP v0.1; it does not measure cognitive or workload autonomy and does not grant authority. Enrollment The process by which a manager evaluates an announced agent and assigns an initial trust state. Trust State The Manager-owned security disposition of an Agent: Efstathiou Expires 15 March 2027 [Page 8] Internet-Draft SAMP September 2026 discovered, pending, trusted, quarantined, rejected, or revoked. It is independent of liveness. Conformance Tier A defined level of protocol support that an implementation may claim. See Section 11. SAMP Endpoint The protocol endpoint implementing the SAMP Agent role. It may be embedded in the managed agent, implemented by a supervisor or sidecar, placed in an AI Agent Gateway, or provided by another infrastructure-control component. Evidence Issuer The entity that evaluates an evidence subject and produces a verdict or other runtime evidence. The issuer is distinct from a SAMP endpoint that merely sends or relays the evidence. Liveness State The Manager-observed reachability of a SAMP endpoint: unknown, reachable, stale, or offline. Changes do not themselves alter trust. Admission Context The authenticated actor, target, operation, request digest, profile revision, and applicable policy revision captured when deciding whether to execute an operation. 3. Architecture The basic SAMP architecture contains a manager and one or more agents: +--------------+ SAMP +--------------+ | SAMP Manager | <-----------------> | SAMP Agent | | | | | | Registry | | Profile | | Policy | | State | | Scheduler | | Capabilities | +--------------+ +--------------+ A SAMP Agent maintains a SAMP Profile and exposes SAMP operations. A SAMP Manager maintains a registry, evaluates trust, applies policy, and initiates management operations. SAMP is a management protocol. It does not require a specific agent framework, model provider, orchestration system, memory backend, or tool protocol. Efstathiou Expires 15 March 2027 [Page 9] Internet-Draft SAMP September 2026 3.1. Roles SAMP Manager: * Maintains a registry of known agents. * Evaluates agent trust and applies policy. * Initiates QUERY, CONFIG, EXEC, SUBSCRIBE, and UNSUBSCRIBE operations. * Receives PING, DISCOVER, and PUSH from agents. * Returns a DISCOVER response to DISCOVER. SAMP Agent: * Maintains a SAMP Profile describing its identity and capabilities. * Sends DISCOVER to announce itself to a manager. * Sends periodic PING heartbeats. * Responds to QUERY requests. * Emits PUSH events. * Accepts or rejects CONFIG and EXEC based on profile and local policy. * Manages event subscriptions for SUBSCRIBE/UNSUBSCRIBE. 3.2. Endpoint Deployment Models and Failure Domains The SAMP Agent is a logical protocol role and does not imply a particular deployment topology. A SAMP endpoint may be embedded in the managed-agent process, implemented by a sidecar or supervisor, placed in an AI Agent Gateway, or implemented by another independent infrastructure-control component. These deployment models do not provide equivalent guarantees. An embedded endpoint may be suitable for cooperative management but can become unavailable or untrustworthy when the managed process fails or is compromised. An endpoint outside the managed agent's failure domain can provide stronger evidence delivery, isolation, quarantine, restart, and termination guarantees. Efstathiou Expires 15 March 2027 [Page 10] Internet-Draft SAMP September 2026 A profile SHOULD declare the endpoint deployment model, whether the endpoint shares the managed agent's process, host, or failure domain, whether its management and evidence paths survive managed-process failure, and whether each advertised control operation is cooperative or independently enforceable. A manager MUST NOT infer out-of-band enforcement merely from the existence of a SAMP endpoint. Gateway deployment is a first-class SAMP deployment model and is RECOMMENDED for security-sensitive or higher-autonomy environments. The core protocol remains deployment-topology-neutral. Deployment metadata describes survival and shared-failure properties, not topology labels. Terms such as "sidecar", "container", or "gateway" describe placement but do not establish what failures or compromises the endpoint survives. Implementations MUST NOT infer a survival boundary from a topology label alone. 4. Agent Lifecycle, Trust, and Liveness The Manager owns trust_state and liveness_state for each Agent. These are orthogonal dimensions. Trust decisions MUST survive ordinary liveness changes. A trusted Agent becoming offline remains trusted unless Manager policy performs a separate trust transition. An Agent may be both quarantined and offline. +=============+=========================================+ | Value | Meaning | +=============+=========================================+ | discovered | Announced, not yet evaluated | +-------------+-----------------------------------------+ | pending | Awaiting a trust decision | +-------------+-----------------------------------------+ | trusted | Accepted by Manager policy; no | | | automatic CONFIG/EXEC enablement | +-------------+-----------------------------------------+ | quarantined | Manager decision to restrict management | | | and investigate; not proof of isolation | +-------------+-----------------------------------------+ | rejected | Enrollment refused | +-------------+-----------------------------------------+ | revoked | Trust explicitly revoked; terminal for | | | this enrollment | +-------------+-----------------------------------------+ Table 2: Trust States Efstathiou Expires 15 March 2027 [Page 11] Internet-Draft SAMP September 2026 +===========+===========================================+ | Value | Meaning | +===========+===========================================+ | unknown | No current observation sufficient to | | | classify reachability | +-----------+-------------------------------------------+ | reachable | A valid exchange recently established | | | endpoint reachability | +-----------+-------------------------------------------+ | stale | Expected valid heartbeats or interactions | | | are overdue | +-----------+-------------------------------------------+ | offline | A transport failure or configured timeout | | | policy establishes current unreachability | +-----------+-------------------------------------------+ Table 3: Liveness States Registry entries MUST store trust_state and liveness_state separately. New entries start with trust_state discovered or pending and liveness_state unknown until a valid observation establishes reachability. Heartbeat interval, stale threshold, and offline timeout are positive, bounded deployment settings; the Manager MUST document them and the precedence of transport failure and timer observations. 4.1. Trust Transitions Only the Manager or an authenticated actor authorized by Manager policy can request a trust transition. Agents MUST NOT self-promote. The following transitions are allowed; all others MUST be rejected for the current enrollment. Efstathiou Expires 15 March 2027 [Page 12] Internet-Draft SAMP September 2026 +===============+=============+=====================================+ | From | To | Condition | +===============+=============+=====================================+ | discovered | pending | Evaluation begins | +---------------+-------------+-------------------------------------+ | pending | trusted | Approval after required validation | +---------------+-------------+-------------------------------------+ | pending | rejected | Enrollment refused | +---------------+-------------+-------------------------------------+ | pending | quarantined | Investigation required | +---------------+-------------+-------------------------------------+ | trusted | quarantined | Authorized restriction decision | +---------------+-------------+-------------------------------------+ | quarantined | pending | Authorized release for | | | | revalidation | +---------------+-------------+-------------------------------------+ | quarantined | trusted | Affirmative authorized restoration | | | | after required revalidation | +---------------+-------------+-------------------------------------+ | Any non- | revoked | Explicit authorized revocation | | revoked state | | | +---------------+-------------+-------------------------------------+ Table 4: Trust Transition Rules A repeated decision to retain the existing state is a no-op and MUST NOT bypass admission checks. rejected and revoked entries do not return to trusted in the same enrollment. Any later enrollment requires an explicitly authorized new enrollment context and MUST NOT reuse the old context to recover authority. Quarantine is a Manager decision. Actual isolation is a separate operational fact. A quarantine record MUST include enforcement_status, a string with value requested, applied, failed, or indeterminate. requested means enforcement was requested but not confirmed; applied requires affirmative confirmation from an authorized enforcement actor; failed means the requested isolation failed; indeterminate means its result is unknown. These values describe enforcement only and do not grant trust. A Manager MUST NOT present requested or indeterminate as confirmed isolation. The Manager MUST audit trust transitions, including actor, reason, previous and resulting trust_state, timestamp, supporting evidence when available, and quarantine enforcement_status when applicable. Confirmation or failure of isolation MUST update its audit trail without silently changing trust_state. Efstathiou Expires 15 March 2027 [Page 13] Internet-Draft SAMP September 2026 4.2. Liveness Transitions An authenticated valid exchange MAY change unknown, stale, or offline to reachable. Configured missed-heartbeat thresholds MAY change reachable to stale. Transport failures or configured offline timeouts MAY change unknown, reachable, or stale to offline. A Manager MUST NOT refresh liveness based on unauthenticated traffic, a stale request, or a duplicate retry of an old PDU. Returning from stale or offline changes liveness only. Re- authentication proves current possession of valid authentication material; it does not independently establish that all previous trust conditions remain satisfied. Manager policy MAY require revalidation before new management operations after recovery. Such revalidation is an admission requirement and MUST NOT implicitly restore quarantined or revoked trust. 4.3. Manager Authority and Endpoint Enforcement The Manager MUST evaluate current trust_state and Manager policy before transmitting each new CONFIG or EXEC. Only trusted Agents are eligible. A quarantined or revoked Agent MUST NOT receive new CONFIG or EXEC operations from a conforming Manager. QUERY and PUSH MAY be permitted for quarantined Agents under policy; QUERY is initiated by the Manager, and PUSH by the Agent. The endpoint MUST authenticate and authorize the requesting Manager and enforce its own local config_policy or exec_policy before execution. Manager policy and endpoint local policy are jointly restrictive: either can deny. The endpoint is not required to maintain a synchronized copy of the Manager trust registry. No new PDU distributes that registry in core v0.1. The Manager owns pre- transmission admission checks; the endpoint owns local pre-execution checks. Any Manager requirement that must be enforced at the endpoint MUST be installed as an identified local policy through an authenticated deployment mechanism before the request is sent. A Manager-side trust transition affects subsequent admission decisions. An already admitted operation uses its captured admission context. Later quarantine or revocation does not retroactively prove execution failure and does not automatically cancel an executing operation. Cancellation or forced termination is possible only when an independently enforceable component explicitly supports it. SAMP v0.1 defines no general cancellation PDU. The audit record and recorded operation state MUST identify profile_revision and policy_revision used at admission. A Manager records its Manager-policy revision; an endpoint records its local Efstathiou Expires 15 March 2027 [Page 14] Internet-Draft SAMP September 2026 policy revision and the Manager-supplied revision when present. These are separate authorities, not claims that both parties share a policy engine. Retrieving recorded state requires current authorization and does not constitute new admission or permit re- execution. Before retransmission the Manager MUST check current trust and policy as well. A retry whose original admission is unknown could still be a first delivery and MUST NOT be transmitted to a quarantined or revoked Agent. Retrieval after a restrictive trust transition is permitted only when the Manager can establish that the operation is already recorded and that the receiver will not admit it anew under its declared retention/restart guarantees. Otherwise reconciliation uses an authorized out-of-band mechanism; an identifier alone is not sufficient assurance. 4.4. Enrollment Enrollment evaluates an announced identity, profile, authentication binding, and local approval requirements. The DISCOVER enrollment object is defined in Section 8.2.2. Supported method identifiers are manual, token, and public_key_metadata. These select evaluation inputs, not new authentication algorithms. Manual enrollment requires explicit operator approval and an authenticated identity binding. A token is sensitive enrollment material checked against pre-registration data. A public key or thumbprint is identifying metadata: matching it does not prove possession of the private key and MUST NOT by itself promote an Agent to trusted. Promotion requires an authenticated proof-of-possession mechanism, another authenticated binding, or explicit out-of-band verification approved by local policy. Core v0.1 does not define a public-key proof-of-possession exchange. The baseline operational authentication is the out-of-band provisioned per-pair HMAC secret. An unauthenticated bootstrap DISCOVER can create only a discovered or pending entry, even if it contains a matching token or thumbprint. An approved out-of-band enrollment decision is separately audited; it does not turn that unauthenticated message into an authenticated one. Operational credentials MUST be installed before authenticated operations begin. Tokens MUST NOT appear in logs, diagnostic errors, or published examples. Receivers MUST redact enrollment.token before logging. Enrollment credentials and management HMAC keys have separate purposes; a token MUST NOT automatically become the management key. Efstathiou Expires 15 March 2027 [Page 15] Internet-Draft SAMP September 2026 Replacement enrollment, credential isolation and ordering recovery MUST follow Section 5.12.1; operator authorization alone does not make old credentials valid for a replacement. 4.5. Agent Bootstrap and Manager Location The Manager HTTPS endpoint URL is configured through a file, environment variable, startup argument, trusted deployment inventory, or manual provisioning. DNS-based location MAY be supplied by an explicitly documented deployment mechanism; core v0.1 defines no DNS SRV service name. Discovery does not bypass endpoint certificate validation or enrollment policy. 5. SAMP Profile A SAMP Profile describes the agent as a managed entity. It includes: * *Identity fields*: agent_id, name, agent_version, profile_version, profile_revision, profile_sequence, agent_type, autonomy_class, and optional framework metadata. * *Categories and fields*: Named groups of exposed state or configuration fields. * *Capabilities*: Event subscriptions, executable commands, or other advertised capabilities. * *Policy declarations*: exec_policy and config_policy controlling CONFIG and EXEC behavior. * *Implementation metadata*: Fields needed by the manager for registration and registry maintenance. trust_state, liveness_state and enforcement_status are Manager registry/report fields, not Agent profile assertions. A Manager MUST ignore any Agent self-declaration of these fields as authority; they cannot establish trust or confirmed isolation. Their normative wire placement, when reported, is the DISCOVER response payload. 5.1. Required Identity Fields The following fields MUST be present in every SAMP Profile: Required Profile Identity Fields: agent_id string; Unique agent identifier name string; Human-readable agent name agent_version string; Agent software version Efstathiou Expires 15 March 2027 [Page 16] Internet-Draft SAMP September 2026 profile_version string; SAMP profile schema version profile_revision string; Required non-empty identifier of current profile content agent_type string; Framework type (e.g., openclaw, hermes, custom) autonomy_class string; Autonomy classification (see Section 6) profile_sequence integer; Required; 1 through 9007199254740991; authenticated enrollment-local ordering Identity fields other than profile_sequence MUST be non-empty strings. profile_version MUST equal "0.1". profile_revision is an opaque identifier unique to one immutable announced profile snapshot within the Agent enrollment; it MUST NOT be ordered lexically or numerically or reused for different content. Every content-changing announcement, including identity, declarations, capabilities, configuration or policy changes, MUST use a new profile_revision and a strictly greater profile_sequence. Runtime readings returned by QUERY do not mutate the announced snapshot or require a revision per observation; including changed readings in a later announced profile does require a new revision and sequence. agent_id MUST equal the envelope agent_id. Assigned identifiers follow Section 5.12. 5.2. Category and Field Model The profile uses top-level category objects (for example system and model) for values, and a required field_declarations array for their type declarations. Each top-level declaration name is a dotted path with at least category.field. Segments MUST match [a-z][a-z0-9_]*. Paths MUST be unique; overlapping parent and child declarations are prohibited. Declaration metadata is separate from category values. Identity and reserved metadata objects are not categories. Each declared category is a closed object: every value path MUST have a declaration, every required declaration MUST have a value, and an undeclared value inside a declared category MUST be rejected as profile_invalid. Unknown top-level extension categories MAY be ignored; they cannot become writable or executable merely by being present. Unknown reserved-profile metadata is ignored as an extension. All values returned for declared QUERY fields and all accepted CONFIG values MUST validate against their declarations. SAMP Type Declaration: name string; required; Dotted path for profile fields; single segment for parameters, properties, items and result declarations. Non-empty; segment syntax above. type string; required; string, integer, number, boolean, object, array, or null required boolean; required; Whether containing object must supply Efstathiou Expires 15 March 2027 [Page 17] Internet-Draft SAMP September 2026 this member nullable boolean; optional; default false; Permits JSON null in addition to the declared type enum array; optional; Non-empty, distinct permitted values; all validate against type and constraints minimum / maximum number; optional; Inclusive numeric limits, applicable only to integer or number; minimum <= maximum min_length / max_length integer; optional; Non-negative Unicode scalar-value counts for strings only; min_length <= max_length items declaration object; required for array only; Recursive declaration named item with required true; applies to every array element properties array of declarations; required for object only; Recursive declarations with unique single-segment names; empty array permits only an empty object description string; optional; Human-readable documentation, no validation authority A declaration MUST NOT contain unknown members or constraints inapplicable to its type. Duplicate names in declarations or JSON objects MUST be rejected. Objects reject all properties not explicitly declared; there is no implicit additional-properties permission. Parameter objects follow this same closed-object rule. Each properties or parameters declaration with required true MUST be present; omission is allowed only for required false. An absent member is distinct from a present null. No coercion, default insertion, or implicit string-to-number conversion is permitted. integer means a finite JSON number with integral mathematical value in the interoperable range -9007199254740991 through 9007199254740991. number means a finite IEEE 754 binary64-compatible JSON number. boolean is not numeric. Strings MUST contain valid Unicode scalar values. JSON null is permitted only by type null or nullable true; type null permits only null. enum, when present, further restricts even nullable values. Enumeration equality compares JSON values structurally, ignores object member order, preserves array order, and compares numbers mathematically. Duplicate enum values under this equality MUST be rejected. Array items are validated recursively. Object properties are validated recursively. items and properties are forbidden on other types. The item declaration required flag is always true and does not set a minimum array length. Result declarations use name result and required true when present. Empty arrays are valid unless excluded by enum. Implementations MUST impose and document positive finite limits on nesting depth, declaration count, string length, and encoded profile size; excess inputs are rejected rather than partially validated. Efstathiou Expires 15 March 2027 [Page 18] Internet-Draft SAMP September 2026 The timestamp semantic is represented by type string plus the explicitly defined field rule requiring an RFC 3339 UTC value with Z. Legacy type names int, float, and timestamp are not declaration type values in this format. External schemas MAY strengthen a deployment contract but MUST NOT replace this mandatory base representation or cause arbitrary URI fetching. When a present value is null and explicitly permitted, numeric, string, array and object constraints do not apply to that null; enum still applies. For all non-null values, type-specific constraints apply. required controls only omission from a containing object. null MUST be explicitly declared in JSON; TOML authoring cannot express null directly and profiles needing null values require an equivalent JSON authoring path. This does not relax on-wire validation. A dotted profile path traverses JSON objects only; intermediate segments are structural containers, never array indices. An object- valued field owns its descendants through properties declarations, so those descendants need not have separate top-level declarations and cannot also be declared as overlapping paths. QUERY and CONFIG address the declared field as a whole; they do not infer separately addressable nested fields. Missing intermediate containers are permitted only when no required descendant declaration depends on them. 5.3. Minimal Required Category Every profile MUST include system and field_declarations entries for the following fields. All four declarations have required true and nullable false. Other fields MAY be declared. Required System Fields: system.status string; Non-empty self-reported endpoint/workload status; not Manager trust_state system.uptime integer; Minimum 0; seconds since managed workload start system.version string; Non-empty Agent software version; consistent with agent_version system.last_seen string; RFC 3339 UTC timestamp with Z; Agent- observed interaction, not Manager-owned liveness Efstathiou Expires 15 March 2027 [Page 19] Internet-Draft SAMP September 2026 5.4. Profile Validation Managers MUST validate required identity fields, profile_version, profile_revision, profile_sequence, required system values and declarations, autonomy_class, the complete recursive field_declarations structure, and all advertised capability policy declarations before trust approval. Command names and required parameter lists MUST be unambiguous. A malformed or unsupported declaration fails with profile_invalid; it MUST NOT silently remove a constraint. Managers MUST NOT fetch arbitrary external profile URLs from untrusted DISCOVER payloads. Profiles are sent inline in core v0.1. External retrieval requires an explicitly identified extension and Manager-approved locations. Profile validation establishes structural validity, not truthfulness, behavioral safety, or independent enforceability. 5.5. Profile Format TOML is the recommended human-readable authoring format for SAMP v0.1. Implementations MAY author or represent profiles as equivalent JSON or another structured model, including for values not representable in TOML. On-the-wire profile encoding is JSON. Implementations MUST enforce a configurable maximum profile size and SHOULD document the configured limit. A receiver MAY reject an oversized inline profile with a profile_invalid error. field_declarations is a required non-empty array of the declaration objects defined above. Profile authoring in TOML does not alter JSON types or permit TOML datetime objects on the wire: timestamp fields are authored as quoted strings. TOML and JSON representations MUST decode to the same profile data model. 5.6. Capabilities and Enablement A profile MUST contain capabilities, an array of distinct lowercase operation names supported by the endpoint. DISCOVER.payload.capabilities MUST equal this array. Capability advertisement states support only and does not grant authority. CONFIG and EXEC require the corresponding local policy declaration even when currently disabled. Efstathiou Expires 15 March 2027 [Page 20] Internet-Draft SAMP September 2026 DISCOVER.payload.supported_versions is an optional non-empty array of distinct version strings and, when present, MUST contain the envelope version. Core v0.1 uses only "0.1"; it defines no negotiation to a different version. Receivers MUST reject any unsupported envelope version with version_unsupported. profile_version is a profile-format version, not a protocol negotiation value. After an admission-relevant profile change, an endpoint MUST reannounce the full current profile and new profile_revision using authenticated DISCOVER before expecting the Manager to use the new revision for new operations. An authenticated reannouncement for an existing enrollment updates metadata without implicitly resetting or promoting trust_state. The Manager MUST preserve its existing trust decision unless it performs a separate authorized transition, and MAY require revalidation. A delayed duplicate DISCOVER returns its recorded response and MUST NOT overwrite a newer registry profile. An endpoint MAY coalesce multiple local changes before reannouncement; advertised revision and content MUST form a consistent snapshot. All such announcements MUST include the corresponding profile_sequence and obey Section 5.12; reannouncement retries do not reinstall older snapshots. 5.7. Configuration Policy A profile advertising config MUST include config_policy. Its members are defined below; unknown policy members MUST be rejected as profile_invalid so that unsupported safeguards cannot be silently ignored. These shared members occur in each config_policy and exec_policy object. config_policy additionally requires writable_fields, an array of distinct declared dotted paths; an empty array grants no writes. Shared CONFIG and EXEC Policy Members: enabled boolean; required; False disables the applicable operation policy_revision non-empty string; required; Unique local policy content revision cooldown number; optional; Finite non-negative minimum seconds between new admissions of the applicable operation max_per_minute integer; optional; Positive maximum new admitted operations in any rolling 60-second window audit boolean; required; MUST be true when the applicable operation is enabled Efstathiou Expires 15 March 2027 [Page 21] Internet-Draft SAMP September 2026 Each writable_fields entry MUST have a field_declarations entry. Typed validation is mandatory. Cooldown and rate limits apply per Agent and operation type across Managers; retries do not consume new admission slots. The endpoint MUST enforce enabled, the allow-list, types, rate limits, and local authorization policy. Manager policy and local policy are jointly restrictive. A denied field MUST NOT be changed. This declaration does not prove behavioral safety. Security-policy metadata, trust_state, liveness_state, identity fields, and admission revision identifiers MUST NOT be writable through core CONFIG. Changing policy or trust through a generic field write is not supported. Admission-relevant configuration changes MUST produce a new profile_revision for subsequent admissions, while the current operation retains the revision captured at its own admission. 5.8. Execution Policy A profile advertising exec MUST include exec_policy. Unknown exec_policy or command-declaration members MUST be rejected as profile_invalid. EXEC is disabled by default and enabled only through explicit local provisioning. enabled, policy_revision, cooldown, max_per_minute and audit have the shared types, presence and rules in Section 5.7. Their limits apply to EXEC independently of CONFIG. Execution Policy Members: allowed_commands array of distinct strings; required; Names explicitly enabled for execution commands array of command declarations; required; Available typed command definitions Command Declaration Members: name string; required; Unique command identifier matching [a-z][a-z0-9_]* parameters array of type declarations; required; Closed params object; empty array means no parameters required_parameters array of distinct strings; required; Exactly the names whose parameter declarations have required true result type declaration; optional; Declaration named result; validates successful EXEC result description string; optional; Human-readable semantics Efstathiou Expires 15 March 2027 [Page 22] Internet-Draft SAMP September 2026 Each allowed_commands entry MUST name exactly one commands entry. Command execution requires both exec_policy.enabled true and membership in allowed_commands. Required parameter declarations and required_parameters MUST agree or profile validation fails. Every received params member MUST be declared and typed. Free-form untyped argument strings are prohibited. A typed string parameter does not authorize interpretation as arbitrary shell code. If no result declaration is present, a succeeded EXEC returns result null. Rate limits have the same scope and retry treatment as CONFIG. The endpoint MUST enforce its local exec_policy and Manager authorization before execution. Manager policy is additionally restrictive. A deployment MAY require validated synchronous evidence for selected commands as described in Section 8.2.5. 5.9. Deployment Metadata A profile MAY include a deployment object with the following fields: endpoint_model One of embedded, sidecar, supervisor, gateway, or infrastructure. shared_process Whether the SAMP endpoint shares the managed agent's process. shared_host Whether the SAMP endpoint shares the managed agent's host. shared_failure_domain Whether failure or compromise of the managed agent is expected to affect the endpoint. independent Whether trusted deployment inventory establishes that the endpoint is outside the managed agent's relevant failure domain. management_path_survives_failure Whether the management path is expected to remain available after managed-process failure. evidence_path_survives_failure Whether the evidence path is expected to remain available after managed-process failure. independently_enforceable_operations An array of operations enforceable without cooperation from the managed agent. These fields are declarations and MUST NOT be treated as proof of independence. A manager SHOULD validate them against deployment inventory, attestation, or other trusted configuration when stronger guarantees are required. Efstathiou Expires 15 March 2027 [Page 23] Internet-Draft SAMP September 2026 The relationship fields describe survival boundaries. They MUST NOT be inferred solely from endpoint_model or another topology label. Trusted deployment inventory takes precedence over a self-declared independence claim. A conflict makes the deployment relationship indeterminate; it does not by itself make the substantive evidence result false. deployment is an optional profile object. endpoint_model, when present, is a string from the listed vocabulary. shared_process, shared_host, shared_failure_domain, independent, management_path_survives_failure and evidence_path_survives_failure are optional booleans; omission means unknown. independently_enforceable_operations is an optional array of distinct non-empty command names declared by an identified control profile; an empty array asserts no such operations. Core v0.1 does not standardize cancellation or quarantine enforcement commands. Unknown deployment metadata is ignored and MUST NOT strengthen an enforcement claim. 5.10. Network Attachment and Discovery Hints A profile MAY include a network object describing how the SAMP endpoint is attached and reached. It may contain management_address, address_family, prefix_length, management_interface, endpoint_port, reachability, and discovery_scope fields. The reachability value describes whether the advertised address is direct, translated, or reached through a proxy or gateway. Network attachment data and discovery_scope are descriptive hints, not authorization to probe a network. A manager MUST validate any advertised address or prefix against trusted inventory and local policy before using it for active discovery. An agent MUST NOT be able to expand manager-authorized discovery scope by advertising a broader prefix. Active address-space scanning is not required by SAMP. In particular, an IPv6 prefix does not imply that exhaustive scanning is feasible or permitted. Scan frequency, rate limits, allow-lists, and maximum scope are manager-policy concerns. network is an optional profile object. management_address is an optional string containing an IPv4 or IPv6 literal; address_family is a conditional string ipv4 or ipv6 required with that address and MUST match it. prefix_length is an optional integer, 0..32 for IPv4 or 0..128 for IPv6, requiring address_family. management_interface is an optional non-empty string. endpoint_port is an optional integer 1..65535. reachability is an optional string direct, translated, proxy, or gateway. discovery_scope is an optional canonical IPv4 or Efstathiou Expires 15 March 2027 [Page 24] Internet-Draft SAMP September 2026 IPv6 CIDR string; it is never authorization. Unknown network fields are ignored. Conflicting address hints MUST NOT override the approved DISCOVER endpoint or expand authorized discovery scope. 5.11. Agent Relationships A profile MAY include parent_agent_id and relationship_type metadata. A related or subordinate agent enrolls independently and MUST NOT inherit trust or management authority solely from the declared relationship. parent_agent_id and relationship_type are optional non-empty strings; relationship_type is deployment-defined descriptive metadata. Neither field changes enrollment, subscription ownership, or management authority. 5.12. Authenticated Profile Announcement Ordering profile_sequence is a required JSON integer from 1 through 9007199254740991, monotonically increasing within one Manager- recognized enrollment of one authenticated Agent identity. The initial accepted profile MUST use 1. Every changed profile revision MUST use a strictly greater value; gaps and coalesced updates are permitted. The same content, revision and sequence MAY be retransmitted. A sequence MUST NOT be reused for different content or revision. At exhaustion, further updates require an explicitly authorized enrollment replacement; integers outside the range are invalid. The Manager MUST retain the accepted profile_sequence, profile_revision and authenticated canonical profile digest, bound to the authenticated Agent identity, enrollment and assigned agent_id. The digest is SHA-256 of RFC 8785 canonical UTF-8 bytes of the complete received profile object, including its revision and sequence. The envelope is not part of this profile digest; request digests remain separately defined in Section 10.3. Unauthenticated DISCOVER MUST NOT establish or advance authoritative ordering. Such bootstrap responses omit accepted-profile identifiers. After checking the credential-to-enrollment binding under Section 5.12.1 and applicable request replay state, the Manager MUST serialize profile-announcement processing per authenticated Agent identity. A greater sequence is a candidate update subject to normal validation and authorization; acceptance atomically replaces the accepted tuple and returns its revision and sequence. Validation failure returns profile_invalid; denied authorization returns policy_denied; an initial sequence other than 1 returns invalid_value. Errors leave accepted state unchanged. Efstathiou Expires 15 March 2027 [Page 25] Internet-Draft SAMP September 2026 A lower sequence is stale: return profile_stale and MUST NOT overwrite current state. An equal sequence with identical revision and digest is a duplicate: return the recorded/current DISCOVER outcome without overwriting newer state. An equal sequence with a different revision or digest MUST be rejected with profile_sequence_conflict. Reusing any known revision with different content or sequence is likewise profile_sequence_conflict. During another update, a receiver MAY queue within declared resource limits or return back_pressure before processing; a queued announcement MUST be compared with the then-current accepted state, not an earlier snapshot. Current authorization controls disclosure of recorded state. Ordering records are mandatory. Wall-clock timestamps MUST NOT determine ordering. Recovery and any sequence restart MUST obey Section 5.12.1; authenticated reconciliation alone is insufficient. Ordinary restart and request-cache expiry do not remove the ordering boundary. An assigned_id MUST be recorded as part of the same authenticated enrollment/order binding, retaining the digest of the received profile. It MUST NOT collide with another enrollment or create a new ordering context implicitly. The Agent incorporates assigned_id in subsequent envelopes and profiles; that changed profile requires a new revision and greater sequence, not another initial sequence. The same revision MUST identify the same sequence and announced snapshot in DISCOVER, QUERY and admission records. A genuine recorded DISCOVER retry may return its original authorized historical outcome in a fresh envelope under Section 10.3 and Section 5.12.1, without reinstalling content. Within the current enrollment, an unseen older announcement returns profile_stale. Previous-enrollment traffic MUST first satisfy the historical-only exception; it MUST NOT reach replacement ordering evaluation. The following independent common error payloads illustrate a stale announcement and an equal-sequence conflict. A busy update or missing restart ordering state uses back_pressure with the same error-envelope structure. { "error": { "code": "profile_stale", "detail": "Profile announcement is stale", "timestamp": "2026-09-11T10:00:01Z" } } Efstathiou Expires 15 March 2027 [Page 26] Internet-Draft SAMP September 2026 { "error": { "code": "profile_sequence_conflict", "detail": "Profile sequence conflicts with accepted content", "timestamp": "2026-09-11T10:00:01Z" } } A back_pressure rejection before processing a candidate MUST NOT install its profile or commit a completed announcement outcome. An identical retry may be considered later under the ordinary freshness and ordering rules. A queued, reserved announcement keeps its reservation while processing; transient busy feedback MUST NOT replace its eventual recorded outcome. 5.12.1. Enrollment Isolation and Non-Rollback Recovery Agent identity identifies the authenticated principal; assigned agent_id is its enrollment-bound protocol identifier. Enrollment context is the Manager-recognized admission instance, distinct from either identifier. An authentication context binds a provisioned operational credential to that enrollment. Profile ordering state is the committed sequence/revision/canonical-profile-digest tuple; request replay state records individual requests and outcomes. These bindings are local state, not new JSON fields. Every explicit enrollment replacement or reset MUST establish a fresh operational credential and a new enrollment-scoped authentication context distinguishable from every previous context for that Agent, before the Manager accepts the first authoritative replacement profile. Clearing sequence state while retaining the same old credential and Agent ID as sufficient authentication MUST NOT implement a reset. Receivers MUST check the authenticated credential-to-enrollment binding before applying ordering rules or admitting new traffic. HMAC validity, the same Agent ID, timestamp freshness and an unseen UUID do not prove current enrollment membership. Previous-enrollment credentials MUST NOT authorize any new request, announcement, profile installation or other state-changing action in the replacement enrollment. A retained old credential MAY be used only to retrieve an exact request already present in retained historical request state, if current policy and the original protocol permit historical retrieval. The receiver MUST establish the original authenticated request bytes (or their retained byte digest), owner, enrollment, target, type and recorded outcome. This exception returns only that historical outcome in a fresh authenticated envelope under the historical context; it MUST NOT create an Efstathiou Expires 15 March 2027 [Page 27] Internet-Draft SAMP September 2026 operation, install/reinstall content, mutate replacement state, or reset/advance its ordering. An unrecorded old request MUST be rejected with policy_denied before ordering evaluation, even during credential overlap. If historical conditions cannot be established, fail closed with policy_denied; an unverifiable or unbound credential uses auth_failed. After ordering-state loss, the Manager MUST remain fenced with back_pressure for affected profile admission unless it restores an integrity-protected authoritative record known to represent the latest committed tuple for that enrollment, bound to authenticated Agent identity, enrollment context, assigned Agent ID and relevant authentication context. Recovery MUST preserve that last committed boundary. Authentication or reconciliation with the Agent alone does not establish checkpoint recency: an older authenticated checkpoint MUST NOT reopen ordering below a possibly newer accepted boundary. If latest-commit status cannot be established, remain fenced or explicitly replace the enrollment under this section. Elapsed time, timers, retry-cache expiry, ordinary reauthentication and unauthenticated announcements MUST NOT recover or reset ordering. This is a local fail-closed invariant; no universal database, external service, consensus mechanism or recovery PDU is required. profile_sequence MAY restart at 1 only after valid explicit replacement has established the fresh context and isolated prior- enrollment traffic as above. Ordinary restart, disconnect, timeout, liveness loss, replay-cache eviction and credential rotation within the same enrollment MUST NOT reset it. Same-enrollment rotation preserves enrollment and its committed ordering boundary; replacement creates a new enrollment with fresh credentials. Clean restart or replay-cache loss with the latest authoritative ordering record preserved continues from that boundary, never from 1. 6. Autonomy Classes The compatibility field name autonomy_class is retained. In SAMP v0.1 it describes management impact and required safeguards; it does not measure cognitive autonomy or workload autonomy. A highly autonomous workload may expose only read-only management operations. Efstathiou Expires 15 March 2027 [Page 28] Internet-Draft SAMP September 2026 +======================+=====================================+ | Value | Rule | +======================+=====================================+ | advisory | Read-only management. MUST NOT | | | advertise or accept CONFIG or EXEC. | +----------------------+-------------------------------------+ | operational-readonly | Observation and limited CONFIG | | | under explicit policy; MUST NOT | | | advertise or accept EXEC. | +----------------------+-------------------------------------+ | operational-write | CONFIG and allow-listed typed EXEC | | | under explicit policy. | +----------------------+-------------------------------------+ | critical-write | CONFIG and allow-listed typed EXEC | | | require safeguards appropriate to | | | high impact. | +----------------------+-------------------------------------+ Table 5: Management Impact Classes The class MUST NOT grant authority by itself. Managers MUST NOT send operations prohibited by the declared class; endpoints MUST reject them with config_disabled or exec_disabled. Profile validation MUST reject capabilities conflicting with the declared class. Manager and local policies can impose stricter restrictions. Manager policy SHOULD require stronger and more independent evidence as operational impact increases. Critical-write operations SHOULD require synchronous pre-admission evidence validated by an enforcement endpoint outside the relevant workload failure domain. A deployment that cannot meet its required safeguards MUST deny admission, irrespective of the class label. 7. Protocol Operations SAMP version 0.1 defines the following PDU types: PING Agent-to-manager heartbeat. The manager responds with a PING PDU with direction: "response". DISCOVER Agent-to-manager self-announcement and profile advertisement. The manager responds with a DISCOVER PDU with direction: "response". QUERY Manager-to-agent request for declared category field values. The agent responds with a QUERY PDU with direction: "response". PUSH Agent-to-manager asynchronous event notification. No SAMP Efstathiou Expires 15 March 2027 [Page 29] Internet-Draft SAMP September 2026 response or acknowledgment PDU is defined for PUSH. SUBSCRIBE Manager-to-agent request to subscribe to an event stream. The agent responds with a subscription_id. UNSUBSCRIBE Manager-to-agent request to cancel a subscription. CONFIG Manager-to-agent configuration change. The agent responds with success or error. EXEC Manager-to-agent request to execute an explicitly exposed operation. The agent responds with a result or error. 7.1. PDU Directions Each PDU has a direction field indicating its role: +==============+==================================+ | Direction | Meaning | +==============+==================================+ | request | Initiates an operation | +--------------+----------------------------------+ | response | Responds to a request | +--------------+----------------------------------+ | notification | Unsolicited asynchronous message | +--------------+----------------------------------+ | error | Error response to a request | +--------------+----------------------------------+ Table 6: PDU Directions 7.2. PDU Exchange Patterns +=============+============================+===========+ | PDU Type | Pattern | Initiator | +=============+============================+===========+ | PING | request - response | Agent | +-------------+----------------------------+-----------+ | DISCOVER | request - response | Agent | +-------------+----------------------------+-----------+ | QUERY | request - response | Manager | +-------------+----------------------------+-----------+ | PUSH | notification (no response) | Agent | +-------------+----------------------------+-----------+ | SUBSCRIBE | request - response | Manager | +-------------+----------------------------+-----------+ | UNSUBSCRIBE | request - response | Manager | +-------------+----------------------------+-----------+ Efstathiou Expires 15 March 2027 [Page 30] Internet-Draft SAMP September 2026 | CONFIG | request - response | Manager | +-------------+----------------------------+-----------+ | EXEC | request - response | Manager | +-------------+----------------------------+-----------+ Table 7: PDU Exchange Patterns 7.3. Authentication Requirements by PDU All PDUs exchanged between a manager and an agent MUST be authenticated when authentication is enabled. QUERY, PUSH, SUBSCRIBE, UNSUBSCRIBE, CONFIG, and EXEC require an enrolled and authenticated peer. A manager MAY accept an unauthenticated DISCOVER only for bootstrap, in which case it MUST NOT create more than a discovered or pending registry entry. See Section 9 for details. 7.4. Liveness Semantics A successful PING exchange establishes only that the peer's SAMP endpoint is reachable and responsive at that time. It does not establish workload progress, behavioural correctness, successful scheduling, task completion, or continued trustworthiness. Workload- specific progress is outside the SAMP v0.1 core protocol. 7.5. DISCOVER Rate Limiting Managers SHOULD rate-limit DISCOVER messages from unknown agents to prevent discovery flooding. A manager MAY maintain a pending-agent quota and reject excess discoveries with a rate_limited error. 7.6. SUBSCRIBE and UNSUBSCRIBE Semantics Every new SUBSCRIBE creates a new subscription owned by the authenticated Manager. Core v0.1 does not renew existing subscriptions. A retry with the same request_id and identical authenticated request bytes returns the original recorded subscription payload in a fresh response envelope; it MUST NOT create another subscription or extend its original expiry. SUBSCRIBE and UNSUBSCRIBE require recorded-state duplicate protection under Section 10.3. For continued delivery, a Manager creates a replacement before the previous subscription expires. Overlap can cause duplicate event delivery. The Agent MUST preserve event_id across copies of the same event; Managers SHOULD deduplicate by agent_id and event_id. Efstathiou Expires 15 March 2027 [Page 31] Internet-Draft SAMP September 2026 subscription_id appears only in a SUBSCRIBE response payload, only in an UNSUBSCRIBE request payload, and only in the common envelope of subscription-associated PUSH. It MUST NOT be duplicated in the PUSH payload. Identifiers are opaque, non-empty strings, unique within an Agent enrollment, and MUST NOT be reused within that enrollment. The endpoint MUST bind ownership to the authenticated Manager. Knowing subscription_id confers no authority to retrieve, cancel, or receive a subscription. Unknown, expired, and already cancelled identifiers return cancelled false with the status defined in the UNSUBSCRIBE payload. An identifier belonging to another Manager returns policy_denied without exposing its filters or state. After successful cancellation the endpoint MUST stop generating new PUSH deliveries for that subscription. Messages already committed to transport or in flight may arrive. Managers MUST tolerate such deliveries and deduplicate them by agent_id and event_id. Subscriptions expire automatically. Core subscriptions do not survive endpoint restart or WebSocket reconnect; persistence requires an explicitly negotiated extension. 8. Message Format All SAMP messages use a common PDU envelope encoded as UTF-8 JSON [RFC8259] in SAMP version 0.1. 8.1. Common PDU Envelope The envelope fields are defined below. Common PDU Envelope Fields: version string; Required; Protocol version, e.g., "0.1" type string; Required; PDU type (see Section 7) direction string; Required; One of request, response, notification, error agent_id string; Required; Identifier of the managed agent timestamp string; Required; UTC timestamp in RFC 3339 format [RFC3339] request_id string; Required; UUID for correlation and replay protection [RFC9562] payload object; Required; PDU-specific JSON object. Empty payloads encode as {}. auth_tag string; Conditional; HMAC-SHA256 authentication tag (see Section 9). Required when authentication is enabled. key_id string; Optional; Opaque identifier for the configured shared secret. It is not an identity credential by itself. sequence integer; Optional; Sequence number for ordered streams Efstathiou Expires 15 March 2027 [Page 32] Internet-Draft SAMP September 2026 subscription_id string; Conditional; Required in the envelope only for a PUSH associated with a subscription. For SUBSCRIBE responses and UNSUBSCRIBE requests it appears only in the payload. Receivers MUST enforce the role/type/direction combinations in the exchange-pattern table: PUSH uses notification; all other defined types use request, response, or error. Response and error type and agent_id MUST match the original request (DISCOVER assigned_id takes effect only afterward). Unknown-type requests are answered with their received type and unknown_type as an explicit exception to the known-type rule. Responses and errors MUST NOT trigger error- response loops. Responses and errors are correlated with an outstanding or recorded request; they are not admitted as new operations. Optional sequence is a positive integer no greater than 9007199254740991 and is permitted only on subscription-associated PUSH. Optional key_id is a non-empty string. auth_tag, when required, MUST be exactly 64 lowercase hexadecimal characters. subscription_id is a non-empty string and MUST NOT appear in other envelope contexts. Unknown envelope fields remain authenticated but have no authorization effect. Implementations MUST document and enforce a positive finite maximum PDU byte length. 8.1.1. Field Validation Rules * version MUST be "0.1" for this version of the protocol. * type MUST be one of the PDU types listed in Section 7, expressed in lowercase (e.g., "ping", "discover", "query"). * direction MUST be one of request, response, notification, error. * agent_id MUST be a non-empty string. * timestamp MUST be a valid RFC 3339 UTC timestamp with timezone designator Z. * request_id MUST be a valid UUID as defined by [RFC9562]. Implementations SHOULD use UUID version 4 or another version with equivalent uniqueness properties. * payload MUST be a JSON object. Empty payloads are encoded as {}. * Unknown envelope fields MUST be ignored by receivers. This ensures forward compatibility. Efstathiou Expires 15 March 2027 [Page 33] Internet-Draft SAMP September 2026 * An unknown PDU type in a request MUST return unknown_type; unknown response/error/notification types MUST NOT generate response loops. 8.1.2. Request/Response Correlation A response or error PDU MUST include the same request_id as the request it corresponds to. This allows both parties to correlate requests and responses without relying on transport-level correlation. The request sender generates request_id. It MUST be unique within that sender's authenticated identity for at least the replay-cache retention window. A notification uses its request_id as the identifier of that transmitted PDU; an event payload may additionally carry event_id and correlation_id with event-specific semantics. 8.1.3. Timestamp Validation timestamp MUST be syntactically valid RFC 3339 UTC with Z. For new requests and notifications, receivers MUST enforce a configured positive finite freshness window; the RECOMMENDED bound is plus or minus 300 seconds. An authenticated recorded duplicate is processed before ordinary request-age rejection as specified in Section 10.3. A timestamp syntax failure is always invalid. Freshness does not replace authenticated replay state. Response and error envelopes MUST use current timestamps and MUST pass ordinary freshness validation. A delayed response may be recovered through an authorized identical retry that obtains a newly generated envelope. Original operation timestamps inside recorded result data are historical values, not envelope freshness claims. 8.1.4. Sequence Numbers The sequence field is OPTIONAL. When present, it provides ordering for streams of PDUs (e.g., subscription event streams). Sequence numbers are per-subscription and start at 1. Receivers MAY detect gaps but MUST NOT reject PDUs solely for sequence gaps in SAMP v0.1. 8.2. PDU-Specific Payloads 8.2.1. PING Request payload: {} Efstathiou Expires 15 March 2027 [Page 34] Internet-Draft SAMP September 2026 Response payload: {"status": "operational"} The status field in the response is a free-form, self-reported endpoint status (e.g., "operational", "degraded"). It does not report workload progress or behavioural correctness. The request payload is an empty object. The response requires status, a non-empty string describing the responding Manager endpoint. Unknown payload extensions are ignored. PING does not report Agent trust_state or workload progress. 8.2.2. DISCOVER DISCOVER request payload members are defined below. The full profile is inline. An unauthenticated bootstrap request can create only discovered or pending trust_state. A matching public-key identifier alone never authenticates a request. DISCOVER Request Members: profile object; required; Complete valid SAMP profile endpoint string; required; Absolute HTTPS Agent URL; HTTP only for loopback testing capabilities array of strings; required; Identical to profile.capabilities supported_versions array of strings; optional; Distinct; contains envelope version enrollment object; required; Closed object defined below Enrollment Object Members: method string; required; manual, token, or public_key_metadata token string; required only for token; Non-empty opaque sensitive enrollment token; forbidden for other methods public_key object; optional only for public_key_metadata; algorithm, encoding, value as below thumbprint object; optional only for public_key_metadata; algorithm, encoding, value as below manual permits only method. public_key_metadata requires at least one of public_key or thumbprint; token forbids both. Unknown members of enrollment or its nested objects MUST be rejected. public_key has required string algorithm (ed25519), encoding (base64), and value (canonical padded RFC 4648 base64 of exactly 32 raw Ed25519 public- key bytes). thumbprint has required string algorithm (sha-256), encoding (hex), and value (64 lowercase hexadecimal characters, Efstathiou Expires 15 March 2027 [Page 35] Internet-Draft SAMP September 2026 SHA-256 of those raw bytes). Other identifiers are rejected as profile_invalid in core v0.1. If both are present their digest MUST agree. These conventions identify metadata only and introduce no signature or proof-of-possession protocol. Managers MUST validate the advertised endpoint against trusted destination policy before connecting, including resolved addresses and every redirect; untrusted discovery MUST NOT authorize access to arbitrary internal services. HTTPS certificate validation remains mandatory. Manager credentials MUST NOT be forwarded to an unauthorized redirected destination. DISCOVER Response Members: trust_state string; required; One of the six defined trust states liveness_state string; required; unknown, reachable, stale, offline manager_version string; required; 0.1 assigned_id string; optional; Non-empty replacement Agent identifier reason string; optional; Human-readable enrollment decision reason; contains no token enforcement_status string; required only when quarantined; requested, applied, failed, indeterminate profile_revision non-empty string; conditional; Accepted snapshot; present together with profile_sequence iff this outcome has an authoritative accepted profile profile_sequence integer; conditional; 1..9007199254740991; paired accepted profile ordering value The old response field state is not used. assigned_id MUST be bound to the authenticated enrollment context and MUST NOT overwrite another enrolled identity. The response envelope retains the requested agent_id; subsequent PDUs and profile use assigned_id. Rejection is a DISCOVER response with trust_state rejected; malformed profiles or authentication failures use the common error envelope. Trust and liveness in DISCOVER report the Manager observation, not a registry-synchronization requirement for endpoints. { "version": "0.1", "type": "discover", "direction": "request", "agent_id": "agent-001", "timestamp": "2026-09-11T10:00:01Z", "request_id": "59388350-8691-5ad0-83a8-ee22e296881a", "payload": { "profile": { "agent_id": "agent-001", "name": "Example Agent", "agent_version": "2026.9.11", "profile_version": "0.1", "profile_revision": "profile-7", "agent_type": "custom", "autonomy_class": "operational-write", "capabilities": [ Efstathiou Expires 15 March 2027 [Page 36] Internet-Draft SAMP September 2026 "ping", "discover", "query", "push", "subscribe", "unsubscribe", "config", "exec" ], "system": { "status": "operational", "uptime": 86400, "version": "2026.9.11", "last_seen": "2026-09-11T10:00:00Z", "log_level": "info" }, "model": {"fallback": "example-model"}, "field_declarations": [ { "name": "system.status", "type": "string", "required": true, "min_length": 1 }, { "name": "system.uptime", "type": "integer", "required": true, "minimum": 0 }, { "name": "system.version", "type": "string", "required": true, "min_length": 1 }, { "name": "system.last_seen", "type": "string", "required": true }, { "name": "system.log_level", "type": "string", "required": true, "enum": ["debug", "info", "warning", "error"] }, { "name": "model.fallback", "type": "string", "required": true, "min_length": 1 }, { "name": "system.optional_counter", "type": "integer", "required": false }, { "name": "system.nullable_note", "type": "string", "required": false, "nullable": true } ], "config_policy": { "enabled": true, "writable_fields": ["system.log_level", "model.fallback"], "policy_revision": "local-3", "audit": true Efstathiou Expires 15 March 2027 [Page 37] Internet-Draft SAMP September 2026 }, "exec_policy": { "enabled": false, "allowed_commands": ["session_reset"], "commands": [ { "name": "session_reset", "parameters": [ { "name": "session_id", "type": "string", "required": true, "min_length": 1 } ], "required_parameters": ["session_id"], "result": { "name": "result", "type": "object", "required": true, "properties": [ { "name": "reset", "type": "boolean", "required": true } ] } } ], "policy_revision": "local-3", "audit": true }, "deployment": { "endpoint_model": "sidecar", "shared_process": false, "shared_host": true, "shared_failure_domain": true, "independent": false, "management_path_survives_failure": true, "evidence_path_survives_failure": true, "independently_enforceable_operations": [] }, "network": { "management_address": "192.0.2.10", "address_family": "ipv4", "prefix_length": 24, "management_interface": "eth0", "endpoint_port": 443, "reachability": "direct", "discovery_scope": "192.0.2.0/24" }, "profile_sequence": 1 }, "endpoint": "https://agent.example/samp", "capabilities": [ "ping", "discover", "query", "push", "subscribe", Efstathiou Expires 15 March 2027 [Page 38] Internet-Draft SAMP September 2026 "unsubscribe", "config", "exec" ], "enrollment": {"method": "manual"} } } { "version": "0.1", "type": "discover", "direction": "response", "agent_id": "agent-001", "timestamp": "2026-09-11T10:00:01Z", "request_id": "59388350-8691-5ad0-83a8-ee22e296881a", "payload": { "trust_state": "pending", "liveness_state": "reachable", "manager_version": "0.1", "profile_revision": "profile-7", "profile_sequence": 1 } } Examples omit auth_tag to show envelope structure and payloads; authenticated outcomes assume a valid enrolled identity binding and a valid tag on the actual exchange. These unsigned illustrations MUST NOT be accepted as authenticated production PDUs. Production senders MUST authenticate the final envelope. Example executions assume prior local enablement and applicable policy approval; HTTPS URLs illustrate deployment configuration. The enrollment metadata encodings use [RFC4648]. These metadata fields do not enable Ed25519 message authentication in core SAMP v0.1. Unknown top-level DISCOVER extensions are ignored, but enrollment is closed. An invalid enrollment object returns schema_mismatch, except unsupported public-key metadata algorithms/encodings or inconsistent key/thumbprint values return profile_invalid. enrollment.method describes the input supplied on reannouncement and does not compel a new approval or silently reset trust. Unknown trust_state or liveness_state values MUST be rejected as invalid_value for core v0.1 and MUST NOT authorize an operation. enforcement_status MUST be absent unless trust_state is quarantined. Authenticated profile installation and duplicate, stale, conflict, busy and restart responses MUST follow Section 5.12. A response reporting an accepted snapshot includes both profile_revision and profile_sequence; bootstrap without an authoritative profile omits both. Trust acceptance and profile acceptance are separate decisions. Efstathiou Expires 15 March 2027 [Page 39] Internet-Draft SAMP September 2026 The accepted-profile response example assumes the authenticated enrollment binding described above. Omitted authentication tags are illustrative; an unauthenticated bootstrap cannot obtain authoritative profile acceptance. Before profile ordering or historical response processing, apply Section 5.12.1. An unseen previous-enrollment announcement returns policy_denied, not initial-profile acceptance, even with a valid retained HMAC. 8.2.3. QUERY +===========================+===========+==========================+ | Member | Type / | Rule | | | presence | | +===========================+===========+==========================+ | fields | array of | Non-empty distinct | | | strings; | declared-category dotted | | | required | paths; duplicate paths | | | | return invalid_value | +---------------------------+-----------+--------------------------+ | expected_profile_revision | non-empty | Expected authoritative | | | string; | profile snapshot | | | required | identifier | +---------------------------+-----------+--------------------------+ Table 8: QUERY Request Members Core QUERY operates only on declared category fields. Reserved identity, deployment, network, relationships, capabilities and configuration/execution policy objects are carried in the authenticated DISCOVER profile; core v0.1 does not define arbitrary dotted-path access to those objects. A future explicitly identified profile or extension may define selective metadata retrieval. Unknown top-level request extensions are ignored. Before resolving any requested field, the endpoint MUST compare expected_profile_revision with its current authoritative revision and bind evaluation to that immutable declaration snapshot. On mismatch it MUST NOT evaluate or return values under another revision and MUST return profile_revision_mismatch in the common error envelope. Missing required request members use schema_mismatch; invalid types, paths or duplicate paths use invalid_value. A required declared field missing from the evaluated instance is profile_invalid, not absent. Efstathiou Expires 15 March 2027 [Page 40] Internet-Draft SAMP September 2026 +==================+===========+===============================+ | Member | Type / | Rule | | | presence | | +==================+===========+===============================+ | profile_revision | non-empty | Exactly the evaluated and | | | string; | requested revision | | | required | | +------------------+-----------+-------------------------------+ | values | object; | Requested declared paths with | | | required | present values satisfying | | | | their declarations | +------------------+-----------+-------------------------------+ | absent | array of | Requested optional declared | | | distinct | paths with no present value | | | strings; | | | | required | | +------------------+-----------+-------------------------------+ | unknown | array of | Requested paths not exposed | | | distinct | or declared as category | | | strings; | fields | | | required | | +------------------+-----------+-------------------------------+ Table 9: QUERY Successful Response Members Every requested path MUST appear exactly once among the keys of values and the members of absent and unknown. These sets MUST be mutually exclusive and their union MUST equal the requested field set. A required field MUST NOT appear in absent. Absence, explicit null and unknown/unexposed are distinct: values may contain null only when it is an actual present value and its declaration permits null. An absent field MUST NOT be encoded as null. All-absent and mixed requests succeed. If and only if every requested path is unknown, return the common unknown_field error rather than a successful partition. Authorization MUST precede disclosure; the endpoint MUST NOT reveal hidden declarations through absent or revision diagnostics. An unauthorized QUERY returns policy_denied without resolving values. A successful response MUST identify the evaluated profile_revision; it cannot refer to a different profile_sequence than the immutable revision binding in Section 5.12. QUERY does not freeze profile evolution or create a transaction. A delayed response remains interpreted under its identified snapshot. If the Manager no longer retains or recognizes that snapshot, it MUST treat the result as unusable, MUST NOT reinterpret it under a newer profile, and MUST refresh the profile before issuing a new QUERY. A retry retains the Efstathiou Expires 15 March 2027 [Page 41] Internet-Draft SAMP September 2026 original expected revision and request bytes under Section 10.3. Without a matching retained QUERY record, an otherwise fresh request is evaluated only if that revision is still authoritative. The following independent payload examples use profile-7. system.optional_counter is declared optional and absent; system.nullable_note is optional, nullable, and has the actual value null for these observations. model.primary is unexposed. Each response payload uses the common response envelope; error payloads use direction error. Present value. { "fields": ["system.status"], "expected_profile_revision": "profile-7" } { "profile_revision": "profile-7", "values": {"system.status": "operational"}, "absent": [], "unknown": [] } Declared but absent. { "fields": ["system.optional_counter"], "expected_profile_revision": "profile-7" } { "profile_revision": "profile-7", "values": {}, "absent": ["system.optional_counter"], "unknown": [] } Explicit nullable value. { "fields": ["system.nullable_note"], "expected_profile_revision": "profile-7" } Efstathiou Expires 15 March 2027 [Page 42] Internet-Draft SAMP September 2026 { "profile_revision": "profile-7", "values": {"system.nullable_note": null}, "absent": [], "unknown": [] } Mixed values, absent and unknown. { "fields": [ "system.status", "system.optional_counter", "model.primary" ], "expected_profile_revision": "profile-7" } { "profile_revision": "profile-7", "values": {"system.status": "operational"}, "absent": ["system.optional_counter"], "unknown": ["model.primary"] } All absent (both optional fields have no value in this independent observation). { "fields": ["system.optional_counter", "system.nullable_note"], "expected_profile_revision": "profile-7" } { "profile_revision": "profile-7", "values": {}, "absent": ["system.optional_counter", "system.nullable_note"], "unknown": [] } Unknown field / all unknown (the single requested field is unexposed): { "fields": ["model.primary"], "expected_profile_revision": "profile-7" } Efstathiou Expires 15 March 2027 [Page 43] Internet-Draft SAMP September 2026 { "error": { "code": "unknown_field", "detail": "No requested category fields are exposed", "timestamp": "2026-09-11T10:00:01Z" } } Revision mismatch: the same request expecting profile-7 after profile-8 becomes authoritative returns this error payload. The optional current revision is shown only for an authorized recipient: { "error": { "code": "profile_revision_mismatch", "detail": "Expected profile revision unavailable", "timestamp": "2026-09-11T10:00:01Z", "current_profile_revision": "profile-8" } } Before using a response, the Manager MUST validate its partition, values and profile_revision against the original request and identified snapshot. A response failing these checks is unusable, not evidence of a changed declaration. 8.2.4. PUSH Notification payload: { "event": "status_change", "data": {"old_status": "operational", "new_status": "degraded"}, "category": "system", "severity": "warning", "event_id": "d9df237c-f7cd-4fc8-b4e7-d35c676ad20f" } The event field is the event type. The data field is an arbitrary JSON object with event-specific content. The category field indicates the profile category the event relates to. The optional severity field is distinct from category and describes operational importance. The event_id field uniquely identifies the event. An optional correlation_id associates the event with an action, request, or state transition. PUSH PDUs use direction: "notification". No SAMP response or acknowledgment PDU is defined for PUSH. Efstathiou Expires 15 March 2027 [Page 44] Internet-Draft SAMP September 2026 event, category, and event_id are required non-empty strings; event_id MUST be a UUID and is stable across deliveries of the same event. data is a required object. category names the relevant profile category; runtime_evidence uses category system. severity is an optional non-empty descriptive string, not an authorization input. correlation_id is an optional non-empty string. Unknown extensions are ignored. A PUSH is a notification, with no separate SAMP acknowledgment. An HTTP response to its POST completes the transport request only. 8.2.5. Runtime Evidence A PUSH with event runtime_evidence carries the runtime-evidence object in payload.data. A CONFIG/EXEC outcome MAY carry the same object in runtime_evidence. CCS is one possible optional Informative binding; it is neither required nor preferred. Evidence profiles define issuer authentication and evidence-specific validation, not a bypass of SAMP admission. Runtime-Evidence Object Members: evidence_subject object; required; Closed object with id, a non- empty evidence subject string issuer non-empty string; required; Identity of evidence producer sender non-empty string; conditional; Required when relay differs from issuer; otherwise absent or equal to issuer validator non-empty string; conditional; Required for pre_admission; actor validating evidence enforcement_actor non-empty string; conditional; Required for pre_admission; actor enforcing decision before execution phase string; required; pre_admission, post_execution, state_observation policy_outcome string; required; allow, deny, indeterminate; evidence verdict, not operation outcome processing_status string; required; verified, unverifiable, malformed, unsupported evidence_format string; required; Stable versioned absolute URI; incompatible formats MUST use different identifiers correlation object; required; Bindings defined below freshness object; required; Time and nonce bindings defined below evidence object; required; Inline or approved integrity-protected reference defined below verifier_deployment object; optional; Survival declarations defined below; never proof of independence recommended_action string; optional; observe, quarantine, revoke; advisory only Evidence Correlation Members: Efstathiou Expires 15 March 2027 [Page 45] Internet-Draft SAMP September 2026 request_id UUID string; required for operation evidence; Original operation request_id agent_id non-empty string; required; Target Agent operation_type string; required for operation evidence; config or exec request_digest string; required for operation evidence; 64 lowercase hex SHA-256 of RFC 8785 canonical request with only auth_tag removed profile_revision non-empty string; required; Admission profile revision policy_revision object; required when applicable; Same endpoint/ manager revision object as captured admission context evidence_subject_id non-empty string; required; MUST equal evidence_subject.id For pre_admission and post_execution, all operation-evidence fields in correlation are mandatory. For state_observation without an associated CONFIG/EXEC, request_id, operation_type, and request_digest MUST be absent; the subject, target, profile revision, and applicable policy revision still bind the observation. Unknown correlation or freshness members MUST be rejected unless an explicitly identified profile specifies them. Evidence content MUST NOT be included in the request it hashes in a way that creates a self-referential digest. Core pre-admission evidence is obtained or generated by the endpoint after it has the complete request. Evidence Freshness Members: issued_at string; required; RFC 3339 UTC with Z expires_at string; required; RFC 3339 UTC with Z; strictly later than issued_at nonce string; required; UUID v4 generated by evidence producer; bound by validated evidence challenge_ref string; conditional; Required for core synchronous pre-admission; validator-generated unpredictable UUID v4 challenge The validator MUST verify issued_at is not beyond its configured clock-skew tolerance in the future, expires_at has not passed, and the lifetime does not exceed a documented finite positive local maximum. Pre-admission validation MUST match an outstanding challenge_ref created for this exact request and context; the challenge MUST expire under a documented finite timeout and be consumed once by admission. nonce MUST be checked for reuse across different subjects or contexts until expiry plus permitted skew. Duplicate retrieval of the same recorded operation does not re-admit it and does not require newly issued evidence. Historical response evidence remains historical: it MUST NOT be reused to authorize a new operation. Efstathiou Expires 15 March 2027 [Page 46] Internet-Draft SAMP September 2026 evidence is a closed object with required kind, a string inline or reference. inline requires content (object) and forbids reference fields. reference requires uri (absolute approved HTTPS URI), digest_algorithm (sha-256), and digest (64 lowercase hex), and forbids content. References MUST NOT embed reusable credentials. Core references use no additional retrieval metadata; other schemes require an identified profile. verifier_deployment, when present, is a closed object of optional booleans shared_process, shared_host, shared_failure_domain, and independent. Missing properties mean unknown, not false. Trusted inventory takes precedence over self-declared independence; disagreement makes the survival relationship indeterminate, not automatically the substantive evidence result false. Core v0.1 supports synchronous pre-admission evidence only when the enforcement endpoint can validate required evidence before execution. validator and enforcement_actor MUST identify the actors in the authenticated evidence/admission record, and the endpoint MUST be able to establish their authority through local policy and the evidence profile. The endpoint MUST NOT execute before validation succeeds. An allow verdict with processing_status other than verified is indeterminate and MUST NOT authorize execution. Correlation mismatch, expiry, failed challenge binding, or unsupported required evidence MUST prevent execution. The endpoint can obtain evidence from an external verifier during its local admission process, validate it, enforce the decision, then return evidence of that process in its response. Evidence returned only after execution cannot satisfy a pre-admission requirement. Evidence included only in the final response records the performed admission/validation process; it gives the Manager no retroactive approval opportunity. If Manager-side validation must precede execution and the endpoint cannot make that decision independently, a two-phase exchange is required. Core SAMP v0.1 does not define it. An explicitly identified and mutually supported profile or extension MUST supply the exchange; otherwise the Manager MUST NOT send the operation and the endpoint MUST deny any request whose required safeguard it cannot enforce. A post-execution PUSH cannot satisfy synchronous pre-admission evidence. Later evidence can inform a Manager-owned trust transition but does not rewrite the original admission outcome. recommended_action never changes trust automatically. The absence of expected evidence MUST NOT be interpreted as correct behavior. Efstathiou Expires 15 March 2027 [Page 47] Internet-Draft SAMP September 2026 Top-level unknown evidence members MAY be ignored only if the identified evidence profile allows them; they MUST NOT strengthen an admission claim. The relying endpoint or Manager MUST select an explicitly supported evidence_format and its validation rules before treating processing_status verified as established. A sender- supplied verified string alone is not verification. For operation evidence, request_digest, profile_revision and policy_revision MUST match the locally captured operation; evidence_subject_id MUST match the evaluated subject identified by the supported evidence profile. Request canonicalization is defined in Section 10.3. Transport authentication of sender does not prove that sender issued the evidence. The identified evidence profile MUST establish issuer authentication and the relationship of issuer, validator and enforcement_actor to the relying policy. A validator or enforcement_actor member outside pre_admission is optional, and if present is a non-empty string describing the actual actor, not a claim of authority. challenge_ref is optional for other phases, and if supplied MUST bind the corresponding challenge according to the evidence profile. Referenced evidence MUST be retrieved over HTTPS with Accept- Encoding: identity. The response MUST have no Content-Encoding header or only the identity content-coding token. Any other coding, including gzip, br or deflate, a coding list, or ambiguous encoding metadata MUST be rejected as unsupported. Transfer framing, including HTTP/1.1 chunk framing, is removed before hashing. SHA-256 covers exactly the resulting HTTP message content octets, without content decoding, transformation, Unicode normalization, JSON parsing, reserialization or canonicalization. Digest validation MUST precede evidence-format parsing. MIME type and evidence-format identity do not change this byte-layer rule. The validator MUST authorize the destination on every redirect hop and validate HTTPS authentication. A redirect MUST NOT change the required digest. Unsupported or ambiguous encoding, digest mismatch or incomplete retrieval MUST fail validation and MUST NOT produce processing_status verified. Libraries that automatically decompress content MUST be configured so these checks and original content bytes are available. Implementations MUST declare and enforce finite deployment-selected limits for downloaded message-content bytes, redirect count, total retrieval duration, connection timeout, read timeout and concurrent evidence retrievals. Time and byte limits MUST be positive; redirect and concurrency limits MAY be zero to disable those facilities. Check capacity before retrieval, count bytes while reading, and reject or terminate when any limit is exceeded. Validate bounds and Efstathiou Expires 15 March 2027 [Page 48] Internet-Draft SAMP September 2026 digest before expensive evidence-format processing. If required pre- admission evidence cannot be retrieved and validated within these limits, admission MUST fail closed. evidence_format MUST be a stable, versioned absolute URI. New identifiers SHOULD use an HTTPS URI under the assigning organization's administrative control; properly allocated URNs MAY also be used. Unregistered urn:ietf identifiers MUST NOT be invented. An HTTPS identifier does not require automatic dereferencing. Identifiers MUST be compared as exact case-sensitive strings, without URI normalization, redirect resolution or case folding; incompatible versions MUST use different identifiers. Byte-layer test vector: the literal 12-byte content below is hexadecimal (including a final LF); it has the following SHA-256 digest. Chunk framing would not change this digest: content hex: 7b226f6b223a747275657d0a sha-256: e5f1eb4d806641698a35efe20e098efd20d7d57a9b90ee69079d5bb650920726 8.2.6. SUBSCRIBE SUBSCRIBE Request Payload: event_types array of distinct non-empty strings; optional; Empty or absent means all events in category category non-empty string; required; Exposed category; unknown category gives unknown_field ttl_seconds integer; required; Positive, no greater than 2147483647, within endpoint-declared deployment bounds An endpoint MUST document minimum and maximum TTL bounds, both positive integers within the protocol bound. An out-of-bounds request returns invalid_value; it is not silently clamped. The accepted TTL is exactly the requested value. Creation time is when the new subscription is committed; expiry is that time plus ttl_seconds. Missing required members or forbidden subscription_id in a request return schema_mismatch. SUBSCRIBE Response Payload: subscription_id non-empty string; required; Opaque identifier owned by authenticated requesting Manager ttl_seconds integer; required; Original accepted TTL expires_at string; required; Original absolute expiry, RFC 3339 UTC with Z Efstathiou Expires 15 March 2027 [Page 49] Internet-Draft SAMP September 2026 A duplicate returns these original values with no new allocation, even if expiry has since passed. The response envelope is regenerated with a current timestamp. The old renew_before field is not defined. For ongoing delivery the Manager creates a replacement using a new request_id. Unknown noncritical payload extensions are ignored. { "version": "0.1", "type": "subscribe", "direction": "request", "agent_id": "agent-001", "timestamp": "2026-09-11T10:00:01Z", "request_id": "34b74b3f-ee59-54a0-b2e7-0cfd10bb21e2", "payload": { "event_types": ["alert"], "category": "system", "ttl_seconds": 300 } } { "version": "0.1", "type": "subscribe", "direction": "response", "agent_id": "agent-001", "timestamp": "2026-09-11T10:00:01Z", "request_id": "34b74b3f-ee59-54a0-b2e7-0cfd10bb21e2", "payload": { "subscription_id": "sub-1", "ttl_seconds": 300, "expires_at": "2026-09-11T10:05:01Z" } } Endpoints MUST declare per-authenticated-Manager and global active- subscription quotas and check them before allocating state. If capacity is unavailable, return rate_limited for a Manager quota or back_pressure for global capacity. Expiry arithmetic MUST use checked operations or sufficiently wide integers so accepted TTLs cannot wrap. Deployments SHOULD select a TTL maximum substantially below the protocol ceiling where appropriate; retaining the bounded wire ceiling does not require accepting a roughly 68-year subscription. 8.2.7. UNSUBSCRIBE The request payload requires subscription_id, a non-empty string; it MUST NOT also appear in the envelope. The response requires cancelled (boolean) and status (string). An active owned subscription returns cancelled true, status cancelled. An expired owned subscription returns false, expired; a previously cancelled owned subscription returns false, already_cancelled; an unknown identifier returns false, unknown. After metadata retention expires an old identifier MAY be classified unknown. Another Manager attempting access to a known foreign identifier receives Efstathiou Expires 15 March 2027 [Page 50] Internet-Draft SAMP September 2026 policy_denied, not subscription details. Retried identical requests return their recorded original payload in a fresh envelope. Unknown noncritical payload extensions are ignored. { "version": "0.1", "type": "unsubscribe", "direction": "request", "agent_id": "agent-001", "timestamp": "2026-09-11T10:00:01Z", "request_id": "9122334b-2a0c-55da-a98d-24f0d5a4be9e", "payload": {"subscription_id": "sub-1"} } { "version": "0.1", "type": "unsubscribe", "direction": "response", "agent_id": "agent-001", "timestamp": "2026-09-11T10:00:01Z", "request_id": "9122334b-2a0c-55da-a98d-24f0d5a4be9e", "payload": {"cancelled": true, "status": "cancelled"} } 8.2.8. Common CONFIG and EXEC Admission and Outcomes CONFIG and EXEC request payloads MUST include admission_context, a closed object requiring profile_revision (non-empty string naming the expected profile snapshot). policy_revision is an optional closed object containing non-empty endpoint and/or manager revision strings; at least one member is required if present. endpoint, when supplied, MUST match the endpoint local policy revision for a new admission. manager identifies the Manager policy used before transmission and is an audit binding, not a replacement for endpoint enforcement. No new admission may silently substitute a different expected profile or endpoint policy revision; mismatch returns policy_denied with not_executed. Unknown admission_context members MUST be rejected. For a recorded duplicate, expected context is compared with the original captured context, not current profile or policy content. Changed current policy can deny access to recorded state but MUST NOT cause re-execution. The record retains the original expected context and actual endpoint admission context. Requests denied before a profile can be resolved use null profile_revision in their outcome and record the requested revision in the audit trail. Efstathiou Expires 15 March 2027 [Page 51] Internet-Draft SAMP September 2026 +===================+============+=================================+ | Member | Type / | Placement and meaning | | | presence | | +===================+============+=================================+ | policy_outcome | string; | allow, deny, indeterminate | | | required | | +-------------------+------------+---------------------------------+ | execution_outcome | string; | not_executed, in_progress, | | | required | succeeded, partially_succeeded, | | | | failed, indeterminate | +-------------------+------------+---------------------------------+ | operation_ref | UUID | Original request_id; scoped to | | | string; | authenticated sender and target | | | required | | +-------------------+------------+---------------------------------+ | profile_revision | non-empty | Captured admission profile; | | | string or | null only if admission denied/ | | | null; | indeterminate before resolution | | | required | | +-------------------+------------+---------------------------------+ | policy_revision | object; | Closed object: endpoint and/or | | | required | manager non-empty revision | | | when | strings captured at admission | | | applicable | | +-------------------+------------+---------------------------------+ | result | JSON | CONFIG result object or typed | | | value; | EXEC result; null when not yet | | | required | available | +-------------------+------------+---------------------------------+ | runtime_evidence | object; | Runtime-evidence object defined | | | optional | in its section | +-------------------+------------+---------------------------------+ | execution_detail | non-empty | Human-readable confirmed EXEC | | | string; | failure detail; never an | | | optional | admission decision | +-------------------+------------+---------------------------------+ Table 10: Common Operation Outcome Object The outcome is the response payload itself for direction response. For an admission error it appears as payload.outcome alongside payload.error, never as a success-shaped response. Only CONFIG and EXEC admission errors require outcome after the receiver authenticates and identifies a syntactically valid operation request. Access, replay-conflict, and pre-admission transport/capacity failures omit outcome when they cannot attest original admission state. Malformed or unauthenticated requests use the ordinary error object without inventing admission state. Efstathiou Expires 15 March 2027 [Page 52] Internet-Draft SAMP September 2026 +================+=====================+=========================+ | policy_outcome | execution_outcome | Rule | +================+=====================+=========================+ | deny | not_executed | Common error envelope; | | | | policy_denied, | | | | config_disabled, or | | | | exec_disabled as | | | | applicable | +----------------+---------------------+-------------------------+ | indeterminate | not_executed | Common error envelope | | | | with policy_denied; | | | | missing/invalid | | | | required evidence does | | | | not authorize execution | +----------------+---------------------+-------------------------+ | allow | in_progress | Execution admitted and | | | | still running; return | | | | recorded state on retry | +----------------+---------------------+-------------------------+ | allow | succeeded | Confirmed complete | | | | success | +----------------+---------------------+-------------------------+ | allow | partially_succeeded | Confirmed partial | | | | result; core CONFIG | | | | only | +----------------+---------------------+-------------------------+ | allow | failed | Confirmed execution | | | | failure, not admission | | | | denial | +----------------+---------------------+-------------------------+ | allow | indeterminate | Execution completion or | | | | effect cannot be | | | | established | +----------------+---------------------+-------------------------+ Table 11: Valid Outcome Combinations All other combinations are invalid. EXEC MUST NOT use partially_succeeded unless an explicitly identified extension defines its result semantics. profile_revision MUST be non-null for allow. A confirmed execution failure uses direction response and execution_outcome failed, not policy_denied. No final response by itself proves that all external effects were transactional. A transport failure alone MUST NOT be interpreted as confirmed execution failure. Efstathiou Expires 15 March 2027 [Page 53] Internet-Draft SAMP September 2026 Every CONFIG/EXEC outcome MUST be auditable and bound to its operation_ref, authenticated sender, target, type, request digest, captured profile and policy context. The Manager and endpoint MUST record admission and execution separately. Access failures on a retry use an ordinary policy_denied error and MUST NOT overwrite the recorded original operation outcome. For deny or indeterminate policy outcomes, result MUST be null. For allow/in_progress, result MUST be null. An outcome object MUST NOT contain unknown members except a mutually supported extension; the known optional execution_detail is permitted only for EXEC with allow/failed. A result validation failure after execution MUST NOT be recast as policy denial: report allow/failed if failure is established, or allow/indeterminate if effects cannot be established. An allow outcome MUST include policy_revision.endpoint identifying the actual local policy used at admission. If admission_context supplied policy_revision.manager, every recorded outcome MUST retain it unchanged. Local policy revisions MUST change for every admission-relevant local policy change and MUST NOT be reused for different policy content within the enrollment. Manager policy revisions obey the same non-reuse rule within that Manager authority. 8.2.9. CONFIG The first request and representative response/error use complete envelopes. Alternative successful-direction outcomes below are payload-only: use the same response envelope fields and correlate request_id with operation_ref; production envelopes MUST be freshly authenticated. An alternative outcome is an independent scenario, not another response changing a completed operation. The request payload requires fields (non-empty object mapping declared dotted paths to values) and admission_context. scope is an optional string; if present it MUST equal agent. Unknown top-level CONFIG request members MUST be rejected as schema_mismatch. Session scope is outside core v0.1. The endpoint MUST validate all field names, values, writable allow-list membership, class restrictions, and local policy before applying any changes. CONFIG remains disabled unless explicitly enabled. Whole-operation denial prevents all writes and uses a common admission error. If policy admits a subset, the endpoint MAY apply individually permitted fields; no atomic transaction or rollback guarantee is implied. result is a required object with applied (array of distinct path strings), rejected (array of objects requiring field and reason non-empty strings), and indeterminate (array of distinct path strings). A final CONFIG result MUST partition all requested Efstathiou Expires 15 March 2027 [Page 54] Internet-Draft SAMP September 2026 fields exactly once across these containers. A rejected entry confirms that field was not changed by this operation; indeterminate means its effect cannot be established. applied MUST include only confirmed changes. For allow, succeeded requires all requested fields in applied. partially_succeeded requires non-empty applied and rejected and empty indeterminate. failed requires empty applied and indeterminate and all fields in rejected after a confirmed execution failure. Any non- empty indeterminate requires execution_outcome indeterminate. While in_progress, result MUST be null; no final per-field partition is asserted. For denied or indeterminate admission, result MUST be null and execution_outcome not_executed. An all-fields policy rejection is a denied admission, not a successful or partially successful CONFIG. If runtime evidence is required, the enforcement endpoint MUST validate it before applying any affected field under Section 8.2.5. The common outcome fields and error placement are mandatory as defined in Section 8.2.8. { "version": "0.1", "type": "config", "direction": "request", "agent_id": "agent-001", "timestamp": "2026-09-11T10:00:01Z", "request_id": "29d3ebbe-a58f-5e34-94a2-ddcf1d9aea0c", "payload": { "fields": { "system.log_level": "debug", "model.fallback": "other-model" }, "scope": "agent", "admission_context": { "profile_revision": "profile-7", "policy_revision": { "endpoint": "local-3", "manager": "manager-5" } } } } Complete successful response: Efstathiou Expires 15 March 2027 [Page 55] Internet-Draft SAMP September 2026 { "version": "0.1", "type": "config", "direction": "response", "agent_id": "agent-001", "timestamp": "2026-09-11T10:00:01Z", "request_id": "29d3ebbe-a58f-5e34-94a2-ddcf1d9aea0c", "payload": { "policy_outcome": "allow", "execution_outcome": "succeeded", "operation_ref": "29d3ebbe-a58f-5e34-94a2-ddcf1d9aea0c", "profile_revision": "profile-7", "policy_revision": { "endpoint": "local-3", "manager": "manager-5" }, "result": { "applied": ["system.log_level", "model.fallback"], "rejected": [], "indeterminate": [] } } } Partial response payload when local policy rejects the second field: { "policy_outcome": "allow", "execution_outcome": "partially_succeeded", "operation_ref": "29d3ebbe-a58f-5e34-94a2-ddcf1d9aea0c", "profile_revision": "profile-7", "policy_revision": { "endpoint": "local-3", "manager": "manager-5" }, "result": { "applied": ["system.log_level"], "rejected": [ {"field": "model.fallback", "reason": "local_policy"} ], "indeterminate": [] } } Indeterminate response payload when the second field effect cannot be established: Efstathiou Expires 15 March 2027 [Page 56] Internet-Draft SAMP September 2026 { "policy_outcome": "allow", "execution_outcome": "indeterminate", "operation_ref": "29d3ebbe-a58f-5e34-94a2-ddcf1d9aea0c", "profile_revision": "profile-7", "policy_revision": { "endpoint": "local-3", "manager": "manager-5" }, "result": { "applied": ["system.log_level"], "rejected": [], "indeterminate": ["model.fallback"] } } The result object permits only applied, rejected and indeterminate. Each rejected item permits only field and reason. A no-op assignment that confirms the requested value already holds is a successful application and is included in applied; it need not generate a new content revision. No indeterminate field may also be reported applied or rejected. The response examples are alternative outcomes for the illustrated request in separate runs, not a sequence of changing final results for one operation. 8.2.10. EXEC The first request and representative response/error use complete envelopes. Alternative successful-direction outcomes below are payload-only: use the same response envelope fields and correlate request_id with operation_ref; production envelopes MUST be freshly authenticated. An alternative outcome is an independent scenario, not another response changing a completed operation. The request payload requires command (non-empty command name declared in exec_policy.commands), params (object validated by the command parameters), and admission_context. Unknown top-level EXEC request members and undeclared params MUST be rejected as schema_mismatch. EXEC MUST be explicitly enabled locally and the command MUST appear in allowed_commands. Free-form untyped arguments are prohibited. Efstathiou Expires 15 March 2027 [Page 57] Internet-Draft SAMP September 2026 The successful and executing examples use a separately provisioned profile-8 snapshot: starting from the appendix profile, local provisioning sets exec_policy.enabled true, exec_policy.policy_revision local-4 and profile_revision profile-8, with profile_sequence 2. CONFIG policy remains local-3. The disabled error example uses profile-7/local-3 and answers an otherwise equivalent request with that admission_context. These identifiers are never reused for different content. The response uses the common outcome model. succeeded result MUST match the command result declaration, or be null if no declaration exists. in_progress and indeterminate return result null because no definitive typed result is asserted. failed returns result null and MAY include execution_detail, an optional non-empty human-readable string in the outcome; execution_detail MUST NOT imply admission denial. The obsolete standalone success string is not an outcome model. If disabled, the recipient MUST return direction error with exec_disabled and a deny/not_executed outcome. Other admission denial uses policy_denied; admission uncertainty uses indeterminate/ not_executed and policy_denied. Evidence requirements are enforced before execution, not approved retroactively from the final response. { "version": "0.1", "type": "exec", "direction": "request", "agent_id": "agent-001", "timestamp": "2026-09-11T10:00:01Z", "request_id": "c2773f5c-8182-5d5b-a11c-f079083b5371", "payload": { "command": "session_reset", "params": {"session_id": "sess-001"}, "admission_context": { "profile_revision": "profile-8", "policy_revision": { "endpoint": "local-4", "manager": "manager-5" } } } } Complete success response after explicit local enablement: Efstathiou Expires 15 March 2027 [Page 58] Internet-Draft SAMP September 2026 { "version": "0.1", "type": "exec", "direction": "response", "agent_id": "agent-001", "timestamp": "2026-09-11T10:00:01Z", "request_id": "c2773f5c-8182-5d5b-a11c-f079083b5371", "payload": { "policy_outcome": "allow", "execution_outcome": "succeeded", "operation_ref": "c2773f5c-8182-5d5b-a11c-f079083b5371", "profile_revision": "profile-8", "policy_revision": { "endpoint": "local-4", "manager": "manager-5" }, "result": {"reset": true} } } In-progress response payload: { "policy_outcome": "allow", "execution_outcome": "in_progress", "operation_ref": "c2773f5c-8182-5d5b-a11c-f079083b5371", "profile_revision": "profile-8", "policy_revision": { "endpoint": "local-4", "manager": "manager-5" }, "result": null } Confirmed execution-failure response payload: { "policy_outcome": "allow", "execution_outcome": "failed", "operation_ref": "c2773f5c-8182-5d5b-a11c-f079083b5371", "profile_revision": "profile-8", "policy_revision": { "endpoint": "local-4", "manager": "manager-5" }, "result": null, "execution_detail": "Reset execution failed." } Indeterminate execution response payload: Efstathiou Expires 15 March 2027 [Page 59] Internet-Draft SAMP September 2026 { "policy_outcome": "allow", "execution_outcome": "indeterminate", "operation_ref": "c2773f5c-8182-5d5b-a11c-f079083b5371", "profile_revision": "profile-8", "policy_revision": { "endpoint": "local-4", "manager": "manager-5" }, "result": null } Complete disabled-operation error: { "version": "0.1", "type": "exec", "direction": "error", "agent_id": "agent-001", "timestamp": "2026-09-11T10:00:01Z", "request_id": "63f40094-6729-5d34-8954-2c5eeab47daa", "payload": { "error": { "code": "exec_disabled", "detail": "EXEC is not enabled", "timestamp": "2026-09-11T10:00:01Z" }, "outcome": { "policy_outcome": "deny", "execution_outcome": "not_executed", "operation_ref": "63f40094-6729-5d34-8954-2c5eeab47daa", "profile_revision": "profile-7", "policy_revision": { "endpoint": "local-3", "manager": "manager-5" }, "result": null } } } The response examples are alternative outcomes in separate runs. The disabled profile-7 example is a distinct request from the enabled profile-8 example. Repeating an already completed operation with altered profile context and the same identifier is prohibited. 8.3. Error Envelope When an error occurs, the response PDU has direction: "error" and the payload contains an error object: Efstathiou Expires 15 March 2027 [Page 60] Internet-Draft SAMP September 2026 { "version": "0.1", "type": "query", "direction": "error", "agent_id": "agent-001", "timestamp": "2026-09-11T10:00:01Z", "request_id": "70a09917-70a4-5707-a59f-c8ff74917a36", "payload": { "error": { "code": "unknown_field", "detail": "Field 'model.primary' is not exposed", "timestamp": "2026-09-11T10:00:01Z" } } } The error payload object has the following fields: Error Payload Fields: code string; Required; Error code (see Section 8.4) detail string; Optional; Human-readable error detail timestamp string; Required; UTC timestamp in RFC 3339 format The error object is payload.error and requires code and timestamp; detail is optional. For authenticated, well-formed CONFIG/EXEC admission errors, payload.outcome additionally contains the common operation outcome. Ordinary access/conflict/transport errors that cannot attest admission or execution state MUST omit outcome rather than fabricate it. Unknown error codes MUST be treated as an unsuccessful request with no inference about execution; they MUST NOT trigger automatic non-idempotent re-execution. For profile_revision_mismatch only, error MAY contain current_profile_revision, a non-empty string identifying the current authoritative revision, but only if its disclosure is authorized. Otherwise this member MUST be absent and detail MUST reveal only that the expected revision is unavailable. It MUST NOT contain profile values. Other errors MUST omit this member. The illustrated unknown_field error uses HTTP 404; bootstrap_failed uses HTTP 403. All core mappings are defined in Section 10.1.4. 8.4. Error Codes The following error codes are defined for SAMP v0.1: Efstathiou Expires 15 March 2027 [Page 61] Internet-Draft SAMP September 2026 +===========================+===================================+ | Code | Description | +===========================+===================================+ | malformed_pdu | The PDU is not valid JSON or is | | | missing required envelope fields | +---------------------------+-----------------------------------+ | unknown_type | The PDU type is not recognized | +---------------------------+-----------------------------------+ | invalid_value | A field value is invalid (e.g., | | | wrong type, out of range) | +---------------------------+-----------------------------------+ | schema_mismatch | The payload does not match the | | | expected schema for the PDU type | +---------------------------+-----------------------------------+ | version_unsupported | The protocol version is not | | | supported | +---------------------------+-----------------------------------+ | profile_invalid | The profile is missing required | | | fields or is otherwise invalid | +---------------------------+-----------------------------------+ | auth_failed | Authentication failed (missing or | | | invalid authentication tag) | +---------------------------+-----------------------------------+ | replay_detected | The request_id was previously | | | seen with different request | | | content, or the PDU violates the | | | replay-window policy | +---------------------------+-----------------------------------+ | unknown_field | A requested field is not exposed | | | by the agent; HTTP 404 | +---------------------------+-----------------------------------+ | exec_disabled | EXEC is not enabled for this | | | agent or command | +---------------------------+-----------------------------------+ | config_disabled | CONFIG is not enabled for this | | | agent | +---------------------------+-----------------------------------+ | policy_denied | Manager or endpoint policy denies | | | admission or cannot establish | | | required safeguards | +---------------------------+-----------------------------------+ | rate_limited | The receiver is rate-limiting | | | requests | +---------------------------+-----------------------------------+ | back_pressure | Receiver temporarily cannot | | | safely process admission, | | | including overload or unavailable | | | profile ordering state | Efstathiou Expires 15 March 2027 [Page 62] Internet-Draft SAMP September 2026 +---------------------------+-----------------------------------+ | bootstrap_failed | Agent bootstrap or enrollment | | | failed; HTTP 403 | +---------------------------+-----------------------------------+ | internal_error | An internal error occurred on the | | | receiver side | +---------------------------+-----------------------------------+ | profile_revision_mismatch | Expected QUERY revision is not | | | the current authoritative | | | snapshot | +---------------------------+-----------------------------------+ | profile_stale | Authenticated profile | | | announcement sequence is below | | | the accepted sequence | +---------------------------+-----------------------------------+ | profile_sequence_conflict | Profile sequence or revision is | | | reused inconsistently with | | | accepted content | +---------------------------+-----------------------------------+ Table 12: SAMP Error Codes 8.5. JSON Encoding Requirements * All SAMP JSON MUST be encoded as UTF-8 [RFC8259]. * Implementations MUST NOT include byte-order marks (BOM). * Implementations MUST NOT use non-standard JSON extensions (e.g., trailing commas, comments). * Field names in the envelope and in defined payloads are lowercase with underscores (e.g., request_id, agent_id). * Timestamps MUST use RFC 3339 UTC format with the Z designator [RFC3339]. * UUIDs MUST be in canonical string form [RFC9562]. * Unknown envelope fields MUST be ignored (forward compatibility). * An unknown PDU type in a request MUST return unknown_type; unknown response/error/notification types MUST NOT generate response loops. All messages MUST satisfy the RFC 8785 input constraints, even in loopback tests with authentication disabled: duplicate member names, lone surrogates, non-finite numbers, and non-interoperable numeric Efstathiou Expires 15 March 2027 [Page 63] Internet-Draft SAMP September 2026 values MUST be rejected. Unknown fields are retained for authentication before semantic ignoring. This prevents different parsers from validating different signed content. 8.6. Behavior for Unknown Fields and Unknown PDU Types Unknown envelope fields MUST be ignored semantically but remain covered by authentication. Unknown request PDU types return unknown_type. Unknown types in responses or notifications MUST NOT initiate response loops; they are discarded or reported locally. Unknown payload extensions are ignored only where the PDU section permits it. CONFIG and EXEC request objects, admission_context, type declarations, policy/command declarations, and enrollment metadata are explicitly closed and MUST reject unknown members. Runtime- evidence correlation/freshness and reference objects are closed except for identified evidence profiles. Unknown profile top-level extensions cannot authorize operations; unknown values inside declared closed categories are invalid. These stricter rules take precedence over generic forward-compatibility behavior. All received fields, including ignored extensions, remain in the authenticated canonical object. A future extension requiring rejection when unsupported must define a negotiated critical- extension mechanism; core v0.1 defines none. 9. Authentication SAMP v0.1 uses shared-secret authentication with HMAC-SHA256 [RFC2104] [RFC6234]. 9.1. Authentication Model SAMP distinguishes between: * *Mandatory implementation support*: All conformant SAMP v0.1 implementations MUST support HMAC-SHA256 message authentication. * *Mandatory deployment use*: Deployments on non-localhost networks MUST enable authentication and MUST use HTTPS for transport confidentiality. * *Localhost/lab exception*: Authentication MAY be disabled for loopback (127.0.0.1/localhost) development and testing only. * *Message authentication*: HMAC-SHA256 over the canonical form of the PDU (see Section 9.4). Efstathiou Expires 15 March 2027 [Page 64] Internet-Draft SAMP September 2026 * *Transport confidentiality*: Provided by TLS 1.3 [RFC8446] for HTTPS. SAMP does not define its own transport encryption. * Authorization policy: Manager-owned trust and Manager policy gate transmission; the endpoint authenticates/authorizes the Manager and enforces local policy before execution. Both restrictions apply. The loopback testing exception does not waive local authorization, typed validation, or admission rules. For such testing an implementation MUST bind a configured local test identity to each peer for recorded-state and subscription ownership; it MUST NOT reuse this exception for non-loopback traffic. Unauthenticated bootstrap DISCOVER is the sole non-loopback authentication exception and cannot itself promote trust. Public-key metadata in DISCOVER is not HMAC authentication and does not prove private-key possession. Manual or token enrollment also requires the authenticated or explicitly verified binding specified in Enrollment. Shared secrets MUST be bound to the configured Manager-Agent pair and never selected solely from an untrusted identity claim. 9.2. HMAC-SHA256 Signing When authentication is enabled: 1. The sender computes a canonical JSON representation of the PDU (see Section 9.4). 2. The sender computes HMAC-SHA256 over the canonical bytes using the shared secret. 3. The resulting authentication tag is placed in the auth_tag envelope field as a lowercase hex-encoded string. 4. The receiver recomputes the HMAC over the canonical form (excluding only the auth_tag field) and compares it to the received authentication tag. 5. If the authentication tag is missing or does not match, the receiver returns an auth_failed error. Efstathiou Expires 15 March 2027 [Page 65] Internet-Draft SAMP September 2026 9.3. Key Identification SAMP v0.1 uses a shared secret per manager-agent pair. A deployment MAY assign an opaque key_id so that a receiver can select among locally configured secrets during manual rotation. A receiver MUST NOT silently fall back to an unrelated key when an unknown key_id is received. Automated key rotation and negotiation are not defined in v0.1. Key distribution is out of band. Implementations SHOULD store shared secrets in a secrets manager, not in plaintext configuration files. Same-enrollment rotation preserves ordering; enrollment replacement requires a fresh, distinguishable credential/context under Section 5.12.1. Optional key_id is only a key selector, not proof of enrollment membership. 9.4. Canonical JSON SAMP v0.1 uses the JSON Canonicalization Scheme (JCS) defined in [RFC8785] for computing HMAC authentication tags. 9.4.1. Canonicalization Procedure 1. Take the PDU as a JSON object. 2. Remove only the auth_tag field from the object. All other envelope, payload, and extension fields, including timestamp, request_id, and key_id, remain covered. 3. Apply RFC 8785 canonicalization to the resulting object: Sort object keys lexicographically (as defined by RFC 8785); serialize numbers according to RFC 8785 rules; escape strings according to RFC 8785 rules; remove insignificant whitespace. 4. Encode the canonical string as UTF-8. 5. Compute HMAC-SHA256 over the UTF-8 bytes. 9.4.2. Authentication Tag Representation The auth_tag field contains the lowercase hex-encoded HMAC-SHA256 digest. The tag is exactly 64 lowercase hexadecimal characters. No example placeholder is a valid authentication tag. Efstathiou Expires 15 March 2027 [Page 66] Internet-Draft SAMP September 2026 9.4.3. Verification Procedure 1. Perform inexpensive size, JSON-syntax, required-field, and timestamp-syntax checks; reject duplicate JSON member names and non-JCS-compatible values before canonicalization. 2. Extract the auth_tag field from the received PDU. 3. Remove only the auth_tag field from the PDU object. 4. Apply RFC 8785 canonicalization to the modified object. 5. Encode as UTF-8. 6. Compute HMAC-SHA256 using the shared secret. 7. Compare the computed digest with the received authentication tag using a constant-time comparison. 8. If they match, authentication succeeds. If not, return auth_failed. 9. After authentication succeeds, compute the request digest and consult recorded state scoped to the authenticated sender before ordinary timestamp-age rejection, as specified in Section 10.3. For requests with no matching record and for notifications, enforce freshness before processing. 9.4.4. Failure Behavior * Missing auth_tag field when authentication is enabled: auth_failed error. * Invalid authentication tag: auth_failed error. * Malformed authentication tag (not a valid hex string): auth_failed error. 9.4.5. Unicode Normalization SAMP does not apply Unicode normalization during authentication-tag generation or verification. JSON strings are preserved exactly as they appear in the PDU object. The sender MUST NOT modify or normalize JSON string values before applying JCS canonicalization. The receiver MUST NOT modify or normalize JSON string values before verifying the authentication tag. Efstathiou Expires 15 March 2027 [Page 67] Internet-Draft SAMP September 2026 Different Unicode code-point sequences produce different canonical bytes and therefore different HMAC authentication tags. If an implementation needs a specific normalization form (e.g., NFC) for application-level consistency, it MUST apply normalization before constructing the PDU object, not as an authentication step. 10. Transport Mapping SAMP defines protocol semantics and message envelopes independently from the underlying transport. 10.1. HTTP Transport SAMP v0.1 requires HTTP [RFC9110] as the baseline transport. 10.1.1. HTTP Method All SAMP PDUs are sent as HTTP POST requests with a JSON body containing the PDU envelope. Responses are returned in the HTTP response body. For agent-to-manager PDUs (PING, DISCOVER, PUSH), the agent sends an HTTP POST to the manager's SAMP endpoint. For manager-to-agent PDUs (QUERY, CONFIG, EXEC, SUBSCRIBE, UNSUBSCRIBE), the manager sends an HTTP POST to the agent's SAMP endpoint. 10.1.2. Content-Type The Content-Type header MUST be application/json. 10.1.3. Endpoint Path Implementations MAY choose any endpoint path. The agent's SAMP endpoint URL is advertised in the DISCOVER payload's endpoint field. The manager's SAMP endpoint URL is configured during agent bootstrap. Recommended conventional paths: Manager: POST /samp (accepts all PDU types); Agent: POST /samp (accepts all PDU types). 10.1.4. HTTP Status Codes SAMP uses HTTP status codes as follows: Efstathiou Expires 15 March 2027 [Page 68] Internet-Draft SAMP September 2026 +==================+=================================+ | HTTP Status | Meaning | +==================+=================================+ | 200 OK | Successful request or response | +------------------+---------------------------------+ | 400 Bad Request | Malformed PDU or invalid JSON | +------------------+---------------------------------+ | 401 Unauthorized | HTTP authentication extension | | | challenge; not core HMAC errors | +------------------+---------------------------------+ | 403 Forbidden | Authentication, policy or | | | bootstrap failure | +------------------+---------------------------------+ | 404 Not Found | Unknown field, agent or | | | endpoint | +------------------+---------------------------------+ | 409 Conflict | Replay detected or state | | | conflict | +------------------+---------------------------------+ | 429 Too Many | Rate limited | | Requests | | +------------------+---------------------------------+ | 500 Internal | Internal error | | Server Error | | +------------------+---------------------------------+ | 503 Service | Back-pressure or overload | | Unavailable | | +------------------+---------------------------------+ Table 13: HTTP Status Code Mapping The SAMP error envelope in the response body provides the precise error code. The HTTP status code is a transport-level indicator; the SAMP error code is authoritative. For a successful PUSH POST, the receiver returns HTTP 200 with an empty body. This is transport completion, not a SAMP acknowledgment PDU, and does not assert durable event processing. For request PDUs, the body contains the SAMP response/error envelope. A failed PUSH POST returns the appropriate HTTP error status with an empty body; it MUST NOT create a SAMP acknowledgment or error PDU for the notification. If malformed input lacks a valid request_id, agent_id, or type, the receiver returns HTTP 400 without a SAMP envelope; it MUST NOT invent correlation identifiers. A response/error MUST NOT trigger another error. For WebSocket, an uncorrelatable malformed message closes the connection under the transport error policy. When a correlated Efstathiou Expires 15 March 2027 [Page 69] Internet-Draft SAMP September 2026 authenticated CONFIG/EXEC is denied during admission, the common error payload includes outcome. Internal transport errors that cannot establish execution state MUST NOT fabricate a succeeded or failed outcome. All successfully processed CONFIG/EXEC response PDUs use HTTP 200, including in_progress, failed, partially_succeeded and indeterminate; this reports protocol processing, not successful effects. Core error mappings MUST be: malformed_pdu, unknown_type, invalid_value, schema_mismatch, version_unsupported and profile_invalid to HTTP 400; auth_failed, policy_denied, config_disabled, exec_disabled and bootstrap_failed to HTTP 403; unknown_field to HTTP 404; replay_detected to HTTP 409; rate_limited to HTTP 429; back_pressure to HTTP 503; internal_error to HTTP 500. The three profile-specific HTTP 409 mappings follow below. HTTP 401 remains reserved for an explicitly specified HTTP-authentication extension; core HMAC defines no challenge behavior. The authenticated SAMP error code remains authoritative. profile_revision_mismatch, profile_stale and profile_sequence_conflict map to HTTP 409. Their SAMP error codes distinguish snapshot mismatch, stale ordering and content conflict; schema_mismatch is reserved for payload/schema invalidity. 10.1.5. HTTPS Requirements * Plain HTTP is suitable ONLY for localhost (127.0.0.1) development and testing. It MUST NOT be used for non-localhost deployments. * HTTPS is REQUIRED for all non-localhost deployments, including isolated management networks. * TLS 1.3 [RFC8446] is RECOMMENDED. TLS 1.2 MAY be used for compatibility but TLS 1.3 is preferred. * Certificate validation MUST be enforced for HTTPS connections, including development HTTPS connections. Loopback plain HTTP remains the explicit testing exception. 10.2. WebSocket Transport WebSocket support is OPTIONAL in SAMP v0.1. WebSocket is primarily useful for: * Persistent event streams (subscription delivery). * Frequent heartbeats (reducing HTTP overhead). Efstathiou Expires 15 March 2027 [Page 70] Internet-Draft SAMP September 2026 * Bidirectional communication without polling. When WebSocket is used: * The connection upgrade follows the WebSocket protocol [RFC6455]. * Each SAMP PDU is sent as one complete WebSocket text message containing one JSON envelope. Receivers reassemble fragmented frames before parsing; frame boundaries are not PDU boundaries. * The same PDU envelope format and authentication rules apply. * A WebSocket connection does not change the request-response semantics of individual PDUs. WebSocket transport is NOT required for any conformance tier in v0.1. Authentication requirements are unchanged by the WebSocket upgrade. If a connection carrying an active subscription is lost, the manager MUST re-establish the connection and re-subscribe unless both peers explicitly implement a persistence extension. Core v0.1 does not require event buffering or subscription persistence across reconnect. Non-loopback WebSocket deployments MUST use wss with certificate validation and the same TLS policy as HTTPS. The initiating peer and URL are configured by deployment; supported roles and message limits MUST be documented. PUSH has no SAMP acknowledgment on this transport. A lost connection does not change trust_state; it affects liveness and subscription transport state. 10.3. Retry and Backoff A genuine retry MUST reuse the original authenticated request bytes, including timestamp, key_id, request_id, and auth_tag. A sender MUST NOT refresh these fields or alter serialization for a retry. The receiver compares the semantic digest defined below; identical bytes always retain that digest. Exponential backoff MAY be used within the declared accepted retry window. A new request_id is a new operation and MUST NOT be used merely to evade uncertain execution state. The request digest is SHA-256 over RFC 8785 canonical UTF-8 bytes of the PDU with only auth_tag removed. It binds type, target, timestamp, request_id, key_id, payload, extensions, and any request admission_context. Parsing and timestamp syntax checks precede authentication; ordinary timestamp age rejection occurs after authenticated recorded-state lookup. Efstathiou Expires 15 March 2027 [Page 71] Internet-Draft SAMP September 2026 Receivers MUST support recorded-operation state for CONFIG, EXEC, SUBSCRIBE, UNSUBSCRIBE and DISCOVER/profile announcements. It is RECOMMENDED for other request types. DISCOVER additionally requires the enrollment ordering state in Section 5.12, which MUST NOT expire merely because a request retry record expires. A record binds authenticated sender, request_id, target Agent, operation type, digest, original request timestamp, captured admission context when applicable, response payload or current operation outcome, and creation/expiry times. A new side-effecting operation MUST reserve its identifier before beginning execution so a concurrent duplicate cannot initiate a second execution. Processing order is: validate syntax and bounded input; authenticate and check the credential/enrollment binding under Section 5.12.1; compute digest; look up recorded state under authenticated sender, enrollment and request_id; check target, type, digest and original bound context; authorize access; return matching state. This duplicate/conflict path precedes ordinary freshness rejection. Bound-value conflicts return replay_detected and MUST NOT execute. Current policy/profile changes do not replace original context; current policy can deny disclosure. Previous-enrollment access is historical-only under that section and cannot fall through to new admission. A matching duplicate returns a newly generated, authenticated response envelope with the current timestamp and original request_id. It MUST NOT return an expired cached envelope byte-for-byte. CONFIG/ EXEC outcomes reference the original request through operation_ref and retain original profile/policy context. If still executing, execution_outcome is in_progress and result is null. A duplicate of an admission error returns the original error outcome in a fresh error envelope. SUBSCRIBE/UNSUBSCRIBE return their original recorded payload; duplicate delivery does not extend expiry or repeat cancellation. Ordinary new request-ID uniqueness is scoped to the authenticated sender. The same UUID can identify unrelated new operations for different authenticated senders. A request for another sender's known operation or subscription MUST NOT retrieve or influence it; if an operation-record lookup identifies that cross-sender conflict, return replay_detected without disclosing state. An unqualified UUID alone MUST NOT select a foreign record. A receiver MUST NOT reject an otherwise unrelated new operation solely because another sender used the same UUID. Possession of an identifier is not authority. If no record exists, the receiver MUST apply ordinary freshness validation before considering new admission. A request outside that window MUST be rejected with replay_detected and MUST NOT execute, Efstathiou Expires 15 March 2027 [Page 72] Internet-Draft SAMP September 2026 including after eviction or restart. If previous execution cannot be established, the execution outcome remains indeterminate; absence of a record is not evidence of not_executed. An authenticated syntactically valid CONFIG/EXEC may receive an ordinary replay_detected error without an outcome when the record needed to establish it is absent. Each implementation MUST declare its freshness/skew bounds, accepted retry window, minimum record retention, capacity behavior, and restart durability. The accepted retry window MUST NOT exceed guaranteed record retention. A side-effecting operation record or non-executable tombstone MUST be retained for at least the larger of the accepted retry window and the remaining interval during which the original timestamp could pass freshness validation (including future clock skew). In-progress records MUST NOT be evicted. If capacity cannot retain that guarantee, new operations MUST be rejected with back_pressure before execution. An implementation losing records on restart MUST preserve sufficient tombstones/admission fencing or fail closed for CONFIG, EXEC, SUBSCRIBE and UNSUBSCRIBE until every request timestamp that could have been accepted before restart is strictly outside the current freshness window. For a symmetric window W, 2W is only an illustrative lower bound, not permission to reopen exactly at elapsed 2W. The fence MUST account for inclusive boundaries, timer resolution, wall-clock adjustment and subsequent backward clock movement; use monotonic elapsed time for the waiting interval. Admission MUST remain or become fenced whenever this safety condition cannot be established. During fencing return back_pressure and MUST NOT execute ambiguous requests. No single restart algorithm is prescribed. Changing credentials MAY aid recovery but does not erase effects already performed. DISCOVER ordering-state loss additionally follows Section 5.12. Recorded outcomes can be retrieved only while retention and authentication credentials permit. Key rotation MUST retain access to the original key for the declared retry window or explicitly document that authenticated retry recovery ends earlier. The effective advertised retry window MUST reflect this limit. No guarantee of exactly-once execution, durable persistence, synchronization, or distributed-store linearizability is made. Across execution crashes, effects may remain indeterminate. Non- idempotent operations SHOULD NOT be retried unless these recorded- state guarantees are supported for that operation type. The complete operation result MUST be retained for the declared accepted retry window; a tombstone alone is sufficient only for the additional non-execution safety interval after that window. A Efstathiou Expires 15 March 2027 [Page 73] Internet-Draft SAMP September 2026 tombstone MUST retain the authenticated owner, identifier, target, type, digest and admission binding and MUST cause a conflict/expired- recovery error, never execution. SUBSCRIBE/UNSUBSCRIBE allocation or cancellation MUST serialize concurrent duplicates until its result is committed. If no committed subscription result is yet available within the response deadline, return back_pressure without releasing the reservation or starting another allocation; this transient feedback does not replace the eventual recorded result. The accepted retry window and minimum retention are measured from initial record creation using a monotonic elapsed-time source. A receiver MUST account conservatively for wall-clock adjustment when deciding whether the request could still pass timestamp freshness. The recorded outcome MAY transition from in_progress to a terminal result as execution resolves; that update MUST retain the same operation identity and original admission context. Retention of an old credential for retry recovery does not authorize new-enrollment traffic: Section 5.12.1 controls replacement overlap and latest-state recovery, independently of the strict timestamp fence above. 11. Conformance Conformance is claimed separately for the Manager role and endpoint role. The following additive tiers identify required operation semantics, including errors, typed validation, and recorded-state behavior where applicable. +================+========================================+ | Tier | Required operations | +================+========================================+ | SAMP-Observe | PING, DISCOVER, QUERY, PUSH | +----------------+----------------------------------------+ | SAMP-Subscribe | Observe plus SUBSCRIBE and UNSUBSCRIBE | +----------------+----------------------------------------+ | SAMP-Configure | Subscribe plus CONFIG | +----------------+----------------------------------------+ | SAMP-Execute | Configure plus EXEC | +----------------+----------------------------------------+ Table 14: Conformance Tiers Endpoints implement the receiving/sending direction of their role; Managers implement the complementary role. Support does not require CONFIG/EXEC to be enabled at deployment. A disabled operation MUST return the specified error. Class restrictions and local policy remain binding at every tier. Efstathiou Expires 15 March 2027 [Page 74] Internet-Draft SAMP September 2026 11.1. Mandatory Implementation Requirements All tiers MUST support UTF-8 JSON, RFC 8785 canonicalization, HTTP and non-loopback HTTPS, HMAC-SHA256, required envelopes, standard error handling, the minimal recursive type declaration model, and separate trust/liveness semantics appropriate to their role. Managers MUST validate profiles; endpoints MUST expose valid profiles and validate inputs. The loopback testing exception does not remove implementation requirements. Subscribe and higher tiers MUST implement subscription ownership, fixed expiry, replacement semantics, and duplicate protection. Configure and Execute MUST implement the common admission/outcome model, policy and profile revisions, local enforcement, admission audit, and recorded-state safety including concurrent duplicates and restart fencing. Optional runtime evidence requires all applicable base correlation/freshness rules and an identified evidence-format profile. QUERY implementations MUST implement Section 8.2.3, including expected revision validation, absent/null/unknown separation and exact partitioning. Managers MUST retain authenticated profile ordering state and fail closed on its loss. Referenced-evidence implementations MUST enforce identity content coding, byte-layer hashing and declared retrieval limits. Subscription implementations MUST enforce declared quotas and overflow-safe expiry. Enrollment replacement and ordering recovery MUST implement Section 5.12.1, including historical-only credential overlap and preservation of the latest committed boundary. 11.2. Conformance Testing Claimed tiers SHOULD be tested across independent implementations for required operations, profile/type validation, authenticated errors, replay/freshness ordering, in-progress duplicates, restart/eviction behavior, partial CONFIG, failed and indeterminate EXEC, ownership violations, overlapping subscriptions, quarantine with offline liveness, and recovered liveness without implicit trust promotion. A reference interoperability suite is not yet available. Local example parsing and same-team tests are implementation evidence, not independent conformance validation. Implementers SHOULD publish interoperability results with declared limits and durability properties. Efstathiou Expires 15 March 2027 [Page 75] Internet-Draft SAMP September 2026 Tests MUST cover present, absent, nullable-null, mixed, all-absent and all-unknown QUERY results; duplicates return invalid_value and revision conflicts return profile_revision_mismatch before resolution. Trace a delayed response across a profile update, including loss of the old snapshot. For announcements test lower (profile_stale), equal-identical (duplicate), equal-conflicting (profile_sequence_conflict), greater (validated update), concurrent updates, assigned identity and restart without ordering state (back_pressure until latest-boundary restoration or valid replacement). Referenced-evidence tests MUST hash fixed identity-coded content before parsing, reject gzip, br, deflate and ambiguous coding, and exercise byte, redirect, duration, timeout and concurrency limits with pre-admission failure closed. Subscription tests MUST exercise both quotas and checked expiry boundaries. Retry-fence tests MUST include inclusive freshness boundaries and backward clock movement; elapsed 2W alone is insufficient. Tests MUST distinguish same-enrollment rotation from replacement; reject unseen old-credential DISCOVER despite a fresh timestamp, same Agent ID and new UUID; allow only authorized exact historical retrieval without replacement mutation; accept sequence 1 only with valid fresh replacement credentials; and fence unavailable or possibly stale recovery checkpoints. Verify preserved latest-state restart, replay-cache loss, disconnect and timeout cannot reset ordering. Verify unknown_field maps to HTTP 404 and bootstrap_failed to HTTP 403. 12. Security Considerations 12.1. Threat Model SAMP v0.1 is designed for controlled environments. The following threats are identified: 12.1.1. Rogue Managers A rogue manager could send unauthorized QUERY, CONFIG, or EXEC PDUs to an agent. Mitigations in v0.1: * Agents SHOULD maintain an allow-list of authorized manager addresses. * Agents MUST validate HMAC authentication tags except in the explicitly configured loopback test mode. Efstathiou Expires 15 March 2027 [Page 76] Internet-Draft SAMP September 2026 * Agents MUST reject CONFIG and EXEC from untrusted or unauthorized managers. Future: Per-agent public key authentication and mTLS. 12.1.2. Rogue Agents A rogue agent could announce itself with DISCOVER and provide false profile information. Mitigations in v0.1: * Managers MUST validate profiles before trusting. * Managers SHOULD use pre-registration or enrollment tokens. * Managers SHOULD rate-limit DISCOVER from unknown agents. Future: Signed profiles and certificate-based identity. 12.1.3. Credential Theft The shared secret used for HMAC authentication could be stolen. Mitigations in v0.1: * Shared secrets SHOULD be stored in a secrets manager. * Secrets SHOULD be distributed out of band. * Secrets SHOULD be rotated periodically. Future: Per-agent public key authentication (Ed25519). 12.1.4. Replay Attacks Receivers MUST authenticate before using recorded state, bind identifiers to authenticated senders and request digests, and follow Section 10.3. CONFIG, EXEC, SUBSCRIBE, UNSUBSCRIBE and DISCOVER require recorded-state protection; DISCOVER also requires enrollment ordering state. Duplicate handling precedes ordinary age rejection, but stale requests with no record MUST NOT execute. Capacity exhaustion and restart state loss MUST fail closed as specified there. Efstathiou Expires 15 March 2027 [Page 77] Internet-Draft SAMP September 2026 Replay state MAY be volatile or persistent; each implementation MUST declare retention and durability. Neither an in-memory cache nor a persistent store alone establishes exactly-once external effects. Runtime evidence has separate nonce, challenge, and expiry checks. Authenticated stale duplicates MUST NOT refresh liveness. 12.1.5. Profile Spoofing An agent could advertise a profile with false capabilities or autonomy class to gain elevated permissions. Mitigations in v0.1: * Autonomy class does not grant permission; manager policy is authoritative. * CONFIG and EXEC require explicit profile exposure AND manager policy authorization. * Managers SHOULD cross-check advertised capabilities against pre- registration data. Managers MUST enforce Section 5.12 and the credential-isolation/non- rollback invariant in Section 5.12.1. HMAC validity alone cannot prove current enrollment membership or latest-checkpoint status. QUERY expected-revision checks and historical-snapshot interpretation remain required. 12.1.6. Unauthorized CONFIG and EXEC A manager with valid credentials could send unauthorized CONFIG or EXEC to an agent. Mitigations in v0.1: * EXEC is disabled by default. * CONFIG and EXEC require explicit profile exposure. * Endpoints MUST enforce local authorization and local policy in addition to Manager pre-transmission policy. * EXEC parameters MUST have typed schemas; free-form arguments are not allowed. * exec_policy in the profile defines enabled, allowed_commands, typed parameter schemas, and audit fields, and MAY define cooldown and max_per_minute limits. Efstathiou Expires 15 March 2027 [Page 78] Internet-Draft SAMP September 2026 * Manager policy MAY require synchronously bound runtime evidence before admitting a sensitive CONFIG or EXEC operation. 12.1.7. Failure-Domain and Evidence-Path Confusion An operator could assume that a SAMP endpoint can enforce control independently when it actually shares the managed agent's process or failure domain. A compromised or failed agent could also suppress evidence when the evidence path depends on that same domain. Mitigations in v0.1: * Deployment metadata describes embedded, sidecar, supervisor, gateway and infrastructure placement separately from survival boundaries. * Managers MUST NOT infer independent enforcement from endpoint reachability alone. * Evidence identifies issuer, sender, and verifier deployment separately. * Deployment and verifier relationships are evaluated as survival boundaries, and trusted deployment inventory takes precedence over self-declared independence. * The absence of expected evidence MUST NOT be interpreted as evidence of correct behaviour. 12.1.8. Version Downgrade An attacker could attempt to force use of a weaker protocol version. Mitigations in v0.1: * v0.1 is the only defined version. * Receivers MUST reject unsupported versions with version_unsupported. * Future versions MUST define backward compatibility rules. 12.1.9. Event and Discovery Flooding An agent could flood a manager with PUSH events or DISCOVER messages. Mitigations in v0.1: Efstathiou Expires 15 March 2027 [Page 79] Internet-Draft SAMP September 2026 * Managers SHOULD rate-limit DISCOVER from unknown agents. * Managers MAY apply back-pressure with rate_limited or back_pressure errors. * Managers MAY maintain a pending-agent quota. 12.1.10. Registry Poisoning A rogue agent could attempt to overwrite or evict legitimate agent entries in the manager's registry. Mitigations in v0.1: * Registry updates require successful authentication. * DISCOVER from unauthenticated agents MUST NOT modify the registry beyond creating a discovered or pending entry. 12.2. Audit Requirements Managers and endpoints MUST audit admission and recorded execution outcomes for CONFIG and EXEC, including authenticated actor, Agent, operation_ref, request digest, timestamp, captured profile_revision and applicable policy_revision, policy_outcome, execution_outcome, and available evidence reference. An indeterminate result MUST NOT be logged as confirmed failure. Retry access events MUST be distinguished from new execution. Managers MUST audit trust transitions and quarantine enforcement updates, including prior/resulting trust_state, actor, reason, timestamp and enforcement_status when applicable. Liveness changes are separate observations and SHOULD be logged with observation source and threshold. Ordinary liveness changes MUST NOT silently overwrite trust decisions. Logs MUST redact enrollment tokens and other credentials. Operation parameters and evidence MAY require redaction under privacy policy while preserving identifiers and integrity digests needed for attribution. Logs SHOULD be tamper-evident and stored outside the managed workload failure domain. The profile audit flags describe detailed local operation logging. Setting audit false while an operation is disabled MUST NOT suppress any mandatory admission, execution, or trust-transition record required by this document. Implementations MAY redact sensitive contents while retaining required attribution and outcome metadata. Efstathiou Expires 15 March 2027 [Page 80] Internet-Draft SAMP September 2026 12.3. Rate Limiting and Back-Pressure Managers and agents SHOULD implement rate limiting for incoming PDUs. Rate limiting MAY be applied per-agent, per-PDU-type, or globally. Excess requests SHOULD be rejected with rate_limited or back_pressure errors. 12.4. Trust Bootstrap The DISCOVER enrollment object supports manual, token, and public_key_metadata inputs. Public key or thumbprint matching identifies metadata only and MUST NOT itself establish trusted status. Private-key possession requires an authenticated proof mechanism, another authenticated binding, or explicit policy-approved out-of-band verification. No new public-key authentication protocol is defined in v0.1. Unauthenticated bootstrap may create only discovered or pending trust_state and MUST NOT overwrite enrolled identity or trust. Enrollment tokens MUST be redacted from logs and errors. Operational HMAC credentials are separately provisioned out of band. 12.5. Token Rotation and Storage Shared secrets SHOULD be rotated periodically. Rotation frequency is a deployment decision. Tokens SHOULD be stored in a secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager) rather than plaintext files. Token rotation in v0.1 requires out-of-band coordination between the manager and agent. Automated rotation is future work. Rotation within an enrollment and replacement enrollment have different ordering effects under Section 5.12.1; neither ordinary rotation nor reauthentication resets the sequence. 12.6. Summary: Current Requirements vs Future Work +================+=========================+======================+ | Threat | v0.1 Mitigation | Future Enhancement | +================+=========================+======================+ | Rogue managers | Manager allow-list, | mTLS, per-agent keys | | | HMAC | | +----------------+-------------------------+----------------------+ | Rogue agents | Profile validation, | Signed profiles, | | | enrollment | cert identity | +----------------+-------------------------+----------------------+ | Credential | Secrets manager, | Per-agent Ed25519 | Efstathiou Expires 15 March 2027 [Page 81] Internet-Draft SAMP September 2026 | theft | rotation | keys | +----------------+-------------------------+----------------------+ | Replay | Authenticated recorded | Negotiated | | | state, freshness, | durability profiles, | | | restart fencing | stream gap recovery | +----------------+-------------------------+----------------------+ | Profile | Manager policy | Signed profiles | | spoofing | authoritative | | +----------------+-------------------------+----------------------+ | Unauthorized | Disabled by default, | RBAC, OPA | | EXEC/CONFIG | policy | integration | +----------------+-------------------------+----------------------+ | Version | Reject unsupported | Version negotiation | | downgrade | versions | | +----------------+-------------------------+----------------------+ | Flooding | Rate limiting, back- | Flow-control | | | pressure | protocol | +----------------+-------------------------+----------------------+ | Registry | Auth-required updates | Signed registrations | | poisoning | | | +----------------+-------------------------+----------------------+ | Failure-domain | Deployment | Attestation and | | confusion | declarations, separated | independently | | | issuer and sender roles | validated topology | | | | inventory | +----------------+-------------------------+----------------------+ Table 15: Security Mitigations: v0.1 vs Future 13. Privacy Considerations 13.1. Sensitive Metadata Exposure SAMP profiles and query responses can expose sensitive information about an agent, including: Framework details and version, Model names and provider information, Configuration values, Active sessions, Tool availability, Memory backends, Operational state, and Uptime and availability patterns. Managers and agents SHOULD minimize exposed fields. Profiles SHOULD include only fields necessary for management. QUERY responses SHOULD NOT include secrets, credentials, prompt contents, private user data, or tool outputs unless explicitly required and authorized. Optional sensitive reserved profile metadata MAY be omitted when unnecessary. Such omitted identity, deployment, network, relationship, capability or policy metadata cannot be assumed retrievable later through core QUERY; only declared category fields Efstathiou Expires 15 March 2027 [Page 82] Internet-Draft SAMP September 2026 are queryable. Authorization MUST prevent QUERY absence classification and revision diagnostics from disclosing hidden profile content. 13.2. Event Data Sensitivity PUSH events can contain operationally sensitive information, including: Status changes revealing operational patterns, Error details exposing internal architecture, Performance metrics revealing capacity or load, and Configuration changes revealing business logic. Operators SHOULD classify and filter events before exporting them to telemetry, logging, or ticketing systems. Events containing user data MUST be handled according to applicable data protection regulations. Runtime evidence may reveal action digests, policy decisions, verifier identities, or references to protected evidence stores. Evidence references MUST NOT embed reusable credentials. Managers MUST apply authorization and data-minimization policy before retrieving, storing, or exporting evidence. 13.3. Data Minimization Agents SHOULD expose the minimum profile data necessary for management. Managers SHOULD query only the fields they need. Bulk profile export or full-state queries SHOULD be restricted to authorized operators. Network attachment and discovery-scope metadata can reveal internal addressing and segmentation. Agents SHOULD omit these fields unless required for management, and managers MUST NOT expose them to unauthorized consumers or use them to expand active-discovery scope. 13.4. Log Protection SAMP audit logs and event stores may contain sensitive operational data. Logs SHOULD be: Access-controlled, Retained according to a defined policy, Protected against tampering, and Sanitized before sharing or export. 14. Operational Considerations 14.1. Network Placement SAMP deployments SHOULD place managers and agents on a dedicated management network or equivalent restricted trust boundary. Firewall rules SHOULD limit SAMP traffic to known managers and agents. Efstathiou Expires 15 March 2027 [Page 83] Internet-Draft SAMP September 2026 Agents SHOULD maintain an allow-list of authorized manager addresses. Managers SHOULD maintain an allow-list or pre-registration registry for expected agents. 14.2. Scaling SAMP v0.1 targets single-agent interactions. A single manager MAY manage multiple agents, but fleet-scale bulk operations are not defined in v0.1. Deployments needing fleet-scale operations SHOULD use external orchestration (e.g., scripts, configuration management) layered on top of SAMP. Scaling approaches compatible with v0.1: * *HTTP-only polling*: Agents are polled by the manager at intervals. Suitable for moderate agent counts. * *Hierarchical managers*: A tier of intermediate managers collects from agents and reports to a central manager. Requires out-of- band coordination. * *Queue-based ingestion*: PUSH events are sent to a message queue rather than directly to the manager. Requires agent-side queue configuration. Federation, multi-manager conflict resolution, and transactional configuration are future work. 14.3. Observability SAMP management traffic SHOULD itself be observable. Implementations SHOULD log: PDU counts and types, Error rates, Authentication failures, Latency metrics, and Agent registration and trust transitions. This metadata MAY be exported to OpenTelemetry or similar observability systems. 14.4. Error Handling in Practice Transient rate_limited or back_pressure errors MAY be retried with exponential backoff using original authenticated bytes within the declared retry window. EXEC and CONFIG retries require safe recorded-state behavior. A stale request without recorded state MUST NOT be executed. A fresh request with a new identifier requires a new admission decision and MUST NOT be substituted automatically for an uncertain operation. Efstathiou Expires 15 March 2027 [Page 84] Internet-Draft SAMP September 2026 Authentication failures require credential investigation; policy_denied, config_disabled and exec_disabled require a policy decision before any new operation. replay_detected indicates a conflict or expired recovery window. in_progress means wait or retrieve recorded state; indeterminate requires reconciliation and MUST NOT be interpreted as confirmed failure or as permission to repeat effects. Ordering-state recovery MUST satisfy Section 5.12.1. When the latest committed boundary cannot be established, keep profile admission fenced with back_pressure or perform valid explicit replacement; an old authenticated checkpoint is insufficient. 15. IANA Considerations This document requests the creation of a SAMP registry group under the "IANA Considerations" framework of [RFC8126]. 15.1. SAMP PDU Types Registry Registry Name: SAMP PDU Types Registration Policy: Specification Required Expert Review Guidelines: The designated expert SHOULD verify that new PDU types include a clear name, description, payload schema, direction semantics, error handling, and security considerations. Initial assignments: Initial SAMP PDU Type Assignments: ping Agent heartbeat; This document discover Agent self-announcement; This document query State query; This document push Asynchronous event notification; This document subscribe Event subscription; This document unsubscribe Cancel subscription; This document config Configuration change; This document exec Execute operation; This document Identifiers are case-sensitive lowercase strings matching [a-z][a-z0-9_]*; comparisons MUST NOT apply case folding. 15.2. SAMP Error Codes Registry Registry Name: SAMP Error Codes Efstathiou Expires 15 March 2027 [Page 85] Internet-Draft SAMP September 2026 Registration Policy: Specification Required Expert Review Guidelines: The designated expert SHOULD verify that new error codes include a clear name, description, and handling guidance. Initial assignments: Initial SAMP Error Code Assignments: malformed_pdu Invalid JSON or missing required fields; This document unknown_type Unrecognized PDU type; This document invalid_value Invalid field value; This document schema_mismatch Payload schema validation failure; This document version_unsupported Unsupported protocol version; This document profile_invalid Invalid or incomplete profile; This document auth_failed Authentication failure; This document replay_detected Replay attack detected; This document unknown_field Unknown field requested; This document; HTTP 404 exec_disabled EXEC not enabled; This document config_disabled CONFIG not enabled; This document policy_denied Admission denied or safeguards indeterminate; This document rate_limited Rate limiting in effect; This document back_pressure Receiver temporarily cannot safely process admission, including overload or unavailable profile ordering state; This document bootstrap_failed Enrollment/bootstrap failure; This document; HTTP 403 internal_error Internal receiver error; This document profile_revision_mismatch Expected QUERY revision is not the current authoritative snapshot; This document profile_stale Authenticated profile announcement sequence is below the accepted sequence; This document profile_sequence_conflict Profile sequence or revision is reused inconsistently with accepted content; This document Identifiers are case-sensitive lowercase strings matching [a-z][a-z0-9_]*; comparisons MUST NOT apply case folding. 15.3. SAMP Autonomy Classes Registry Registry Name: SAMP Autonomy Classes Registration Policy: Specification Required Initial SAMP Autonomy Class Assignments: Efstathiou Expires 15 March 2027 [Page 86] Internet-Draft SAMP September 2026 advisory Read-only observation only; This document operational-readonly Observation and limited policy-authorized CONFIG; no EXEC; This document operational-write Configuration allowed, limited execution; This document critical-write Configuration and execution under strict policy; This document Values are case-sensitive lowercase ASCII identifiers matching [a-z][a-z0-9-]*. The designated expert SHOULD require management- impact semantics, prohibited operations, safeguard requirements, and compatibility rules. A new class MUST NOT claim to measure cognitive autonomy solely through its management surface. advisory prohibits advertising and accepting CONFIG and EXEC. Identifiers are case-sensitive lowercase strings matching [a-z][a-z0-9-]*; comparisons MUST NOT apply case folding. 15.4. SAMP Trust States Registry Registry Name: SAMP Trust States. Registration Policy: Specification Required. Values are lowercase ASCII identifiers matching [a-z][a-z0-9_]* and are case-sensitive. The designated expert SHOULD require explicit trust semantics, transitions, authorization, audit and interaction with liveness. Reachability conditions MUST NOT be registered as trust decisions. Initial SAMP Trust State Assignments: discovered Announced; This document pending Awaiting evaluation; This document trusted Approved; This document quarantined Restricted by Manager decision; enforcement separate; This document rejected Enrollment refused; This document revoked Trust explicitly revoked; This document Identifiers are case-sensitive lowercase strings matching [a-z][a-z0-9_]*; comparisons MUST NOT apply case folding. 15.5. SAMP Liveness States Registry Registry Name: SAMP Liveness States. Registration Policy: Specification Required. Values are lowercase case-sensitive ASCII identifiers matching [a-z][a-z0-9_]*. Expert review SHOULD require observable transition conditions, timer behavior, and preservation of independent trust decisions. Efstathiou Expires 15 March 2027 [Page 87] Internet-Draft SAMP September 2026 Initial SAMP Liveness State Assignments: unknown No sufficient current observation; This document reachable Recent valid endpoint response; This document stale Expected observations overdue; This document offline Currently unreachable; This document Identifiers are case-sensitive lowercase strings matching [a-z][a-z0-9_]*; comparisons MUST NOT apply case folding. 15.6. SAMP Profile Namespaces Registry Registry Name: SAMP Profile Namespaces. Registration Policy: Specification Required. Namespace names are lowercase case-sensitive ASCII matching [a-z][a-z0-9_]*. Each registration supplies name, description, reference, field declarations, and security/privacy considerations. The designated expert SHOULD verify collision avoidance, interoperable type declarations, and that new fields cannot bypass policy or authorization. The initial category assignment is system (required base operational fields; this document). model and tools have no standard assignment in v0.1; deployments using such categories MUST document their field declarations. Top-level metadata names agent_id, name, agent_version, profile_version, profile_revision, profile_sequence, agent_type, autonomy_class, capabilities, field_declarations, config_policy, exec_policy, deployment, network, parent_agent_id and relationship_type are reserved and MUST NOT be assigned as category names. Identifiers are case-sensitive lowercase strings matching [a-z][a-z0-9_]*; comparisons MUST NOT apply case folding. 15.7. Media Type Registration This document does NOT request a media type registration. SAMP PDUs use application/json [RFC8259] as the content type. A dedicated SAMP media type (e.g., application/samp+json) MAY be requested in a future version if warranted. 16. Implementation Status This section records implementation experience and will be removed before RFC publication. Earlier Python AgMS work exercised SAMP envelopes, discovery, query, events, subscriptions, configuration, authentication, replay handling, and disabled-by-default execution. Framework adapters provide development experience across heterogeneous frameworks. Efstathiou Expires 15 March 2027 [Page 88] Internet-Draft SAMP September 2026 That experience predates the complete remediated trust/liveness, type-declaration, outcome, and recorded-state requirements in this revision. No claim is made here that those implementations conform to all requirements of this document. Independent implementation and interoperability validation remain to be performed. Local document checks and same-team tests do not establish conformance or exactly- once execution. 17. References 17.1. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002, . [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, September 2011, . [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . Efstathiou Expires 15 March 2027 [Page 89] Internet-Draft SAMP September 2026 [RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP Semantics", STD 97, RFC 9110, June 2022, . [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, May 2024, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006, . 17.2. Informative References [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", RFC 3411, December 2002, . [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", RFC 3416, December 2002, . [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", RFC 2578, April 1999, . [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", RFC 2579, April 1999, . [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Conformance Statements for SMIv2", RFC 2580, April 1999, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, August 2016, . Efstathiou Expires 15 March 2027 [Page 90] Internet-Draft SAMP September 2026 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 8126, June 2017, . [OPAMP] OpenTelemetry SIG, "Open Agent Management Protocol (OpAMP)", . [MCP] Anthropic, "Model Context Protocol", . [A2A] Linux Foundation, "Agent-to-Agent Protocol", . [CCS] Wang, G., "Correctover Conformance Shape (CCS): Runtime Verification for AI Agent Tool Calls", Work in Progress, Internet-Draft, draft-correctover-ccs-08, 26 August 2026, . Appendix A. Changes from -01 This revision separates Manager-owned trust from observed liveness and defines quarantine enforcement status, preserves Manager admission authority without registry replication, adds a minimal recursive type model and profile revisions, and specifies a common CONFIG/EXEC outcome model. It defines identical-byte retry handling before freshness rejection, recorded-state retention and restart safety, precise endpoint-side pre-admission evidence and enrollment metadata boundaries, fixed subscription expiry and replacement behavior, and advisory management-impact restrictions. It clarifies OpAMP composition, keeps CCS optional and Informative, preserves descriptive-only network/discovery hints, and aligns examples, conformance, operational guidance and registries. It makes no exactly-once execution claim. Revision -02 introduces experimental wire-contract changes relative to -01, including typed profile declarations, operation outcomes, enrollment, QUERY and subscription semantics. Mixed -01 and -02 implementations are not presumed interoperable: implementations MUST update together or use an explicitly identified compatibility profile. Internet-Draft revisions identify document iterations; protocol/profile versions identify the experimental format. Retaining SAMP protocol and profile version 0.1 is an explicit Architect decision during experimental development, not a claim of wire compatibility. Efstathiou Expires 15 March 2027 [Page 91] Internet-Draft SAMP September 2026 Appendix B. Open Issues The mandatory minimal SAMP declaration representation is defined in this document. Optional mappings to JSON Schema, CUE, or YANG remain future work and do not replace core validation. Subscription renewal is not defined; continued delivery uses replacement subscriptions. Persistence extensions, federation, multi-manager conflict resolution, general cancellation, and two-phase Manager-side evidence admission remain outside core v0.1. A dedicated media type, automated public-key authentication and key rotation, optional deployment-specific evidence formats, and transport bindings to other agent protocols may be specified separately. Existing references and implementation descriptions are not independent validation evidence. SAMP v0.1 uses application/json and configured endpoint URLs (/samp is a convention), does not normalize Unicode during JCS, and supports only the operation, evidence, and enrollment semantics explicitly defined here. Appendix C. Example SAMP Profile (JSON Wire Representation) The complete JSON wire profile appears once, as payload.profile in the DISCOVER request in Section 8.2.2. The TOML example in the following appendix decodes to that same profile object; the DISCOVER envelope and enrollment members are not part of the profile. Appendix D. Example SAMP Profile (TOML) This TOML authoring representation decodes to exactly the same data model as the preceding JSON profile, including declarations and disabled EXEC. agent_id = "agent-001" name = "Example Agent" agent_version = "2026.9.11" profile_version = "0.1" profile_revision = "profile-7" profile_sequence = 1 agent_type = "custom" autonomy_class = "operational-write" capabilities = [ "ping", "discover", "query", "push", "subscribe", Efstathiou Expires 15 March 2027 [Page 92] Internet-Draft SAMP September 2026 "unsubscribe", "config", "exec", ] [system] status = "operational" uptime = 86400 version = "2026.9.11" last_seen = "2026-09-11T10:00:00Z" log_level = "info" [model] fallback = "example-model" [[field_declarations]] name = "system.status" type = "string" required = true min_length = 1 [[field_declarations]] name = "system.uptime" type = "integer" required = true minimum = 0 [[field_declarations]] name = "system.version" type = "string" required = true min_length = 1 [[field_declarations]] name = "system.last_seen" type = "string" required = true [[field_declarations]] name = "system.log_level" type = "string" required = true enum = ["debug", "info", "warning", "error"] [[field_declarations]] name = "model.fallback" type = "string" required = true Efstathiou Expires 15 March 2027 [Page 93] Internet-Draft SAMP September 2026 min_length = 1 [config_policy] enabled = true writable_fields = ["system.log_level", "model.fallback"] policy_revision = "local-3" audit = true [exec_policy] enabled = false allowed_commands = ["session_reset"] policy_revision = "local-3" audit = true [[exec_policy.commands]] name = "session_reset" required_parameters = ["session_id"] [[exec_policy.commands.parameters]] name = "session_id" type = "string" required = true min_length = 1 [exec_policy.commands.result] name = "result" type = "object" required = true [[exec_policy.commands.result.properties]] name = "reset" type = "boolean" required = true [deployment] endpoint_model = "sidecar" shared_process = false shared_host = true shared_failure_domain = true independent = false management_path_survives_failure = true evidence_path_survives_failure = true independently_enforceable_operations = [] [network] management_address = "192.0.2.10" address_family = "ipv4" prefix_length = 24 Efstathiou Expires 15 March 2027 [Page 94] Internet-Draft SAMP September 2026 management_interface = "eth0" endpoint_port = 443 reachability = "direct" discovery_scope = "192.0.2.0/24" [[field_declarations]] name = "system.optional_counter" type = "integer" required = false [[field_declarations]] name = "system.nullable_note" type = "string" required = false nullable = true Appendix E. Example PDU Flows The following sequences use the complete normative payloads in the operation sections. Each subsection is an independent scenario. All response envelopes use the original request_id and current timestamp. Production messages require authentication. E.1. Discovery and Liveness Flow Agent sends DISCOVER with its full profile and enrollment method. Manager returns trust_state pending and liveness_state reachable. A later authorized Manager approval changes trust_state to trusted in the Manager registry; it does not require a new PDU to synchronize that registry with the endpoint. If heartbeats stop, liveness may become stale and then offline while trust remains trusted. A quarantined Agent can likewise be offline. +=============+================+====================+ | trust_state | liveness_state | enforcement_status | +=============+================+====================+ | quarantined | offline | requested | +-------------+----------------+--------------------+ Table 16: Independent Registry Dimensions (not a PDU) For replacement, E1 accepts R1/sequence 1 then R2/sequence 2; E2 receives fresh credentials. A delayed unseen E1 R1 announcement, even with the same Agent ID and fresh timestamp, is bound to E1 and rejected with policy_denied before E2 ordering. An exact retained E1 retry may return only its authorized historical outcome. E2 sequence 1 is accepted only under its fresh context (Section 5.12.1). Efstathiou Expires 15 March 2027 [Page 95] Internet-Draft SAMP September 2026 E.2. Query Flow Use the payloads in Section 8.2.3. A QUERY evaluated under profile-7 may arrive after an authenticated profile-8 announcement. Interpret it under retained profile-7; if that snapshot is unavailable, discard the result as unusable, refresh and issue a new QUERY. Reissuing the original request after the update does not authorize evaluation under profile-8. E.3. Event Subscription Flow Manager creates sub-1 with a new SUBSCRIBE. Before its expires_at it creates sub-2 with another request_id if continued delivery is needed. No renewal occurs. The same event delivered on both subscriptions retains event_id; envelope request_id identifies each individual notification. A repeated original SUBSCRIBE returns the original sub-1 allocation and expiry. Manager may cancel sub-1; in- flight deliveries may still arrive. { "version": "0.1", "type": "push", "direction": "notification", "agent_id": "agent-001", "timestamp": "2026-09-11T10:00:01Z", "request_id": "045d6c34-45e9-539f-9a4a-ad35d773982c", "payload": { "event": "alert", "category": "system", "data": {"status": "degraded"}, "event_id": "d9df237c-f7cd-4fc8-b4e7-d35c676ad20f" }, "subscription_id": "sub-1" } E.4. Configuration Flow The Manager checks trust and policy; the endpoint authorizes the Manager, captures admission context, records admission and applies permitted fields. The complete request and outcomes in Section 8.2.9 are authoritative. A later trust transition does not rewrite this admission or automatically cancel execution. E.5. Execution Rejection Flow When EXEC is disabled, use the common error envelope and deny/ not_executed outcome in Section 8.2.10. A success-shaped rejection is invalid. A subsequent enablement requires a new profile revision and greater profile sequence; it does not change the recorded denial. Efstathiou Expires 15 March 2027 [Page 96] Internet-Draft SAMP September 2026 E.6. Runtime-Evidence Flow For endpoint-side pre-admission validation: Manager sends EXEC with bound admission_context; endpoint obtains a fresh challenge-bound receipt, validates issuer, correlation, freshness and policy, and records validator plus enforcement_actor before executing. Its final response may include the admission receipt. An asynchronous post_execution PUSH is a subsequent observation and cannot supply missing pre-admission authorization. Manager-required two-phase approval is not defined by core v0.1. Evidence-format profiles supply concrete signed evidence and issuer validation; no placeholder object here is represented as a verified receipt. Appendix F. Glossary Glossary: SAMP Simple Agent Management Protocol PDU Protocol Data Unit Manager System that manages agents via SAMP Agent AI agent exposing a SAMP interface Profile Structured declaration of agent identity and capabilities Trust State Manager-owned security disposition, independent of reachability Autonomy Class Management impact and safeguards; not workload autonomy Enrollment Process of evaluating and accepting an agent Conformance Tier Level of protocol support claimed by an implementation Liveness State Observed endpoint reachability, independent of trust Author's Address Stelios E. Efstathiou Independent Email: ietf@samp-protocol.org Efstathiou Expires 15 March 2027 [Page 97]