Credential guard

Credential guard removes strong password and key matches before a chat message or comment is stored, edited, indexed or relayed. It covers web, mobile, API, MCP and bot writes, using one shared detector. Known key prefixes, labelled values and strong standalone password shapes trigger; ordinary project names, ticket IDs, hashes, URLs, file paths and code identifiers do not.

The sender receives a private card: “That looked like a password or key, so GoodQA removed it. Change or revoke it where it came from. Use this secure form instead.” A secure request lasts seven days. At most five requests are created per person per organization per rolling hour; further messages are still redacted. Retrying or editing the same source does not create another request. For bot writes, the card belongs to the human key owner.

Fulfil uses the existing masked vault form and session-only security rules. In a direct conversation with a persona, that persona can be the requesting principal. Other conversations use a request addressed to the sender themselves; this does not grant a conversation participant access to a credential. If vault requests are unavailable, redaction still works and the notice asks for revocation; secretRequestId is null.

Successful guarded writes add credentialGuard: {redacted: true, secretRequestId} to their API response. Web and mobile composers offer a warning before sending. The server remains authoritative. The org status endpoint is GET /v1/orgs/{orgId}/credential-guard; owners and admins also get the total guardedMessages, without content.

The platform rollout setting chat.credentialGuard defaults false. The org entitlement of the same name defaults true and is a kill switch after rollout. No settings are enabled by this change. Encrypted message ciphertext, vault values and fulfil requests retain their existing security model. This feature does not retroactively erase historical content.

See the design and secret requests.

• API reference: guarded chat/comment responses and org status in /v1/openapi.json.
• MCP tools: existing message/comment writers return the guard receipt; see the MCP tool reference.
• Runbook: secret incident response; rollout and org kill switch are described in the design.

Organization-free support threads and notes to self are outside this org-scoped rollout: existing secret requests require an organization, while those surfaces deliberately follow personal tenancy. A personal secure-request design is required before covering them; no personal/support tenancy or vault security rule is changed here.