Inkury
Our security posture

Security is architecture, not a feature.

Inkury's security model is built into the editor core. Content is sanitized before it can render, traffic is encrypted in transit, and secrets are kept out of our images. Here is the real posture -- and what is still on the roadmap.

InputSanitizeSafe
Editor-core hardening

Untrusted content never reaches the DOM unchecked

Security in Inkury starts in the editor itself. All incoming content -- pasted HTML, imported Markdown, API inputs -- is converted into a structured canonical model and sanitized before it can render. Unsafe DOM writes are blocked before they execute.

  • DOMPurify-based sanitization on every import path
  • script/style/iframe/svg/form stripped by allowlist
  • A single canonical model -- no unsanitized side path
  • Server-side input validation with schema enforcement
What we guarantee today

The controls that ship in the product

We are precise about what is protected and how. Each item below is implemented today -- nothing here is aspirational.

XSS sanitization on every path

Pasted HTML, imported Markdown, and API inputs are converted into a structured canonical model and sanitized before they can render. There is no second, unsanitized path to the DOM.

  • DOMPurify on every import path
  • Strict tag & attribute allowlist
  • Event-handler & javascript: URLs blocked

Content-hash integrity

Every revision is content-hashed, so a document loads back exactly as it was written and tampering is detectable. Integrity is verified on save and on load.

  • Hash verified on save & load
  • Deterministic, replayable revisions
  • Audit-friendly change record

TLS 1.3 in transit

Every request between your browser and our servers is encrypted with modern TLS.

  • TLS 1.3 for all traffic
  • httpOnly, secure session cookies

Encrypted secrets, Vault-brokered

Sensitive secrets are encrypted at the application layer and brokered through HashiCorp Vault rather than baked into our images. The cluster state store is encrypted at rest.

  • TOTP secrets encrypted with AES-256-GCM
  • Secrets brokered through HashiCorp Vault
  • Cluster state store (etcd) encrypted at rest

Append-only audit logging

Internal admin operations are recorded in an append-only audit log. Per-workspace, customer-facing audit logs are on the roadmap (see below).

  • Append-only internal admin log
  • Tamper-evident operation history

Access controls & hashing

Passwords are hashed with bcrypt and sessions are short, opaque tokens. Staff-side RBAC governs our internal admin panel today.

  • bcrypt (cost 12) password hashing
  • SHA-256 session-token digests
  • Staff RBAC on the admin panel
TLS 1.3
for every request in transit
AES-256
GCM for sensitive secrets at rest
bcrypt
cost-12 password hashing
Vault
brokers secrets -- never baked into images
We are precise about what is encrypted and how. Traffic is encrypted in transit, sensitive secrets are encrypted at the application layer, and our infrastructure data store is encrypted at rest. We do not claim per-document client-side encryption that we have not built.
-- Inkury engineering, on our encryption posture
Your data, your control

Local-first by default, portable on demand

Lives on your device first

Documents are persisted locally before any server sees them, then sync over an encrypted connection.

No content tracking

No third-party analytics or tracking runs against your document content.

Export anytime

Take everything with you in Markdown, HTML, or JSON whenever you want -- no lock-in.

Delete on request

It is your content. You can delete all of your data at any time.

Australian-operated

Operated in Australia, under Australian privacy law.

Coming next

On the roadmap

These controls are designed but not yet generally available. We will not present them as shipped until they are.

Plugin sandboxing

Coming

A capability-based plugin system where each extension runs in an isolated sandbox worker with explicit permission grants (network, storage, DOM). The model is specified; the runtime and marketplace are not yet open.

SSO & role-based access control

Coming

Single sign-on and workspace-level RBAC for teams. Staff-side RBAC already governs our internal admin panel; customer-facing workspace SSO/RBAC is planned for the Team and Enterprise tiers.

SOC 2 Type II

Coming

We are pursuing SOC 2 Type II. We are not certified today, and we will say so plainly until an audit is complete. GDPR-aligned data handling and data-processing agreements are available on request.

Customer-facing audit logs & data residency

Coming

Per-workspace audit logs and choice of hosting region (AU/US/EU) are planned for Enterprise. Append-only audit logging already exists for our internal admin operations.

Responsible disclosure

Found a security issue? We take every report seriously. Please email security@inkury.com with details. We aim to acknowledge reports within one business day and to keep you updated as we investigate and remediate confirmed issues. Please give us reasonable time to fix an issue before disclosing it publicly.

Need more details?

We are happy to discuss our security architecture, share what we can about our roadmap, or arrange a call with our engineering team.

Contact us