Guild integrations

Keep guild integration inventory behind its own audit toggle and exact guild allowlist. The allowlist must remain a subset of any configured read-guild scope. Require pinned application and bot identities, an exact guild and owner, exact connector membership, complete bounded role evidence, a strict bounded integration response, and effective guild-level MANAGE_GUILD before returning an inventory or plan.

Project each Discord integration immediately to exact integration, role, application, and associated bot IDs; normalized type; bounded lifecycle and synchronization properties; recognized OAuth scope names; count-only unknown scopes and fields; and an explicit privacy contract. Never return integration, external account, application, user, or bot names or profiles, external account IDs, descriptions, icon hashes, raw payloads, or unknown field values. Preserve a future integration type as unknown for audit and never infer its semantics.

Discord's integration endpoint has a hard maximum and no pagination. Mark a response at that boundary as incomplete and prohibit every deletion from an incomplete inventory. Reject responses above the bound, duplicate identities, malformed timestamps or fields, unsorted or duplicate normalized scopes, and any evidence that cannot support one canonical privacy-safe snapshot.

Keep deletion behind a second capability gate plus exact guild and integration allowlists. Do not add an immediate-call path. Keep guild_subscription integrations audit-only. Fail closed when any inventory entry has an unknown type, OAuth scope, or field because privacy-discarded evidence cannot be reviewed safely. Protect the connector's own application and bot identities and every configured protected associated bot.

Discord deletion removes associated webhooks and can kick an associated bot, while the API does not expose the exact affected webhook set. Require explicit acknowledgment of webhook removal for every request and a separate bot-kick acknowledgment whenever the target names an associated bot. Verify that bot's exact current membership without member enumeration. Acknowledgments record informed intent but must never weaken identity, scope, permission, freshness, approval, reservation, activity, coordination, or readback requirements.

Bind the exact normalized request, one-shot key hash, pinned identities, guild owner, connector member and roles, complete permission evidence, full projected integration inventory, target, associated-bot membership, privacy projection, acknowledgments, and warnings into the process-keyed plan. Rebuild the complete plan before signed interactive confirmation and immediately before mutation. A client without MCP elicitation must not execute integration deletion.

After durable coordination, atomically reserve the operation key and append pending content-free activity before one non-retried DELETE carrying the reviewed audit reason. Claim the exact integration, guild integration collection, guild webhook collection, and associated bot member when present. Fetch a complete fresh inventory after the write and report completion only when the target is absent and every non-target projection is unchanged. Discord supplies no conditional deletion primitive, so treat the final inventory-to-delete interval as an unavoidable external race and require an exclusive administration window for high-risk changes.

A known Discord client refusal other than request timeout or rate limiting may settle as failed. Treat transport failure, rate limiting, server failure, malformed evidence, incomplete or drifting readback, or any otherwise indeterminate post-reservation state as uncertain and potentially completed. Spend every reserved key, retain durable claims and the process-local same-guild quarantine after uncertainty, and never retry, reinstall a bot, recreate a webhook, or compensate automatically.

Integration-deletion activity and operation records may contain only exact guild, integration, target application, and associated bot IDs, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Never persist names, external account identities, profiles, descriptions, icon hashes, audit reasons, raw operation keys, unknown OAuth values, raw responses, permission evidence, or transport causes. Mark integration list and deletion REST operations content-sensitive so response bodies and external error details cannot enter diagnostics.

Canonical source: SECURITY.md