Security and Key Rotation

Credential boundaries

Provider keys, server credentials, webhook secrets, and purchase details should stay out of prompts, screenshots, presentations, support messages, and public documentation. SophMate settings should be limited to trusted administrators who understand provider billing, privacy impact, and production support ownership.

Rotation workflow

Rotate provider credentials after staff changes, suspected exposure, provider account changes, agency handoffs, or security incidents. Test the new key in SophMate settings, keep old and new ownership documented, and review budget and usage controls after the change so unexpected spend does not hide in normal usage.

Incident handling

If a key may have been exposed, revoke it at the provider, pause write-capable workflows, refresh diagnostics, and open an internal incident record before changing multiple settings. Use privacy and data retention and incident response when support evidence may contain sensitive context.

Owner and cadence

• Primary owner: site administrator with provider, billing, and security responsibility.
• Review cadence: after provider, mailbox, role, budget, security, WooCommerce, or integration changes.
• Escalate when a credential may be exposed, a provider owner changed, or usage appears after a key should have been revoked.

Production checklist

• Rotate provider keys after staff changes, suspected exposure, agency handoffs, provider account changes, or security incidents.
• Re-test provider connection and review usage immediately after rotation.
• Document who owns provider credentials, budget limits, role access, notification routing, and ongoing review.
• Keep configuration changes behind administrator access and review them after plugin updates, staff changes, or incidents.

Acceptance checks

• The old key is revoked at the provider and no longer works for SophMate requests.
• The new key owner, billing owner, rotation date, and next review date are documented.
• A second administrator can explain why each high-risk setting is enabled and who may change it.
• No production credential, support mailbox, or notification path depends on an unmanaged personal account.

Common mistakes

• Pasting keys into prompts, support tickets, screenshots, or client presentations while trying to prove the issue.
• Using personal provider keys, personal mailboxes, or broad administrator access because it is faster during setup.
• Changing budgets, roles, notifications, or integrations without recording the owner and review reason.

Related operations

• Pair rotation with Connect an AI Provider.
• Use Incident Response Runbook when exposure is suspected.
• Pair configuration work with Roles and Permissions.
• Review Approval Controls before enabling write-capable modules.
• Use Cost Allocation and Client Billing Review before client or team billing reviews.
• Use Security and Key Rotation before changing provider credentials.
• Use Cache Queue and Performance before scaling automation or alerts.
• Use Scheduled Task and Cron Reliability before relying on recurring work.
• Use Provider Models and Fallbacks before changing production model behavior.
• Use Data Residency and Provider Policy Review before sending sensitive context.
• Use Provider Rate Limits and Retry Planning before high-volume automation.
• Use Source Freshness Review Calendar before teams depend on policy sources.
• Use Email Deliverability and Domain Authentication before operational mail matters.