Contribute
Ways to contribute technical reviews, operational use cases, security analysis, experimental implementations and interoperability testing to SAMP.
Contribute to SAMP
The Simple Agent Management Protocol is an open technical proposal intended to be reviewed, challenged, implemented and improved through practical experience.
Contributions are welcome from protocol designers, AI-agent framework developers, operators, security engineers, researchers, vendors, integrators and independent implementers.
SAMP is currently an individual 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:
- technical review of the Internet-Draft;
- identification of overlap with existing or emerging protocols;
- operational-management use cases;
- security and threat-model analysis;
- proposed protocol corrections or simplifications;
- experimental Manager and Agent implementations;
- adapters for existing AI-agent frameworks;
- positive and negative protocol test cases;
- interoperability testing;
- implementation reports;
- and documented deployment experience.
Critical review is particularly valuable during the Experimental stage. A contribution does not need to endorse SAMP to be useful.
Review the Internet-Draft
The current specification is:
https://datatracker.ietf.org/doc/draft-efstathiou-samp-agent-management/
Simple Agent Management Protocol (SAMP)
draft-efstathiou-samp-agent-management-00
When submitting comments, please identify:
- the draft revision being reviewed;
- the relevant section or protocol element;
- the technical issue or ambiguity;
- the expected operational or security impact;
- and, where practical, a proposed correction or alternative.
A proposed solution is helpful but not required. Clearly documented problems, counterexamples and deployment constraints are valuable contributions on their own.
Priority Review Areas
Review of the initial draft is particularly welcome in the following areas:
- whether the proposed management-plane scope represents a genuine protocol gap;
- boundaries and overlap with A2A, MCP, OpAMP and related work;
- Manager and Agent role definitions;
- discovery and enrollment behavior;
- agent identity and profile structure;
- lifecycle and trust-state transitions;
- autonomy classification;
- request and response semantics;
- event delivery and subscriptions;
- authentication and authorization;
- key management;
- replay detection and retry behavior;
- safe configuration;
- policy-gated execution;
- extensibility;
- error handling;
- and operational deployment scenarios.
Public Technical Discussion
Public technical discussion should take place through the relevant IETF mailing lists whenever possible. This keeps discussions open, archived and available to the broader technical community.
The initial SAMP discussion is intended for the IETF agent2agent mailing list:
Mailing-list address:
Subscription:
https://mailman3.ietf.org/mailman3/lists/agent2agent.ietf.org/
Public archive:
https://mailarchive.ietf.org/arch/browse/agent2agent/
Before posting, participants should review the purpose of the list and the applicable IETF participation policies.
Messages sent to IETF mailing lists are public and are treated as contributions to IETF work under the applicable IETF rules and policies.
IETF Note Well:
https://www.ietf.org/about/note-well/
Direct Technical Contact
Technical comments may also be sent directly to:
Direct email is useful for initial coordination or when a contributor is unsure where an issue belongs.
Where appropriate and with the contributor's agreement, technical matters may subsequently be summarized or discussed through a public technical channel.
Direct email should not be used to create a private substitute for open protocol review.
Security Reports
Potential vulnerabilities involving an implementation, unpublished exploit details, credentials or information that could create immediate operational risk should not initially be posted to a public mailing list.
Send security-sensitive reports to:
A security report should include, where possible:
- the affected draft or implementation version;
- the affected protocol operation or component;
- prerequisites for exploitation;
- expected impact;
- reproduction information;
- and any proposed mitigation.
General protocol security analysis that does not contain sensitive exploit information may be discussed publicly.
Experimental Implementations
Independent implementations are strongly encouraged.
Useful implementation work includes:
- minimal SAMP Managers;
- minimal SAMP Agent endpoints;
- framework adapters;
- profile validators;
- protocol test harnesses;
- malformed-message generators;
- replay and retry tests;
- and interoperability test environments.
Implementations should clearly identify the SAMP draft revision they target.
For the current baseline:
draft-efstathiou-samp-agent-management-00
Implementation behavior must not silently redefine the specification. Differences should be documented as implementation defects, experimental extensions, proposed corrections or unresolved interoperability issues.
No implementation should claim general SAMP conformance solely because it interoperates with its own corresponding implementation.
Framework Adapters
Adapters for existing AI-agent frameworks can help determine whether the SAMP management model applies consistently across heterogeneous environments.
An adapter contribution should document:
- the framework and version tested;
- the SAMP draft revision implemented;
- the supported SAMP operations;
- the exposed profile categories;
- trust and enrollment assumptions;
- unsupported or intentionally disabled capabilities;
- security restrictions;
- and known interoperability limitations.
Adapters should begin with restrictive defaults.
EXEC should remain disabled unless the implementation provides explicit authorization, policy enforcement and audit controls suitable for the deployment.
Interoperability Testing
Interoperability testing should involve independently developed components whenever possible.
Testing should include both successful and unsuccessful protocol exchanges, including:
- valid discovery and enrollment;
- liveness and profile queries;
- event delivery;
- invalid authentication;
- modified or malformed messages;
- replay attempts;
- duplicate requests;
- stale timestamps;
- unsupported operations;
- unauthorized configuration;
- trust-state enforcement;
- version mismatches;
- and attempts to invoke disabled execution.
Test results should identify the exact implementation versions, draft revision, environment and relevant configuration.
Public Repositories
Public source repositories, contribution guidelines, issue templates and interoperability artifacts will be linked from this Page when they are ready for independent use.
Until a public repository is announced, do not assume that repositories with similar names are official SAMP project resources.
Official repositories will be referenced from:
and from this Page.
Contribution Handling
SAMP is currently maintained as an individual Internet-Draft.
There is no SAMP IETF Working Group, formal membership programme or claim of IETF consensus.
Technical feedback may result in:
- clarification of the website documentation;
- tracked implementation issues;
- proposed changes to a future Internet-Draft revision;
- additional security considerations;
- new test cases;
- or documented reasons for retaining the current design.
Acknowledgment of a contribution does not imply endorsement of SAMP by the contributor or the contributor's employer.
Similarly, participation in discussion does not imply adoption or endorsement by the IETF.
Authoritative Source
The published Internet-Draft remains the authoritative source for normative SAMP protocol requirements.
Website content, implementation notes, examples, test artifacts and adapters are explanatory or experimental unless explicitly incorporated into a future published revision of the Internet-Draft.
If any website material appears inconsistent with the current Internet-Draft, the Internet-Draft takes precedence.
General Contact
General project enquiries:
Technical and IETF-related communication:
Security-sensitive reports: