TILLSHIELD · CHANGELOG

TillShield, in order.

What we shipped on the security side of TillDev. Newest first. Material breaking changes are flagged in bold — these can require changes to your rules or SDK config.

v1.2 — July 2026 · TillGate (the human check)

Shipped 2026-07-09. TillGate is GA — a drop-in, privacy-first bot challenge for the projects TillShield already guards. A widget issues a signed pass token after a client-side proof-of-work bound to your hostname with a short TTL; your server verifies it at /siteverify. It’s a cost on automation plus hostname and replay binding — not a behavioral or machine-learning detector.

  • Widget + verification. Embed the hosted script (https://tilldev.dev/tillgate.js) or install @tilldev/tillgate. The pass lands in a tillgate-response field; verify server-side at POST /api/tillgate/siteverify with a familiar request and response (success, hostname, challenge_ts, error-codes).
  • Three modesmanaged, invisible, and interactive — over the same proof-of-work core; the mode only changes how much the visitor sees.
  • Per-project keys, minted under Shield → TillGate: a public site key (tg_site_…, embedded) and a server-side secret key (tg_secret_…, used only for /siteverify).
  • WAF challenge integration. An inline WAF rule in challenge mode can present TillGate instead of a bare 429 — the same enforcement decision with a softer edge.
  • Privacy-first by construction: no third-party tracking, no cross-site cookies, no behavioral profiling. See the TillGate docs.

v1.1 — July 2026 · Inline enforcement

Shipped 2026-07-08. TillShield now does both halves of the job: it still reacts to security telemetry after the fact, and it can now enforce rules inline, at request time, on your own edge and origin.

  • Inline WAF / edge decisioning is GA. Request-time rules are evaluatedlocally, per request, at your own edge or origin — no phone-home on the hot path. Rules and a hashed threat-intel deny list are fetched from TillDev and cached; decisions are reported back asynchronously. Fails open by default (configurable to fail closed).
  • New server-side SDKs — @tilldev/shield-node (Express / Connect / Fastify + raw http) and @tilldev/shield-cloudflare (Cloudflare Workers).
  • Drop-in edge workertillshield-edge, a ready-made reverse-proxy Worker: set an edge key and origin, deploy, and route your hostname at it. Zero application code.
  • Inline rules match on client IP (CIDR, IPv4 + IPv6), URL path globs, HTTP method, country, User-Agent regex, and a threat_intel flag. Each rule has a mode — block, challenge, or log — an optional token-bucket rate limit, and a priority (first match wins). An optional per-rule flag rolls repeated blocks into an incident.
  • Per-project edge keys (tse_…) — a server-side secret, minted under Shield → Inline WAF, kept distinct from the public ingest DSN.
  • Cross-customer threat-intel contribution is now opt-out-controllable per workspace in Shield → Settings. Contribution stays on by default; you consume the shared feed either way.

v1.0 — July 2026 · General availability

TillShield is GA. The reactive stack is complete and running in the workspace you already have.

  • Reactive rules — a trigger (security types, minSeverity, minConfidence, and a threshold count within a time window) paired with one action. Test-mode dry-runs and per-rule cooldowns included.
  • Four actions — raise_incident, quarantine_session, revoke_sessions (via TillAuth), and alert.
  • Incidents — a triage workflow with status (open → investigating → contained → resolved), severity, an assignee, and an append-only timeline of notes, status changes, and actions taken.
  • Detection types normalized from TillPulse security telemetry — device_compromised (root / jailbreak), cert_pinning_failure, overlay_capable_app_present, and web / desktop tamper_detected.
  • Cross-customer threat intel — privacy-preserving hashed indicators shared across every org, anonymized, opt-out, surfaced as threat_intel_match signals you can write rules against.
  • Every rule fire, incident change, and automated action writes to the shared TillDev audit log.

v0.2 — June 2026 · Reactions

  • Rules engine private preview — triggers and the raise_incident and alert actions.
  • Session actions — quarantine_session and revoke_sessions wired through to TillAuth.
  • Incident timeline moved to append-only; status set fixed at open / investigating / contained / resolved.
  • Confidence scoring added alongside severity so rules can gate on both.

v0.1 — May 2026 · Signals

  • Ingest of TillPulse security telemetry — device-integrity, TLS-pinning, and overlay-abuse events normalized into security types.
  • Cross-customer threat-intel feed — hashed indicators only, matched at ingest.
  • Read-only security surface in the workspace, ahead of the reactive layer.

Looking for another product? See the TillAuth and TillForge changelogs, or the TillPulse changelog. The full TillDev shipping log lives at /changelog for now — a unified cross-product log is on the roadmap.