Skip to content

Application posture

Derive application posture only from the authenticated current-application response already required for pinned identity verification. Do not add a caller-selected application ID, application mutation, new policy gate, broader Discord scope, Gateway connection, cache, persistent file, activity record, or telemetry payload for this audit. Bind every conclusion to the freshly verified application and bot identities and to the selected connector capabilities that actually require privileged intents or Gateway Interaction delivery.

Project the response before returning it. Permit only verified IDs, booleans, fixed enums and findings, normalized known permission names, and bounded counts. Never return or persist application or bot profile text, media hashes, verification data, owner, team, guild identity, URL values, redirect targets, RPC origins, raw flags, raw permission bitfields, webhook event names, raw objects, or unknown values. Count unknown contexts, enums, scopes, permission bits, and fields without guessing their meaning. Treat malformed known evidence and unsupported bounds as errors, and treat absent or invalid authoritative flags as unknown rather than disabled.

Keep per-context installation defaults separate from legacy defaults. Report Administrator and unknown authority explicitly. Treat outgoing-webhook and Gateway Interaction delivery as mutually exclusive, require only the privileged intents selected connector capabilities need, and warn about unused Presence intent without enabling a presence workload. Findings and remediation text must come from a fixed local vocabulary, never from Discord-provided text.

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.