Your API Keys Should Not Need to Trust Us

---

The easiest onboarding flow for a social media tool is familiar: click Connect, authorize every account, and let the service keep the tokens somewhere in its cloud.

It is convenient. It also asks the user to add another company, another database, and another infrastructure stack to the list of systems they must trust with their content and publishing access.

While building WeMAIde Content Operator, we decided to take a different path.

The current Windows application uses a local-first workspace and a bring-your-own-credentials model. Content, imported knowledge, drafts, editorial states, and generated media stay on the user's computer. API keys and platform credentials are encrypted through Windows secure storage. When the user requests generation or publishing, the desktop application connects directly to the selected provider or social platform. There is no intermediary WeMAIde server receiving and retaining those credentials.

This design reduces the trust surface. It also creates friction. Users must obtain their own credentials, understand permissions, and occasionally replace an expired token.

We believe that trade-off is worth discussing honestly.

The problem is bigger than an API key field

An AI content workspace can contain much more than public posts:

• internal product facts;

• positioning and audience notes;

• unpublished announcements;

• customer-sensitive context;

• drafts that were rejected;

• a publishing calendar;

• access tokens capable of posting to company accounts.

If all of that is copied into a vendor-managed cloud, the product may be easier to access from multiple devices. But the vendor also becomes a permanent part of the security model.

That changes the question from “Is this feature useful?” to “How many systems must remain secure for this workflow to remain private?”

Our answer for the current milestone was to keep WeMAIde out of the credentials path.

The device becomes the control plane

In Content Operator 0.6.0, the local Windows application is the control plane.

The workspace database is stored in the application's local user-data directory. Generated images are saved locally. Channel credentials are kept separately from the content workspace and encrypted with Windows secure storage before they are written to disk.

The credentials are not intentionally inserted into:

• the content database;

• generated posts;

• exported content;

• the knowledge base;

• application logs.

The interface only reports whether the required credential fields are present. It does not need to display saved secrets back to the user.

This is a smaller trust boundary, not a claim of perfect security. A compromised Windows account or device can still create risk. Local-first architecture does not replace endpoint security, token rotation, least-privilege permissions, or safe backups.

It does, however, remove one unnecessary destination: our server.

Local-first does not mean offline-only

This distinction matters.

Content Operator is not an offline AI model, and we do not describe it as one. When the user asks the application to generate text or an image, the selected context is sent directly to the configured AI provider. Text generation through the OpenAI Responses API is sent with store: false.

When the user clicks Test connection or Publish now, the application contacts the selected platform directly. That platform receives the data required to perform the requested action.

So the accurate statement is:

The workspace and credentials remain local until a user requests an operation that requires an external provider.

The inaccurate statement would be:

Nothing ever leaves the device.

Privacy language should describe data flow, not hide it.

Why bring your own credentials?

BYOC—bring your own credentials—means the account owner creates or obtains access through the platform's official developer tools and enters the resulting values into the desktop application.

For example, the current connectors require different combinations:

• Telegram: a bot token and channel or chat ID;

• X: API key, API key secret, access token, and access token secret;

• Threads: a long-lived access token and user ID;

• LinkedIn: an access token and person or organization URN;

• Facebook Pages: a Page access token and Page ID;

• Instagram Professional: an access token and account ID, with additional media-hosting constraints.

This is less elegant than one universal OAuth button. But it gives the account owner direct control over the developer application, requested permissions, token lifecycle, and revocation.

It also avoids pooling credentials from many customers in one service. A central credential store is convenient operationally, but it increases the value and potential blast radius of that system.

The convenience we are giving up

We should be explicit about the cost.

A user may need to:

1. Open a platform's developer portal.

2. Create or configure an application.

3. Request the correct publishing permissions.

4. Generate tokens after those permissions are enabled.

5. Find an account, Page, channel, or organization identifier.

6. Paste the values into Content Operator.

7. Replace credentials when a platform expires or revokes them.

Every platform uses different terminology. Some permissions require review. Some APIs support text but impose extra requirements on media. A token that can read an account may still be unable to publish.

This is real onboarding friction, and calling it “simple” would not make it disappear.

Our responsibility is to make the complexity understandable: provide platform-specific instructions, validate connections before publishing, explain missing permissions, and recommend testing with a private channel or non-critical account first.

Human approval remains part of the security model

Credential storage is only one layer. Publishing behavior matters too.

The current milestone does not silently publish in the background. A draft must be reviewed, moved to the appropriate state, and sent through an explicit Publish now action. Automatic background scheduling and retry processing are deliberately not enabled yet.

That decision also costs convenience. But an access token should not automatically turn every generated draft into a public statement.

We want approval to belong to the exact version that was reviewed. If the content changes, the approval should no longer be treated as unconditional.

Current capabilities and honest limits

Content Operator 0.6.0 can test configured connections for Telegram, X, Threads, LinkedIn, Facebook Pages, and Instagram Professional accounts.

Explicit text publishing is implemented for Telegram, X, Threads, LinkedIn, and Facebook Pages. Telegram and Facebook Pages can also publish a local image. Media upload for X and LinkedIn is not enabled in the current connector. Threads and Instagram require a publicly reachable media URL for API image publishing, so local images remain in a manual workflow there. Instagram publishing itself is not enabled in this milestone.

These constraints are not hidden behind a “supports every platform” badge. A privacy-oriented architecture is only credible when its limitations are visible too.

What we are optimizing for

We are not trying to make users responsible for security and call the job finished.

We are optimizing for a different relationship:

• the user owns the provider accounts;

• the user owns the credentials;

• the user can revoke access at the source;

• the user's device stores the working context;

• WeMAIde does not need a copy of the keys;

• external data transfer happens only for an operation the user requests.

The long-term challenge is to preserve that ownership while reducing setup friction. Better guided onboarding, clearer permission checks, credential health indicators, and safer test flows can improve the experience without moving secrets into a central WeMAIde backend.

That is the direction we are testing.

The trade-off

Cloud software often optimizes for the shortest route to the first successful click. Local-first software may need to optimize for something else: the shortest route to informed control.

For Content Operator, we are currently choosing a harder first connection in exchange for a smaller trust surface.

It will not be the right choice for every team. Some will prefer a shared cloud workspace and managed OAuth. Others will accept a few extra setup steps if their unpublished content, provider keys, and publishing access do not have to live on another vendor's server.

We want to hear from both groups.

Would you accept a more technical setup to keep your publishing credentials under your control? And what would a local-first product need to do before that trade-off felt reasonable rather than inconvenient?

— Alexandr, WeMAIde

Learn more: https://wemaide.com/content-operator