Contribute to SAMP

The Simple Agent Management Protocol (SAMP) is an open technical proposal for managing heterogeneous AI agents through a lightweight, vendor-neutral management plane.

The project welcomes independent technical review, criticism, experimental implementations, interoperability testing, and documented operational experience.

SAMP is intended to evolve through engineering evidence and open technical discussion, not through assumptions about its suitability or adoption.

Contributions are welcome from protocol designers, network and security engineers, AI-agent framework developers, infrastructure operators, researchers, vendors, integrators, and independent implementers.

Current baseline: SAMP version 0.2, defined in draft-efstathiou-samp-agent-management-04, published on 26 October 2026.

SAMP remains an individual Experimental Internet-Draft. It has not been adopted by an IETF Working Group and is not endorsed by the IETF.

How to Contribute

Useful contributions include:

• Independent technical review of the current Internet-Draft.
• Identification of overlap or potential integration with existing protocols.
• Operational management use cases from real AI-agent deployments.
• Security analysis, threat modeling, and adversarial testing.
• Protocol corrections, simplifications, or alternative designs.
• Independent SAMP Manager and Agent implementations.
• Adapters for existing AI-agent frameworks and runtimes.
• Positive and negative conformance test cases.
• Interoperability experiments between independently developed components.
• Runtime-evidence and authorization interoperability research.
• Failure-injection testing and recovery analysis.
• Documented implementation and deployment experience.

Critical review is particularly valuable.

A contribution does not need to endorse SAMP or agree with its architectural decisions.

A well-documented counterexample, conflicting requirement, security weakness, or demonstration that an existing protocol already addresses a proposed SAMP capability may be as valuable as a new implementation.

Review the Internet-Draft

The current specification is:

Simple Agent Management Protocol (SAMP)

• Protocol version: 0.2
• Internet-Draft: draft-efstathiou-samp-agent-management-04
• Published: 26 October 2026
• Intended status: Experimental
• Submission: Individual Internet-Draft

Current revision:

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

Internet-Draft landing page:

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

When submitting technical feedback, please identify:

• The Internet-Draft revision being reviewed.
• The relevant section, PDU, field, or protocol requirement.
• The identified issue, ambiguity, or conflicting assumption.
• The expected operational, interoperability, or security impact.
• A proposed correction or alternative, where practical.

A proposed solution is helpful but not required.

Clearly documented problems and negative test results are welcome contributions.

Priority Review Areas

SAMP version 0.2 introduces substantial refinements to protocol authorization, operational evidence, consequential execution, and recovery semantics.

The following areas are particularly important for independent review.

1. Management-Plane Scope and Protocol Boundaries

• Whether SAMP addresses an operational management requirement not adequately covered by existing protocols.
• Functional overlap with SNMP, NETCONF/YANG, OpAMP, OpenTelemetry, MCP, A2A, ACP, and related work.
• Opportunities for composition or reuse rather than protocol duplication.
• Separation of management, orchestration, agent communication, and tool invocation.
• Scope limitations and opportunities for simplification.

2. Discovery, Enrollment, and Trust

• Agent identity and enrollment assumptions.
• Authenticated DISCOVER processing.
• Profile revision and sequence ordering.
• Credential-to-enrollment binding.
• Registry poisoning and stale-announcement protection.
• Trust-state transitions and revocation.
• Separation of trust and liveness.
• Recovery after Manager restart, failover, or loss of ordering state.

3. Authorization and Consequential Operations

• Authorization binding to an exact CONFIG or EXEC request.
• Validation of authorization authority and decision references.
• Interaction between Manager policy and endpoint-local enforcement.
• Approval, delegation, and authorization-expiration handling.
• Deterministic authorization of actions originating from conversational interfaces.
• Prevention of unauthorized or repeated consequential execution.
• Fail-closed behavior when authorization services are unavailable.

4. Execution Outcomes and Recovery

• Request correlation, digest binding, and replay protection.
• Duplicate CONFIG and EXEC requests.
• Lost responses and uncertain execution outcomes.
• Persistent operation identity.
• Authoritative record_revision ordering.
• Rollback and conflicting-outcome detection.
• Reconciliation after restart or failover.
• Late resolution of indeterminate outcomes.
• Preservation of audit history and recorded execution facts.

A particularly important question is whether an implementation can safely recover from uncertainty without inventing an execution result or accidentally repeating an external effect.

5. Runtime Evidence and Operational Assurance

• Evidence provenance, freshness, and correlation.
• Distinction between runtime verification and externally observable execution effects.
• Independent verification and enforcement boundaries.
• Effect-time evidence and clock uncertainty.
• Delayed, contradictory, or historical evidence.
• Evidence retention and audit consistency.
• Optional integration with external verification mechanisms.

6. Deployment Models and Failure Domains

• Embedded, sidecar, supervisor, gateway, and infrastructure deployment models.
• Management endpoint availability during managed-workload failure.
• Cooperative versus independently enforceable operations.
• Evidence delivery when the managed agent becomes unavailable.
• Quarantine requests versus confirmed isolation.
• Failure-domain and enforcement-capability declarations.

7. Profiles, Extensions, and Interoperability

• Profile and field declaration consistency.
• Capability and extension advertisement.
• Observation provenance and shared-resource accounting.
• Protocol version compatibility.
• Closed authorization and execution schemas.
• Unknown or unsupported extension handling.
• Explicit separation of core requirements from optional interoperability profiles.

These priorities are not exhaustive. Review of any part of the specification is welcome.

Public Technical Discussion

Open technical discussion is encouraged through the appropriate IETF mailing lists.

SAMP technical discussion and development updates currently take place on 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/

The earlier SAMP discussion took place on the [email protected] mailing list.

On 4 September 2026, the author announced that subsequent SAMP discussion would continue through DMSC.

When posting, please use a descriptive subject such as:

[SAMP] Review of draft-efstathiou-samp-agent-management-04

Participants should review the mailing list's scope and applicable IETF participation rules before posting.

Discussion of SAMP on an IETF mailing list does not constitute IETF adoption, Working Group consensus, or endorsement.

IETF Note Well

Participation in IETF activities is subject to applicable IETF policies, including those addressing intellectual property rights, contribution procedures, and public technical discussion.

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

IETF mailing-list messages are publicly archived and may constitute contributions under the applicable IETF rules.

Direct Technical Contact

Technical comments may also be sent directly to:

[email protected]

Direct contact is appropriate for initial coordination, questions about the specification, implementation discussions, or determining the appropriate public forum.

Where suitable, technical matters may subsequently be discussed publicly, with appropriate consideration for contributor consent and sensitive information.

Direct correspondence is not intended to replace open protocol review.

Security Reports

Potential vulnerabilities involving SAMP implementations, sensitive exploit details, credentials, or information presenting immediate operational risk should not initially be disclosed through a public mailing list.

Security-sensitive reports may be sent to:

[email protected]

A useful report should include, where possible:

• The affected Internet-Draft or implementation revision.
• The affected protocol operation or component.
• Required conditions or prerequisites.
• Potential confidentiality, integrity, availability, or authorization impact.
• Reproduction information.
• Possible mitigations or containment measures.

Reports involving consequential execution, authorization bypass, replay, evidence forgery, or incorrect enforcement outcomes are particularly relevant.

General protocol security analysis that does not expose sensitive operational information may be discussed publicly.

Experimental Implementations

Independent SAMP implementations are strongly encouraged.

Useful experimental projects include:

• Minimal SAMP Managers.
• Minimal SAMP Agent endpoints.
• Framework-independent management adapters.
• Profile and message validators.
• HMAC and canonicalization test harnesses.
• Enrollment and trust-state test environments.
• Configuration and execution policy evaluators.
• Authorization-context validation tests.
• Replay, duplicate-request, and retry testing.
• Recorded-outcome reconciliation tests.
• Runtime-evidence verification adapters.
• Failure-injection and interoperability test environments.

Implementations should identify the exact protocol revision they target.

Current baseline:

draft-efstathiou-samp-agent-management-04

Protocol envelope version:

0.2

The base profile-format version remains separately defined as 0.1. It must not be confused with protocol-envelope compatibility.

SAMP version 0.2 introduces consequential-operation outcome requirements that are not automatically wire-compatible with earlier experimental protocol versions.

Implementations must not silently reinterpret earlier CONFIG/EXEC requests as conforming to SAMP 0.2.

Any compatibility bridge or experimental extension should be explicitly documented.

Implementation behavior must not silently redefine the specification.

Differences should be identified as implementation defects, experimental extensions, proposed protocol corrections, or unresolved interoperability issues.

An implementation must not claim general SAMP conformance solely because it interoperates with its own corresponding Manager or Agent implementation.

Framework Adapters

Adapters can help determine whether SAMP's management model works consistently across heterogeneous AI-agent frameworks and runtime environments.

An adapter contribution should document:

• The framework and version being integrated.
• The targeted SAMP Internet-Draft revision.
• The supported SAMP operations.
• The declared profile fields and capabilities.
• The endpoint deployment model.
• Trust and enrollment assumptions.
• Management endpoint and workload failure-domain relationships.
• Supported authorization and enforcement mechanisms.
• Unsupported or intentionally disabled operations.
• Known security and interoperability limitations.

Adapters should use restrictive defaults.

CONFIG and EXEC must remain subject to their declared policies and applicable authorization requirements.

EXEC is disabled by default and must not be exposed without explicit provisioning and suitable enforcement controls.

An adapter's ability to communicate with a runtime does not automatically establish independent authority to isolate, terminate, restart, or control that runtime.

Interoperability Testing

Independent interoperability testing is a central objective of SAMP's Experimental development.

Where possible, tests should involve independently developed implementations rather than multiple components sharing the same codebase.

Testing should include both valid and invalid protocol exchanges.

Discovery and Lifecycle

• Valid and invalid DISCOVER exchanges.
• Enrollment and trust-state transitions.
• Authenticated profile reannouncement.
• Stale or conflicting profile revisions.
• Profile-sequence recovery and rollback resistance.
• Trust and liveness independence.

Authentication and Message Validation

• Valid and invalid HMAC authentication.
• Canonicalization consistency.
• Modified or malformed message payloads.
• Timestamp validation.
• Replay and duplicate-request handling.
• Unsupported protocol versions.
• Unknown or malformed extensions.

Configuration and Execution

• Authorized and unauthorized CONFIG requests.
• Disabled or unsupported EXEC operations.
• Invalid or expired authorization decisions.
• Approval and delegation failures.
• Request-digest or target mismatches.
• Endpoint-local policy denial.
• Duplicate consequential requests.
• Lost responses and indeterminate execution.
• Recorded-outcome revision ordering and conflict detection.

Runtime Evidence and Failure Handling

• Missing, stale, or contradictory evidence.
• Evidence issuer and subject validation.
• Late resolution of uncertain outcomes.
• Clock uncertainty and effect-time provenance.
• Managed workload failure.
• Management endpoint failure.
• Quarantine enforcement failure or uncertainty.
• Recovery without unintended re-execution.

Test reports should identify the exact draft revision, implementation versions, relevant configuration, deployment topology, and observed results.

Negative results and unresolved differences should be documented rather than hidden.

Interoperability with External Protocols

SAMP is intended to coexist with other protocols and security mechanisms without introducing unnecessary mandatory dependencies.

The project welcomes technical exploration of optional interoperability with external mechanisms for runtime verification, authorization, evidence exchange, and operational observability.

Two areas of particular interest are:

SAMP and Correctover Conformance Shape (CCS)

Potential interoperability work may investigate how externally verifiable runtime evidence and receipts can be represented, transported, correlated, and evaluated within SAMP management operations.

CCS is an informative, optional evidence-verification candidate, not a required component of the SAMP core protocol.

Evidence validation must not be interpreted as proof of an external effect unless the evidence and its applicable verification profile establish that claim.

SAMP and EMILIA

Potential interoperability experiments may examine how independently verifiable, exact-action authorization mechanisms can complement SAMP's authorization-context and consequential-execution model.

Such integration must preserve SAMP's request binding, policy enforcement, replay protection, and execution-outcome safeguards.

These areas are opportunities for collaborative research and experimentation.

No completed interoperability result, formal integration, or conformance claim is implied unless supported by published technical evidence.

Public Repositories and Test Artifacts

Public repositories, implementation guidelines, test vectors, interoperability artifacts, and issue trackers will be linked when they are ready for independent use.

Until officially announced, repositories with similar names should not be assumed to represent the SAMP project.

Official project resources will be referenced from:

https://samp-protocol.org/

Independent implementers may contact the project directly to coordinate experiments or report implementation findings.

Contribution Handling

SAMP is currently maintained as an individual Internet-Draft.

There is no SAMP-specific IETF Working Group, formal membership programme, or claim of IETF consensus.

Technical feedback may lead to:

• Corrections or clarifications in website documentation.
• Implementation issues and test cases.
• Additional protocol security considerations.
• Clarification or simplification of protocol requirements.
• New interoperability experiments.
• Proposals for optional extensions.
• Changes in future Internet-Draft revisions.
• Documented reasons for retaining an existing design decision.

Contributions are evaluated on technical merit and relevance.

Acknowledgment of a contribution does not imply endorsement of SAMP by the contributor or their employer.

Participation in discussion does not imply adoption or endorsement by the IETF.

Authoritative Source

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

Website articles, architecture notes, implementation examples, experimental adapters, and interoperability reports are explanatory or experimental unless incorporated into a published revision of the Internet-Draft.

If website material conflicts with the current specification, the Internet-Draft takes precedence.

SAMP is a work in progress and may be revised based on technical review, implementation experience, and independent interoperability results.

General Contact

General project enquiries:

[email protected]

Technical and IETF-related communication:

[email protected]

Security-sensitive reports:

[email protected]

Official website:

https://samp-protocol.org/

Current Internet-Draft:

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

SAMP is developed through engineering, open review, and practical experimentation.

Independent criticism, implementation experience, and interoperability evidence are essential to determining whether the protocol provides a useful and technically sound management plane for heterogeneous AI agents.

Review the design. Challenge the assumptions. Test the protocol. Contribute to its evolution.