Credentials are encrypted at rest
If you connect your own email provider, the API key is encrypted with an authenticated cipher before it is written, and decrypted only in memory at the moment a message is sent. It is never returned to the browser after you save it. API keys you issue for the Inkhost API are stored as hashes, shown once at creation, and revocable.
Untrusted content is sanitized
Post bodies are sanitized before they are stored and again before they are rendered. Custom header and footer markup captured from your site or uploaded as a bundle is sanitized too, and then mounted inside a shadow root so its styles and scripts cannot reach into the rest of the page.
Uploaded bundles are extracted with guards against path traversal and decompression bombs, and their assets are rehosted rather than linked from wherever they came from.
Outbound requests are constrained
Several features fetch a URL you supply: favicon lookup, header capture, the business brief. Every one of those goes through a guard that rejects private, loopback, link-local and metadata-service addresses, so a supplied URL cannot be used to reach inside our network. Redirects to such addresses are rejected too.
Inbound webhooks are verified
Delivery, bounce and complaint events from our email provider are signature-verified before they are acted on, so a forged request cannot add addresses to a suppression list or falsify engagement figures.
Integration access is scoped and logged
Connecting an AI client goes through an OAuth consent screen that names what is being authorized. Every change made through that integration is written to an audit log with the actor and the action, and calls are rate limited. API keys are scoped to a single blog and can be revoked without affecting the others.
Reader privacy is a security property
Blogs carry no third-party analytics or advertising tags. View counting uses a salted daily hash with no cookie and no persistent identifier, so there is no reader database to breach in the first place. See the privacy policy.
Infrastructure
The application runs on Vercel. The database, authentication and file storage run on a Supabase instance we operate. Traffic is served over TLS throughout. Sign-in redirects are validated against an allowlist so an authentication link cannot be used to bounce someone to an attacker’s site.
What we do not claim
Being straight about this is more useful than a badge wall. Inkhost has not been through a SOC 2 or ISO 27001 audit and does not currently offer single sign-on, hardware key enforcement, or a contractual uptime guarantee. There is no bug bounty programme with cash rewards.
If your procurement process requires any of those, talk to us before you commit to building on Inkhost.
Reporting a vulnerability
Email security@inkhost.app with enough detail to reproduce the issue. We will acknowledge within three business days and keep you updated while we work on it.
Please give us a reasonable window to fix an issue before disclosing it publicly, and while testing do not access or modify data belonging to anyone else, degrade the service for other users, or run automated scans that amount to a denial of service. Research carried out in that spirit is welcome and we will not pursue you for it.