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. Detection you don’t have to be awake for.

LIVE · watching
device-integrity · tls-pinning · overlay-abuse · cross-org intel
WHAT’S INSIDE

Four moving parts.

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_integrity", "tls_pinning_failure"],
    minSeverity: "high",
    minConfidence: 0.8,
    threshold: { count: 3, within: "10m" },
  },
  then: { action: "revoke_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_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_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.

ON THE ROADMAP · NOT SHIPPING TODAY

What TillShield doesn’t do yet.

TillShield reacts to signals after they’re reported. It does not sit in the request path today. Two things are coming — and we’ll say so plainly until they ship.

COMING

Inline WAF / edge decisioning

A request-time worker that blocks or challenges traffic on the hot path — turning a detection into a decision before the request is served, not after. In design.

COMING

Server-side SDKs

Dedicated packages — @tilldev/shield-node and @tilldev/shield-cloudflare — to enforce rules at your own edge and origin. Not published yet.

TURN IT ON

If TillPulse is already watching your projects, TillShield is one workspace away from watching for the attacks.

PART OF TILLDEV

One of four.

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.