Protocol

Simple Agent Management Protocol

The Simple Agent Management Protocol (SAMP) defines a lightweight, vendor-neutral management plane for heterogeneous AI agents.

SAMP provides a common operational interface through which management systems can discover agents, establish and maintain their trust state, observe operational health, inspect capabilities, receive events, apply controlled configuration, and invoke explicitly exposed operations under policy control.

Inspired by network management principles such as those used in SNMP, SAMP extends operational management into environments where AI agents may differ in framework, model provider, deployment architecture, execution capabilities, and management authority.

SAMP version 0.2, defined in draft-efstathiou-samp-agent-management-04, is an Experimental protocol intended for controlled environments, technical evaluation, implementation experience, and independent interoperability testing.

SAMP is not an agent-to-agent communication protocol, a tool-use protocol, or an AI agent framework.

Its purpose is to provide a consistent management plane for AI agents as operational entities.

Overview

Modern AI-agent environments increasingly combine autonomous and semi-autonomous systems built using different frameworks, models, tools, and execution environments.

Protocols addressing agent communication, collaboration, and tool access provide important interoperability capabilities. However, those capabilities do not eliminate the operational need to manage, monitor, authorize, and control agents throughout their lifecycle.

SAMP addresses this requirement through two principal roles:

• SAMP Manager: The management authority responsible for agent registration, trust decisions, operational monitoring, policy evaluation, event handling, and management control.
• SAMP Agent: The logical protocol endpoint exposing a SAMP-compatible management interface for an AI agent or its associated runtime.

The protocol establishes a management relationship between these roles without prescribing the internal implementation of the managed AI agent.

SAMP does not define how an agent reasons, plans, stores memory, chooses tools, or collaborates with other agents.

It defines how that agent can be managed within an operational environment.

Architecture

A SAMP deployment consists of one or more Managers and one or more managed SAMP Agents.

The architecture separates management authority from the internal reasoning and execution mechanisms of the managed agent.

A managed endpoint may expose SAMP through different deployment models:

• Embedded: The management interface operates within the managed agent's process.
• Sidecar: A separate management component operates alongside the agent.
• Supervisor: An external component observes or controls the managed process.
• Gateway: An AI Agent Gateway provides a management interface for one or more managed agents.
• Infrastructure: An independent infrastructure-control component implements the SAMP endpoint.

These deployment models do not provide identical operational or security guarantees.

An embedded endpoint may become unavailable when its managed process fails. An independently enforceable component outside the managed workload's failure domain may provide stronger guarantees for monitoring, isolation, restart, termination, and evidence delivery.

SAMP explicitly distinguishes deployment topology from enforcement capability.

The presence of a sidecar, supervisor, or gateway does not automatically prove that it can survive a particular failure or independently enforce a management decision.

Deployment metadata can describe these boundaries so that management systems do not assume guarantees that the underlying architecture cannot provide.

Protocol Operations

SAMP version 0.2 defines eight core Protocol Data Unit (PDU) types.

Each operation has a defined direction, exchange pattern, and associated validation requirements.

DISCOVER

Agent to Manager

Allows a SAMP Agent to announce its identity, endpoint, capabilities, and profile to a Manager.

DISCOVER supports initial registration, enrollment, and subsequent authenticated profile announcements.

Profile revisions and sequence ordering protect the Manager's registry against stale or conflicting announcements.

Discovery alone does not establish trust or authorize management operations.

PING

Agent to Manager

Provides an agent-initiated heartbeat used by the Manager to assess endpoint reachability.

PING contributes to liveness monitoring but does not independently establish trust, workload health, or successful execution of an agent task.

QUERY

Manager to Agent

Retrieves selected operational values from declared profile categories and fields.

QUERY provides structured access to exposed state without requiring unrestricted access to the agent's internal memory, reasoning process, or implementation details.

PUSH

Agent to Manager

Delivers asynchronous operational events, notifications, and supported runtime-evidence information.

PUSH messages may include event identifiers, categories, severity information, and correlation references.

SAMP v0.2 does not define a separate application-level acknowledgment PDU for PUSH. Successful HTTP transport delivery must not be interpreted as proof of durable event processing.

SUBSCRIBE

Manager to Agent

Creates a time-bounded subscription to selected event categories or event types.

Subscriptions use explicit identifiers, expiration times, and authorization controls.

UNSUBSCRIBE

Manager to Agent

Terminates an existing event subscription.

Subscription ownership and lifecycle operations are subject to authenticated management relationships.

CONFIG

Manager to Agent

Requests changes to explicitly declared and writable configuration fields.

CONFIG requires typed field validation, local policy enforcement, and authorization bound to the requested operation.

A Manager cannot modify arbitrary internal agent state simply because the agent exposes a SAMP interface.

EXEC

Manager to Agent

Requests execution of an explicitly exposed and allow-listed operation.

EXEC is disabled by default and requires explicit local provisioning.

Execution requests use declared command schemas and typed parameters, together with authorization and policy controls.

Arbitrary shell commands and unrestricted natural-language execution are not part of the core EXEC model.

A trusted Manager does not automatically possess execution authority.

Every consequential CONFIG or EXEC request must satisfy the applicable admission and authorization requirements.

Agent Profiles

A SAMP Profile describes the identity, manageable characteristics, declared capabilities, and management policies of an agent.

SAMP version 0.2 defines a structured profile model containing required identity metadata and declared operational fields.

Required identity information includes the agent identifier, name, software version, agent type, profile version, profile revision, profile sequence, and management autonomy classification.

The mandatory system category exposes a minimal operational model, including:

• system.status
• system.uptime
• system.version
• system.last_seen

Additional declared categories and fields may describe capabilities, tools, memory-related information, health observations, or other implementation-specific characteristics.

Profiles also declare supported operations and, where applicable, their configuration and execution policies.

Profile Validation and Versioning

SAMP uses explicit field declarations and typed validation.

Profile revisions identify immutable announced snapshots, while profile sequences provide ordering within an authenticated enrollment.

Operational observations obtained through QUERY or PUSH may change without requiring a new profile announcement.

However, changes to an announced profile's capabilities, policies, declarations, or other profile content require appropriate revision and sequence updates.

Observation Scope and Provenance

SAMP distinguishes observations made by the management endpoint from facts established about the managed workload.

For example, the availability of a shared runtime or connector does not necessarily establish that every agent using that runtime is healthy.

Where relevant, observations should preserve their source, subject, observation time, freshness, and resource-accounting scope.

This distinction also applies to token usage, shared quotas, provider resources, and externally hosted workloads.

Agent Lifecycle, Trust, and Liveness

SAMP treats trust and liveness as separate operational dimensions.

Trust describes the Manager's authorization and enrollment relationship with an agent. Liveness describes observed endpoint reachability.

SAMP version 0.2 defines six trust states:

• Discovered: The agent has been announced but not yet evaluated.
• Pending: The agent is awaiting a trust decision.
• Trusted: The agent has been accepted by Manager policy.
• Quarantined: The Manager has restricted the agent's management relationship pending investigation or remediation.
• Rejected: Enrollment has been refused.
• Revoked: Trust has been explicitly revoked for the current enrollment.

The protocol also defines four liveness states:

• Unknown
• Reachable
• Stale
• Offline

These dimensions remain independent.

A trusted agent may become offline without automatically losing its trusted status. Equally, an agent may remain reachable while quarantined or revoked.

Quarantine and Enforcement

A quarantine decision does not automatically establish that the agent has been successfully isolated.

SAMP separately represents the enforcement status of quarantine:

• requested
• applied
• failed
• indeterminate

Confirmation of isolation requires evidence from an authorized enforcement actor.

This distinction prevents a management interface from presenting requested containment as successfully enforced containment.

Autonomy Classes and Management Impact

SAMP retains the profile field autonomy_class, but version 0.2 uses it to describe management impact and required safeguards, rather than the cognitive autonomy of an AI model.

Four classes are defined:

• advisory: Read-only management without CONFIG or EXEC.
• operational-readonly: Observation and limited policy-controlled CONFIG, without EXEC.
• operational-write: Policy-controlled CONFIG and allow-listed typed EXEC operations.
• critical-write: Consequential management operations requiring safeguards appropriate to their operational impact.

An autonomy class does not independently grant permission.

Actual authority remains subject to the declared operation capabilities, authorization decisions, Manager policy, and endpoint enforcement.

Higher-impact operations may require stronger assurance, independent enforcement, and validated evidence before execution.

Authorization and Controlled Execution

SAMP version 0.2 establishes an explicit authorization contract for consequential CONFIG and EXEC operations.

The protocol does not define an organization's complete identity hierarchy, RBAC/ABAC policy language, approval workflows, or delegation administration.

Those responsibilities remain with the deployment's authorization infrastructure.

Instead, SAMP defines how an authorization decision is bound to a specific management request and verified before execution.

The authorization context identifies information such as:

• The trusted authorization authority and decision reference.
• The originating human or machine principal.
• The applicable policy identifier and version.
• The exact authorization-bound operation and request digest.
• The authorization expiration time.
• Approval or delegation references where required.

The final Policy Enforcement Point must verify the trusted authorization decision against the authenticated request and local state.

Manager-side authorization and endpoint-local policy are jointly restrictive.

Authentication establishes identity. It does not, by itself, establish permission to execute an operation.

Natural Language Is Not an Authorization Boundary

SAMP does not treat an unprocessed conversational instruction as a valid consequential management operation.

Systems exposing natural-language management interfaces must resolve an instruction into a deterministic, structured action before authorization and execution.

The resolved action must identify the intended target, exact operation, parameters, and applicable constraints.

This separation allows conversational interfaces to coexist with deterministic management authorization and enforcement.

Runtime Evidence and Operational Assurance

SAMP version 0.2 introduces a generic runtime-evidence representation for operational observations and consequential management outcomes.

Runtime evidence can be delivered through PUSH notifications or included in supported CONFIG/EXEC outcomes.

Evidence metadata may identify:

• The subject of the evidence.
• The evidence issuer and sender.
• The verification and enforcement actors.
• The evidence phase and policy verdict.
• The evidence format and processing status.
• Correlation and freshness information.
• Relevant verifier deployment characteristics.

Evidence may be used to support operational policy decisions, admission requirements, or subsequent reconciliation.

However, the existence of evidence does not automatically establish that an external action occurred successfully.

The evidence must support the specific claim being made.

SAMP does not prescribe a universal runtime-verification system or mandate a particular external evidence format.

Optional interoperability bindings, including those involving Correctover Conformance Shape (CCS), can be defined separately without introducing mandatory dependencies into the core protocol.

Execution Outcomes, Retries, and Failure Handling

Distributed management operations must account for timeouts, lost responses, process failures, retries, and uncertain execution results.

SAMP version 0.2 distinguishes authorization decisions from execution outcomes.

For CONFIG and EXEC, the protocol defines separate representations for:

• Policy outcome: Whether the operation was allowed, denied, or its admission decision was indeterminate.
• Execution outcome: Whether an operation was not executed, is in progress, succeeded, partially succeeded, failed, or remains indeterminate.
• Audit persistence: Whether the required audit or evidence state was durably recorded.

Consequential operation records include an operation reference and an authoritative record_revision mechanism for tracking the progression of recorded outcomes.

Retries and reconciliation are subject to authenticated request identity, digest binding, retention rules, and recorded-state safeguards.

A timeout must not be interpreted as proof that an operation failed.

Likewise, an uncertain outcome must not automatically cause an operation to be executed again.

Where supported by the required evidence contract, previously indeterminate outcomes may be resolved using validated evidence without repeating the original consequential operation.

SAMP does not promise exactly-once execution of arbitrary external effects.

Its objective is to make management decisions, execution uncertainty, and recovery behavior explicit and auditable.

Security

SAMP treats management interfaces as security-sensitive control surfaces.

The version 0.2 security model includes:

• HMAC-SHA256 message authentication.
• JSON Canonicalization Scheme (JCS), as defined in RFC 8785.
• Authenticated message integrity and request correlation.
• Timestamp validation and replay protection.
• Enrollment and credential-binding safeguards.
• Profile revision ordering and stale-announcement protection.
• Explicit authorization for consequential operations.
• Typed configuration and command validation.
• Local policy enforcement and restrictive default behavior.
• Rate limiting, back-pressure, and controlled retries.
• Runtime evidence and audit requirements.
• Failure-domain-aware enforcement.

SAMP v0.2 requires implementations to support HMAC-SHA256 authentication.

Non-localhost deployments must enable authentication and use HTTPS to protect management traffic.

HTTP is the baseline transport, while additional transport mappings may be supported where explicitly defined.

Management credentials are provisioned out of band. The core protocol does not define automatic key negotiation or rotation.

SAMP provides mechanisms for enforcing operational policy, but it does not claim to make an inherently unsafe agent safe.

Relationship to Other Protocols

SAMP addresses a management-plane responsibility that is complementary to agent communication, tool access, and observability technologies.

Agent-to-Agent Protocols: A2A and ACP

Agent communication protocols support interaction, collaboration, and task exchange between agents.

SAMP addresses the operational management relationship between a management authority and managed agents.

An agent can participate in agent-to-agent communication while independently exposing a SAMP management interface.

Model Context Protocol (MCP)

MCP provides standardized interfaces through which applications and agents access tools, resources, and contextual information.

SAMP does not replace MCP or prescribe how an agent invokes tools.

Instead, SAMP may expose management information about an agent's declared capabilities and tools without taking over the tool-use protocol.

OpenTelemetry

OpenTelemetry provides mechanisms for collecting and correlating traces, metrics, and logs.

SAMP can coexist with observability infrastructure and contribute management-specific operational information.

It does not attempt to replace existing telemetry and tracing systems.

Open Agent Management Protocol (OpAMP)

OpAMP addresses operational management of telemetry and data-collection agents, including configuration, reporting, and lifecycle-related functions.

SAMP shares certain management principles and acknowledges areas of functional overlap.

Its additional focus includes heterogeneous AI-agent enrollment, Manager-owned trust decisions, typed consequential operations, authorization-bound admission, runtime-evidence handling, and failure-domain-aware enforcement.

These distinctions are intended to be evaluated through technical review and implementation experience, not assumed to establish superiority over existing protocols.

Implementation and Interoperability

SAMP is designed for implementation across heterogeneous agent environments, either natively or through adapters, sidecars, supervisors, and gateways.

The Agent Management System (AgMS) is an experimental implementation project applying SAMP management concepts to real AI-agent environments.

AgMS is currently in Alpha development.

Its implementation experience supports evaluation of discovery, monitoring, event handling, agent integration, configuration, authentication, and operational failure scenarios.

AgMS development and internal testing must not be confused with independent interoperability certification or complete conformance to every requirement of SAMP version 0.2.

Independent implementations, protocol reviews, conformance testing, and interoperability experiments remain important goals of the project.

Current Specification

Simple Agent Management Protocol (SAMP)

• Protocol version: 0.2
• Internet-Draft: draft-efstathiou-samp-agent-management-04
• Publication date: 26 October 2026
• Intended status: Experimental
• Submission type: Individual Internet-Draft
• Author: Stelio E. Efstathiou

Official IETF Datatracker:

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

Revision 04:

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

SAMP is currently an individual Internet-Draft. It has not been adopted as an IETF standard, is not endorsed by the IETF, and has no formal standing in the IETF standards process.

Internet-Drafts are works in progress and may be revised, replaced, or withdrawn.

The published Internet-Draft remains the authoritative source for protocol requirements, message definitions, conformance rules, and security considerations.

This website provides explanatory, architectural, and project-level information intended to support technical understanding, review, implementation, and interoperability work.