Your API keys should not need to trust us
Why Content Operator uses local, bring-your-own credentials—even though that makes onboarding less magical.
The easiest onboarding flow for a social media product is familiar: click Connect, authorize every account and let the service keep the tokens in its cloud. It is convenient. It also adds another company, database and infrastructure stack to the systems a user must trust with publishing access.
Content Operator takes a different path. The Windows application stores its workspace locally and uses a bring-your-own-credentials model. Channel secrets are encrypted through Windows secure storage. When a user requests generation, a connection test or publication, the desktop application contacts the selected provider or platform directly.
The device is the control plane
Credentials are kept separately from the content workspace and are not intentionally inserted into generated posts, exports, the knowledge base or application logs. The interface reports whether required fields are present without displaying saved secrets back to the user.
This is a smaller trust boundary, not a promise of perfect security. A compromised device remains a risk. Local-first architecture does not replace token rotation, least-privilege permissions, endpoint security or safe backups. It removes one unnecessary destination: our server.
What bring your own credentials requires
- The account owner creates or configures an application in the platform’s official developer tools.
- They request the publishing permissions required by their account type.
- They generate the relevant token and account, Page, channel or organization identifier.
- They enter those values locally and test the connection before publishing.
- They can revoke or rotate access at the original platform.
Every network uses different terminology. Some permissions require review. Some APIs support text but impose additional requirements on media. A token that can read an account may still be unable to publish. We do not hide that complexity—we provide a platform-specific setup guide and connection test.
Current publishing coverage
The 0.6 beta can test configured connections for Telegram, X, Threads, LinkedIn, Facebook Pages and Instagram Professional. Explicit text publishing is available for Telegram, X, Threads, LinkedIn and Facebook Pages. Telegram and Facebook Pages also support a local image in the current connector. Other media paths remain manual where an API requires a public media URL or a separate upload flow.
We choose a harder first connection in exchange for a smaller permanent trust surface.
This model will not suit every team. Some will prefer managed OAuth and a shared cloud workspace. Others will accept a technical setup if their unpublished content and publishing access do not need to live on another vendor’s server. Content Operator is built for the second group.
