Internet-Draft

SAMP Internet-Draft

The Simple Agent Management Protocol (SAMP) is documented as an individual Internet-Draft published through the Internet Engineering Task Force (IETF) Datatracker.

SAMP defines a lightweight, vendor-neutral management-plane protocol for heterogeneous AI agents, inspired by established network-management principles and designed for experimental implementation, technical review, and interoperability testing.

The specification has evolved through five published revisions, from the initial proposal in August 2026 to the current SAMP version 0.2.

Current Internet-Draft

Simple Agent Management Protocol (SAMP)

• Author: Stelio E. Efstathiou
• Document: draft-efstathiou-samp-agent-management-04
• Protocol version: 0.2
• Profile-format version: 0.1
• Published: 26 October 2026
• Expiration date: 29 April 2027
• Document status: Active Individual Internet-Draft
• Intended status: Experimental
• IETF Working Group adoption: None

Official IETF Datatracker:

Simple Agent Management Protocol (SAMP)

Current revision:

draft-efstathiou-samp-agent-management-04

HTML specification:

Read SAMP-04

The Datatracker landing page provides access to the current revision, previous revisions, available document formats, and publication history.

Status of the Document

An Internet-Draft is a working technical document intended for discussion, evaluation, and further development.

Publication as an Internet-Draft does not mean that a proposal has been adopted, approved, or endorsed by the IETF.

SAMP is currently an individual Internet-Draft, not an IETF Standard or published RFC.

Its Experimental intended status reflects the project's objective of validating the protocol through practical implementations, security review, operational testing, and interoperability experiments.

The current specification is intended primarily for controlled environments, including research facilities, private infrastructure, and operator-managed agent deployments.

Future revisions may introduce changes based on implementation experience and technical feedback.

No particular timetable for IETF Working Group adoption, standards-track progression, or RFC publication is implied.

Specification Scope

SAMP version 0.2 defines a management relationship between a SAMP Manager and one or more managed SAMP Agents.

The specification includes:

• Manager and Agent protocol roles.
• Agent discovery, enrollment, and identity management.
• Agent profiles, declarations, and capability advertisement.
• Management-impact autonomy classes.
• Independent trust and liveness state models.
• Eight core protocol operations.
• JSON-based PDU message envelopes.
• HTTP(S) transport requirements.
• HMAC-SHA256 authentication and message integrity.
• Timestamp validation and replay protection.
• Event notification and subscription semantics.
• Typed configuration and execution operations.
• Authorization-context binding for consequential operations.
• Runtime-evidence representation and validation.
• Execution outcomes, retry fencing, and recorded-state recovery.
• Endpoint deployment and failure-domain considerations.
• Conformance tiers and implementation requirements.
• Security, operational, and extensibility considerations.
• An IANA registry framework for future standardization work.

SAMP does not define an AI reasoning framework, model-selection interface, agent-to-agent communication protocol, or tool-invocation protocol.

It is intended to complement existing technologies rather than replace them.

The specification explicitly discusses its relationship with SNMP, NETCONF/YANG, OpenTelemetry, OpAMP, MCP, A2A, and related protocols.

Document Evolution

SAMP was first published as an individual Internet-Draft on 17 August 2026.

Subsequent revisions introduced refinements informed by architectural analysis, security considerations, operational failure scenarios, and implementation experience.

Revision History

Earlier revisions remain accessible for historical reference and technical comparison.

From SAMP 0.1 to SAMP 0.2

Revisions -00 through -03 developed the experimental protocol using envelope version 0.1.

Revision -04 introduced SAMP protocol-envelope version 0.2, reflecting additional requirements affecting protocol behavior and compatibility.

The base profile-format version remains separately identified as 0.1.

Internet-Draft revision numbers, protocol-envelope versions, and profile-format versions are distinct identifiers and must not be treated as interchangeable.

SAMP 0.2 does not imply automatic interoperability with older experimental consequential-operation implementations.

Implementers should follow the version-handling and compatibility requirements defined in the current Internet-Draft.

Major Developments in SAMP-04

Revision -04 strengthens the specification in several operationally important areas.

Profile Lifecycle and Operational Observations

The specification clarifies the distinction between immutable authenticated profile announcements and mutable operational observations obtained through QUERY or PUSH.

This prevents changes in runtime observations from being confused with changes in the agent's declared management profile.

Additional metadata supports observation provenance, shared-resource accounting, and agent relationships.

Recorded Execution Outcomes

SAMP-04 introduces explicit record_revision semantics for CONFIG and EXEC operation records.

These revisions support the tracking of authoritative operation-state changes, including subsequent resolution of previously uncertain outcomes.

The specification addresses conflicting records, audit consistency, and safeguards against unsafe repeated execution.

A lost response or timeout does not establish that a consequential operation was never executed.

Runtime Evidence and Verification

The specification refines runtime-evidence handling, including evidence issuer identification, freshness, correlation, and historical validation.

Optional effect-time information can support reasoning about when an externally observed operation occurred.

Evidence timing and ordering must account for clock uncertainty and the limitations of independently observed events.

The base protocol does not mandate a specific external runtime-verification system.

Authorization and Enforcement

SAMP-04 retains and refines the authorization architecture developed in revision -03.

Consequential CONFIG and EXEC requests require authorization decisions bound to the exact request and applicable policy context.

A trusted Manager does not automatically acquire unrestricted configuration or execution authority.

The final Policy Enforcement Point must enforce the applicable authorization and endpoint-local policy constraints.

Optional Protocol Extensions

Revision -04 introduces additional provisions for explicit advertisement of supported optional extensions.

Extensions must not silently redefine core operations or bypass mandatory protocol security requirements.

Optional interoperability mechanisms remain separate from the mandatory base protocol.

Protocol Versioning

The change to SAMP protocol version 0.2 establishes an explicit compatibility boundary.

SAMP 0.2 peers must apply the corresponding version and consequential-operation validation rules.

Unsupported or ambiguous compatibility must not cause an automatic downgrade to weaker authorization or execution safeguards.

Implementation and Conformance

SAMP is being evaluated through experimental software development and practical management scenarios.

The Agent Management System (AgMS) is an Alpha-stage implementation project exploring SAMP-based management of heterogeneous AI agents.

Implementation work provides feedback on protocol behavior, operational monitoring, security controls, event handling, and failure recovery.

However, implementation experience does not automatically establish complete conformance.

SAMP version 0.2 defines four additive conformance tiers:

• SAMP-Observe: PING, DISCOVER, QUERY, PUSH.
• SAMP-Subscribe: SAMP-Observe plus SUBSCRIBE and UNSUBSCRIBE.
• SAMP-Configure: SAMP-Subscribe plus CONFIG.
• SAMP-Execute: SAMP-Configure plus EXEC.

All claimed tiers remain subject to the applicable mandatory security and protocol requirements.

Conformance is assessed separately for Manager and Agent roles.

No general, independently validated SAMP 0.2 conformance claim is currently made for AgMS or its associated experimental adapters.

For further information:

SAMP Implementations

Independent Review and Interoperability

Independent technical review is essential to determining whether SAMP provides a useful and sufficiently differentiated management-plane protocol.

Areas of particular interest include:

• Management-plane boundaries and overlap with existing protocols.
• Agent discovery, enrollment, and trust semantics.
• Authentication, authorization, and policy enforcement.
• Profile validation and version compatibility.
• Runtime-evidence provenance and verification.
• Consequential CONFIG/EXEC behavior.
• Retry safety and recorded-state recovery.
• Quarantine enforcement and failure-domain assumptions.
• Negative and adversarial protocol testing.
• Independent Manager and Agent interoperability.

Both positive implementation results and documented failures are valuable.

An unsuccessful interoperability test may reveal a specification ambiguity, an undocumented assumption, or an implementation defect.

The project welcomes independent implementations and experimental integrations with complementary technologies.

Optional interoperability research involving Correctover Conformance Shape (CCS) and EMILIA is of particular interest for runtime verification and exact-action authorization respectively.

Such research does not imply that the protocols have already been formally integrated, independently validated, or jointly standardized.

Public Technical Discussion

Public SAMP technical discussion currently takes place through the DMSC mailing list.

Mailing-list address:

[email protected]

Subscription:

https://mailman3.ietf.org/mailman3/lists/dmsc.ietf.org/

Public archive:

https://mailarchive.ietf.org/arch/browse/dmsc/

Technical discussion through IETF mailing lists is public and subject to applicable IETF policies.

The use of an IETF mailing list does not imply adoption of SAMP by an IETF Working Group.

IETF Note Well

Contributors should familiarize themselves with the IETF participation and intellectual property policies.

https://www.ietf.org/about/note-well/

Technical Feedback

Technical comments, implementation findings, security observations, and interoperability proposals are welcome.

Technical correspondence:

[email protected]

Security-sensitive reports:

[email protected]

When submitting feedback, please identify the relevant Internet-Draft revision, section, observed issue, and potential impact.

For additional contribution guidelines:

Contribute to SAMP

Document Lifecycle and Expiration

Internet-Drafts are temporary working documents.

They may be updated, replaced, or withdrawn as technical work progresses.

The current SAMP-04 revision expires on 29 April 2027, unless superseded or updated through the applicable Internet-Draft publication process.

Expiration does not automatically establish rejection, technical invalidity, or the termination of a proposal.

The version-independent Datatracker URL should be used to locate the latest published revision:

https://datatracker.ietf.org/doc/draft-efstathiou-samp-agent-management/

Authoritative Source

The published Internet-Draft remains the authoritative source for SAMP protocol requirements.

Website documentation, technical articles, implementation notes, examples, and experimental interoperability materials are explanatory unless incorporated into a subsequently published Internet-Draft revision.

In the event of any inconsistency, the published Internet-Draft takes precedence.

Implementers should identify the exact revision and protocol version against which their software was developed and tested.

Important Notice

SAMP is an individual Experimental Internet-Draft.

It has not been adopted by an IETF Working Group, approved as an IETF Standard, or published as an RFC.

The specification remains subject to technical review, experimental implementation, interoperability testing, and future revision.

The objective is not merely to define a management protocol, but to evaluate whether its architecture, security model, and operational semantics can be implemented consistently across heterogeneous AI-agent environments.