Application linked-role metadata

Audit application role-connection metadata only for the freshly verified pinned application and bot. Accept no caller-selected application ID, bearer token, user role-connection values, guild role target, schema mutation, new configuration field, policy gate, Gateway connection, cache, persistent file, activity record, or telemetry payload. Validate verification-endpoint presence without returning or persisting its URL, then fetch the complete Discord inventory under the documented maximum of five records and a fixed response-byte ceiling.

Return only exact metadata keys, transient untrusted names and descriptions with character counts, normalized value families and comparisons for the eight documented types, localization counts, bounded unknown-field and future-type counts, fixed findings, and verified application and bot IDs. Never return localization values, user metadata values, raw payloads, unknown field values, or the verification URL. Fail closed on malformed identities, known fields, duplicate keys, Unicode, controls, bounds, payload size, or endpoint evidence.

Do not infer which guild roles use a metadata record, whether any user satisfies it, or whether Discord will grant a linked role. Treat future fields and type codes as explicitly incomplete evidence, never as permission or eligibility. Keep the tool and fixed resource private and uncached, and make the guided prompt stop after one read-only audit.

Keep schema changes behind a separate capability gate and the linked-roles toolset. Use only the verified current application's bot token; require no guild permission or privileged intent. Accept only replace with one complete non-empty canonical schema and exact application-wide replacement acknowledgement, or clear with exact clearance acknowledgement. Reject partial updates, raw Discord objects, caller-selected application IDs, empty replacement arrays, unsupported metadata types, duplicate keys, unordered localizations, unknown fields, and every guild-role or user-value operation.

Bind the freshly verified application and bot identities, verification-endpoint presence, complete transient current and desired schemas, exact ordering, complete count-only diff, schema digests, acknowledgements, risks, warnings, and domain-separated operation-key hash into the keyed plan. Require a fresh exact plan before signed interactive confirmation and again before mutation. Signed request state may contain only the action, application ID, desired-schema digest, operation-key hash, and plan digest; never place metadata keys, labels, descriptions, localization values, the verification URL, or raw keys in it.

Acquire one durable application-wide role-connection-metadata collection claim before reservation so separate connector processes cannot overlap schema replacements. Append pending content-free activity before exactly one non-retried complete-schema PUT, validate the exact complete response, and require an independent fresh exact readback. An already-current replacement or already-empty clearance is a record-free no-op. A definite pre-response Discord client refusal may fail; rate limiting, transport ambiguity, server failure, malformed or mismatched evidence, unreadable readback, or failed receipt finalization is uncertain, spends the key, retains the claim, and blocks same-application changes for operator review. Never retry, compensate, merge, restore, or roll back automatically.

Activity and operation records may retain only the exact application and bot IDs, action, record counts, reorder flag, plan and operation-key digests, timestamps, fixed status and verification values, activity ID, and sanitized error category. Never persist metadata keys, labels, descriptions, localization values, verification URLs, user role-connection values, guild-role configuration, raw requests or responses, raw operation keys, credentials, or transport causes.

Canonical source: SECURITY.md