How OfflineCreator MCP API keys are protected

Follow the key lifecycle from issue to revocation

Create a separate key for the MCP task, choose only the scopes it needs, and copy the secret during the one-time display. Put it directly into the MCP client's secret configuration or environment instead of a chat message, source file, command example, or URL. By default, the published package uses the Studio HTTPS origin and allows localhost development. Setting OFFLINECREATOR_ALLOW_INSECURE_API_BASE=true permits a user-selected non-loopback host, including an HTTP origin; the package limits that escape hatch to private, non-production hosts. Enabling it removes the default origin-and-transport safeguard, so an untrusted base can receive the bearer key.

For local stdio, the package reads OFFLINECREATOR_API_KEY. For the legacy remote fallback, it documents an Authorization bearer header and explicitly rejects putting the credential in a query string. When the integration is retired, the key is lost, or exposure is suspected, use Studio Settings to revoke that key. The privacy policy says users can revoke an individual key or all keys at any time; the terms instruct immediate revocation when compromise is possible.

One-way hashing is verified; HMAC is not publicly established

The current public evidence supports a narrower statement than “HMAC hashing.” OfflineCreator's privacy policy and terms repeatedly say that personal key secrets are stored only as a hash or one-way hash after creation. Neither cited page names HMAC, a digest algorithm, a server-held hashing key, a pepper, or the exact verification procedure for personal API keys. This research therefore cannot responsibly claim that the stored API-key value is specifically an HMAC.

That distinction matters in a security review. “One-way hash” describes the published storage outcome; “HMAC” would describe a particular keyed construction and would require implementation documentation or an independently inspectable artifact for API-key storage. Treat HMAC as an evidence gap for personal keys, not as a confirmed control. The supported conclusions are that plaintext is not retained after creation according to current first-party policy, the secret cannot be retrieved from the key-management view, and loss requires replacement rather than redisplay.

Verified publicly

One-time display and one-way-hash storageCurrent first-party policy states that plaintext is not retained after key creation.

Not verified publicly

HMAC algorithm and server-side key managementNo cited public source identifies the personal API-key hash construction or its operational key controls.

The documented API-key boundary, in one answer

OfflineCreator documents personal MCP API keys as recoverable only at creation: the secret is shown once, while the service retains a one-way hash rather than the plaintext. Its privacy policy also says key secrets are excluded from application logs. The account keeps non-secret operational metadata—a display prefix, assigned scopes, and last-used timestamps—so a key can be identified and managed without displaying its credential again.

The published @offlinecreator/mcp package describes the fallback key as a scoped credential. MCP tools are filtered against three named scopes: models, read, and generate. This limits what an issued key is intended to authorize, but it does not make the key safe to expose. The same package places the key in an environment variable or MCP client secret configuration, and the product's terms tell users not to share it, commit it, paste it into untrusted tools, or embed it in client-side code. Remote OAuth is the package's recommended connection path; API-key stdio and the legacy remote header fallback remain available when a static key is required.

Bearer transport protects syntax, not possession

OfflineCreator's legacy remote MCP fallback sends the static API key as an Authorization: Bearer credential. RFC 6750 defines a bearer token as a credential usable by any party that possesses it; no proof of a separate cryptographic key is required. The practical consequence is that hashing on the server does not neutralize a plaintext copy leaked from an MCP configuration, process environment, terminal transcript, support bundle, or screen share.

Keep the credential in the header and send it only to the intended HTTPS origin. OWASP's REST guidance says HTTPS protects API keys in transit and warns that credentials in URLs can be captured in web-server logs. OfflineCreator's default package configuration follows those boundaries and says never to use an api_key query parameter, but its explicit insecure-base override can allow a non-loopback HTTP destination. Do not enable that override for normal Studio use. If a bearer key leaks, containment comes from revocation and replacement, not from assuming the stored hash protects the copied client-side secret.

Choose the next review from the risk you found

Open the MCP security directory for the broader review, continue to the media-privacy page for media-delivery questions, or continue to the OAuth page for its separate authorization review. This page stays limited to personal API-key creation, storage claims, scopes, transport, handling, and revocation.

Editorial ownership and evidence boundary

This page owns the query “offlinecreator mcp api key security” by connecting one-time disclosure, documented hash storage, scope selection, bearer handling, and revocation in one review path. It does not claim an independent penetration test or production configuration audit. If public evidence cannot continue to support the API-key lifecycle—or if the HMAC implementation remains essential to the title promise—consolidate this material into /security/mcp-security instead of presenting an unverified algorithm as fact.