Security

Your customers' history, guarded like it matters.

Softechlog stores security-relevant data about your users, so our security model has to be legible. This page states what's in place today — plainly, without vanity claims — and what we don't claim yet.

The model

Least privilege, by construction.

Three credentials, each with exactly the power it needs — so the blast radius of any exposed credential is small and known in advance.

Secret key — server only

stl_sk_… ingests, reads, exports, and mints feed tokens for one project. Lives in your server environment; shown once at creation, stored hashed, revoked instantly on delete.

Public key — ingest only

stl_pk_… can submit auto-capture events and nothing else — every read attempt returns 403. Embedding it in a page can never expose other users' activity.

Feed token — one user or one account

stl_ft_… is minted by your server, pinned to a single user, a single customer account, or one user within it — read-only, and it expires (60 s – 24 h). It's the only credential a customer's browser ever holds.

Controls

What's enforced automatically.

Project isolation

Every event, actor, and session is scoped to one project at the database level. Each credential resolves to exactly one project; there is no cross-project read path.

Tamper-evident history

No API edits events. Every event is hashed at ingest and sealed into hash-chained, Ed25519-signed checkpoints every 5 minutes. The only ways data leaves are retention and per-user erasure — and verification shows both. Pin a checkpoint and not even we can rewrite what came before it without detection. How it works.

Right to erasure

One call (or one button) erases a user's personal data for a GDPR Art. 17 request: delete their events, or redact them to keep what happened without who. Mentions in other people's events are scrubbed, and a sealed evidence event records that it happened. Erasure docs.

Automatic retention

Retention is set by plan (30/90/365 days) and enforced hourly by a scheduled purge — a stated policy executed by a machine, not by intention.

Encrypted transport

All traffic is HTTPS/TLS. SMTP and internal service connections verify certificates; strict security headers are set on every response.

Rate limiting

Redis-backed sliding-window limits on ingest (per secret key and per public key), on reads (per credential), and per source IP on sign-in and sign-up — with fail-safe defaults.

Instant revocation

Deleting a key revokes it on the next request. Keys are stored hashed; plaintext is never persisted. Feed tokens expire on their own within 24 hours at most.

Honesty section

What we don't claim (yet).

We're an early-stage product, and we'd rather you know exactly where we stand:

  • No SOC 2 report of our own yet. We provide the logging controls your audit needs; our own certification is on the roadmap, not in hand. Ask us and we'll share our current practices in detail.
  • Single-region managed infrastructure. If you have hard data-residency requirements, talk to us before integrating.
  • Tamper evidence is only as strong as your pinning. We host the database and hold the signing key: without a checkpoint you stored yourself, we could rebuild a consistent history. With one, we can't.
  • Your metadata is your responsibility. We cap and store what you send; don't put secrets or unnecessary PII in event metadata.

The full technical detail — CORS policy, key lifecycle, credential scoping, and what to verify before production — is in the security documentation. Found a vulnerability? Email hello@softechlog.com and we'll respond fast.

Evaluating for a security-sensitive rollout? We'll walk through the architecture with you.

Schedule Technical Call