Static rich-embed messages

Do not add an immediate rich-embed call or a path around the independent capability, exact embed-message channel or thread allowlist, pinned identities, confirmed Message Content intent, complete channel and thread evidence, process-keyed planning, signed interactive confirmation, write-aware host approval, final fresh-plan match, shared interaction limiter, durable exact-target coordination, atomic request-bound one-shot reservation, pending content-free activity, one non-retried mutation, or exact response and fresh readback. Keep execution unavailable when the client cannot support MCP elicitation. Interaction scope and the Components V2 workflow grant no substitute authority.

Accept only optional bounded plain content without HTTP URLs plus 1 through 10 static embeds containing title, description, integer color, explicit-offset timestamp, author label, footer text, and ordered bounded fields. Enforce every per-field limit, the per-embed field limit, the 6,000-character aggregate embed limit, and the canonical presentation byte limit before Discord access. Reject HTTP URLs in plain content so the required EMBED_LINKS permission cannot add an unreviewed automatic link embed. Never accept raw Discord embed JSON, an embed URL field, author or footer icon URL, image, thumbnail, video, provider, attachment, caller-selected type, unknown field, remote asset, data URL, base64 payload, or reusable content-bearing template. Embed text may contain ordinary Discord markdown links; show them in the exact review, treat them as untrusted presentation, and never fetch them through the connector.

Require every target channel or active unlocked thread to have its own exact embed-message scope entry. Verify the application, bot, guild, connector member, complete bounded roles, channel and parent identity, overwrites, private-thread membership where applicable, and complete VIEW_CHANNEL, READ_MESSAGE_HISTORY, EMBED_LINKS, plus applicable send permission evidence. Keep all notifications suppressed unless each exact user is locally authorized and visibly mentioned in the optional plain content. An embed-text mention may remain visible but must never authorize notification. Never enable role, @everyone, or @here notification. Treat reply-author notification as a separate create-only reviewed permission.

Create only a default message or exact reply with a deterministic enforced nonce. Edit only an exact unpinned default non-reply message owned by the verified bot with default flags and no webhook owner, attachment, component, sticker, poll, unsupported embed field, role mention, or mass mention. Treat editing as complete replacement of plain content and the ordered embed array. Never convert Components V2, forwarded, poll, webhook, reply, mixed-media, system, or unknown message state, and never alter identity, flags, pin state, creation timestamp, or reply state. Only an exact presentation match with empty live parsed user-mention state and an empty requested notification list is a notification-free no-op; it must bypass confirmation, coordination, reservation, activity, limiter, and mutation.

Bind the complete normalized presentation, live target state, identities, intent, independent scope, thread evidence, complete permissions, reply, notifications, privacy projection, warnings, and operation-key hash into the process-keyed plan. Each create or edit issues one non-retried mutation, validates strict response evidence, then requires a semantically exact GET readback. A known pre-response Discord 4xx other than timeout or rate limiting may be failed; transport ambiguity, rate limiting, server error, malformed evidence, mismatch, readback failure, or local completion-record failure is uncertain. Permanently spend the key and retain the exact-channel or exact-message claim after uncertainty. Never retry, compensate, restore, or delete automatically.

Derive restart-safe request verification from the active bot secret independently of the process-bound plan key. Compare the request binding and receipt target before Discord access, then revalidate exact scope, identity, intent, thread and reply evidence, notification policy, and read permissions before fetching only the receipt-bound message. Never scan history, trust a caller-selected create message ID, inspect coordination, reserve a key, append activity, or consume the limiter during verification.

Never persist plain content, embed text or layouts, notification or parsed-mention IDs, mention profiles, URLs, nonce, raw payloads, raw operation key, or transport cause. Rich-embed activity and operation records may contain only exact guild, channel, optional reply, and resulting message IDs, action, request and plan digests, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category.

Canonical source: SECURITY.md