TILLSHIELD · TILLDEV

See the attack.
Act on it.

Root, jailbreak, pinning failures, overlay abuse — the security signals TillPulse already collects, watched by rules that raise an incident, quarantine the session, or revoke the user’s auth. And now the same rules run inline, at your own edge and origin, deciding each request in real time. Detection you don’t have to be awake for.

LIVE · watching + enforcing
device-compromise · cert-pinning · overlay · threat-intel · inline-waf · human-check
WHAT’S INSIDE

Five moving parts.

DetectionGA

Device integrity, TLS pinning, overlay abuse, web + desktop tamper — collected by the SDKs, scored by severity and confidence.

› Read the docs
Reactive rulesGA

Watch security signals; when a trigger crosses its threshold, take one action — automatically. Test-mode and cooldowns included.

› Read the docs
Inline WAFGA

Enforce rules at request time on your own edge or origin. Rules and a sha256 deny list are fetched and cached; each request is decided locally, off the hot path.

› Read the docs
IncidentsGA

A real triage workflow — status, severity, an assignee, and an append-only timeline of every note, change, and action taken.

› Read the docs
Threat intelGA

Privacy-preserving sha256 indicators shared across every org. A binary caught attacking others surfaces for you first.

› Read the docs
WHAT IT SEES

Threats, already in the pipe.

TillShield doesn’t ask you to instrument anything new. It reads the security telemetry your TillPulse SDKs already send, scores it, and puts it in front of a rule.

MOBILE · SDK

Root & jailbreak

The TillPulse mobile SDKs report device-integrity failures at runtime — a rooted Android or jailbroken iOS device is a compromised trust boundary, and TillShield treats it as one.

MOBILE · TRANSPORT

TLS certificate-pinning failures

A pinned connection that doesn’t match its expected certificate is a man-in-the-middle in progress. The failure the SDK reports becomes a signal you can act on before the session continues.

ANDROID · UI

Overlay-permission abuse

Foreign windows drawn on top of your app are the classic tap-jacking and credential-capture vector. TillShield flags overlay abuse the moment the SDK detects it over a sensitive screen.

WEB · DESKTOP

Tamper signals

Web and desktop runtimes report their own tamper indicators. Same pipeline, same scoring, same rules — so a single policy can span every surface you ship on.

CROSS-ORG

Shared threat intelligence

Every detection carries privacy-preserving sha256 indicators. A package, certificate, or binary caught attacking another TillDev customer surfaces for you before it reaches you.

SCORING

Severity & confidence

Every signal lands with a security type, a severity, and a confidence score. Rules trigger on those numbers — so you decide how sure and how serious a threat has to be before anything happens.

THE REACTIVE LAYER

A trigger, and one action.

A rule watches a set of security types and fires when they cross a threshold — a minimum severity, a minimum confidence, and a count within a time window. When it does, it takes exactly one action.

Run a new rule in test-mode first — it logs what it would have done without doing it. A per-rule cooldown keeps one bad actor from firing the same action a hundred times a minute.

Writing rules →
ts · rule.ts
// Kill sessions on repeated integrity failures.
{
  name: "integrity-lockdown",
  when: {
    types: ["device_compromised", "cert_pinning_failure"],
    minSeverity: "high",
    minConfidence: 0.8,
    threshold: { count: 3, within: "10m" },
  },
  then: { action: "revoke_auth_sessions" }, // via TillAuth
  testMode: false,   // dry-run: log, don't act
  cooldown: "30m",
}
THE FOUR ACTIONS
raise_incident

Open a triage record with the triggering events attached.

quarantine_session

Cut off the offending session without touching the rest of the account.

revoke_auth_sessions

Kill every auth session for the user — TillShield asks TillAuth to do it.

alert

Notify the channel you already route TillPulse alerts to.

WHEN SOMETHING FIRES

An incident, not an inbox.

When a rule raises an incident, you get a record you can actually work — a status, a severity, an assignee, and an append-only timeline that captures every note, every status change, and every action TillShield took automatically.

open
investigating
contained
resolved

Assign it

Every incident has an owner. Assign it to a teammate and it shows up on their plate — no separate ticketing tool to reconcile.

Trace it

The timeline is append-only. Notes, status changes, and the actions a rule already took are all one ordered record — nothing gets quietly edited away.

Close it

Move it open → investigating → contained → resolved. The severity and the triggering events stay attached the whole way through.

SHARED, NEVER SHARED

One customer’s attacker
is everyone’s warning.

When a malicious package, certificate, or binary is seen attacking one TillDev customer, its indicator is shared across every org — so it can surface for you before it ever reaches your users.

The catch is that we never share the thing itself. Indicators are sha256 hashes only — a fingerprint you can match against, carrying no raw identifier, no user data, and nothing that ties a threat back to the org that first saw it.

THE PRIVACY MODEL
Hashed

Indicators are sha256 digests — one-way, no reversible payload.

Anonymous

No org name travels with an indicator. You see the threat, not the victim.

Opt-out

Contribution is on by default and can be turned off; you still consume the shared feed.

Yours to act on

A shared indicator is just another signal — the same rules and actions apply.

NOT A BOLT-ON

Same workspace. Same login.

TillShield isn’t a separate product to integrate — it’s the security layer of the TillDev workspace you already have. It reads what TillPulse collects and acts on what TillAuth controls, and every move lands in the one audit log.

01 · READS

TillPulse telemetry

The device-integrity, pinning, and overlay signals TillShield reacts to are the ones your TillPulse SDKs already send. Nothing new to install.

02 · ACTS ON

TillAuth sessions

revoke_auth_sessions and quarantine work because TillShield can reach into TillAuth and end a session — the same sessions your users authenticate against.

03 · RECORDS

One audit log

Every rule fire, incident change, and automated action writes to the shared TillDev audit log, next to your Pulse and Auth events — one history, not three.

THE INLINE LAYER · NOW GA

Not just after. Now during.

TillShield now sits in the request path. An inline WAF enforces your rules at your own edge and origin — a detection becomes a decision before the request is served, not after.

Rules and a sha256 threat-intel deny list are fetched from TillDev and cached, so every request is decided locally — no phone-home on the hot path. Decisions report back asynchronously, and it fails open by default (configurable to fail closed) so a control-plane blip never wedges your traffic.

Auth is a per-project, server-side edge key (tse_…) minted under Shield → Inline WAF — a secret, kept distinct from your public ingest DSN.

Inline WAF integration guide →
ts · rule.ts
// An inline rule — first match wins, evaluated per request.
{
  name: "deny-known-hostile",
  priority: 10,
  mode: "block",            // block | challenge | log
  match: {
    threat_intel: true,     // sha256(client IP) on the shared deny list
    paths: ["/api/*", "/login"],
    methods: ["POST"],
    // countries, ip_cidrs, user_agent_regex also supported
  },
  rate_limit: { requests: 20, window_seconds: 60, by: "ip" },
  response_status: 403,
}
THREE WAYS TO DEPLOY IT
NODE ORIGINS
@tillstack/shield-node

One package, three adapters: Express / Connect middleware, a Fastify onRequest hook, and a raw http handler. Drop it in front of the routes you already serve.

CLOUDFLARE WORKERS
@tillstack/shield-cloudflare

Decide at the edge using Cloudflare’s own request signals. Wrap your fetch handler, or pass a KV namespace for a rate limiter shared across isolates.

DROP-IN · ZERO CODE
tillshield-edge

A ready-made reverse-proxy Worker. Set an edge key and your origin, deploy it, and route your hostname at it — no changes to your application code at all.

THE HUMAN CHECK · TILLGATE

Prove there’s a human.

TillGate is a drop-in bot challenge. A widget issues a signed pass token after the browser does a small proof-of-work — bound to your hostname, with a short TTL — and your server verifies it at /siteverify.

It’s a cost on automation, not a surveillance tool: no third-party tracking, no cross-site cookies, no behavioral scoring. Three modes — managed, invisible, interactive — and a per-project site key (tg_site_…) minted under Shield → TillGate.

And it plugs into the inline WAF: a rule in challenge mode can present TillGate instead of a bare 429.

html · login.html
<!-- Drop-in: the widget writes a pass into tillgate-response. -->
<script src="https://tilldev.dev/tillgate.js" async defer></script>

<form method="POST" action="/login">
  <div class="tillgate" data-sitekey="tg_site_…"></div>
  <button type="submit">Sign in</button>
</form>

<!-- Server verifies at:
  POST https://tilldev.dev/api/tillgate/siteverify
  { "secret": "tg_secret_…", "response": "<token>" }
  → { "success": true, "hostname": "example.com", "error-codes": [] } -->
TURN IT ON

If TillPulse is already watching your projects, TillShield is one workspace away from watching for the attacks — and blocking them inline.

PART OF TILLDEV

One of seven.

You don't have to use the rest. But they fit together — same workspace, same audit log, same shortcut to switch between them. Add what you need when you need it.