Simple Agent Management Protocol (SAMP)
draft-efstathiou-samp-agent-management-04
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Stelio E. Efstathiou | ||
| Last updated | 2026-10-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-efstathiou-samp-agent-management-04
Individual Submission S. E. Efstathiou
Internet-Draft Independent
Intended status: Experimental 26 October 2026
Expires: 29 April 2027
Simple Agent Management Protocol (SAMP)
draft-efstathiou-samp-agent-management-04
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.2 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 29 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Efstathiou Expires 29 April 2027 [Page 1]
Internet-Draft SAMP October 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 . . . . . 11
3.3. Authorization Architecture and Responsibility Boundary . 11
3.4. Conversational Management Boundary . . . . . . . . . . . 12
4. Agent Lifecycle, Trust, and Liveness . . . . . . . . . . . . 12
4.1. Trust Transitions . . . . . . . . . . . . . . . . . . . . 14
4.2. Liveness Transitions . . . . . . . . . . . . . . . . . . 15
4.3. Manager Authority and Endpoint Enforcement . . . . . . . 15
4.4. Enrollment . . . . . . . . . . . . . . . . . . . . . . . 16
4.5. Agent Bootstrap and Manager Location . . . . . . . . . . 17
5. SAMP Profile . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Required Identity Fields . . . . . . . . . . . . . . . . 18
5.2. Category and Field Model . . . . . . . . . . . . . . . . 19
5.3. Minimal Required Category . . . . . . . . . . . . . . . . 21
5.4. Profile Validation . . . . . . . . . . . . . . . . . . . 21
5.5. Profile Format . . . . . . . . . . . . . . . . . . . . . 22
5.6. Capabilities and Enablement . . . . . . . . . . . . . . . 22
5.6.1. Optional Profile and Extension Support
Advertisement . . . . . . . . . . . . . . . . . . . . 23
5.7. Observation Scope, Provenance, and Shared Resources . . . 24
5.8. Configuration Policy . . . . . . . . . . . . . . . . . . 25
5.9. Execution Policy . . . . . . . . . . . . . . . . . . . . 25
5.10. Deployment Metadata . . . . . . . . . . . . . . . . . . . 26
5.11. Network Attachment and Discovery Hints . . . . . . . . . 28
5.12. Agent Relationships . . . . . . . . . . . . . . . . . . . 28
5.13. Authenticated Profile Announcement Ordering . . . . . . . 29
5.13.1. Enrollment Isolation and Non-Rollback Recovery . . . 31
6. Autonomy Classes . . . . . . . . . . . . . . . . . . . . . . 32
7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 33
7.1. PDU Directions . . . . . . . . . . . . . . . . . . . . . 34
7.2. PDU Exchange Patterns . . . . . . . . . . . . . . . . . . 34
7.3. Authentication Requirements by PDU . . . . . . . . . . . 35
Efstathiou Expires 29 April 2027 [Page 2]
Internet-Draft SAMP October 2026
7.4. Liveness Semantics . . . . . . . . . . . . . . . . . . . 35
7.5. DISCOVER Rate Limiting . . . . . . . . . . . . . . . . . 35
7.6. SUBSCRIBE and UNSUBSCRIBE Semantics . . . . . . . . . . . 35
8. Message Format . . . . . . . . . . . . . . . . . . . . . . . 36
8.1. Common PDU Envelope . . . . . . . . . . . . . . . . . . . 36
8.1.1. Field Validation Rules . . . . . . . . . . . . . . . 37
8.1.2. Request/Response Correlation . . . . . . . . . . . . 38
8.1.3. Timestamp Validation . . . . . . . . . . . . . . . . 38
8.1.4. Sequence Numbers . . . . . . . . . . . . . . . . . . 38
8.2. PDU-Specific Payloads . . . . . . . . . . . . . . . . . . 39
8.2.1. PING . . . . . . . . . . . . . . . . . . . . . . . . 39
8.2.2. DISCOVER . . . . . . . . . . . . . . . . . . . . . . 39
8.2.3. QUERY . . . . . . . . . . . . . . . . . . . . . . . . 44
8.2.4. PUSH . . . . . . . . . . . . . . . . . . . . . . . . 48
8.2.5. Runtime Evidence . . . . . . . . . . . . . . . . . . 49
8.2.6. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . 55
8.2.7. UNSUBSCRIBE . . . . . . . . . . . . . . . . . . . . . 56
8.2.8. Authorization Context and Request Binding . . . . . . 57
8.2.9. Common CONFIG and EXEC Admission and Outcomes . . . . 60
8.2.10. CONFIG . . . . . . . . . . . . . . . . . . . . . . . 69
8.2.11. EXEC . . . . . . . . . . . . . . . . . . . . . . . . 74
8.3. Error Envelope . . . . . . . . . . . . . . . . . . . . . 79
8.4. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 80
8.5. JSON Encoding Requirements . . . . . . . . . . . . . . . 83
8.6. Behavior for Unknown Fields and Unknown PDU Types . . . . 83
9. Authentication . . . . . . . . . . . . . . . . . . . . . . . 84
9.1. Authentication Model . . . . . . . . . . . . . . . . . . 84
9.2. HMAC-SHA256 Signing . . . . . . . . . . . . . . . . . . . 85
9.3. Key Identification . . . . . . . . . . . . . . . . . . . 85
9.4. Canonical JSON . . . . . . . . . . . . . . . . . . . . . 86
9.4.1. Canonicalization Procedure . . . . . . . . . . . . . 86
9.4.2. Authentication Tag Representation . . . . . . . . . . 86
9.4.3. Verification Procedure . . . . . . . . . . . . . . . 86
9.4.4. Failure Behavior . . . . . . . . . . . . . . . . . . 87
9.4.5. Unicode Normalization . . . . . . . . . . . . . . . . 87
10. Transport Mapping . . . . . . . . . . . . . . . . . . . . . . 87
10.1. HTTP Transport . . . . . . . . . . . . . . . . . . . . . 87
10.1.1. HTTP Method . . . . . . . . . . . . . . . . . . . . 88
10.1.2. Content-Type . . . . . . . . . . . . . . . . . . . . 88
10.1.3. Endpoint Path . . . . . . . . . . . . . . . . . . . 88
10.1.4. HTTP Status Codes . . . . . . . . . . . . . . . . . 88
10.1.5. HTTPS Requirements . . . . . . . . . . . . . . . . . 90
10.2. WebSocket Transport . . . . . . . . . . . . . . . . . . 91
10.3. Retry and Backoff . . . . . . . . . . . . . . . . . . . 92
11. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 95
11.1. Mandatory Implementation Requirements . . . . . . . . . 96
11.2. Conformance Testing . . . . . . . . . . . . . . . . . . 96
12. Security Considerations . . . . . . . . . . . . . . . . . . . 98
Efstathiou Expires 29 April 2027 [Page 3]
Internet-Draft SAMP October 2026
12.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 99
12.1.1. Rogue Managers . . . . . . . . . . . . . . . . . . . 99
12.1.2. Rogue Agents . . . . . . . . . . . . . . . . . . . . 99
12.1.3. Credential Theft . . . . . . . . . . . . . . . . . . 99
12.1.4. Replay Attacks . . . . . . . . . . . . . . . . . . . 100
12.1.5. Profile Spoofing . . . . . . . . . . . . . . . . . . 100
12.1.6. Unauthorized CONFIG and EXEC . . . . . . . . . . . . 100
12.1.7. Failure-Domain and Evidence-Path Confusion . . . . . 101
12.1.8. Version Downgrade . . . . . . . . . . . . . . . . . 102
12.1.9. Event and Discovery Flooding . . . . . . . . . . . . 102
12.1.10. Registry Poisoning . . . . . . . . . . . . . . . . . 103
12.2. Audit Requirements . . . . . . . . . . . . . . . . . . . 103
12.3. Rate Limiting and Back-Pressure . . . . . . . . . . . . 104
12.4. Trust Bootstrap . . . . . . . . . . . . . . . . . . . . 104
12.5. Token Rotation and Storage . . . . . . . . . . . . . . . 104
12.6. Summary: Current Requirements vs Future Work . . . . . . 105
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 106
13.1. Sensitive Metadata Exposure . . . . . . . . . . . . . . 106
13.2. Event Data Sensitivity . . . . . . . . . . . . . . . . . 106
13.3. Data Minimization . . . . . . . . . . . . . . . . . . . 106
13.4. Log Protection . . . . . . . . . . . . . . . . . . . . . 107
14. Operational Considerations . . . . . . . . . . . . . . . . . 107
14.1. Network Placement . . . . . . . . . . . . . . . . . . . 107
14.2. Scaling . . . . . . . . . . . . . . . . . . . . . . . . 107
14.3. Observability . . . . . . . . . . . . . . . . . . . . . 108
14.4. Conversational and Fleet-Orchestration Interfaces . . . 108
14.5. Error Handling in Practice . . . . . . . . . . . . . . . 108
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 109
15.1. SAMP PDU Types Registry . . . . . . . . . . . . . . . . 109
15.2. SAMP Error Codes Registry . . . . . . . . . . . . . . . 110
15.3. SAMP Autonomy Classes Registry . . . . . . . . . . . . . 111
15.4. SAMP Trust States Registry . . . . . . . . . . . . . . . 112
15.5. SAMP Liveness States Registry . . . . . . . . . . . . . 112
15.6. SAMP Profile Namespaces Registry . . . . . . . . . . . . 112
15.7. Media Type Registration . . . . . . . . . . . . . . . . 113
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 113
17. Implementation Status . . . . . . . . . . . . . . . . . . . . 113
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 114
18.1. Normative References . . . . . . . . . . . . . . . . . . 114
18.2. Informative References . . . . . . . . . . . . . . . . . 115
Appendix A. Changes from -01 . . . . . . . . . . . . . . . . . . 116
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 117
Appendix C. Example SAMP Profile (JSON Wire Representation) . . 117
Appendix D. Example SAMP Profile (TOML) . . . . . . . . . . . . 117
Appendix E. Example PDU Flows . . . . . . . . . . . . . . . . . 120
E.1. Discovery and Liveness Flow . . . . . . . . . . . . . . . 120
E.2. Query Flow . . . . . . . . . . . . . . . . . . . . . . . 121
E.3. Event Subscription Flow . . . . . . . . . . . . . . . . . 121
Efstathiou Expires 29 April 2027 [Page 4]
Internet-Draft SAMP October 2026
E.4. Configuration Flow . . . . . . . . . . . . . . . . . . . 122
E.5. Execution Rejection Flow . . . . . . . . . . . . . . . . 122
E.6. Runtime-Evidence Flow . . . . . . . . . . . . . . . . . . 122
Appendix F. Glossary . . . . . . . . . . . . . . . . . . . . . . 122
Appendix G. Changes from -03 . . . . . . . . . . . . . . . . . . 123
Appendix H. Candidate Extensions for Further Interoperability
Study (Non-Normative) . . . . . . . . . . . . . . . . . . 124
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 125
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.2, 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.2 is not intended for untrusted
networks without additional security mechanisms.
1.1. Scope
SAMP v0.2 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.
Efstathiou Expires 29 April 2027 [Page 5]
Internet-Draft SAMP October 2026
* Management-impact classes that restrict operations without
granting authority.
* HMAC-SHA256 message authentication.
* HTTP(S) as the baseline transport.
* Conformance tiers.
* IANA registry framework.
SAMP v0.2 does NOT define:
* Federation or multi-manager coordination.
* Fleet-wide bulk or transactional operations.
* Organization-specific RBAC/ABAC policy languages, role taxonomies,
identity-provider configuration, or approval workflow engines.
SAMP does define the protocol authorization context and
enforcement invariants needed to carry and bind authorization
decisions for consequential operations.
* 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.
Efstathiou Expires 29 April 2027 [Page 6]
Internet-Draft SAMP October 2026
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)
[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
Efstathiou Expires 29 April 2027 [Page 7]
Internet-Draft SAMP October 2026
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.
+=====================+===============+==========================+
| 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.
Efstathiou Expires 29 April 2027 [Page 8]
Internet-Draft SAMP October 2026
Autonomy Class A declaration of management impact and required
safeguards in SAMP v0.2; 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:
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.
Authorization Context The structured request metadata that
identifies the acting principal and authorization decision and
binds that decision to one exact SAMP operation.
Authorization Artifact An optional opaque or signed proof carried
inside an Authorization Context. Core SAMP does not define its
policy language or signature format.
Policy Enforcement Point (PEP) The SAMP endpoint, sidecar, gateway,
or other independently enforceable component that performs the
final local authorization check before a consequential operation
is admitted.
3. Architecture
The basic SAMP architecture contains a manager and one or more
agents:
Efstathiou Expires 29 April 2027 [Page 9]
Internet-Draft SAMP October 2026
+--------------+ 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.
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.
Efstathiou Expires 29 April 2027 [Page 10]
Internet-Draft SAMP October 2026
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.
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.
3.3. Authorization Architecture and Responsibility Boundary
SAMP does not define an organization's identity hierarchy, RBAC or
ABAC policy language, geographic or organizational resource tree,
approval workflow, or delegation administration. Those decisions
belong to the deployment's authorization system.
SAMP does define the protocol contract used to carry, bind, validate,
and enforce an authorization decision for consequential management
operations. A trusted or authenticated Manager is not implicitly
authorized to perform CONFIG or EXEC. Manager-side policy and
endpoint local policy are jointly restrictive, and the SAMP endpoint
or independently enforceable SAMP component acts as the final Policy
Enforcement Point (PEP).
Efstathiou Expires 29 April 2027 [Page 11]
Internet-Draft SAMP October 2026
Authorization is specific to the authenticated actor, managed Agent,
operation type, request identifier, exact operation content, and
applicable profile and policy context. Authorization for one request
MUST NOT be reused for another request, another Agent, modified
parameters, or a different operation.
Bearer credentials, complete organizational policies, and role
definitions MUST NOT be required inside ordinary SAMP messages.
Deployments may validate an opaque decision reference, an embedded
signed artifact, or both, provided the binding and enforcement
requirements in Section 8.2.8 are satisfied.
3.4. Conversational Management Boundary
Natural-language conversation is a user interface and MUST NOT be
treated as an authorization or execution boundary. A deployment that
accepts conversational instructions MUST resolve them into a
deterministic structured action before constructing a consequential
SAMP request.
The structured action identifies the resolved Agent target or
targets, exact operation and parameters, authorization and approval
requirements, and any execution constraints such as dry-run, canary,
batching, or blast-radius limits. Large-scale target selection and
orchestration remain outside core SAMP. No unprocessed natural-
language instruction is a valid substitute for a typed CONFIG or EXEC
payload.
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.
Efstathiou Expires 29 April 2027 [Page 12]
Internet-Draft SAMP October 2026
+=============+=========================================+
| 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
+===========+===========================================+
| 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.
Efstathiou Expires 29 April 2027 [Page 13]
Internet-Draft SAMP October 2026
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.
+===============+=============+=====================================+
| 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.
Efstathiou Expires 29 April 2027 [Page 14]
Internet-Draft SAMP October 2026
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.
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 the requesting Manager, validate the
request authorization context for consequential operations, and
enforce its own local config_policy or exec_policy before execution.
Manager policy and endpoint local policy are jointly restrictive:
either can deny. Authentication or Manager trust alone MUST NOT
imply authorization. The endpoint is not required to maintain a
synchronized copy of the Manager trust registry. No new PDU
distributes that registry in core v0.2. The Manager owns pre-
transmission admission checks; the endpoint or independently
enforceable SAMP component is the final Policy Enforcement Point and
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.
Efstathiou Expires 29 April 2027 [Page 15]
Internet-Draft SAMP October 2026
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.2 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
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.2 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
Efstathiou Expires 29 April 2027 [Page 16]
Internet-Draft SAMP October 2026
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.
Replacement enrollment, credential isolation and ordering recovery
MUST follow Section 5.13.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.2 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.
Efstathiou Expires 29 April 2027 [Page 17]
Internet-Draft SAMP October 2026
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
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.13.
Operational values carried in an authenticated announced profile are
a snapshot of values at the time of that announcement; a profile
revision does not identify an instantaneous runtime state. After
announcement, changes in a managed workload's operational
observations (including system.last_seen, system.uptime, or status)
MAY be exposed as fresh QUERY values or PUSH events without changing
the authoritative profile_revision or profile_sequence. This does
not permit retransmission of a changed profile object under the same
revision and sequence. If an endpoint includes changed operational
values in a subsequent DISCOVER profile object, the complete
announced-profile digest changes and the endpoint MUST allocate a new
revision and greater sequence in accordance with the announcement
ordering rules. Implementations SHOULD keep rapidly changing
readings in QUERY/PUSH rather than repeatedly announcing profiles.
The Manager MUST NOT treat an unmodified profile snapshot as proof
that the workload remains currently healthy.
Efstathiou Expires 29 April 2027 [Page 18]
Internet-Draft SAMP October 2026
Protocol envelope version and profile-format version are distinct.
SAMP 0.2 uses envelope version "0.2" while the base profile format
continues to identify itself as profile_version "0.1". This is
deliberate and MUST NOT be interpreted as permission to use the
former envelope version "0.1" with SAMP 0.2 operation semantics.
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
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
Efstathiou Expires 29 April 2027 [Page 19]
Internet-Draft SAMP October 2026
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.
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.
Efstathiou Expires 29 April 2027 [Page 20]
Internet-Draft SAMP October 2026
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
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.2.
External retrieval requires an explicitly identified extension and
Manager-approved locations. Profile validation establishes
structural validity, not truthfulness, behavioral safety, or
independent enforceability.
Efstathiou Expires 29 April 2027 [Page 21]
Internet-Draft SAMP October 2026
5.5. Profile Format
TOML is the recommended human-readable authoring format for SAMP
v0.2. 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.
DISCOVER.payload.supported_versions is an optional non-empty array of
distinct version strings and, when present, MUST contain the envelope
version. SAMP 0.2 uses only envelope version "0.2" and defines no
automatic negotiation to an older version. Receivers MUST reject an
unsupported envelope version with version_unsupported.
profile_version remains an independent profile-format version and
does not negotiate the wire protocol.
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.
Efstathiou Expires 29 April 2027 [Page 22]
Internet-Draft SAMP October 2026
All such announcements MUST include the corresponding
profile_sequence and obey Section 5.13; reannouncement retries do not
reinstall older snapshots.
5.6.1. Optional Profile and Extension Support Advertisement
An endpoint MAY announce supported_extensions as an optional top-
level profile metadata array. Each entry MUST be a closed JSON
object containing extension_id (non-empty absolute URI identifying a
stable extension family independently of its version) and
extension_version (non-empty string naming the exact specification
version); an optional extension_publisher non-empty string identifies
a claimed publisher for display only. The array MUST NOT contain
duplicate (extension_id, extension_version) pairs. A versioned
format MUST NOT be inferred solely from extension_id, including URI
path components; the pair is the unique versioned contract. Equality
is exact case-sensitive string comparison of both members; no
implicit ranges, semantic-version ordering, aliases or fallback are
defined. Changing any advertised entry or publisher information
changes the authenticated announced profile and requires the normal
profile revision/sequence ordering.
The claimed extension_publisher is informational self-asserted
metadata, not a verified identity, registry entitlement, security
principal, credential, or authorization. A SAMP Manager MUST
explicitly recognize the (extension_id, extension_version) pair from
an applicable trusted configuration/specification and apply local
disclosure and authorization policy before interpreting extension-
defined content. Advertisement proves neither Manager support nor
authority to perform an operation. Unknown advertised extensions MAY
be ignored as metadata. Supporting PUSH does not imply support for a
particular event family. An extension MUST NOT silently reinterpret
core fields, add unrecognized PDU types to the core contract, or
bypass closed CONFIG/EXEC authorization and evidence rules.
This advertisement is discovery metadata, not a negotiated critical-
extension mechanism or mutual peer selection handshake. SAMP 0.2
defines no general custom-PDU invocation syntax. A critical
extension requires an independently defined, explicitly mutually
recognized and authorized contract; it MUST NOT become active solely
through an Agent advertisement. The extension identifier and version
MUST be validated as metadata even when the extension is unsupported.
Unknown extension metadata does not grant authority.
Non-normative excerpt of announced profile metadata (other required
profile members omitted):
Efstathiou Expires 29 April 2027 [Page 23]
Internet-Draft SAMP October 2026
{
"supported_extensions": [
{
"extension_id": "https://example.net/samp/extensions/usage",
"extension_version": "1.0",
"extension_publisher": "Example Research Group"
}
]
}
5.7. Observation Scope, Provenance, and Shared Resources
A QUERY value or PUSH observation expresses only information
available to its declared source. A Manager MUST NOT infer per-Agent
workload liveness from a shared desktop, connector, or hosting-
runtime heartbeat. Endpoint reachability, workload availability,
Agent logical identity and evidence of execution are separate claims.
A profile or optional observation extension SHOULD distinguish
source, target, observed-at time, reporting time, freshness, and
resource/accounting scope where those dimensions materially affect
interpretation.
Token or resource usage reported for an Agent execution, thread, or
request MUST NOT be represented as an independent quota when it is
actually an account-, provider-, deployment-, or pool-scoped limit.
A given resource MAY be consumed by multiple Agent identities and one
Agent MAY consume multiple external resources. Extensions defining
resource identifiers or Agent-to-resource bindings MUST specify
identifier scope, collision behavior, disclosure restrictions, epoch/
reset behavior and whether values are actual measurements or
estimates. Shared resource identity MUST NOT be derived solely from
a matching provider name.
The values zero, absent, explicit null, unsupported, unavailable,
stale and unknown are semantically distinct. In particular, the
QUERY unknown result retains the unexposed/undeclared-path semantics
already defined by core QUERY; extensions MUST NOT overload it to
mean a declared field whose current value cannot be established. A
reporting endpoint MUST NOT attribute its own uptime, version, or
heartbeat to a distinct remotely hosted workload unless the field
definition explicitly names the endpoint as the measured subject.
Core required profile fields and their validation rules remain
unchanged in this revision; proxy-observed cloud workload support
with missing mandatory fields requires a separately specified profile
or future revision.
Efstathiou Expires 29 April 2027 [Page 24]
Internet-Draft SAMP October 2026
5.8. 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
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.9. 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.
Efstathiou Expires 29 April 2027 [Page 25]
Internet-Draft SAMP October 2026
enabled, policy_revision, cooldown, max_per_minute and audit have the
shared types, presence and rules in Section 5.8. 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
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.10. 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.
Efstathiou Expires 29 April 2027 [Page 26]
Internet-Draft SAMP October 2026
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.
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.2 does not
standardize cancellation or quarantine enforcement commands. Unknown
deployment metadata is ignored and MUST NOT strengthen an enforcement
claim.
Efstathiou Expires 29 April 2027 [Page 27]
Internet-Draft SAMP October 2026
5.11. 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
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.12. 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.
Logical Agent identity is independent of shared framework/runtime
placement, graphical grouping, and coordination hierarchy. A related
Agent may have a common runtime failure domain or account dependency;
Efstathiou Expires 29 April 2027 [Page 28]
Internet-Draft SAMP October 2026
this does not permit copying a shared runtime heartbeat as individual
Agent liveness. The optional descriptive relationship metadata does
not establish delegation or authorization, and does not by itself
prove a common workload identity.
5.13. 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.13.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 29 April 2027 [Page 29]
Internet-Draft SAMP October 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.13.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.13.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 29 April 2027 [Page 30]
Internet-Draft SAMP October 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.13.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 29 April 2027 [Page 31]
Internet-Draft SAMP October 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.2 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 29 April 2027 [Page 32]
Internet-Draft SAMP October 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.2 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 29 April 2027 [Page 33]
Internet-Draft SAMP October 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 29 April 2027 [Page 34]
Internet-Draft SAMP October 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.2 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.2 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 29 April 2027 [Page 35]
Internet-Draft SAMP October 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.2.
8.1. Common PDU Envelope
The envelope fields are defined below.
Common PDU Envelope Fields:
version string; Required; Protocol version: "0.2"
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 29 April 2027 [Page 36]
Internet-Draft SAMP October 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.2" 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 29 April 2027 [Page 37]
Internet-Draft SAMP October 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. Within the sender's
authenticated identity, a request_id MUST NOT be reassigned to a
different logical request, regardless of replay-cache expiry,
endpoint record retention, sender restart, credential rotation or
enrollment renewal for that sender. A retry or retrieval of the
original logical request MUST retain its original request_id and the
original request binding; a different logical request MUST use a
fresh request_id. This is a sender-side semantic non-reassignment
requirement, not a requirement that receiving peers retain replay
records indefinitely. 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.2.
Efstathiou Expires 29 April 2027 [Page 38]
Internet-Draft SAMP October 2026
8.2. PDU-Specific Payloads
8.2.1. PING
Request payload:
{}
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
Efstathiou Expires 29 April 2027 [Page 39]
Internet-Draft SAMP October 2026
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,
SHA-256 of those raw bytes). Other identifiers are rejected as
profile_invalid in core v0.2. 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.2
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.
Efstathiou Expires 29 April 2027 [Page 40]
Internet-Draft SAMP October 2026
{
"version": "0.2", "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": [
"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",
Efstathiou Expires 29 April 2027 [Page 41]
Internet-Draft SAMP October 2026
"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
},
"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": {
Efstathiou Expires 29 April 2027 [Page 42]
Internet-Draft SAMP October 2026
"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",
"unsubscribe", "config", "exec"
],
"enrollment": {"method": "manual"}
}
}
{
"version": "0.2", "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.2", "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.2.
Efstathiou Expires 29 April 2027 [Page 43]
Internet-Draft SAMP October 2026
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.2
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.13. 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.
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.13.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
Efstathiou Expires 29 April 2027 [Page 44]
Internet-Draft SAMP October 2026
authenticated DISCOVER profile; core v0.2 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.
+==================+===========+===============================+
| 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.
Efstathiou Expires 29 April 2027 [Page 45]
Internet-Draft SAMP October 2026
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.13. 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
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"
}
Efstathiou Expires 29 April 2027 [Page 46]
Internet-Draft SAMP October 2026
{
"profile_revision": "profile-7",
"values": {},
"absent": ["system.optional_counter"],
"unknown": []
}
Explicit nullable value.
{
"fields": ["system.nullable_note"],
"expected_profile_revision": "profile-7"
}
{
"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"
}
Efstathiou Expires 29 April 2027 [Page 47]
Internet-Draft SAMP October 2026
{
"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"
}
{
"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:
Efstathiou Expires 29 April 2027 [Page 48]
Internet-Draft SAMP October 2026
{
"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.
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.
Optional event-family profiles MAY standardize event schema, source
identity, sequence/epoch, correlation, correction and privacy rules
while using existing PUSH PDUs. A generic PUSH capability does not
claim support for every event family; explicit extension support
advertisement, when available, identifies the applicable profile.
Event identifiers MUST NOT be conflated with operation request_id
values. No durable delivery acknowledgement is inferred from a
successful HTTP response.
8.2.5. Runtime Evidence
A CCS receipt MAY be referenced or transported through the existing
evidence representation only when an explicitly defined optional CCS-
to-SAMP evidence-binding profile provides verified issuer, integrity,
operation/request/enrollment correlation, and the meaning of the CCS
claim. CCS is informative in this core specification. The optional
profile MUST NOT equate a runtime verification verdict with proof
that a consequential external effect occurred or with evidence of
effect time unless the receipt and its binding profile actually
establish those properties. No CCS-specific core field or mandatory
Efstathiou Expires 29 April 2027 [Page 49]
Internet-Draft SAMP October 2026
CCS dependency is introduced.
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:
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
Efstathiou Expires 29 April 2027 [Page 50]
Internet-Draft SAMP October 2026
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. The
issued_at/expires_at freshness test above applies when evidence is
first used for consequential admission or new late-resolution
validation; it MUST NOT be reapplied against the time of a later,
unchanged historical outcome retrieval as if that retrieval requested
new authorization. A duplicate retrieval of the same recorded
operation does not re-admit it and does not require newly issued
evidence. To recognize historical evidence as verified, the relying
party MUST have sufficient retained authenticated evidence and
validation context to establish that the relevant receipt was
correctly validated at its original applicable time, including issuer
authenticity, operation binding and the then-applicable validity and
revocation rules of the identified evidence profile. A stored
processing_status value by itself is not sufficient proof to a
Efstathiou Expires 29 April 2027 [Page 51]
Internet-Draft SAMP October 2026
relying party. If that historical validation cannot be established,
the relying party MUST NOT claim independent historical verification;
it MUST preserve the recorded outcome and accurately report the
evidence-verification limitation or uncertainty without fabricating
execution failure. The evidence profile defines archival signature,
revocation and time-proof requirements. Historical response evidence
remains historical: it MUST NOT be reused to authorize a new
operation.
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.2 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.
Efstathiou Expires 29 April 2027 [Page 52]
Internet-Draft SAMP October 2026
If Manager-side validation must precede execution and the endpoint
cannot make that decision independently, a two-phase exchange is
required. Core SAMP v0.2 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.
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.
Runtime evidence used to resolve an indeterminate CONFIG/EXEC outcome
is subject to the stricter effect-evidence contract in Section 8.2.9.
Core correlation members alone do not prove the original enrollment
or authorization decision. The selected evidence profile MUST
cryptographically or otherwise authentically bind the evidence to the
original authenticated Manager identity, Agent enrollment context,
authority_ref, decision_ref, authorization_digest, request_id,
request_digest, operation type, and captured profile/policy context.
If any of those bindings cannot be reconstructed and validated
against the authoritative recorded operation, the evidence MUST NOT
resolve that operation.
Efstathiou Expires 29 April 2027 [Page 53]
Internet-Draft SAMP October 2026
processing_status verified states that the identified evidence
profile validated the evidence; it does not by itself mean that the
managed operation succeeded. An effect-evidence profile used for
late resolution MUST define the authenticated terminal-effect claim,
temporal and provenance rules, and typed result or CONFIG per-field
partition needed to justify the claimed transition. Mere post-
condition observation without sufficient causal attribution MUST NOT
be promoted to execution_outcome succeeded.
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
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.
Efstathiou Expires 29 April 2027 [Page 54]
Internet-Draft SAMP October 2026
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
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.
Efstathiou Expires 29 April 2027 [Page 55]
Internet-Draft SAMP October 2026
{
"version": "0.2", "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.2", "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
policy_denied, not subscription details. Retried identical requests
return their recorded original payload in a fresh envelope. Unknown
noncritical payload extensions are ignored.
Efstathiou Expires 29 April 2027 [Page 56]
Internet-Draft SAMP October 2026
{
"version": "0.2", "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.2", "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. Authorization Context and Request Binding
authorization_context is a closed object required by every core
CONFIG and EXEC request. It contains the following members:
authority_ref non-empty string; required; identifies the configured
trusted authorization authority namespace in which decision_ref is
interpreted
actor_ref non-empty string; required; originating human or machine
principal asserted by the trusted authorization decision; it is
not authenticated merely by appearing in the request
decision_ref non-empty string; required; authorization decision
reference unique within authority_ref
policy_id non-empty string; required; identifier of the policy set
that produced the decision
policy_version non-empty string; required; immutable version or
revision of that policy content
authorization_digest 64 lowercase hexadecimal characters; required;
SHA-256 binding to the exact authorization-bound action defined
below
expires_at RFC 3339 UTC timestamp; required; requested authorization
expiry. It MUST NOT extend beyond the trusted decision's validity
interval or the deployment maximum authorization age.
approval_ref non-empty string; optional in the wire object; required
when the trusted decision or local policy requires approval
delegation_ref non-empty string; optional in the wire object;
required when the trusted decision relies on delegated authority
artifact closed object; optional; contains required non-empty format
and value strings for an opaque or signed authorization proof.
Core SAMP treats the value as opaque and does not define the proof
format.
Efstathiou Expires 29 April 2027 [Page 57]
Internet-Draft SAMP October 2026
The authorization-bound action is the complete request PDU with
auth_tag removed and with
payload.admission_context.authorization_context removed. The sender
computes authorization_digest as SHA-256 over the RFC 8785 canonical
UTF-8 bytes of that object. Excluding authorization_context avoids a
circular signature or token dependency while binding version, type,
direction, target Agent, timestamp, request_id, operation parameters,
expected profile revision, and Manager/endpoint policy revisions.
The full replay-fencing request digest in Section 10.3 remains
unchanged and therefore also binds the supplied authorization_context
and any artifact bytes.
The authorization_digest is an action identifier, not an
authorization decision. Before new admission, the final Policy
Enforcement Point (PEP) MUST obtain an authenticated decision record
from the configured authority named by authority_ref, or validate an
authenticated authorization artifact issued by that authority. The
trusted decision MUST assert an allow decision for the recomputed
authorization_digest and MUST bind that decision to the authenticated
requesting Manager, actor_ref, target Agent and its current
authenticated enrollment context, operation type, policy_id and
policy_version, applicable constraints or obligations, required
approval and delegation state, and a finite validity interval. A
sender-supplied decision_ref, actor_ref, expires_at, policy
identifier, or matching digest is only a claim until it is matched
against that trusted decision.
The PEP MUST compare the trusted decision with the actual
authenticated request and local state. The authenticated Manager
identity is established by the SAMP authentication/credential context
and MUST equal the Manager identity bound by the trusted decision.
The current Agent enrollment is established under Section 5.13.1 and
MUST equal the enrollment bound by the trusted decision. The
originating actor may be a human, machine, or delegated principal
distinct from the Manager; actor_ref MUST equal the actor bound by
the trusted decision. A decision for another Manager, actor, Agent,
enrollment, operation, digest, policy snapshot, approval, delegation,
or constraint set MUST NOT authorize the request.
The trusted authority's validity interval is authoritative. Before
every new CONFIG/EXEC admission, the final PEP MUST verify that its
current time, allowing only the deployment-declared clock-skew
tolerance, is not later than authorization_context.expires_at and is
also within the trusted decision validity interval and the deployment
maximum authorization age. A request whose own expires_at has passed
MUST fail closed with authorization_expired and deny/not_executed
even if the trusted authority decision remains otherwise valid. The
request expires_at MUST be no later than the authority decision
Efstathiou Expires 29 April 2027 [Page 58]
Internet-Draft SAMP October 2026
expiry, and the PEP MUST enforce a documented finite positive maximum
authorization age for new admission. The sender cannot extend
authority by changing expires_at. If current revocation, approval,
delegation, or policy status is required by the trusted decision or
deployment policy, an offline/cached decision MUST NOT be accepted
unless the configured authorization profile defines a bounded
freshness and revocation rule that the PEP can validate. If required
current status cannot be established, admission fails closed with
policy_unavailable. These expiry checks apply to new admission only;
authenticated retrieval of an already recorded operation outcome
remains governed by recorded-state disclosure policy and retry
semantics.
A missing, malformed, unverifiable, expired, revoked, mismatched, or
insufficient authorization decision MUST NOT imply permission.
authorization_expired applies when the trusted decision is outside
its validity interval; delegation_invalid applies when a required
delegation is invalid, revoked, expired, or insufficient.
approval_required and step_up_required indicate that the current
request is conclusively not executed but may be resubmitted as a new
request after satisfying the named precondition. policy_unavailable
indicates a temporary inability to establish required authorization
state.
An authorization artifact is optional at the SAMP core layer because
a deployment may validate decision_ref through a local or online
authority. A deployment requiring offline or post-execution
verification MAY require artifact and define its format in an
explicitly identified profile. Regardless of representation, the
endpoint and audit record MUST retain the authority_ref,
decision_ref, authorization_digest, actor_ref, authenticated Manager
identity, enrollment binding, policy identity/version, approval/
delegation references when applicable, and decision validity metadata
sufficient to establish which trusted decision authorized the exact
operation.
Earlier Internet-Draft -03 introduced the consequential authorization
context while retaining experimental protocol envelope version 0.1.
Revision -04 defines envelope version 0.2 and preserves those
authorization requirements while adding the record_revision and
related outcome-history contract. An earlier 0.1 envelope cannot
assert 0.2 consequential-operation conformance. For 0.2-to-0.1
boundaries the version_unsupported and fail-closed rules in
Section 12.1.8 apply.
Efstathiou Expires 29 April 2027 [Page 59]
Internet-Draft SAMP October 2026
Example requests in this document show the SAMP request-side context
only. A matching authorization_digest and valid SAMP HMAC are
insufficient for admission: the PEP still MUST retrieve or validate
the trusted authority decision and perform the comparisons above
before any effect occurs.
8.2.9. 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) and authorization_context as defined in
Section 8.2.8. 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,
authorization decision, or endpoint policy revision; mismatch returns
policy_denied with deny/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 disclosure but MUST NOT cause re-
execution. Expiry or revocation that would block a new admission
MUST NOT erase an already recorded outcome; authenticated access to
recorded state remains governed by current disclosure policy and
Section 10.3.
+===================+============+===============================+
| 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 |
| | string; | to authenticated sender and |
| | required | target |
+-------------------+------------+-------------------------------+
| record_revision | integer or | Positive monotonically |
| | null; | increasing revision of an |
Efstathiou Expires 29 April 2027 [Page 60]
Internet-Draft SAMP October 2026
| | required | authoritative operation |
| | | record; null only when no |
| | | authoritative operation |
| | | record exists for a transient |
| | | pre-admission response. |
+-------------------+------------+-------------------------------+
| profile_revision | non-empty | Captured admission profile; |
| | string or | null only if admission was |
| | null; | rejected before profile |
| | required | resolution |
+-------------------+------------+-------------------------------+
| policy_revision | object; | Closed object: endpoint and/ |
| | required | or manager revision strings |
| | when | captured at admission |
| | applicable | |
+-------------------+------------+-------------------------------+
| result | JSON | CONFIG result object or typed |
| | value; | EXEC result; null when not |
| | required | available |
+-------------------+------------+-------------------------------+
| audit_persistence | string; | complete, failed, or unknown; |
| | required | independent of execution |
| | | outcome |
+-------------------+------------+-------------------------------+
| runtime_evidence | object; | Runtime-evidence object |
| | optional | defined in Section 8.2.5 |
+-------------------+------------+-------------------------------+
| effect_time | object; | Issuer-attested bounded |
| | optional | effect-occurrence time; |
| | | defined below. Does not |
| | | replace endpoint resolution |
| | | time. |
+-------------------+------------+-------------------------------+
| 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 a correlated authenticated, syntactically valid CONFIG/EXEC
admission error, it appears as payload.outcome alongside
payload.error. Malformed or unauthenticated requests and transport/
capacity failures that cannot attest operation admission state use
the ordinary error object without inventing an outcome.
deny / not_executed Used by policy_denied, config_disabled,
Efstathiou Expires 29 April 2027 [Page 61]
Internet-Draft SAMP October 2026
exec_disabled, authorization_expired, and delegation_invalid.
Non-execution is conclusive. Any corrected or newly authorized
attempt uses a new request_id.
indeterminate / not_executed: approval_required or
step_up_required Non-execution is conclusive. After satisfying the
precondition, the Manager sends a new authorized request with a
new request_id.
indeterminate / not_executed: policy_unavailable Temporary pre-
admission condition. The receiver keeps the mandatory non-
executable reservation defined below. A byte-identical retry may
be re-evaluated while fresh; conflicting content for the same
reserved request_id returns replay_detected.
allow / in_progress Execution was admitted and is still running. A
duplicate retrieves recorded state and never starts another
effect.
allow / succeeded Confirmed complete success. Terminal.
allow / partially_succeeded Confirmed partial CONFIG result.
Terminal; core CONFIG only.
allow / failed Confirmed execution failure. Terminal; this is not
an admission denial.
allow / indeterminate Execution completion or effect cannot yet be
established. Reconcile under the evidence rules below; do not
repeat effects.
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.
For deny or indeterminate policy outcomes, result MUST be null. For
allow/in_progress, result MUST be null. A confirmed execution
failure uses direction response and allow/failed, not policy_denied.
No response by itself proves that all external effects were
transactional, and a transport failure alone MUST NOT be interpreted
as confirmed execution failure.
policy_unavailable is a transient pre-admission response and MUST NOT
create a durable terminal denial or side-effecting operation record.
Before returning policy_unavailable, the receiver MUST retain a non-
executable reservation for the accepted retry/freshness period that
binds the authenticated Manager, current Agent enrollment,
request_id, target Agent, operation type, original request timestamp,
and full replay-fencing request digest. After the documented
Efstathiou Expires 29 April 2027 [Page 62]
Internet-Draft SAMP October 2026
backoff, a byte-identical retry received while that reservation is
valid MUST have its authorization state re-evaluated after backoff if
and only if the original request timestamp still satisfies ordinary
request freshness at the time of first admission; otherwise the retry
is stale and is rejected as specified below. The receiver MUST check
original request freshness and current authorization before
converting the reservation to an admitted consequential operation;
reservation validity MUST NOT extend either requirement. If the
original request timestamp is stale, the receiver MUST return
replay_detected without an operation outcome, MUST NOT admit or
execute, and MUST retain the non-executable reservation for its
otherwise required replay-fencing lifetime. The stale pre-admission
retry is not an already admitted historical operation retrieval. Any
request using the same authenticated Manager/enrollment/request_id
tuple with a different full request digest MUST return
replay_detected and MUST NOT execute. The reservation MUST survive
the same restart/recovery boundary required for the deployment's
accepted retry window; if the receiver cannot retain or recover that
reservation reliably, it MUST fail closed for policy_unavailable
requests rather than accept later reuse of that request_id.
Expiration of the reservation after the documented retry/freshness
period does not convert policy_unavailable into a terminal denial.
Every CONFIG/EXEC outcome MUST be auditable and bound to
operation_ref, authenticated Manager, target Agent, original
enrollment context, operation type, full request digest, captured
profile/policy context, and authority_ref/decision_ref/
authorization_digest. The Manager and endpoint MUST record admission
and execution separately. Access failures on a retry MUST NOT
overwrite the recorded original operation outcome.
An execution_outcome of indeterminate records genuine uncertainty and
is not a confirmed failure. Core v0.2 permits a recorded allow/
indeterminate operation to advance to a terminal outcome only while
the authoritative operation record remains available under the
declared retry/record-retention contract and only by the enforcement
endpoint/PEP that owns that record. The resolver MUST validate an
explicitly identified, mutually supported effect-evidence profile (or
equivalent trusted local mechanism) that proves the claimed effect
for the exact original operation. The proof MUST bind the original
authenticated Manager, Agent and enrollment, operation_ref, request
digest, authority_ref, decision_ref, authorization_digest, captured
profile/policy context, evidence provenance and freshness, and the
terminal effect being asserted.
Evidence used for resolution MUST establish more than policy validity
or observation of a desired state. The selected effect-evidence
profile MUST define authenticated effect semantics sufficient to
Efstathiou Expires 29 April 2027 [Page 63]
Internet-Draft SAMP October 2026
establish succeeded, failed, or, for CONFIG only,
partially_succeeded; it MUST carry or authenticate the corresponding
typed EXEC result or complete CONFIG applied/rejected/indeterminate
partition. A verified policy verdict, health report, or later state
observation that could have been caused by another actor is
insufficient unless the evidence profile provides the causal/
provenance guarantees required to attribute that effect to the
recorded operation. If those guarantees cannot be established, the
operation remains indeterminate.
A permitted resolution MUST update the authoritative record
atomically without changing operation identity or authorizing
execution. The original indeterminate observation, original
admission/authorization binding, resolution evidence reference, and
resolution timestamp MUST remain in append-only audit history. A
byte-identical retry received while the record remains retrievable
returns the latest resolved outcome and MUST NOT execute again. An
endpoint SHOULD emit a runtime_evidence PUSH containing the validated
resolution evidence when an applicable active subscription exists;
PUSH delivery is not a durability guarantee. After the operation
record is no longer available under the declared core retention/retry
contract, later evidence is a state observation and MUST NOT
retroactively create a core terminal operation record.
Once a confirmed terminal execution outcome has been established,
later contradictory observations MUST NOT silently rewrite it. They
are recorded as an audit inconsistency requiring reconciliation.
audit_persistence is independent of policy_outcome and
execution_outcome. complete means the endpoint has durably recorded
the audit/evidence state required by its declared policy for the
outcome currently reported; failed means required persistence was
attempted and failed; unknown means the endpoint cannot establish
persistence state. A confirmed execution MUST NOT be changed to
failed solely because audit persistence failed, but a peer MUST NOT
infer evidence completeness from execution success. If failed or
unknown is later repaired, the latest recorded outcome MAY report
complete while the audit history retains the prior persistence
failure and repair timestamp.
If required audit/evidence persistence fails after an effect has
occurred, the endpoint MUST preserve the known effect facts for
audit/reconciliation to the extent they can safely be retained and
MUST surface the persistence condition through its available
authorized operational alarm/event mechanism. If it can establish
and commit a valid authoritative record_revision for a current
outcome, and can still respond, it MUST return the known execution
truth with audit_persistence failed or unknown. If an updated
Efstathiou Expires 29 April 2027 [Page 64]
Internet-Draft SAMP October 2026
authoritative snapshot cannot be committed or assigned a new valid
revision (including because record_revision is exhausted or latest-
commit authority is uncertain), the authoritative-outcome fence below
takes precedence: the endpoint MUST return back_pressure without
payload.outcome, MUST NOT expose changed execution truth under an old
revision, and MUST NOT infer execution failure or trigger re-
execution. If the local audit subsystem is so impaired that even the
failure state cannot be durably recorded, the endpoint MUST fail
closed for subsequent consequential admissions until required
persistence guarantees are restored; SAMP cannot retroactively make
an already performed external effect durable. Failure of the alarm
channel itself does not justify a fabricated outcome or a new
execution.
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.
Each authoritative CONFIG/EXEC operation record MUST carry
record_revision as an exact JSON integer in the inclusive range 1
through 9007199254740991, initialized at 1 and scoped to the original
operation_ref, full authenticated request digest, Manager identity,
target Agent and enrollment. A transient pre-admission
policy_unavailable non-executable reservation without an
authoritative operation record MUST report JSON null; null MUST NOT
be returned for an existing authoritative operation record. The
endpoint MUST atomically advance the revision for every material
change to the authoritative peer-visible operation-outcome snapshot,
including its execution state, result, audit_persistence, attached
verified runtime_evidence, effect_time, evidence/provenance
corrections and resolution information. It MUST retain the
superseded immutable snapshots, revisions and their operation
bindings in append-only audit history. A later observation that
contradicts a confirmed terminal result is an audit inconsistency,
not a silent rewrite of that result. Transport envelope timestamps,
authentication tags, and retrieval delivery metadata are not material
recorded-outcome changes. Identical authenticated retrievals of
unchanged recorded state MUST return the same revision; they MUST NOT
execute again. A changed snapshot MUST NOT reuse an earlier
revision, including across restart, replica failover or recovery. If
the endpoint cannot establish the latest committed authoritative
revision and its durable operation binding, it MUST fail closed for
new consequential admission affecting that record and MUST NOT return
an intact but potentially stale checkpoint as the current
Efstathiou Expires 29 April 2027 [Page 65]
Internet-Draft SAMP October 2026
authoritative outcome in response to an otherwise valid duplicate
retrieval. It MUST return an ordinary back_pressure error without
payload.outcome while authoritative retrieval is fenced; this error
does not assert execution failure or permission to issue a new
request_id. Authentication, disclosure authorization and replay-
binding checks still apply before an outcome is disclosed. An
explicitly identified historical audit snapshot MAY remain available
through an independently authorized mechanism but MUST NOT be
misrepresented as the current outcome. If the maximum
record_revision has been reached, the endpoint MUST NOT reuse or wrap
the revision, MUST fail closed for additional consequential admission
affecting the record, and MUST use a back_pressure error without
payload.outcome instead of reporting a changed result under an old
revision when it cannot make a new authoritative record. This
restriction does not erase an already occurred effect; recovery and
escalation MUST preserve the known facts and audit trail. The
inability to report an authoritative current outcome MUST NOT trigger
replay as a new operation or fabricate a definitive outcome.
Efstathiou Expires 29 April 2027 [Page 66]
Internet-Draft SAMP October 2026
A Manager MUST authenticate and validate each received CONFIG/EXEC
outcome, including operation_ref and the original immutable request/
enrollment binding, before accepting record_revision. For every
authoritative record it has previously accepted, the Manager MUST
retain the greatest accepted revision and the canonical peer-visible
outcome snapshot (or an integrity digest together with sufficient
retained evidence to compare its content). A lower revision MUST NOT
replace accepted state; the Manager MUST retain the higher revision
and record a stale/rollback anomaly. The same revision and identical
authoritative snapshot is a valid idempotent retrieval; the same
revision with different canonical outcome contents or a different
original request binding MUST be recorded as a conflict and MUST NOT
overwrite state. A higher revision with a valid binding and profile-
consistent transition MAY advance the Manager view and MUST be
auditable. An anomaly is not authority to retry the original
consequential effect. A transient pre-admission outcome with
record_revision null is an observation of authorization
unavailability, not an authoritative record revision. Once a Manager
has accepted a positive authoritative record_revision for the same
original request and enrollment binding, a delayed null outcome MUST
NOT replace, downgrade, or be used as a current execution-state
decision basis in preference to that record. It MAY be retained as a
historically truthful earlier observation with its response receipt
time. The same non-overwrite principle applies to later-arriving
ordinary retry access/capacity errors without an operation outcome.
A Manager MUST serialize or atomically reconcile concurrent response
consumption against its retained authoritative state; transport
arrival order alone MUST NOT determine authority. A null observation
seen before any authoritative revision is not proof that no later
execution occurred. Local alarm/quarantine response is subject to
Manager policy; no new PDU is defined.
An optional effect_time is valid only when an identified and mutually
recognized effect-evidence profile establishes an occurrence interval
for the exact original operation. Whenever effect_time is present in
an outcome, that same outcome MUST carry the associated
runtime_evidence object. The receiver MUST validate its
evidence_format, issuer authentication, evidence-processing state and
binding to the original authenticated operation and enrollment using
the recognized profile before accepting the temporal claim. An HMAC
from the reporting endpoint alone does not authenticate a third-party
evidence issuer. An unverified, malformed, or mismatched optional
effect_time MUST NOT be accepted as a verified time: the Manager MUST
record the invalid-claim anomaly rather than derive an occurrence
time. Where that evidence is also required to establish a previously
indeterminate execution outcome, the claimed late resolution MUST NOT
be accepted without valid effect evidence. Invalid optional timing
metadata alone MUST NOT rewrite an already established execution
Efstathiou Expires 29 April 2027 [Page 67]
Internet-Draft SAMP October 2026
outcome or authorize another execution. It MUST be a closed JSON
object with issuer (non-empty string), earliest and latest (non-empty
RFC 3339 UTC timestamp strings ending in Z, earliest no later than
latest), and optional clock_ref (non-empty string). The issuer MUST
exactly equal the authenticated runtime_evidence.issuer unless that
explicitly identified evidence profile specifies an independently
authenticated issuer-identifier mapping; otherwise the claim MUST be
rejected. The evidence profile MUST define temporal bounds, asserted
uncertainty, issuer and clock provenance, and the validation of
operation and enrollment binding; any clock_ref is scoped only to
that issuer and profile-defined temporal domain, not a global clock
identity. The endpoint MUST validate the claim under that profile,
including its uncertainty/bounds and original operation binding. The
interval is the evidence issuer's assertion, not a guarantee that
different clocks are comparable. The endpoint MUST NOT construct
effect_time from resolution_timestamp or Manager/endpoint receipt
clocks. If no sufficiently verified effect-occurrence bounds exist,
effect_time MUST be absent. An otherwise properly proven terminal
outcome may still be valid without effect_time. The distinct
resolution timestamp identifies when the endpoint learned and
recorded its later resolution.
Event ordering derived from unrelated clock domains is not
authoritative merely because timestamps can be numerically compared.
An auditor or Manager MAY establish precedence through validated
causal links, a declared comparable clock domain with sufficient
error bounds, or another applicable evidence-profile rule. If these
conditions do not prove an order, the events MUST be treated as
unordered rather than assigned a fabricated precedence. A late-
validated result can describe an effect that occurred before lease
expiration even when evidence was obtained afterward; revocation or
lease loss does not itself rewrite the original effect or execution
outcome. Any new consequential act requires independently current
authorization.
Non-normative illustration of recorded-outcome excerpts (other
mandatory outcome members and validated supporting evidence are
omitted):
Efstathiou Expires 29 April 2027 [Page 68]
Internet-Draft SAMP October 2026
{
"observed_first": {
"operation_ref": "11111111-2222-4333-8444-555555555555",
"record_revision": 1,
"policy_outcome": "allow",
"execution_outcome": "indeterminate"
},
"observed_later": {
"operation_ref": "11111111-2222-4333-8444-555555555555",
"record_revision": 2,
"policy_outcome": "allow",
"execution_outcome": "succeeded",
"effect_time": {
"issuer": "verifier-A",
"earliest": "2026-10-25T14:00:00Z",
"latest": "2026-10-25T14:00:10Z"
}
}
}
8.2.10. 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.2. The endpoint MUST validate the
authorization context, 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
fields exactly once across these containers. During late resolution
of an allow/indeterminate CONFIG operation with a recorded per-field
partition, a later revision MAY refine previously indeterminate
Efstathiou Expires 29 April 2027 [Page 69]
Internet-Draft SAMP October 2026
fields to confirmed applied or rejected only on the basis of
correctly bound effect evidence. Fields already recorded as
confirmed applied or rejected MUST retain those classifications
through ordinary late resolution; the endpoint MUST NOT silently
reclassify or erase them. Contradictory evidence about a previously
confirmed field MUST be recorded as a separate, correlated audit
inconsistency with source and original operation/revision binding.
It MUST be surfaced through an authenticated, authorized operational
reporting mechanism declared for the deployment; where a relevant
subscribed SAMP PUSH event family is supported the endpoint SHOULD
notify the Manager, but PUSH is not durable delivery. Any
reconciliation that alters a previously confirmed classification
requires a separately specified, authorized correction procedure;
core late resolution alone does not authorize such a change. Until
the contradiction is resolved, the endpoint MUST NOT assert a new
terminal partition that contradicts its previously confirmed fields
or automatically repeat CONFIG effects. 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.9.
In the request example, authority_ref and decision_ref identify a
trusted authorization decision, but the decision record itself is
intentionally not serialized by core SAMP. Before admission, the PEP
recomputes authorization_digest, authenticates the SAMP Manager,
validates the current Agent enrollment, retrieves or verifies the
trusted decision under authority_ref, and confirms that the
authority-bound digest, Manager, actor, Agent/enrollment, operation,
policy snapshot, constraints, approval/delegation state, and validity
interval all match. Digest equality and HMAC authentication alone
are insufficient.
Efstathiou Expires 29 April 2027 [Page 70]
Internet-Draft SAMP October 2026
{
"version": "0.2",
"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"
},
"authorization_context": {
"authority_ref": "authz:local-authority-01",
"actor_ref": "manager:core-01",
"decision_ref": "authz-config-29d3ebbe",
"policy_id": "samp-ops",
"policy_version": "42",
"authorization_digest":
"704374ed9a2727768a9e53db216d6912b9753a9d6d5a520360143ebc0dc421a0",
"expires_at": "2026-09-26T11:00:00Z"
}
}
}
}
Complete successful response:
Efstathiou Expires 29 April 2027 [Page 71]
Internet-Draft SAMP October 2026
{
"version": "0.2",
"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",
"record_revision": 1,
"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": []
},
"audit_persistence": "complete"
}
}
Partial response payload when local policy rejects the second field:
Efstathiou Expires 29 April 2027 [Page 72]
Internet-Draft SAMP October 2026
{
"policy_outcome": "allow",
"execution_outcome": "partially_succeeded",
"record_revision": 1,
"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": []
},
"audit_persistence": "complete"
}
Indeterminate response payload when the second field effect cannot be
established:
Efstathiou Expires 29 April 2027 [Page 73]
Internet-Draft SAMP October 2026
{
"policy_outcome": "allow",
"execution_outcome": "indeterminate",
"record_revision": 1,
"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"
]
},
"audit_persistence": "complete"
}
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.11. 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.
Efstathiou Expires 29 April 2027 [Page 74]
Internet-Draft SAMP October 2026
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.
The endpoint MUST validate the authorization context before
execution. EXEC MUST be explicitly enabled locally and the command
MUST appear in allowed_commands. Free-form untyped arguments are
prohibited.
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. For all other EXEC
admission failures, the authorization/error/outcome mapping in
Section 8.2.8 and Section 8.2.9 is authoritative, together with the
applicable error transport rules. An EXEC receiver MUST NOT replace
a required specific code (including authorization_expired,
delegation_invalid, approval_required, step_up_required, or
policy_unavailable) with a generic policy_denied. policy_denied is
applicable only when no more specific required denial code applies.
policy_unavailable is limited to temporary inability to establish
required authorization state and its non-executable reservation and
freshness rules. Evidence requirements are enforced before
execution, not approved retroactively from the final response.
In the request example, authority_ref and decision_ref identify a
trusted authorization decision, but the decision record itself is
intentionally not serialized by core SAMP. Before admission, the PEP
recomputes authorization_digest, authenticates the SAMP Manager,
validates the current Agent enrollment, retrieves or verifies the
trusted decision under authority_ref, and confirms that the
authority-bound digest, Manager, actor, Agent/enrollment, operation,
Efstathiou Expires 29 April 2027 [Page 75]
Internet-Draft SAMP October 2026
policy snapshot, constraints, approval/delegation state, and validity
interval all match. Digest equality and HMAC authentication alone
are insufficient.
{
"version": "0.2",
"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"
},
"authorization_context": {
"authority_ref": "authz:local-authority-01",
"actor_ref": "manager:core-01",
"decision_ref": "authz-exec-c2773f5c",
"policy_id": "samp-ops",
"policy_version": "42",
"authorization_digest":
"fec1ee3c922bf29220e206ce9fff040de6ff5c466fbc29ac461f0bb8aee32f42",
"expires_at": "2026-09-26T11:00:00Z"
}
}
}
}
Complete success response after explicit local enablement:
Efstathiou Expires 29 April 2027 [Page 76]
Internet-Draft SAMP October 2026
{
"version": "0.2",
"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",
"record_revision": 1,
"operation_ref": "c2773f5c-8182-5d5b-a11c-f079083b5371",
"profile_revision": "profile-8",
"policy_revision": {
"endpoint": "local-4",
"manager": "manager-5"
},
"result": {
"reset": true
},
"audit_persistence": "complete"
}
}
In-progress response payload:
{
"policy_outcome": "allow",
"execution_outcome": "in_progress",
"record_revision": 1,
"operation_ref": "c2773f5c-8182-5d5b-a11c-f079083b5371",
"profile_revision": "profile-8",
"policy_revision": {
"endpoint": "local-4",
"manager": "manager-5"
},
"result": null,
"audit_persistence": "complete"
}
Confirmed execution-failure response payload:
Efstathiou Expires 29 April 2027 [Page 77]
Internet-Draft SAMP October 2026
{
"policy_outcome": "allow",
"execution_outcome": "failed",
"record_revision": 1,
"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.",
"audit_persistence": "complete"
}
Indeterminate execution response payload:
{
"policy_outcome": "allow",
"execution_outcome": "indeterminate",
"record_revision": 1,
"operation_ref": "c2773f5c-8182-5d5b-a11c-f079083b5371",
"profile_revision": "profile-8",
"policy_revision": {
"endpoint": "local-4",
"manager": "manager-5"
},
"result": null,
"audit_persistence": "complete"
}
Complete disabled-operation error:
Efstathiou Expires 29 April 2027 [Page 78]
Internet-Draft SAMP October 2026
{
"version": "0.2",
"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",
"record_revision": 1,
"operation_ref": "63f40094-6729-5d34-8954-2c5eeab47daa",
"profile_revision": "profile-7",
"policy_revision": {
"endpoint": "local-3",
"manager": "manager-5"
},
"result": null,
"audit_persistence": "complete"
}
}
}
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 29 April 2027 [Page 79]
Internet-Draft SAMP October 2026
{
"version": "0.2", "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.2:
Efstathiou Expires 29 April 2027 [Page 80]
Internet-Draft SAMP October 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 |
+---------------------------+-------------------------------------+
| approval_required | Authorization is not yet complete; |
| | a required approval is absent. The |
| | request was not executed and any |
| | approved attempt is a new request. |
+---------------------------+-------------------------------------+
| step_up_required | Stronger authentication or |
| | authorization assurance is required |
Efstathiou Expires 29 April 2027 [Page 81]
Internet-Draft SAMP October 2026
| | before admission. The request was |
| | not executed and any stepped-up |
| | attempt is a new request. |
+---------------------------+-------------------------------------+
| authorization_expired | The request-side authorization |
| | deadline has passed, the trusted |
| | authorization decision is expired, |
| | or the request expiry exceeds the |
| | trusted decision validity interval. |
+---------------------------+-------------------------------------+
| delegation_invalid | A required delegation is invalid, |
| | revoked, expired, mismatched, or |
| | insufficient for this exact action. |
+---------------------------+-------------------------------------+
| policy_unavailable | Required trusted authorization, |
| | revocation, approval, delegation, |
| | or policy state is temporarily |
| | unavailable; no execution occurred. |
+---------------------------+-------------------------------------+
| rate_limited | The receiver is rate-limiting |
| | requests |
+---------------------------+-------------------------------------+
| back_pressure | Receiver temporarily cannot safely |
| | process admission or establish the |
| | current authoritative outcome for |
| | retrieval, including overload or an |
| | unavailable latest-commit/ordering |
| | boundary |
+---------------------------+-------------------------------------+
| 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 11: SAMP Error Codes
Efstathiou Expires 29 April 2027 [Page 82]
Internet-Draft SAMP October 2026
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
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.
Efstathiou Expires 29 April 2027 [Page 83]
Internet-Draft SAMP October 2026
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.2 defines none.
The optional supported_extensions advertisement defined in the
profile is not a negotiated critical-extension mechanism. A peer
that ignores an advertised extension MUST NOT be assumed to have
recognized, accepted, or enforced its semantics. An extension
carrying consequential authority MUST NOT be interpreted by endpoints
that lack an explicitly supported and authorized enforcement
contract.
9. Authentication
SAMP v0.2 uses shared-secret authentication with HMAC-SHA256
[RFC2104] [RFC6234].
9.1. Authentication Model
SAMP distinguishes between:
* *Mandatory implementation support*: All conformant SAMP v0.2
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).
* *Transport confidentiality*: Provided by TLS 1.3 [RFC9846] 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.
Efstathiou Expires 29 April 2027 [Page 84]
Internet-Draft SAMP October 2026
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.
9.3. Key Identification
SAMP v0.2 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.2.
Key distribution is out of band. Implementations SHOULD store shared
secrets in a secrets manager, not in plaintext configuration files.
Efstathiou Expires 29 April 2027 [Page 85]
Internet-Draft SAMP October 2026
Same-enrollment rotation preserves ordering; enrollment replacement
requires a fresh, distinguishable credential/context under
Section 5.13.1. Optional key_id is only a key selector, not proof of
enrollment membership.
9.4. Canonical JSON
SAMP v0.2 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.
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.
Efstathiou Expires 29 April 2027 [Page 86]
Internet-Draft SAMP October 2026
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.
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.2 requires HTTP [RFC9110] as the baseline transport.
Efstathiou Expires 29 April 2027 [Page 87]
Internet-Draft SAMP October 2026
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 29 April 2027 [Page 88]
Internet-Draft SAMP October 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, overload, or temporary |
| Unavailable | authorization/policy unavailability |
+------------------+---------------------------------------+
Table 12: 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.
Efstathiou Expires 29 April 2027 [Page 89]
Internet-Draft SAMP October 2026
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
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,
bootstrap_failed, approval_required, step_up_required,
authorization_expired and delegation_invalid to HTTP 403;
unknown_field to HTTP 404; replay_detected to HTTP 409; rate_limited
to HTTP 429; back_pressure and policy_unavailable 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.
For CONFIG/EXEC, approval_required and step_up_required use
indeterminate/not_executed; authorization_expired and
delegation_invalid use deny/not_executed; policy_unavailable uses
indeterminate/not_executed. These codes describe pre-admission state
and never imply execution. policy_unavailable is transient and may be
re-evaluated on a byte-identical retry as specified in Section 10.3;
satisfying approval, step-up, renewed authorization, or delegation
changes the authorization context and therefore requires a new
request_id.
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.
Efstathiou Expires 29 April 2027 [Page 90]
Internet-Draft SAMP October 2026
* TLS 1.3 [RFC9846] 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.2. WebSocket is primarily
useful for:
* Persistent event streams (subscription delivery).
* Frequent heartbeats (reducing HTTP overhead).
* 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.2.
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.2 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.
Efstathiou Expires 29 April 2027 [Page 91]
Internet-Draft SAMP October 2026
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.
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.13, 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.
Except when a specified access, capacity, or authoritative-recovery
fence requires an ordinary error without an operation outcome, 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/authorization context. If still
executing, execution_outcome is in_progress and result is null. A
duplicate of a durable conclusive pre-admission error returns the
original error outcome in a fresh error envelope. policy_unavailable
is the exception: before returning it the receiver retains the
mandatory non-executable Manager/enrollment/request_id/full-digest
reservation defined in Section 8.2.9; an identical retry during the
valid reservation period is eligible for re-evaluation only if its
original request timestamp is still fresh for first admission, and
current authorization is independently valid. A stale identical pre-
admission retry returns replay_detected without an operation outcome
or execution, while the reservation remains subject to required
Efstathiou Expires 29 April 2027 [Page 92]
Internet-Draft SAMP October 2026
retention. Conflicting content for the reserved request_id returns
replay_detected without execution. SUBSCRIBE/UNSUBSCRIBE return
their original recorded payload; duplicate delivery does not extend
expiry or repeat cancellation.
Processing order is: validate syntax and bounded input; authenticate
and check the credential/enrollment binding under Section 5.13.1;
compute digest; look up recorded state under authenticated sender,
enrollment and request_id; check target, type, digest and original
bound context; authorize access; establish the latest committed
authoritative operation revision and its durable binding when
claiming a current CONFIG/EXEC outcome; return matching state only if
that authority can be established. If latest committed state cannot
be established, apply the back_pressure outcome-retrieval fence
defined in Section 8.2.9 without inventing a current operation
outcome. This duplicate/conflict path precedes ordinary freshness
rejection, but an authenticated pre-admission policy_unavailable
reservation does not exempt a retry from the original timestamp
freshness check before first consequential admission. An identical
request with a matching, still-retained reservation but an expired
original timestamp MUST receive replay_detected without
payload.outcome and MUST NOT execute. Its required reservation MUST
NOT be released early merely because the timestamp became stale.
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.
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,
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.
Efstathiou Expires 29 April 2027 [Page 93]
Internet-Draft SAMP October 2026
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.13.
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.
Efstathiou Expires 29 April 2027 [Page 94]
Internet-Draft SAMP October 2026
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
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.13.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 13: Conformance Tiers
Efstathiou Expires 29 April 2027 [Page 95]
Internet-Draft SAMP October 2026
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.
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.13.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.
Efstathiou Expires 29 April 2027 [Page 96]
Internet-Draft SAMP October 2026
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.
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.
For this revision, conformance tests MUST distinguish profile
snapshot retransmission from changing operational QUERY values,
reject equal-sequence profiles with any changed canonical profile
content, validate optional supported_extensions identity and
duplicate handling, and ensure advertisement never grants authority.
CONFIG/EXEC tests MUST check initial record_revision, monotonic
changes, identical historical reads, indeterminate-to-terminal late
resolution, audit persistence repair, and null revision for a
transient pre-admission reservation. Effect-time tests MUST reject
issuer/operation mismatches and inverted bounds, preserve an absent
occurrence time when unsupported, and avoid imposing cross-clock
order without verified causal or clock-comparability evidence.
Efstathiou Expires 29 April 2027 [Page 97]
Internet-Draft SAMP October 2026
SAMP 0.2 consequential-operation conformance tests MUST include:
receipt of a 0.1 envelope (version_unsupported, no admission); a
valid record_revision 1 then 2 transition; rejection of revision 1
following accepted revision 2; a same-revision/different-outcome
conflict; unchanged same-revision retrieval with fresh envelope
metadata; refusal of a revised outcome following unrecoverable
endpoint revision state; Manager audit of a decision based on
revision 1 despite later resolution to revision 2; effect_time
rejection for missing/incorrect issuer, invalid or inverted bounds
and unbound operation evidence; acceptance of absent effect_time
where effect cannot be reliably timed; and correct policy_denied
versus policy_unavailable mapping. Additional negative vectors MUST
cover: valid original evidence retrieved after expiry but bound to
the original verification time; insufficient archival validation
material; delayed transient null and ordinary access-error responses
after a numbered outcome; recovered stale checkpoints where the
latest committed revision cannot be established; exhaustion of the
revision integer after an already occurred effect; contradictory
CONFIG per-field evidence; effect_time without accompanying
runtime_evidence; and a mismatched evidence issuer. Additional
interoperability vectors MUST cover: an EXEC request with
authorization_expired, delegation_invalid, approval_required,
step_up_required and transient policy_unavailable without generic
remapping; a successful external effect combined with audit
persistence failure and exhausted record_revision, where
back_pressure without an outcome takes precedence; a late
authenticated response to operation A after record expiry while an
unrelated operation B would otherwise reuse A's request_id,
confirming sender non-reassignment; and a valid policy_unavailable
reservation whose retry arrives after original request freshness
expires but before reservation/authority validity expires, requiring
replay_detected without first admission. These tests MUST NOT treat
a transport error as proof of effect failure or authorize automatic
re-execution. Advertisement tests MUST cover duplicate extension
pairs, exact-version recognition, and extension_publisher having no
authorization significance.
12. Security Considerations
Optional observability profiles and Agent-to-shared-resource bindings
are disclosure surfaces. Implementations MUST authorize access to
account/provider scope, Agent relationships, task metadata and usage
history independently of their ability to parse or transport those
values. Advertising an optional extension does not permit CONFIG/
EXEC, confer trust, or bypass local enforcement. A fencing token
carried as opaque metadata does not enforce exclusion unless the
actual effect boundary validates the applicable generation; lease
loss is not evidence that a previously admitted effect failed.
Efstathiou Expires 29 April 2027 [Page 98]
Internet-Draft SAMP October 2026
12.1. Threat Model
SAMP v0.2 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.2:
* Agents SHOULD maintain an allow-list of authorized manager
addresses.
* Agents MUST validate HMAC authentication tags except in the
explicitly configured loopback test mode.
* 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.2:
* 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.2:
* Shared secrets SHOULD be stored in a secrets manager.
* Secrets SHOULD be distributed out of band.
Efstathiou Expires 29 April 2027 [Page 99]
Internet-Draft SAMP October 2026
* 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.
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.2:
* 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.13 and the credential-isolation/non-
rollback invariant in Section 5.13.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.
Efstathiou Expires 29 April 2027 [Page 100]
Internet-Draft SAMP October 2026
Mitigations in v0.2:
* EXEC is disabled by default.
* CONFIG and EXEC require explicit profile exposure.
* CONFIG and EXEC require a bound authorization_context;
authenticated Manager identity alone is insufficient.
* The endpoint or independently enforceable SAMP component is the
final Policy Enforcement Point and MUST fail closed when
authorization, approval, delegation, or required policy state
cannot be validated.
* 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.
* 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.2:
* 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.
Efstathiou Expires 29 April 2027 [Page 101]
Internet-Draft SAMP October 2026
* 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
Internet-Draft revision -04 specifies SAMP envelope protocol version
"0.2". The profile-format version remains "0.1"; it is not an
indication that a 0.1 protocol-envelope peer supports SAMP 0.2.
Version 0.2 changes the mandatory CONFIG/EXEC operation outcome
contract by requiring record_revision and the associated history,
rollback/conflict and audit semantics. Version 0.1 and 0.2 peers are
not wire-interoperable for consequential operations without a
separately specified bridge or compatibility implementation. A SAMP
0.2 peer MUST reject a received envelope version other than 0.2 with
version_unsupported before processing its operation, and MUST NOT
silently downgrade, re-sign, translate or reinterpret a version 0.1
CONFIG/EXEC request as 0.2. No automatic version negotiation,
downgrade, or mixed-version consequential-operation mode is defined
in this document. version_unsupported is an error response only to an
otherwise reply-eligible request; unsupported response, error and
notification PDUs, including PUSH, MUST NOT elicit a SAMP reply or
error loop. A version rejection does not establish an operation
admission or execution outcome.
Operators upgrading experimental 0.1 deployments MUST explicitly
upgrade or reconfigure both endpoint and Manager before resuming
consequential admission under 0.2, preserving historical enrollment,
replay, and already-recorded operation identity as applicable. Any
legacy state migration requires a trustworthy provenance and revision
checkpoint; when the original revision cannot be established, peers
MUST NOT invent a value or permit an unsafe retry. A pre-existing
0.1 operation record without revision metadata may be archived as
legacy history under local policy, but cannot be treated as a native
0.2 record merely by filling in record_revision.
12.1.9. Event and Discovery Flooding
An agent could flood a manager with PUSH events or DISCOVER messages.
Mitigations in v0.2:
* Managers SHOULD rate-limit DISCOVER from unknown agents.
Efstathiou Expires 29 April 2027 [Page 102]
Internet-Draft SAMP October 2026
* 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.2:
* 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
When a Manager takes an action, waits, alarms, escalates or resolves
an incident based on a CONFIG/EXEC outcome, its audit record MUST
bind the decision and authenticated actor to the specific
operation_ref, original request digest, target Agent and enrollment,
received record_revision (or explicit null for a transient pre-
admission reservation), recorded policy_outcome and
execution_outcome, decision and receipt timestamps, and the validated
response snapshot or its integrity digest with sufficient retained
material to reconstruct the decision basis. Each later resolution
MUST create a distinct audit entry, not rewrite the earlier decision.
Endpoint and Manager audit MUST preserve verified effect_time,
evidence issuer and resolution timestamp separately when present. No
standard database, distributed log, external evidence store, or
historical-retrieval PDU is mandated by this requirement.
Managers and endpoints MUST audit admission and recorded execution
outcomes for CONFIG and EXEC, including authenticated Manager,
originating actor, Agent and enrollment binding, operation_ref, full
request digest, timestamp, captured profile_revision and applicable
policy_revision, authority_ref, decision_ref, authorization_digest,
approval/delegation references when applicable, policy_outcome,
execution_outcome, audit_persistence, and available evidence
reference. An indeterminate result MUST NOT be logged as confirmed
failure. Any later permitted evidence-backed resolution MUST
preserve the original indeterminate observation and append the
resolved state, effect-evidence binding, and resolution timestamp.
Retry access events MUST be distinguished from new execution.
Changes in audit_persistence, including repair after failed or
unknown persistence, MUST preserve prior persistence-state history.
Efstathiou Expires 29 April 2027 [Page 103]
Internet-Draft SAMP October 2026
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.
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.2.
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.
Efstathiou Expires 29 April 2027 [Page 104]
Internet-Draft SAMP October 2026
Token rotation in v0.2 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.13.1; neither ordinary
rotation nor reauthentication resets the sequence.
12.6. Summary: Current Requirements vs Future Work
+================+=========================+======================+
| Threat | v0.2 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 |
| 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 14: Security Mitigations: v0.2 vs Future
Efstathiou Expires 29 April 2027 [Page 105]
Internet-Draft SAMP October 2026
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
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.
Efstathiou Expires 29 April 2027 [Page 106]
Internet-Draft SAMP October 2026
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.
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.2 targets single-agent interactions. A single manager MAY
manage multiple agents, but fleet-scale bulk operations are not
defined in v0.2. Deployments needing fleet-scale operations SHOULD
use external orchestration (e.g., scripts, configuration management)
layered on top of SAMP.
Scaling approaches compatible with v0.2:
* *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.
Efstathiou Expires 29 April 2027 [Page 107]
Internet-Draft SAMP October 2026
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.
Deployments SHOULD retain the provenance, observation time and
reception time of each telemetry record separately. Where PUSH and
QUERY observations cannot be ordered from a source-defined sequence/
epoch or authenticated causal relation, a consumer SHOULD preserve
the uncertainty rather than silently overwrite one with the other.
Core SAMP does not define durable PUSH delivery, generic event-log
replay, or bounded historical retrieval; a separate optional
extension would be required for interoperable gap recovery.
14.4. Conversational and Fleet-Orchestration Interfaces
Conversational parsers, fleet-wide target selection, batching, canary
strategy, and user-interface confirmation are orchestration functions
outside core SAMP. Such systems MUST reduce a human request to exact
typed SAMP operations before authorization is evaluated and before
transmission, as described in Section 3.4.
For high-impact or large target sets, deployments SHOULD expose the
resolved target count, operation, constraints, authorization
requirements, and expected blast radius to the operator before
execution. One authorization decision MUST NOT be silently expanded
to targets or operations outside its bound scope.
14.5. 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.
policy_unavailable is a transient pre-admission authorization
failure: after backoff and matching reservation lookup, a byte-
identical request may be re-evaluated for first admission only while
its original timestamp is fresh and the current authorization checks
pass. An expired original timestamp requires replay_detected without
Efstathiou Expires 29 April 2027 [Page 108]
Internet-Draft SAMP October 2026
an outcome while the non-executable reservation is retained as
required; an already admitted operation instead follows recorded-
outcome retrieval rules. approval_required and step_up_required
establish not_executed for the original request; after the required
approval or stronger assurance is obtained, the Manager sends a new
authorization-bound request with a new request_id.
authorization_expired and delegation_invalid likewise require new
valid authorization before a new request. None of these rules
permits a new operation to bypass an unresolved allow/indeterminate
execution.
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.
If an originally indeterminate CONFIG or EXEC is later resolved under
Section 8.2.9, the byte-identical original retry retrieves the latest
resolved recorded outcome. Resolution changes recorded knowledge,
not operation identity, and MUST NOT authorize a second execution.
The audit history retains both the earlier indeterminate state and
the evidence-backed resolution.
Ordering-state recovery MUST satisfy Section 5.13.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:
Efstathiou Expires 29 April 2027 [Page 109]
Internet-Draft SAMP October 2026
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
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
approval_required Additional approval is required before admission;
This document
step_up_required Stronger authentication or authorization assurance
is required; This document
authorization_expired Authorization decision or artifact expired;
This document
delegation_invalid Delegated authority is invalid or insufficient;
Efstathiou Expires 29 April 2027 [Page 110]
Internet-Draft SAMP October 2026
This document
policy_unavailable Required authorization policy or validation state
is temporarily unavailable; This document
rate_limited Rate limiting in effect; This document
back_pressure Receiver temporarily cannot safely process admission
or establish the current authoritative outcome for retrieval,
including overload or an unavailable latest-commit/ordering
boundary; 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:
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.
Efstathiou Expires 29 April 2027 [Page 111]
Internet-Draft SAMP October 2026
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.
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
Efstathiou Expires 29 April 2027 [Page 112]
Internet-Draft SAMP October 2026
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.2; 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.
The top-level metadata name supported_extensions is reserved for the
optional support advertisement defined in this document and MUST NOT
be registered as a category namespace. This reservation does not
assign any optional observational category or extension identifier.
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. Acknowledgments
The author thanks Iman Schrock, Vernon Wharff, Guigui Wang, and Sumit
P. Ahuja for detailed technical review and comments that materially
improved the admission, retry, trust-transition, evidence,
deployment/failure-domain, and authorization semantics of this
document. Their review and contributions do not imply endorsement of
every design choice in this specification.
17. Implementation Status
The published -03 revision adds explicit CONFIG/EXEC trusted-
authority decision binding, deterministic authorization-error/retry
semantics, bounded evidence-backed resolution of previously
indeterminate operations, and separate audit-persistence reporting.
Existing implementation experience predates these additions; no
implementation-conformance claim is made for them.
This section records implementation experience and will be removed
before RFC publication. Earlier Python AgMS work exercised SAMP
envelopes, discovery, query, events, subscriptions, configuration,
Efstathiou Expires 29 April 2027 [Page 113]
Internet-Draft SAMP October 2026
authentication, replay handling, and disabled-by-default execution.
Framework adapters provide development experience across
heterogeneous frameworks.
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.
18. References
18.1. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997, <https://www.rfc-editor.org/rfc/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002,
<https://www.rfc-editor.org/rfc/rfc3339>.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, September
2011, <https://www.rfc-editor.org/rfc/rfc6234>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, December 2011,
<https://www.rfc-editor.org/rfc/rfc6455>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
[RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, July 2026,
<https://www.rfc-editor.org/rfc/rfc9846>.
Efstathiou Expires 29 April 2027 [Page 114]
Internet-Draft SAMP October 2026
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
[RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP
Semantics", STD 97, RFC 9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, May 2024,
<https://www.rfc-editor.org/rfc/rfc9562>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
18.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, <https://www.rfc-editor.org/rfc/rfc3411>.
[RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations
for the Simple Network Management Protocol (SNMP)",
RFC 3416, December 2002,
<https://www.rfc-editor.org/rfc/rfc3416>.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", RFC 2578, April 1999,
<https://www.rfc-editor.org/rfc/rfc2578>.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
RFC 2579, April 1999,
<https://www.rfc-editor.org/rfc/rfc2579>.
[RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Conformance Statements for SMIv2",
RFC 2580, April 1999,
<https://www.rfc-editor.org/rfc/rfc2580>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, June 2011,
<https://www.rfc-editor.org/rfc/rfc6241>.
Efstathiou Expires 29 April 2027 [Page 115]
Internet-Draft SAMP October 2026
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, August 2016,
<https://www.rfc-editor.org/rfc/rfc7950>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", RFC 8126,
June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.
[OPAMP] OpenTelemetry SIG, "Open Agent Management Protocol
(OpAMP)", <https://opentelemetry.io/docs/specs/opamp/>.
[MCP] Anthropic, "Model Context Protocol",
<https://modelcontextprotocol.io/>.
[A2A] Linux Foundation, "Agent-to-Agent Protocol",
<https://a2a-protocol.org/>.
[CCS] Wang, G., "Correctover Conformance Shape (CCS): Runtime
Verification for AI Agent Tool Calls", Work in Progress,
Internet-Draft, draft-correctover-ccs-10, 7 October 2026,
<https://datatracker.ietf.org/doc/draft-correctover-
ccs/10/>.
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;
Efstathiou Expires 29 April 2027 [Page 116]
Internet-Draft SAMP October 2026
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.
Revision -03 (historical) added a mandatory CONFIG/EXEC
authorization-context contract with final PEP verification of a
trusted authority decision bound to the exact action, authenticated
Manager, actor, Agent enrollment and policy context. It defines
deterministic authorization-error and retry behavior, bounded late
resolution of indeterminate outcomes using effect-evidence profiles,
peer-visible audit_persistence state, and explicit lockstep/
compatibility requirements for -02/-03 consequential operations while
protocol/profile version remains experimental 0.1.
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.2.
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.2 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.
Efstathiou Expires 29 April 2027 [Page 117]
Internet-Draft SAMP October 2026
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",
"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]]
Efstathiou Expires 29 April 2027 [Page 118]
Internet-Draft SAMP October 2026
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
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
Efstathiou Expires 29 April 2027 [Page 119]
Internet-Draft SAMP October 2026
[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"
[[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.
Efstathiou Expires 29 April 2027 [Page 120]
Internet-Draft SAMP October 2026
+=============+================+====================+
| trust_state | liveness_state | enforcement_status |
+=============+================+====================+
| quarantined | offline | requested |
+-------------+----------------+--------------------+
Table 15: 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.13.1).
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.2", "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"
}
Efstathiou Expires 29 April 2027 [Page 121]
Internet-Draft SAMP October 2026
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.10 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.11. 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.
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.2.
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
Efstathiou Expires 29 April 2027 [Page 122]
Internet-Draft SAMP October 2026
Appendix G. Changes from -03
Clarified that immutable announced profile snapshots and mutable
QUERY/PUSH operational readings have distinct lifecycles; retained
the complete authenticated profile digest and ordering semantics.
Added optional explicit supported_extensions metadata, constrained to
versioned identifiers and Manager recognition, without creating
custom PDUs or negotiated critical extensions.
Defined record_revision on CONFIG/EXEC outcome records and preserved
append-only state revisions when late resolution or audit repair
changes known state.
Clarified latest-committed-record retrieval fencing, transient null-
response precedence, CONFIG per-field late-resolution consistency,
historical evidence validation at original time, and effect_time
dependency on accompanying runtime_evidence.
Updated the normative TLS 1.3 reference from RFC 8446 to RFC 9846
without changing the declared preference for TLS 1.3 over optional
TLS 1.2 compatibility.
Added optional issuer-attested effect_time interval semantics and
explicit safeguards against fabricated ordering across incomparable
clock domains.
Clarified source/scope/provenance of optional telemetry, shared-
resource accounting, Agent relationships, and uncertainty in PUSH/
QUERY observations.
Added security and conformance considerations for new metadata and
recorded-state semantics; core PDU set and transport mapping remain
unchanged.
Changed SAMP envelope protocol version to 0.2 while retaining the
separate base profile-format version 0.1. Defined strict 0.2 peer-
version handling and no automatic mixed-version consequential
operation interoperability.
Added receiver-side revision rollback/conflict handling, decision-to-
revision audit binding, evidence issuer/time validation, and optional
informational extension_publisher. Clarified optional CCS evidence
binding without core dependency.
Efstathiou Expires 29 April 2027 [Page 123]
Internet-Draft SAMP October 2026
Appendix H. Candidate Extensions for Further Interoperability Study
(Non-Normative)
Task and usage observability: optional versioned profiles for task
identity, lifecycle transitions, structured model/token usage, deltas
versus cumulative counters, accounting epochs and correction
provenance. Standardizing these requires source-verified
implementation evidence and complete schemas; this document
introduces no mandatory task or token category.
Shared resources: standardized Agent-to-resource binding, opaque
resource identity, provider/account quota scopes, shared rate-limit
buckets and per-Agent consumption attribution. No resource
scheduler, billing contract, inferred per-Agent quota or credentials
are specified here.
Cloud/proxy-managed Agents: investigate an optional profile or future
base-profile revision for managed logical Agent identities whose
external workloads do not expose required system.uptime,
system.version or system.last_seen. The existing mandatory core
fields have not been relaxed in this revision.
Agent portability and identity continuity: investigate runtime-
incarnation and provenance bindings across framework migration, with
separately evaluated trust and enrollment continuity. No memory
transport, framework state transfer or migration operation is
standardized here.
External identity/delegation and authority fencing: investigate
versioned bindings to independent workload identity and delegated-
authority systems, including issuer, scope, lease and monotonic
fencing generation. Neither a distributed lock manager nor an IAM
protocol is introduced. A final effect boundary must enforce stale-
generation rejection for fencing to be effective.
Durable event history and reconciliation: investigate source epoch
and monotonic stream sequence, retained history cursors, explicit
gaps and loss, bounded retrieval, and, only if required, durable
acknowledgement. Core QUERY is not expanded into a generic event-log
retrieval operation in this revision.
These topics are exploratory and are not protocol capabilities
implied by the optional support advertisement. An implementation is
not intended to claim standardized interoperability for a candidate
profile until its actual versioned specification and validation
contract exist.
Efstathiou Expires 29 April 2027 [Page 124]
Internet-Draft SAMP October 2026
Author's Address
Stelios E. Efstathiou
Independent
Email: ietf@samp-protocol.org
Efstathiou Expires 29 April 2027 [Page 125]