send.message.world
Send a message to anyone. Its effect is no: cannot be undone.
What this id is made of
This is not a string. It is send↗.message↗.world↗, three nodes joined by three edges, and each of them has an address, a page and a JSON file. Follow any of them and you get the query for that word rather than a definition of it.
| Node | Edge | Reads as |
|---|---|---|
send↗ | has_verb | this capability has the verb send |
message↗ | acts_on | this capability acts on message |
world↗ | reaches | this capability reaches world |
communication↗ | in_family | this capability is in the communication family |
no↗ | has_undo_class | this capability has the undo class no |
The gloss above is a convenience, not the definition. A node carries no inherent meaning: what
send.message.worldis emerges from the edges traceable from it. The strongest case isworld↗, where the deployment shapes that use it do not agree about what it means, and the page keeps the disagreement rather than averaging it.
In 4 of 17 published shapes
| Deployment shape | Barrier there | Known by | Whose material | Note | |
|---|---|---|---|---|---|
| ◐ | Claude, with the Gmail connector enabled (contributed by riskmandate.ai) | setting (not a control) | measured | third_party | Anthropic: "Send, reply to, and forward emails from Gmail." and "During authentication, Google's OAuth screen mentions email sending permissions... Claude can send, reply to, and forward emails, but only does so with your explicit approval by default." The directory listing names reply and forward; Google's own reference for the same server (2026-07-21) names no tool that sends - see contradictions. The credential is the grant; the approval prompt is the barrier, and by the enforcer test it is a setting - the grant includes the ability to remove it. Measured 2026-09-16: one message sent to an address the deployer named for the purpose, after "Allow once"; Claude confirmed the send and the sending address. The message as sent carries no header naming the client: no X-Mailer, no User-Agent; the Received line says "by gmailapi.google.com with HTTPREST" from a numeric sender that is the OAuth client's Google Cloud project number, and the body is signed with the account holder's name. To the recipient it is the account holder's mail (evidence/09). |
| ● | Claude, with the Gmail connector enabled (contributed by riskmandate.ai) | none (not a control) | measured | own | send_message is on Always allow: a plain message and then one with an attachment went to an external address with no prompt, and the recall attempt confirmed that a delivered message cannot be unsent. The approval prompt that would make this a setting is switched off for this tool and on for reply and forward; a row sits at its weakest route. The vault's whole recommendation is one change here: move send_message to Needs approval and leave create_draft open. |
| ○ | Claude's Microsoft 365 connector (Outlook, SharePoint, OneDrive, Teams) (contributed by riskmandate.ai) | boundary | documented | third_party | outlook_send_mail - "Send an email as the user." To any address. Listed under Write tools on the same page whose read section says the connector "provides read-only access to" its sources. |
| ○ | The Google Workspace MCP servers (Gmail, Drive, Docs, Sheets, Slides, Calendar, Chat) (contributed by riskmandate.ai) | boundary | documented | third_party | gmail.compose - "Manage drafts and send emails." The setup page advertises "create draft emails"; the scope it asks for also sends. Whether the server exposes a tool that sends is open, below. |
| Barrier | What stands in the way | Is it a control | |
|---|---|---|---|
| ● | none | nothing in the way | no |
| ◉ | expectation | a rule in prose, enforced by nobody | no |
| ◐ | setting | a switch the agent's own account can flip | no |
| ○ | boundary | enforced above the grant, out of the agent's reach | yes |
What the starting mandates say about it
| The mandate says | Which mandates |
|---|---|
| authorised | What the agent inferred it was authorised to do, from one session |
| refused | A coding assistant on my machine, Chat, with connectors switched on, Chat in the browser, nothing connected, A reader on my mailbox, Find things in the inbox, draft replies, never send, Search our tenant, read-only, An assistant over my Workspace, reading |
| unstated | A coding assistant in a container on the web, The desktop app, with local tools switched on, A CI job on a hosted runner, A browser extension I installed, A scheduled job under a service account, A reader on my drive, Find and read my files, A sandbox: build and run one AI-agent workflow |
Unstated is not authorised. A mandate that never mentioned a capability did not authorise it, and the delta on every example page counts it as excess and says which kind it was.
What would move it to the fourth barrier
| What | What it costs | The barrier afterwards |
|---|---|---|
| no mail or chat connector, or a connector that drafts and never sends | you press send | boundary |
This is a published reduction, not a recommendation. Whether it is worth doing depends on the assets and the consequences, which are not in this document and are not this site's to guess. Since v0.4.3 it is also a node,
setting/send.message.world, in the deployment shape universe↗: it narrows this capability and moves it to the barrier named in the third column, which is the path the prohibitions table's last column is a projection of.
The capability grammar↗ · This primitive as JSON↗
Site index for agents↗ · HTML version↗