See the attack.
Act on it.

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.

// 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",
}

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.

// 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,
}

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.

<!-- 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": [] } -->

Every attack has a tell.

TillTell reads one security stream made of what every Till product already records on the server: sign-ins and second factors, keys and roles, secret reads, pushes and branch protection, backup deletions, and the decisions TillGate makes at the edge. With the endpoint agent, your servers and workstations join it. A library of rules, each tied to a MITRE ATT&CK technique, watches it.

Rules earn their way. Each starts in shadow, recorded and never alerting. You promote it when you trust it; it demotes itself when it cries wolf. Verdicts are appended, never edited. A rule that would revoke or block never fires on evidence an app merely claimed.

Write your own for the attacks only your team would recognise. Same format as the library, held to the same tests, and replayed against your recent events before it runs. Patterns can't backtrack, and a rule that runs too long pauses itself instead of slowing anyone down.

TillHunt is for the attack nobody has written a rule for yet. Ask the same stream a question in the rule grammar, find the rarest address or the busiest reader, pivot on any value, and keep what you find as a rule with tests made from the real events. When a hunt stops short of the whole range, it says exactly how far back it read.

The coverage map shows the gaps, not just the wins. Every ATT&CK technique reads no rule, rule, or proven by drill, and the ones your connected products can't see are faded instead of counted. A gap names the product whose records would close it.

A finding proposes. A person decides.

When a live rule fires, its playbook is ready: tell the right people, make the account prove its second factor, sign it out everywhere, block the address at the edge for a day, stop a compromised app session from sending data, end a process on a host, or cut the host off the network.

Nothing that takes access away runs on its own until the rule has earned it. A waiting run reminds you once, then expires. Nobody can wave off a response aimed at their own account, and drills rehearse every step without touching anyone. Alerts reach email, Slack and a signed webhook.

Your servers have tells too.

The TillTell agent reports what happens on Linux, macOS and Windows hosts: processes started, sign-ins, sudo, new accounts and admins, persistence, SSH keys, kernel modules, listening ports, cleared logs and defences turned off. The same rules, hunts and incidents read them, and the coverage map lights up what only a host can show.

One command installs it, after checking the release signature. A new host waits until someone approves the fingerprint it printed. Secrets in command lines are scrubbed before they leave the host. When a source is missing, such as an audit policy that is off, the host says so and names the command that turns it on.

When the host is the problem, end the process or isolate the host: it keeps only its link back to TillShield, so you can watch it and let it go. Every command is signed for one host and checked by the agent before it acts, and undoing an isolation on the host is reported.

Rehearse the attack before it comes.

TillDrill tests your sites and APIs from the outside, the way an attacker or a traffic spike would. It starts with ownership. It tests only targets you prove are yours, and checks the proof again before every run.

A DNS record proves the name. A file on the server proves the server, and only that lets a load drill run, because a name can point at anyone's machine. A domain you already verified for single sign-on or TillAuth counts, with nothing to publish.

Passive checks are live now. They are OWASP-tagged checks of TLS, headers, cookies and the DNS records that guard mail and certificates. Run them by hand, or let each target repeat them daily or weekly. You hear about it when something new breaks.

Active checks ask the target itself, and read only. Paths that leak by accident, a folder listing its files, the methods it states, what it shares with another origin, a link parameter that sends visitors off-site, a name pointing at a provider that no longer claims it, advisories for the version it names. Nothing is written, no credential is guessed, and the origin and host it asks with are reserved names that cannot resolve. They need the file on your server, or a record over https, and stay off until you turn them on.

Intrusive probes go one step further, and so they ask more of you. They send inputs built to be mishandled — a stray quote, a value a template engine would run, an over-long field, a sign-in that must fail against a name that can never exist — to find where your own target slips. They turn on only with the file proof, your written authorisation, and a maintenance window you set, run one at a time, and still write nothing and guess no real password.

Latency is measured from regions around the world, four of them in Africa, against a budget you set, hourly or daily. Load drills ramp up to a planned rate with hard caps, and stop on their own when errors or latency pass your threshold.

It reads the apps you ship, too. Upload an APK, an IPA or a desktop build, or pick a TillForge release, and TillDrill flags debuggable builds, plain-text traffic, components any app can open, keys shipped in the code and weak crypto, each tagged with its OWASP MASVS control. The build is deleted once read, and a release can fail in CI on what it made worse.

Your machines get the same treatment, from their own side. Connect a cloud account and TillDrill reads the public addresses it holds; each one can then be scanned for the ports that answer the internet, what is listening, and the certificates they serve. It opens a connection, reads what the service announces and closes — no payload, no credential, nothing changed. Then it lines that up against the rules the account itself declares, and names the port answering that no rule opens and the rule that opens a port with nothing behind it.

And it drills your detection. A defense drill replays a TillTell rule’s own test as signed drill traffic, kept apart from the real thing, and times how long the rule takes to fire and the playbook to finish, every step simulated. A rule that fires is marked proven on the ATT&CK map, dated.

Know what you actually run.

Posture reads your accounts on a schedule and keeps an inventory of what is there: each resource, the settings that matter for security, and when it appeared, changed and went. Connectors only read, and they read settings, never secret values.

Start with your own workspace: repositories and the policy on each default branch, service tokens, API keys and sign-in apps. Then connect AWS, Google Cloud and Azure through federation: TillDev signs a token that lasts five minutes and a read-only role, workload identity pool or app registration in your account trusts it, so no cloud key or secret is ever stored. IAM, storage, networks, instances, databases and audit trails. Cloudflare and DigitalOcean, which have no federation, read with a read-only token sealed the moment you add it: Cloudflare members and two-factor, API tokens, each zone’s TLS, HSTS and DNSSEC, and public R2 buckets; DigitalOcean Droplets, firewalls, databases, Kubernetes and load balancers.

A resource leaves the inventory only when a full read no longer finds it. A read that falls short keeps what it had and says so, so a provider hiccup never looks like a deletion.

Every sync judges each resource against a library of checks: a port for remote administration open to the internet, a public bucket, a user without MFA, a key nobody rotated. Failures open findings that close on their own once fixed, and a check that couldn’t read what it needs says so instead of passing. Choose which checks alert, accept a risk with a reason and an end date, and see each setting that changed since the last baseline.

Every finding has a due date.

TillDrill, app build scans, Posture, and TillForge’s dependency, code, IaC and secret scanning each keep their own page. Vulnerabilities puts what they find in one list, with days to fix set per level, an owner for each item, and a message when something falls overdue. An item closes when the next scan no longer finds it.

Accept a risk with a reason and an end date, and watch mean time to fix by level. On a vulnerable dependency, one click opens the pull request: npm, pnpm, yarn, pip, Go and Cargo lockfiles are edited to the smallest version that fixes every advisory, and where a change wouldn’t be safe you get the command to run instead.

A front door for the people who find things.

Publish a disclosure program in minutes: your policy, what is in scope, safe harbor, reward ranges, and how quickly you answer. TillShield writes the security.txt that points researchers to it, and checks the copy on each of your domains.

Reports arrive only after the researcher confirms them, sealed with your workspace’s key. Your inbox keeps a clock for the first reply and one for the decision, and an accepted report joins Vulnerabilities with a due date. Emails on either side carry a link, never the report.

Purple team, red team and pentests, on the record.

Write the rules of engagement once: scope, the networks testing comes from, the window and who to call to stop. An owner authorises exactly that, and the window starts and ends testing on its own.

Each technique tried is checked against what TillTell saw from the testers’ networks, and a detected one proves the technique on your coverage map. Outside testers work through a private link, findings land in Vulnerabilities with a fix-by date, and the report is ready for your auditor.

Know what everyone else already saw.

Every security event is checked against the Tor exit list and against addresses that three or more other workspaces’ findings named in the last 30 days. The finding says how many saw it and which techniques they saw, never who, and your own rules can act on it.

In Vulnerabilities, a CVE on CISA’s known-exploited list rises to the top, with its EPSS score from FIRST.org beside it. Feeds ship only when their licence allows it, and intel adds context; it never blocks anyone on its own.

The evidence is already recorded.

Who signs in with a second factor, whether detections were proven by a drill, how fast vulnerabilities were fixed, whether a backup was actually restored: TillShield reads it from your products over the period you choose and judges thirty controls, each mapped to SOC 2, ISO/IEC 27001 and NIST CSF criteria.

Policies and reviews you keep elsewhere are attested, with a fresh approval. Snapshots can’t be changed, each carries the digest of the one before, and your auditor can check the export without us. It is evidence for their assessment, not a replacement for it.

Trusted and watched.

Fourteen TillTell rules look inward: every repository cloned in an hour, a repository made public, a mirror pushing code somewhere new, secrets revealed or deleted in bulk, a detection turned down, required two-factor switched off, and API keys and service tokens doing what they never did before.

They read what your products already record, start in shadow, and rank each member and credential by what fired. Benign findings stop counting. A score tells you where to look first, never what to conclude.