Security

Keep social credentials inside the publishing system.

People, AI tools, and API clients use OpenPost access that you can remove. Social account keys stay encrypted inside OpenPost. If you self-host, you must secure the server, keys, backups, and social apps.

Read the security policy Report a vulnerability Review managed-service access

Controls in the product

Credentials, sessions, and access are protected separately.

A database leak, a stolen browser, and a leaked API key are different risks. OpenPost gives you a separate way to limit each one.

Social account keys

OpenPost encrypts access tokens, refresh tokens, TOTP secrets, and saved social app secrets with AES-256-GCM.

Inspect code

Passwords and sign-in

Passwords are hashed with bcrypt. Users can add TOTP or passkeys and review or revoke active browser sessions.

Inspect code

Browser sessions

Signed sessions expire after seven days, are tracked server-side, and use HttpOnly cookies with Secure and SameSite=Lax protections on HTTPS.

Inspect code

API and tool access

OpenPost stores API, CLI, and MCP tokens as hashes. You can remove them or limit them to one workspace. MCP tools can use read-only mcp:read or full mcp:full access.

Inspect code

Read and write access

mcp:read blocks all changes. mcp:full uses query_operation for reads and execute_operation for changes or calls to outside services.

Inspect code

Automation access

Know what each access level allows.

OpenPost keeps social account keys apart from tool access. A full-access token can still make changes.

The client receives an OpenPost token

It does not receive the X, Meta, LinkedIn, Mastodon, Bluesky, TikTok, or Google credential stored for a connected account.

Start with read-only mcp:read

It can find tools and read workspace data. It cannot make changes.

mcp:full can make changes

A tool with full access can create, change, schedule, or publish through execute_operation. Give it only to tools you trust.

You choose when to review

Review drafts in the web app before scheduling. OpenPost does not add a separate approval step for every tool that can make changes.

Control and responsibility matrix

Managed and self-hosted deployments divide work differently.

The application provides product controls. The managed operator runs the hosted environment. A self-hosted operator replaces that managed boundary. Customers and selected providers still control their own accounts, devices, and services. Current managed locations, providers, and human access are listed in the trust register. This matrix was reviewed 9 August 2026.

Security controls and responsibilities for managed and self-hosted OpenPost deployments
Control	Application	Managed service	Self-hosted operator	Customer or provider
Identity, sessions, roles, and workspace access Inspect auth.go Inspect service.go Inspect service.go Inspect auth.go	Hashes passwords, supports TOTP and passkeys, records revocable browser sessions, and enforces organization, workspace, scope, and action checks.	Configures hosted identity options, preserves the break-glass administrator boundary, and responds to verified account or access incidents.	Chooses identity providers and administrator accounts, protects recovery access, reviews members and sessions, and removes access promptly.	Users protect their sign-in methods and devices. A selected identity provider controls its own authentication and account-recovery process.
Social credentials and application secrets Inspect encrypt.go Inspect service.go Inspect config.go Inspect managed-service.json	Encrypts stored social tokens, TOTP secrets, OIDC client secrets, and saved provider-app secrets with AES-256-GCM; API-family bearer tokens are stored as hashes.	Supplies and protects the encryption key and hosted provider credentials outside the image and repository and limits production access to the disclosed operator boundary.	Generates, stores, rotates, backs up, and restricts the encryption key, JWT secret, social app credentials, and email or storage credentials.	Users revoke connections or access tokens they no longer need. Social and identity providers protect and can revoke their provider-side credentials.
TLS, host, database, media, and network boundary Inspect auth.go Inspect config.go Inspect production-checklist.md Inspect managed-service.json	Uses secure cookie attributes on HTTPS, validates trusted origins and redirect targets, and accesses database and media through configured service boundaries.	Terminates public TLS, keeps direct host and database access inside the disclosed operator boundary, and configures the current managed data locations and providers.	Places OpenPost behind correctly configured TLS, restricts database and media access, patches the host and reverse proxy, and chooses where data is stored.	Hosting, network, storage, and social providers secure the infrastructure and endpoints they control under their own terms.
Human production access Inspect auth.go Inspect managed-service.json	Enforces authenticated role and workspace checks. Submitting a support request does not change the user's application authorization.	Uses the named key-only operator and sudo boundary described in the trust register. Routine application work is automated; exceptional access is limited to the stated support, recovery, security, abuse, legal, or fraud purpose.	Defines who can reach the host, database, media, logs, and backups; applies least privilege; reviews keys; and records access at the level its risk requires.	Customers choose workspace members and roles. Infrastructure providers control their own privileged-access programs.
Backups, restore, retention, and deletion Inspect account_lifecycle.go Inspect service.go Inspect backups.md Inspect managed-service.json	Provides scoped deletion flows and durable media-cleanup jobs while protecting active publication, library, favorite, tag, template, and brand references.	Makes the disclosed daily database and media recovery copies, prunes routine recovery history after 14 days, and performs the stated restore drill.	Chooses backup location and retention, protects required secrets with the backup, tests restoration, and fulfills deletion obligations for its installation.	Customers resolve shared ownership and active billing blockers before account deletion and control provider-side content separately.
Dependency, release, and vulnerability checks Inspect security-check.sh Inspect release.mjs Inspect ci.yml Inspect release.yml Inspect SECURITY.md	Pins supported toolchains and dependencies and includes formatting, lint, test, race, vulnerability, secret, workflow, browser, image, and restart-smoke gates in the release process.	Deploys an immutable image only after the release workflow succeeds and verifies readiness and the exact running revision, with rollback when readiness fails.	Tracks supported releases, evaluates security notices, updates the application and host, and verifies its own deployment and rollback path.	Dependency and infrastructure providers publish fixes for the components they maintain; customers report suspected vulnerabilities privately.
Operational logs, health, and monitoring Inspect routes.go Inspect service.go Inspect service.go Inspect logs.md Inspect managed-service.json	Emits service and authentication events, exposes readiness and version endpoints, and keeps provider responses and secrets out of normalized analytics and communication records.	Uses size-bounded system and service journals and public readiness and revision checks. It does not claim a complete command-level operator audit trail.	Chooses log access, retention, alerts, and monitoring and must avoid collecting secrets or more customer content than its operating need requires.	Infrastructure and social providers keep separate logs under their own controls; customers review their account and provider activity where available.
Vulnerability and incident response Inspect SECURITY.md Inspect models.go Inspect admin.go Inspect managed-service.json	Provides a private security contact and keeps durable state needed to investigate failed jobs, authentication, and provider writes without intentionally storing reusable plaintext tokens in those records.	Triages private reports, contains and repairs confirmed incidents, preserves only necessary evidence, notifies affected customers or authorities when required, and maintains the public incident wording on this page.	Owns detection, containment, evidence, recovery, notifications, and post-incident work for its installation and coordinates with OpenPost when a product flaw is involved.	Report suspected OpenPost flaws privately, rotate exposed credentials, follow incident instructions, and contact the relevant provider when the event is provider-side.
Social networks, subprocessors, and user-requested services Inspect adapter.go Inspect openrouter.go Inspect managed-service.json	Routes user-authorized provider actions through capability-specific adapters; automatic image captions use a generated thumbnail and bounded context.	Publishes reviewed data-location, provider, transfer, and human-access facts and updates the register before a new service receives managed customer data.	Chooses and configures its hosting, email, storage, AI, analytics, social apps, and optional services and publishes disclosures required for its users.	Customers choose social, identity, stock-media, and AI-triggering actions. Each selected provider controls its service, API, logs, and provider-side data.

Incident history

Read an empty register carefully.

OpenPost currently has no incident entries in this public register. This means no incident has been disclosed here; it is not a guarantee that no security or privacy event has ever occurred.

When the operator confirms a material managed-service incident, OpenPost will add the date, affected service and data, customer action, and remediation status when disclosure is lawful and does not increase risk.

Self-host securely

Use TLS and keep the application port behind a reverse proxy.
Store strong JWT and encryption secrets outside the image and repository.
Back up the database, media, and required secrets; test the restore.
Install current releases and dependency fixes.

Report privately

Do not open a public issue for a vulnerability. Email the maintainer with the affected version, reproduction steps, impact, and any suggested fix.

openpost+security@rgo.pt

Scanned before release

Before release, OpenPost checks Go and JavaScript packages for known security issues. A passing check lowers known risk, but it is not a security certification.

Inspect the release check