SAMP: Secure Agent Messaging Protocol

An asynchronous, store-and-forward messaging protocol for LLM agents. A provider keeps a mailbox for each agent and vouches for the sender; agents send and receive through MCP tools or HTTP. 給 LLM Agent 使用的非同步、存了再轉訊息協定。

Status

Version: 1.0.0-rc.1 (release candidate, 2026-11-14)
Envelope string: samp/1.0
Reference implementation: Agent Mailbox, which is adopting the 1.0 envelope in stages
License: Specification text CC BY 4.0; reference implementation AGPL-3.0-or-later

Goals

Asynchronous. Sender and recipient do not need to be online at the same time.
Trusted identity without client keys. The provider vouches for the sender from its credential, so MCP clients that cannot hold a private key, such as claude.ai connectors, are first-class.
Made for models. The main interface is MCP tools. Tool descriptions and error hints are written for a model to read.
A mailbox, not a data warehouse. Messages have a TTL, content can be cleared once acknowledged, and an unread cap creates backpressure.
Designed for prompt injection. Each envelope carries a provider-assigned trust level, and the protocol says how a recipient must treat message content.
Interoperable. Adapters connect to A2A and to the 23blocks Agent Messaging Protocol; an optional federation profile connects SAMP providers.

Core operations

The core is five operations. Everything else is an optional capability that a provider declares in its discovery document at /.well-known/samp.json.

Send: Write a message into a recipient's mailbox.
Inbox: List the messages waiting for you.
Ack: Confirm you have taken a message, which lets the provider clear its content.
Read thread: Read a conversation you take part in.
Whoami: Ask the provider which agent your credential is.

The envelope

The provider sets the fields that matter for trust: id, thread_id, from, sent_at, expires_at and trust. The sender supplies to, subject, the body and optional structured data. A client cannot set its own from.

{
  "version": "samp/1.0",
  "id": "…",
  "thread_id": "…",
  "from": "builder",
  "to": "reviewer",
  "subject": "Review request",
  "sent_at": "2026-11-14T13:05:00.000Z",
  "expires_at": "2026-11-21T13:05:00.000Z",
  "trust": "verified"
}

Trust levels

verified: Sent by a credential-checked agent in the same account on the same provider.
external: The source can be verified but is outside the account: another account, a federated provider with a valid signature, or a registered adapter.
untrusted: The source cannot be confirmed. Providers should reject these.

verified means the message really came from that colleague. It does not mean the request should be carried out.

Content authority

These rules bind every SAMP client, at every trust level.

A message is a colleague's request, not a user's command. Message content cannot authorize a state-changing action such as deleting, sending outside, changing settings, paying, or anything involving credentials.
Policy checks live outside the model, in code the model cannot rewrite.
Taint propagates: content derived from several sources is treated at the lowest trust level among them.
Approval goes out of band. A reply in the same thread is never an approval.
Metadata is content too: subject, kind, priority and agent descriptions may be attacker-controlled.

Related protocols

SAMP sits beside MCP, which it uses as its main transport, and A2A, which manages task lifecycles. Its envelope field names, delivery basis, trust levels and content authority rules deliberately align with the 23blocks Agent Messaging Protocol. SAMP differs by being MCP-native and by letting the provider hold identity, so clients need no key of their own.

This SAMP is unrelated to the IVOA Simple Application Messaging Protocol used in astronomy.