Security

CMS credentials

• CMS tokens and passwords are encrypted with AES-256-GCM (a fresh random IV per value, authenticated so tampering is detected) before they are stored. The key is held in the server environment, separate from the database.
• Credentials are decrypted only on the server, only to make a call to your CMS. They are never sent to agents, browsers or logs.
• WordPress one-click connect replaces the Application Password that passed through your browser with a fresh one and deletes the original straight away.
• Every connection is checked for write access when added and re-tested hourly.

Agent access

• Agents never hold your CMS credentials, only a Lyntcast agent key or an OAuth token. Both are stored as SHA-256 hashes and can be revoked instantly.
• OAuth follows the MCP authorization spec and OAuth 2.1: PKCE with S256 only, resource indicators, 1-hour access tokens, rotating 30-day refresh tokens with replay detection, and token revocation.
• Rate limits per agent, daily change and delete limits, an emergency stop for all agents, and automatic pause on unusual bursts or repeated rejections.
• Rules block injected scripts, event handlers, hidden text, unknown iframes and obfuscated code, which is how prompt-injected agents usually do harm.

Accounts and sessions

• Passwords are hashed with scrypt and a per-user salt. Session tokens are random and stored only as hashes; the cookie is HttpOnly, Secure and SameSite=Lax.
• Roles (owner, admin, reviewer, viewer) limit who can approve, change rules or manage connections. Two-factor sign-in is being added.

Tamper-evident audit log

Every proposal, decision, write, undo and setting change is appended to an audit log in which each entry includes the hash of the previous one. Changing or removing an entry breaks the chain, and the built-in integrity check reports where. Admins can export the full log with its integrity result.

Network protections

• SSRF protection: every server-side request to an address you provide (and every redirect hop) must resolve to a public IP. Loopback, private, link-local, CGNAT and multicast ranges are refused, so a connection setting can’t make Lyntcast call internal services.
• Webhook URLs carry a per-site secret compared in constant time.
• Pages are served with X-Frame-Options: DENY, X-Content-Type-Options: nosniff and a strict referrer policy. Content previews render in a sandboxed frame with no scripts.
• All traffic is served over HTTPS.

AI processing

Most rules are deterministic and run on Lyntcast’s servers. Only ai_policy rules send content to an AI model, and then only the proposed change, through the Vercel AI Gateway. See subprocessors.

Infrastructure

The hosted service runs on Vercel with a Neon Postgres database. Data is encrypted in transit (TLS) and at rest by our providers. You can also self-host Lyntcast and hold the encryption key yourself.

What Lyntcast can’t protect

Lyntcast governs changes that go through it, plus what the WordPress plugin and webhooks can see. It cannot stop an attacker who can run code on your server or who uses a CMS token you gave out directly. Keep your CMS, plugins and themes updated, limit who holds CMS tokens, and use strong passwords.

Reporting a vulnerability

Email hello@lyntcast.com with details and steps to reproduce. We will acknowledge within 3 business days, keep you informed, and credit you if you wish. Please don’t access other customers’ data or degrade the service while testing.