Implementations

SAMP version 0.1 is intended to provide a concrete baseline for experimental implementations, framework adapters and independent interoperability testing.

Implementation work is currently at an early experimental stage. No implementation is presented as production-ready, independently validated or formally conformant.

The objective is to test whether the protocol model can be implemented consistently across heterogeneous AI-agent environments and to use implementation experience to improve subsequent revisions of the Internet-Draft.

Current Status

The initial implementation programme is focused on a minimal proof of concept.

The first objective is not to implement every optional capability. It is to validate the core management relationship between a SAMP Manager and a managed SAMP Agent.

The initial proof of concept will prioritize:

• agent discovery and identification;
• liveness and health checking;
• profile and state queries;
• agent-to-manager operational event delivery;
• request and response correlation;
• authentication and message integrity;
• replay-detection behavior;
• and explicit rejection of unsupported or unauthorized operations.

CONFIG will initially be restricted to explicitly permitted, low-risk configuration fields.

EXEC will remain disabled and rejected by default.

Reference Implementation Model

The planned reference environment consists of the following logical components:

SAMP Manager

A minimal management-side implementation capable of:

• discovering and enrolling SAMP Agents;
• maintaining agent identity and trust state;
• sending management requests;
• validating responses;
• receiving agent events;
• recording protocol exchanges;
• and enforcing operation-level policy.

SAMP Agent

A minimal managed endpoint capable of:

• responding to discovery and liveness requests;
• exposing a constrained SAMP Profile;
• returning selected operational state;
• sending controlled operational events;
• validating authenticated management requests;
• and rejecting unsupported, unauthorized or policy-disabled operations.

Framework Adapters

Adapters will allow existing AI-agent frameworks to expose a SAMP-compatible management interface without requiring their internal architecture to be redesigned.

An adapter is expected to translate between:

• framework-specific identity and SAMP identity;
• framework health information and SAMP health fields;
• framework capabilities and SAMP Profile categories;
• framework events and SAMP PUSH or subscription semantics;
• and explicitly supported configuration or operational controls.

Adapter behavior must not expose credentials, unrestricted memory content, hidden prompts or sensitive implementation details merely because a corresponding SAMP Profile category exists.

Initial Validation Sequence

The first implementation sequence is expected to proceed incrementally.

Phase 1: Discovery and Identity

Validate:

• DISCOVER exchanges;
• agent identity fields;
• enrollment behavior;
• initial trust-state handling;
• malformed-request rejection;
• and discovery rate limiting.

Phase 2: Reachability and State

Validate:

• PING behavior;
• health and liveness reporting;
• QUERY operations;
• profile validation;
• request and response correlation;
• and timestamp and sequence processing.

Phase 3: Operational Events

Validate:

• PUSH operations;
• event categorization;
• subscription and unsubscription behavior;
• event ordering;
• and handling of unavailable subscribers.

Phase 4: Controlled Configuration

Validate a restricted CONFIG profile using explicitly permitted, non-sensitive configuration fields.

Unknown, unsupported, unauthorized or unsafe configuration requests must be rejected.

Phase 5: Interoperability Testing

Test independent Manager and Agent implementations against the same draft revision.

Interoperability testing should examine both successful exchanges and negative behavior, including:

• invalid authentication;
• modified messages;
• replay attempts;
• duplicate requests;
• stale timestamps;
• malformed profiles;
• unsupported operations;
• unauthorized configuration;
• and attempts to invoke disabled execution.

EXEC is outside the initial proof-of-concept success path and remains disabled by default.

Version Identification

Every experimental implementation should identify the specific SAMP draft revision against which it was developed.

For the current baseline:

draft-efstathiou-samp-agent-management-00

Implementation behavior must not silently replace or redefine normative requirements from the corresponding Internet-Draft.

If implementation behavior differs from the draft, the difference should be documented as one of the following:

• an implementation defect;
• an experimental extension;
• a proposed protocol correction;
• or an unresolved interoperability issue.

Conformance and Interoperability

A successful local test does not establish general SAMP conformance.

Similarly, an implementation produced by the author of the Internet-Draft does not define the protocol independently of the published specification.

Meaningful interoperability requires separately developed implementations to exchange valid SAMP messages and apply the same protocol requirements consistently.

Testing should include:

• positive protocol exchanges;
• negative and malformed inputs;
• security-policy enforcement;
• version mismatch behavior;
• and operational failure scenarios.

Independent implementation experience is particularly valuable because it can identify hidden assumptions in the specification.

Security Defaults

Experimental implementations should begin with restrictive defaults:

• authenticated management operations;
• TLS-protected communication;
• minimal profile disclosure;
• explicit configuration allowlists;
• rate limiting;
• replay protection;
• structured audit records;
• no implicit trust after discovery;
• and EXEC disabled.

A proof of concept must not weaken these defaults merely to simplify a demonstration.

Source Code and Repositories

Public source repositories, implementation instructions and test artifacts will be linked from this Page when they are ready for independent use.

The absence of a public repository does not indicate protocol maturity or interoperability.

No repository should be treated as an authoritative substitute for the Internet-Draft.

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

Participation

Implementers are invited to contribute:

• independent Manager or Agent implementations;
• adapters for existing agent frameworks;
• operational use cases;
• protocol test cases;
• negative and adversarial test scenarios;
• interoperability reports;
• and documented implementation differences.

Technical contact:

[email protected]

Security-related implementation findings:

[email protected]

Important Notice

SAMP version 0.1 is Experimental.

No current implementation should be assumed to be production-ready, independently certified, secure for unrestricted deployment or endorsed by the IETF.