OfflineCreator MCP credential incident response

Contain a suspected MCP credential leak first

Treat a possibly exposed OfflineCreator credential as usable by someone else until you have contained it. Stop the affected MCP client or automation so it cannot create more requests, record the time and client involved, and then revoke the credential. OfflineCreator's current product page says OAuth connections can be revoked from Settings and that a fallback API key should be revoked immediately if it may have leaked. The Privacy Policy separately says Settings can revoke one personal API key or all personal API keys.

Choose the narrowest containment action that removes the suspected access. Revoke the single OAuth connection when one client grant is implicated. Revoke one personal key when its identity is known; use the documented revoke-all control when you cannot isolate which personal key escaped. Do not merely delete a token from a local configuration: RFC 7009 distinguishes server-side revocation from local deletion and says a revocation request invalidates the token, subject to possible propagation delay and the authorization server's cascading policy.

First

Pause the affected clientPrevent new tool calls while preserving the minimum timeline needed for investigation.

Then

Revoke the implicated grant or keyUse Settings for the documented OAuth and personal-key controls.

Escalate

Revoke all personal keys if attribution is uncertainContain the known personal-key surface before issuing replacements.

Use a production incident order that preserves evidence

Run the response as detect, respond, and recover rather than jumping straight from suspicion to a replacement key. NIST SP 800-61 Revision 3 places analysis, containment, eradication, recovery, reporting, and communication across those functions. It also describes incident handlers as collecting and analyzing data and evidence, prioritizing actions, limiting damage, finding root causes, and restoring operations.

For this credential scenario, capture non-secret facts before changing the environment: when exposure may have started, where the credential was configured, which client or repository could read it, and which OfflineCreator account was involved. Never paste the suspected token into a ticket or incident note. After revocation, remove the leaked value from the original storage location, check whether repository history, build logs, chat transcripts, or client logs need separate remediation, and record each containment action with its timestamp.

Detect

Bound the time, client, account, and possible exposure pathPreserve useful evidence without copying the credential.

Respond

Pause, revoke, remove, and investigateContain access before rotating or reconnecting.

Recover

Issue only the access still required and verify itDocument the recovery check and the remaining uncertainty.

Match containment to OAuth or personal API keys

An OAuth connection and a personal API key are different incident units. OfflineCreator recommends remote OAuth and says it avoids storing an API key in the client file. Its live authorization-server metadata advertises authorization-code and refresh-token grants, a revocation endpoint, S256 PKCE, and models, read, and generate scopes. The MCP authorization security considerations warn that a stolen token can produce requests that look legitimate to a resource server, which is why local deletion alone is not containment. The metadata proves only what the server advertises; this research pass did not test whether revocation immediately invalidates every related access and refresh token.

For a personal-key incident, the Privacy Policy says the secret is shown once and retained as a one-way hash with a display prefix, scopes, and last-used timestamps. A replacement is therefore a newly issued secret, not a request to recover the old plaintext. Keep the replacement only in the client's secret configuration, grant no more capability than the workflow needs, and do not reconnect until the original exposure path has been removed.

OAuth connection

Revoke the affected connectionReconnect through browser authorization only after the client environment is trusted.

Known personal key

Revoke that key and issue a new oneDo not reuse or attempt to recover the exposed secret.

Unknown personal key

Use revoke-all, then rebuild deliberatelyExpect every dependent personal-key client to require new configuration.

Investigate with the logs that actually exist

OfflineCreator's Privacy Policy describes sampled API request logs containing the route, status code, key identifier, and a truncated one-way hash of the network address. It says personal-key secrets are not written to application logs and sampled security and audit logs may be retained for up to 12 months. These are useful boundaries, but sampled metadata is not a complete forensic record and the public policy does not prove that every application log path excludes every prompt, media value, or error body.

Compare the suspected exposure window with whatever account and client-side observations are available. Look for routes, status patterns, key identifiers, timestamps, or job identifiers you do not recognize, while avoiding sensitive prompt or media bodies in the incident record. If the evidence suggests unauthorized generations, an account takeover, or a server-side problem, contact OfflineCreator support and provide the non-secret timeline. Do not send the compromised key.

Useful metadata

Route, status, key identifier, and time-correlated client evidenceUse identifiers to build a timeline without duplicating secrets.

Known limitation

Request logging is sampledA missing entry does not establish that no request occurred.

Retention ceiling

Up to 12 months for sampled security and audit logsAvailability for a particular request is not guaranteed.

Continue with revocation or the broader security review

Use the revocation guide for control-by-control follow-up, then return to the security directory to reassess scopes, transport, client storage, and data handling. The content-moderation page is the next narrow route when the incident involves suspicious generation requests rather than credential storage alone.

Evidence limits for this incident runbook

The documented containment surface is credential-level: OAuth-connection revocation and individual or all-personal-key revocation. No retrieved public primary source documents a global user-facing switch that disables the public OfflineCreator MCP service, so this page does not instruct readers to use one. It also does not claim that revoking one OAuth token necessarily invalidates every related token; RFC 7009 makes cascading behavior dependent on server policy, and the public product sources do not describe OfflineCreator's policy.

Recent community evidence is insufficient. The 2026-08-09 last30days v3.18.4 run returned 54 items with zero OfflineCreator-specific relevant records. Reddit ended partial after HTTP 429, Instagram failed with HTTP 404, arXiv was rate-limited, and X was not configured, while GitHub and Hacker News completed with no results. Those failures do not show that communities were quiet. No community anecdote is used for product behavior, customer impact, or incident frequency, and this research pass did not perform a live credential leak, penetration test, or end-to-end post-revocation token test.