Reviewed Components V2 messages

Do not add an immediate component-message call or a path around the existing interaction toggle, exact interaction-channel 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 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.

Accept only the bounded text, separator, callback-free link-row, authenticated request-row, and one-level container DSL. Either row may appear at the top level or directly inside a container, must contain one to five buttons, and must count its row and every button toward the recursive component ceiling. Require one bounded single-line label per button and one normalized absolute HTTPS URL per link button. A request Button may select only primary, secondary, success, or danger; treat style as presentation without write or administration meaning. Never accept raw Discord component JSON, caller-selected component or custom IDs, disabled states, emojis, selects, modals, arbitrary callbacks, sections, thumbnails, media galleries, files, attachments, remote-media URL fields, data fields, base64 fields, or reusable content-bearing templates. Text Display content may contain ordinary Discord markdown links; show them in the exact review and never fetch them. Require at least one Text Display and enforce the complete recursive component, aggregate Unicode text, and canonical-byte limits locally before any Discord call. Reject every request row in one-to-one private-message workflows because native Interaction ingress is exact-guild scoped.

Keep link buttons disabled unless scopes.componentLinkOrigins contains every exact canonical HTTPS origin. Reject credentials, wildcards, paths, queries, fragments, trailing slashes, duplicates, and noncanonical spellings in the configured origins; reject surrounding whitespace, control characters, credentials, non-HTTPS schemes, malformed URLs, and oversized normalized destinations in layouts. Enforce the origin policy before any Discord request during planning and verification. Expose exact normalized destinations and unique sorted origins in transient review and bind them into the keyed request and plan digests. Never fetch a destination, resolve DNS, follow a redirect, inspect remote content, or claim that the configured first-hop origin is the final destination opened by a Discord client.

Require every target channel or thread to have its own exact interaction-scope entry. Verify the application, bot, guild, connector member, complete bounded roles, channel and parent identity, overwrites, active thread state, private-thread membership where applicable, and complete VIEW_CHANNEL, READ_MESSAGE_HISTORY, plus applicable send permission evidence. Keep all mentions suppressed unless each exact user is both locally authorized and visibly mentioned in the normalized layout. Never enable role, @everyone, or @here notification. Treat reply-author notification as a separate create-only reviewed permission.

Before planning any layout with a request row, require the target guild and exact channel in native Interaction scope, a nonempty exact user allowlist, a paired broker in ready state, freshly verified pinned application and bot identities, an unset outgoing Interaction endpoint, and exactly one contract-matching managed command from a fresh complete inventory read. Bind verified Gateway delivery, the authorized user IDs, broker phase, guild, command ID, command version, and schema into the plan digest, then repeat every fresh check and require identical readiness before execution. Generate every custom ID inside the connector from a token-derived domain-separated HMAC. Bind its route to the pinned application and bot, exact guild and channel, complete normalized layout, and operation-key hash; bind each tag to that route plus the button index, exact label, and style. Never return or persist the custom ID or route, accept caller routing input, or create a callback registry or route database. A normal restart with the same token must preserve authentication, while token rotation must invalidate every old route.

Set the irreversible Components V2 flag only during reviewed creation. Edit only an exact default already-V2 non-webhook message owned by the verified bot. Never convert a legacy message, alter its identity or reply reference, or accept a target with content, embeds, attachments, stickers, a poll, TTS state, role or mass mentions, unsupported component fields, unauthenticated request Buttons, or duplicate or invalid component IDs. Require parsed user mentions to be unique, visible in the normalized layout, and transiently reviewed. Only an exact layout and authenticated route match with empty parsed user-mention state is a notification-free no-op; it must bypass confirmation, coordination, reservation, activity, limiter, and mutation.

Bind the normalized layout and link destinations, freshly verified Gateway, identity, request-button command, and exact authorized-user evidence, live message state, intent, exact channel, link-origin, and native Interaction scope, thread evidence, complete permissions, reply, notifications, privacy projection, warnings, and operation-key hash into the process-keyed plan. Create uses a deterministic enforced nonce. Create and edit each issue one non-retried mutation, validate the strict response, then require a semantically exact GET readback after stripping only Discord-assigned numeric component IDs and authenticating every request Button. 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.

Never persist component text, normalized or raw layouts, link destinations or origins, request-button custom IDs or authenticated routes, notification or parsed-mention IDs, mention profiles, generated numeric IDs, nonce, raw payloads, raw operation key, or transport cause. Component-publication activity and operation records may contain only exact guild, channel, optional reply, and resulting message IDs, action, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category.

Canonical source: SECURITY.md