Guild audit logs

Keep Discord guild audit history in the separate read-only audit-logs toolset and inside the existing exact guild allowlist. Do not add a broader guild scan, member enumeration, or Gateway cache. Every page must remain bounded, use an exact before-entry cursor, request only one lookahead entry, and validate unique IDs, descending order, cursor direction, and exact actor and action filters. Exact lookup must use the predecessor cursor and validate the returned entry ID so a neighboring audit entry can never stand in for a missing one.

Treat the entire Discord response as untrusted evidence. Validate its shape and bounds before returning any projection. Preserve unknown future numeric action types without guessing a name. Derive timestamps locally from audit-entry snowflakes rather than trusting content fields. Reject malformed reason Unicode and contradictory remote filter or ordering evidence.

Return structural summaries only. Never return change values, option values, embedded users, webhooks, integrations, threads, application commands, scheduled events, AutoMod rules, or other embedded objects. Audit target identifiers are polymorphic and can contain invite codes; return a target only when it is a valid snowflake and explicitly mark every other non-null target as redacted. Reflect only bounded conservative change and option keys, and disclose how many keys were omitted.

Reasons remain opt-in Discord content. Omit them by default and make the selected tier explicit in every result. Never persist, cache, journal, log, or export an audit response, reason, structural key, target, actor, filter, or result. Observability may record only the fixed MCP and REST operation names with aggregate outcomes and durations. Keep Discord's retained server history distinct from the connector's local content-free write activity.

Canonical source: SECURITY.md