Skip to content

Attachment messages

Do not add an attachment shortcut that bypasses the capability gate, exact attachment-channel allowlist, canonical directory roots, pinned bot identity, complete permission evidence, bounded stable file read, process-keyed byte planning, signed interactive confirmation, write-aware client approval, final fresh-plan match, shared interaction limiter, atomic one-shot operation-key reservation, pending activity journaling, single multipart POST, or exact message readback. If a client cannot support MCP elicitation, keep attachment execution unavailable in that client.

Keep the surface local-file-only and single-file. Never accept remote URLs, data URLs, base64 payloads, arbitrary byte fields, directories, multiple files, or a runtime-configurable Discord origin. Reject path escapes, symlinks, hardlinks, foreign-owned files, non-regular files, empty files, files above the configured byte ceiling, any file identity, metadata, or path change across a read, and runtimes that cannot prove numeric process ownership. Read the bounded bytes into memory before reservation and upload only that reviewed snapshot.

Require an exact channel or thread entry even when its parent is allowlisted. Require complete VIEW_CHANNEL, READ_MESSAGE_HISTORY, ATTACH_FILES, and applicable send-permission evidence. Keep all mentions suppressed unless exact visible user mentions and reply-author notification have each passed the existing notification allowlist. Never enable role, @everyone, or @here notification through this workflow.

Exclude the raw operation key from plan material, signed request state, records, results, and errors while binding its domain-separated hash into the plan. Keep the MCP execute tool non-idempotent. A reserved key remains spent after every outcome, including known failure, uncertainty, or local recording failure. Neither the REST client nor any wrapper may automatically retry the multipart POST, and the connector must not delete a sent message as compensation.

Never persist the local path, filename, description, file metadata, file size, byte digest, message content, notification user IDs, attachment URL, multipart body, or raw Discord response. Attachment activity and operation records may contain only exact guild, channel, reply, and message IDs, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category.

Canonical source: SECURITY.md

Documentation generated for guildcontrol@0.0.0. Canonical source and edit history remain in the public repository. GuildControl is an independent project and is not affiliated with or endorsed by Discord Inc. Discord is used only to identify the platform that GuildControl connects to.