TillShield, in order.

October 2026 · Fixes: engagements and docs

• Engagements: a play with a run time but no verdict yet shows as not judged rather than not run, and the counts say judged. tilldev shield engagements show says the same.
• Engagements: window dates in the list follow your own locale and timezone, and rows in the engagement, play and finding tables open from the keyboard. Insider risk rows do too.
• Docs: lists show their bullets and numbers again, and the sidebar marks only the page you are on.

October 2026 · Insider risk: members and service credentials

• Fourteen new library rules, in shadow to start. For members: many repositories cloned in an hour, a repository made public, a push mirror added or pointed at a newly allowed host, bursts of secret reveals or deletions, a secret read from a project the person never touched, several detections weakened in an hour, required two-factor sign-in or a step-up policy turned off, and repositories deleted or erased. For service credentials: an action or an environment the credential never used before, and a credential minting another.
• Shield → Insider risk ranks each member and credential by what the pack found about them over 7, 30 or 90 days: critical 8, high 4, medium 2, low 1. Findings triaged as a false positive, benign or a duplicate stop counting; drills are left out. A score is a reason to look, never a verdict on a person. Owners and admins only.
• New records in the security stream: every authenticated git fetch or clone, against the person or the machine key that made it; repository visibility changes with what they changed from and to; and API keys in the workspace audit now act as credentials, not as people.
• Shared verbs for more workspace and TillForge actions. Repository deletion, erasure and mirror changes, step-up and required two-factor changes, and TillTell rule stage changes and deletions now arrive as repo.deleted, repo.erased, repo.mirror_changed, repo.mirror_hosts_changed, iam.policy_changed, detection.rule_stage_changed and detection.rule_deleted. A custom rule or saved hunt that matched these actions by their old names should match the new verb; the old name is still in raw.action.
• API: /api/v1/shield/insider and /api/v1/shield/insider/findings. CLI: tilldev shield insider. Docs.

October 2026 · Compliance evidence: SOC 2, ISO/IEC 27001 and NIST CSF

• Thirty controls judged from your own records: two-factor sign-in, access review, the audit trail, detection and whether drills proved it, triage, vulnerability due dates and known-exploited CVEs, source protection, approved production deploys, backups and restores, incidents, on-call, secret age, devices and governance. Each shows its facts, where they came from, and the SOC 2, ISO/IEC 27001:2022 and NIST CSF 2.0 criteria it supports, named by identifier.
• Pick a period, the last 90 days by default and up to 366. A product you don't use shows as not in use; evidence that can't be read shows as unknown, never as a pass.
• Attestations and exclusions for evidence held outside TillDev and controls that don't apply, each with a fresh approval and in the audit log. Attestations lapse and can be revoked, never edited, and never turn a failing control into a pass.
• Snapshots that cannot be changed. One each month on its own, or any period on demand, each carrying the SHA-256 digest of the one before it. Export as JSON or Markdown; tilldev shield compliance verify checks a JSON export offline.
• Shield → Compliance, for owners and admins. API: /api/v1/shield/compliance. CLI: tilldev shield compliance. This is evidence for an assessment, not an assessment or a certification. Docs.

October 2026 · Threat intel: Tor exits, exploited CVEs and cross-workspace patterns

• Every security event is checked against the Tor Project's exit relay list and against addresses TillTell findings at three or more other workspaces named in the last 30 days. Findings keep an intel block with the feeds, how many other workspaces (never which) and the ATT&CK techniques they saw, and your own rules can match on it.
• Two new library rules, in shadow to start: a sign-in from a Tor exit relay (medium) and a sign-in from an address other workspaces flagged (high). Defense drills can test both.
• Exploited vulnerabilities first. Inventory items with a CVE show whether CISA's Known Exploited Vulnerabilities catalog lists it, with ransomware use, and its EPSS score from FIRST.org. Vulnerabilities gains an Exploited count, filter and sort.
• Patterns leave out drills, client-reported events and findings marked false positive or benign. A workspace that stops contributing under Shield → Settings is no longer counted and still gets the checks. Intel never blocks on its own.
• Shield → Threat intel shows each feed's freshness and licence. API: /api/v1/shield/intel, and exploited and sort=exploit on /api/v1/shield/vulns. CLI: tilldev shield intel and tilldev shield vulns --exploited. Docs.

October 2026 · Engagements: purple team, red team and pentests

• Testing by people, on the record. Shield → Engagements plans a purple-team exercise, a red-team run or a pentest: objectives, rules of engagement, what is in and out of scope, the networks testing comes from, the window and a stop contact.
• An owner authorises it, with a fresh approval of exactly that scope, window and those networks, and an optional reference such as the statement of work. Changing any of them before testing withdraws the authorisation; once testing starts they are fixed.
• The window runs it. An authorised engagement starts when its window opens and testing ends when it closes. The team can pause, resume, end early or cancel; a plan whose window passes unstarted is cancelled.
• Plays checked against TillTell. For each ATT&CK technique tried, the engagement lists the TillTell findings from the tester networks around the run and suggests Detected. A detected play proves the technique on the coverage map for 90 days.
• Private links for testers, made per tester and shown once, with no account needed: they read the rules, scope and stop contact, log runs, report findings, confirm fixes on retest and talk to your team. Finding contents and notes are sealed with your workspace's data key.
• Confirmed findings join Vulnerabilities as Pentest items with a fix-by date and close when the retest passes. State changes and testers' findings reach your security alerts as tillshield.engagement.state and tillshield.engagement.findings, without what a finding says.
• A Markdown report for auditors. API: /api/v1/shield/engagements and /api/v1/engage. CLI: tilldev shield engagements. Docs.

October 2026 · Vulnerability disclosure

• A public page for security researchers. Shield → Disclosures sets up a program at /disclose/<handle>: your policy, what is in and out of scope, safe harbor, reward ranges per level, and how quickly you reply and decide.
• Reports reach you once the researcher confirms them from an emailed link; unconfirmed ones are deleted after 7 days. The form asks the browser for a small proof of work, and reports are limited per network, per address and per program.
• Sealed with your workspace's data key, per report and per field. Your team never sees the researcher's address, and emails to either side carry a link, never the report. Rotating the data key re-seals them.
• An inbox with a clock for the first reply and one for the decision, levels from a CVSS 3.1 vector, duplicates, notes only the team sees, and rewards recorded from proposed to paid. Accepted reports join Vulnerabilities.
• New reports and replies reach your security alerts as tillshield.disclosure.received and tillshield.disclosure.reply, without their contents.
• security.txt written for you, a hosted copy that stays current, a check of the file on each of your domains, and an optional thanks page. API: /api/v1/shield/disclosures and /api/v1/disclose. CLI: tilldev shield disclosures. Docs.
• Security alerts to Slack now escape Slack's control characters, so text from outside can't turn into a link or a mention.

October 2026 · Vulnerabilities: one inventory, a clock and fix pull requests

• Everything vulnerable in one list. Shield → Vulnerabilities gathers what TillDrill scans, app build scans, Posture, and TillForge dependency, code scanning, IaC and secret scanning find. Each item closes as fixed when the next scan no longer reports it, and opens again with a new clock if it comes back.
• A due date per level. 7 days for critical, 30 for high, 90 for medium and 180 for low unless you change them. Items are due soon in the last quarter of their window, and the workspace's security alerts name each item once when it falls overdue, as email, Slack or the signed tillshield.vulns.overdue webhook.
• Owners and accepted risk. Assign any member. TillDrill and app scan items are accepted here with a reason and an end date; the rest are accepted where they were found, so the merge gate agrees.
• Fix pull requests. On a dependency advisory, TillDev edits package-lock.json, pnpm-lock.yaml, yarn.lock (v1), requirements.txt, go.mod and Cargo.lock to the smallest version that fixes every advisory, and opens the pull request. A lockfile it can't change safely gets the command to run instead.
• Mean time to fix, by level and source, and the share fixed in time. API: /api/v1/shield/vulns. CLI: tilldev shield vulns. Docs.

October 2026 · Posture: checks, findings and drift

• Every resource judged on every sync. A library of checks across data exposure, identity, network, logging, encryption, compute and backup covers every provider Posture reads: AWS, Google Cloud, Azure, Cloudflare, DigitalOcean and your TillDev workspace. A failing check opens a finding that names the fields that failed, and the finding resolves on its own once a full read shows it fixed. Checks and findings.
• Unread is never a pass. A check that needs a field the sync couldn’t read, because the provider didn’t answer or a permission was left out, is counted as not run and never closes a finding.
• Modes and exceptions. Each check alerts, reports or is off for your workspace; critical and high checks alert by default, in one message per sync over your security notifications. An exception accepts a risk for one resource or every resource, with a reason and an end date of at most a year, and is in the audit log. Modes and exceptions.
• Drift from a baseline. A resource’s first read is its baseline; a later read that changes a setting that matters lists each field’s old and new value until you accept it. Sign-in times, status and versions are left out. Drift.
• Dashboard: Shield → Posture opens on Findings once a connector exists, with Checks and Drift beside the inventory. API: /api/v1/shield/posture/findings, /policies, /exceptions, /drift and /baseline, in /openapi.json. CLI 0.10.0: tilldev shield posture findings, checks, except, drift and baseline.

October 2026 · TillDrill: exposure scans of your cloud addresses

• See what your own addresses answer on. An exposure scan opens a TCP connection to each of 105 well-known ports on one public address, reads what the service announces, reads the certificate where the port speaks TLS, and closes. It reports the ports that answered, which of them belong on an internal network, what appears to be running, certificates that are expired, self-signed, weak or for another name, exchanges that carry credentials in the clear, and what opened or closed since the last scan. Read them under Shield → TillDrill → Exposure. How exposure scans work.
• The cloud account is the proof. Addresses come only from the cloud accounts you connect under Posture, never from something typed in. An address arrives with scanning off, is retired when the account stops holding it, and is scanned only while the account has confirmed it in the last 7 days — read again before a single connection is made. This proof allows nothing but an exposure scan, and no other proof allows one.
• Your own rules, next to what actually answered. The rules in the account that open a port to the whole internet are read from the account, not from the network, and lined up against what answered: a port answering with no rule that opens it, and a rule opening a port with nothing behind it. Where a provider cannot tie its rules to one address, the scan says so instead of guessing.
• Reads only, and capped. No payload, no credential, nothing changed — and only the ports on the list, on the one address the account proves. One scan makes at most 140 connections, 8 at a time, and stops after 4 minutes. A workspace can have 3 scans waiting or running, start 60 a day, and scan one address once every 15 minutes. Stop ends a scan within seconds and keeps what it saw. Anyone watching the address will see the connections.
• Judged like the rest. 19 checks tagged with their OWASP Top 10 category, each with how to fix it; a part that could not run is reported as not run, never as a pass. Scanning is off for a new address, and exposure schedule sets it daily or weekly. A scheduled scan that finds a new failure at medium or above alerts; one you start by hand never does. CLI 0.10.0: tilldev shield drill exposure sweep, tilldev shield drill exposure and tilldev shield drill exposure scan <address-id> --wait.

October 2026 · TillDrill: intrusive probes, opt-in

• Find where your own target mishandles input. Intrusive probes send values built to be parsed wrong — a stray quote, a value a template engine would evaluate, an over-long field, a sign-in that must fail — and read the answer for a leaked database error, an evaluated marker, a server fault, or a session that isn’t locked down. They are the one part of TillDrill that reaches the target this way, so they stay off until you turn them on. How intrusive probes work.
• Three gates before a single request. They need the file served on your target (not a DNS record or a domain verified elsewhere), your recorded authorisation that you may test it (which lapses after 90 days), and a maintenance window you set — a weekday, a start time and a length, read in your timezone. A run outside every window is refused, and only one intrusive run happens at a time across the workspace.
• Inert by design. Nothing written, nothing deleted, no real password guessed, and no real account touched — the failing sign-ins only ever use a reserved username that can never exist. The values sent are the smallest that reveal mishandling, never a working exploit, and a run touches at most 6 pages and 20 parameters, one request at a time, so it is never a load test. One run sends at most 240 requests and stops after 5 minutes; Stop ends it within seconds and keeps what it saw.
• Judged like the rest, and audited. Checks tagged with their OWASP Top 10 category, each with how to fix it; a part that could not run is reported as not run, never as a pass. Recording or withdrawing authorisation is in the workspace audit log. A scheduled run that finds a new failure at medium or above alerts; one you start by hand never does.
• CLI 0.10.0: tilldev shield drill targets intrusive <target-id> on records your authorisation, window add --day Sun --start 02:00 --minutes 120 sets a window, and tilldev shield drill intrusive <target-id> --wait runs one inside an open window.

October 2026 · TillDrill: safe active checks

• Ask your own target directly, and read only. An active run asks for a short fixed list of paths that leak by accident, reads whether a folder lists its files, reads the methods the target states and whether TRACE answers, asks what it shares with another origin, tests whether a link parameter sends visitors off-site, reads DNS for a name pointing at a provider that no longer claims it, and looks up public advisories for the version the target names. How active checks work.
• Nothing is written. No PUT, DELETE, PATCH or CONNECT is ever sent, no credential is guessed, and no request carries a payload meant to change behaviour. The origin used to ask about cross-origin sharing and the host used to test redirect parameters are both reserved names that cannot resolve, so a target that honours the redirect sends nobody anywhere real.
• Gated on the proof, and off by default. Active checks need the file on your server, or a DNS record over https. They are off for every target until you turn them on, so an upgrade never starts them on a target proven for passive checks alone. One run sends at most 160 requests, 4 at a time, and stops after 3 minutes; Stop ends it within seconds and keeps what it saw.
• Judged like the rest. 15 checks tagged with their OWASP Top 10 category, each with how to fix it. A part that could not run is reported as not run, never as a pass. A path counts as leaking only when its body matches what that file looks like and differs from the page the target serves for anything missing, and an advisory match is shown as a fingerprint, not proof.
• CLI 0.10.0: tilldev shield drill active <target-id> --wait runs them and exits 1 on a failing check at medium or above; tilldev shield drill targets active <target-id> daily sets the schedule.

October 2026 · TillDrill: defense drills

• Prove a rule still fires. A defense drill replays a TillTell rule’s own smallest test that fires into your security stream, then times how long TillTell takes to record the finding and how long the playbook it suggests takes to finish. Start one under Shield → TillDrill → Defense drills. How defense drills work.
• Kept apart from real traffic. Drill events are signed by Till, and one that claims to be a drill without the signature is handled as real. They are correlated on their own, so they can’t set off or hide a real detection. Their findings never alert, and every playbook step they start is simulated.
• Proven on the coverage map. A detected drill marks the rule’s ATT&CK techniques as proven for 90 days, for the rule version it drilled. Changing the rule takes the proof away until it is drilled again.
• CLI 0.10.0: tilldev shield drill defense lists the rules that can be drilled and when each was last proven; defense <rule-id> --wait prints the times and exits 1 when nothing detected the drill.

October 2026 · Posture: DigitalOcean teams

• Connect DigitalOcean with a read-only token. Make a personal access token with seven read scopes in the team you connect, and add the connector with the team’s UUID. The token is sealed in TillSecrets as it arrives, and each sync stops if the token belongs to another team. Connect DigitalOcean.
• What it reads. Droplets with public addresses, backups and the cloud firewalls that guard them (or that none do); firewall rules open to the internet; managed databases any address can reach; Kubernetes clusters without auto-upgrade or a control plane firewall; and load balancers that take plain HTTP without redirecting.
• Every listed provider is now live. TillDev, AWS, Google Cloud, Azure, Cloudflare and DigitalOcean. A scope left off the token makes its type partial and names the scope; Spaces buckets aren’t read, since the API can’t list them with a token.

October 2026 · Posture: Cloudflare accounts

• Connect Cloudflare with a read-only token. Cloudflare has no identity federation, so its connector reads with an Account API token you create with six read permissions, listed on the connector and in the docs. The token is sealed in TillSecrets as it arrives, shown only by its last four characters, and destroyed when you disconnect. The first sync starts at once and stops if the token answers for another account. Connect Cloudflare.
• What it reads. Whether the account enforces two-factor sign-in, members without it and super administrators; the account’s API tokens that can write, cover every resource, have no IP limit or no expiry; each zone’s SSL mode, Always Use HTTPS, minimum TLS, HSTS, DNSSEC and records that aren’t proxied; and R2 buckets with a public r2.dev address or custom domain.
• Honest about gaps. A permission left off the token makes its type partial and names the permission to add. A token Cloudflare no longer accepts fails the sync and says to replace it, which Shield → Posture and tilldev shield posture token do in place.
• CLI 0.10.0: tilldev shield posture add cloudflare --account <id> --token-stdin; without a token on a terminal it lists the permissions and asks for it hidden. trust <id> and providers list the permissions.

October 2026 · Posture: Azure subscriptions

• Connect Azure with no client secret. Add a connector with the subscription, tenant and the client ID of an app registration, then give the app a federated credential naming that one connector and the Reader role on the subscription. Each sync signs in to Microsoft Entra ID with a five-minute TillDev token and checks the subscription is in your tenant before it reads. Shield → Posture shows the credential and the Azure CLI commands filled in. Connect Azure.
• What it reads. Who holds Owner, Contributor and User Access Administrator on the subscription, custom roles that allow every action, Defender for Cloud plans and activity log export; storage accounts, network security groups, virtual machines and their public addresses, Azure SQL servers with their firewall rules and auditing, and key vaults.
• Honest about gaps. A resource provider that isn’t registered leaves its type empty and is listed on the subscription. A refused sign-in says which part of the trust is wrong.
• CLI 0.10.0: tilldev shield posture add azure --account <subscription> --tenant-id <id> --client-id <id>, trust <id> --out . writes the federated credential, and tenant and client change the app in place.

October 2026 · Posture: Google Cloud projects

• Connect Google Cloud with no service account key. Add a connector with the project id and the workload identity provider that trusts it, then create the pool and provider with TillDev’s connector issuer and an attribute condition naming that one connector, and grant its principal read access. Each sync exchanges a five-minute TillDev token for a fifteen-minute access token. A service account to act as is optional. Shield → Posture shows the steps and the gcloud commands with your project filled in. Connect Google Cloud.
• What it reads. The project’s IAM policy (grants to anyone on the internet, owners and editors, personal Gmail accounts, service accounts with owner or editor, project-wide impersonation, data access audit logging), service accounts and their user-managed keys, Cloud Storage buckets and their public grants, VPC firewall rules, Compute Engine instances and Cloud SQL instances.
• Honest about gaps. An API that is off in the project leaves its type empty and is listed on the project. A zone Google Cloud can’t reach leaves instances partial and names it. A refused exchange says which part of the trust is wrong.
• CLI 0.10.0: tilldev shield posture add gcp --account <project> --audience <provider> [--service-account <email>], trust <id> prints the principal, condition and commands, and audience and service-account change them in place.

October 2026 · Posture: AWS accounts

• Connect AWS with no AWS key. Add an AWS connector with the account id, then trust it in three steps: TillDev’s connector issuer as an OpenID Connect provider, a role whose trust policy names that one connector, and a read policy of exactly the calls a sync makes. Each sync assumes the role for fifteen minutes. Shield → Posture shows the steps with your account filled in. Connect AWS.
• What it reads. The account’s root MFA and keys, password policy and S3 Block Public Access; IAM users from the credential report; IAM roles and who their trust lets in; S3 buckets; and in each enabled region, default EBS encryption, security groups, EC2 and RDS instances and CloudTrail trails.
• Honest about gaps. A region the role can’t read leaves those types partial and names the region; list the regions you use and the next sync reads in full. A setting the role can’t read is marked unread, never guessed. A sync that can’t start a session says why.
• CLI 0.10.0: tilldev shield posture add aws --account <id> [--role] [--regions], trust <id> --out . writes the trust and read policies, and role and regions change them in place. A federated connector’s first sync is now started by hand, once the account trusts it; sync_id is null until then.

October 2026 · Posture: what your infrastructure looks like

• Connectors that only read. Under Shield → Posture, connect a provider and it reads that account’s settings on a schedule, daily unless you set hourly or off, into an inventory: each resource, the settings that matter for security, and when it appeared, changed and went. Settings only, never secret values. Posture.
• Start with your own workspace. The TillDev connector reads your TillForge repositories and the policy guarding each default branch, TillSecrets service tokens, API keys and TillAuth apps.
• No cloud keys stored. Cloud accounts will connect through federation: TillDev signs a token that lasts five minutes, and your account trusts the issuer and the connector’s own subject. Providers without federation keep a read-only token sealed in TillSecrets, unsealed only for a running sync and never returned. AWS, Google Cloud, Azure, Cloudflare and DigitalOcean open next.
• An inventory you can trust. A resource leaves the inventory only when a sync read its whole type and didn’t find it. A type that couldn’t be read in full keeps what it had, and the sync says so. Removed resources stay visible for 30 days.
• CLI 0.10.0: tilldev shield posture add | show | sync | schedule | rename | token | syncs | rm | resources. sync --wait exits 1 when the sync fails. API: /api/shield/posture, documented in /openapi.json.

October 2026 · TillDrill: latency by region, and load drills

• How fast it answers, from where your users are. A latency run sends five ordinary requests to a target from each region you pick, four of them in Africa, and times connecting, the TLS handshake, the first byte and the whole answer. Six checks judge it against the target's budget: over budget, a slow first byte, one region far slower than the rest, failed requests, and the target down from some or every region. Run it now from Speed and load on a target, or set it hourly or daily. Any proof allows it. Latency.
• Load drills with a hard ceiling. Plan a ramp, steps, a constant rate or a spike up to 500 requests a second for 30 seconds to 10 minutes, GET or HEAD on one path. A plan past a cap is refused, never trimmed. Only the file on the server allows a load drill, and each one asks you to confirm the plan first. Load drills.
• It stops on its own. Every region checks its error rate and 95th percentile every 10 seconds and stops the whole drill when either passes the threshold you set. Stop it any time and it keeps what it measured. A probe that can't reach TillShield for 20 seconds stops by itself. A workspace can start 10 load drills a day, one at a time, and one target once every 15 minutes.
• Same safety as every drill. The proof is checked again, the name is resolved once, a private address refuses the run, and every request goes to the checked address. Requests carry a TillDrill user agent and an x-tilldrill-run header so you can find them in your logs. Starting, stopping and the end of every load drill are in the audit log with who started it.
• Regions and their addresses. Shield → TillDrill lists which regions can measure now and the addresses their traffic leaves from, so you can let them through your firewall. When no probe host is online in a region, latency in nine of them is measured from TillShield's edge instead. Regions.
• A scheduled latency run that finds checks newly failing at medium or above sends the same tillshield.drill.checks_failing alert, with run.profile set to latency.
• CLI 0.10.0: tilldev shield drill latency | load | stop | regions, targets latency and runs --profile. load asks before it starts unless you pass --yes, and Ctrl-C while it waits stops the drill. API: /api/shield/drill/runs/:id/stop and /api/shield/drill/regions, with profile, regions, budget_ms and plan on /api/shield/drill/targets/:id/runs, documented in /openapi.json.

October 2026 · TillDrill: scan your app builds

• 41 checks of the builds you ship. Upload an APK, an IPA, a zipped .app or a Windows or Linux build, or pick a release asset TillForge stored, under Shield → TillDrill → App builds. TillDrill reads the manifest or Info.plist, the network settings, the entitlements and signing, how each executable was built, and every string in the code and bundled files. Each check is tagged with its OWASP MASVS control and says how to fix what it finds. App builds.
• What it finds. Debuggable and test builds, backups left on, plain-text traffic and App Transport Security turned off, user-added certificates trusted, components any app can open, old target SDKs, v1-only signing, executables without PIE, NX, RELRO, stack canaries, ASLR or CFG, macOS apps without the hardened runtime, secret keys shipped in the app, weak ciphers and hashes, and unsafe hostname checks.
• The build is deleted once read. Each scan reads the build once, within fixed limits, and keeps only the report. A key found in the code is kept masked, never in full.
• New since the last build. Each scan marks the failing checks that passed on the last scan of the same app, so a release can fail on what it made worse.
• CLI 0.10.0: tilldev shield drill apps upload | from-release | releases | show | checks | rm. upload --wait exits 1 on a failing check at medium or above, or at --fail-on; --new-only counts only new failures. API: /api/shield/drill/apps, documented in /openapi.json.

October 2026 · TillDrill: passive checks

• 32 checks of what any visitor can see. A passive run reads the TLS versions and certificate, the security headers, cookies, whether plain http moves visitors to https, and the DNS records that protect mail and certificates: SPF, DMARC, CAA and DNSSEC. Each check is tagged with its OWASP Top 10 category, and with ASVS requirements where one fits, and says how to fix what it finds. Passive checks.
• Safe by construction. Every run checks the proof again first. It is refused if the hostname resolves to a private address, and it connects only to the addresses it checked. It makes only TLS handshakes, GET requests and DNS lookups, never reads a page body, and keeps cookie names, never their values.
• By hand or on a schedule. Run a target now from Shield → TillDrill or the CLI. Each proven target also repeats on its own, daily unless you set it to weekly or off. Results are grouped by section and show what was seen for each failure. A check that couldn't run says why and never counts as a pass.
• Alerts when it gets worse. A scheduled run that finds checks newly failing at medium or above sends one security alert by email, Slack and signed webhook, as tillshield.drill.checks_failing. A run that finds a verified target's proof gone sends tillshield.drill.target_lapsed.
• TillTell rules can carry a remediation note that says how to fix what they find.
• CLI 0.10.0: tilldev shield drill run | runs | runs show | checks and targets schedule. run --wait exits 1 on a failing check at medium or above, or at the level --fail-on sets, so it can gate a deploy. API: /api/shield/drill/targets/:id/runs, /api/shield/drill/runs and /api/shield/drill/checks, documented in /openapi.json.

October 2026 · TillDrill: test what you own, from the outside

• Targets come first. Shield → TillDrill holds the sites and APIs your workspace may test: a hostname, or a base URL with its scheme, port and path. Private and reserved names, bare addresses and Till's own domains are refused. The drills that run against targets arrive next. TillDrill docs.
• Prove you own it. Publish a TXT record at _tillshield. plus the hostname, or serve the same value at /.well-known/tillshield-verify on the target. A domain the workspace already verified for single sign-on, or a TillAuth custom domain, proves it with nothing to publish.
• The proof decides the drill. A DNS record proves the name, but a name can point at anyone's server. Only the file proves the server itself, so load drills need it, and active checks on a DNS proof run over https only.
• Checked again before every run. A drill won't start unless a proof it accepts holds at that moment. A proven target whose proof has gone shows as lapsed, and a DNS outage on Till's side changes nothing. Adding, proving, lapsing and removing targets are in the audit log.
• CLI 0.10.0: tilldev shield drill targets ls | add | show | check | rm. API: /api/shield/drill/targets, documented in /openapi.json.

October 2026 · Respond on the host: end a process, isolate a host

• End a process from TillShield. From a host under Shield → Endpoints, the CLI or a playbook, an owner or admin can end a process. The agent ends it only if the PID still runs the binary you named, so a PID the system has reused is left alone.
• Isolate a host. Isolation blocks all traffic, connections already open included, except loopback, DHCP, the agent's link to TillShield and up to 16 networks you leave open. The host keeps reporting, so you can watch it and release it from TillShield. It can lift by itself after 5 minutes to 30 days, even if the host can't reach TillShield, or hold until released. The agent uses nftables or iptables on Linux, pf on macOS and Windows Filtering Platform on Windows, and puts back rules that were removed.
• Signed, for one host, once. TillShield signs every command for one host. The agent checks the signature, the host and the expiry before it acts, runs each command once and reports what happened. A command the host never takes lapses, and one still waiting can be called back.
• Undoing it on the host is seen. tell-agent isolation release lifts an isolation on the host. If a host reports itself open with no release sent, TillShield records it, and the new TillTell rule “Host isolation lifted on the host” reads it. The library now holds 42 rules.
• Two new playbooks. kill-process-and-notify and isolate-host-and-notify act on the host that reported the finding. The web-shell and reverse-shell rules suggest the first; the LSASS rule suggests the second. They wait for a person unless the rule has earned unattended runs. Host playbooks.
• CLI 0.10.0: tilldev shield endpoints isolate | release | kill | commands | cancel, and --status isolated. API: /api/shield/endpoints/:id/commands. Respond.

October 2026 · Endpoints: your hosts join the stream

• The TillTell agent for Linux, macOS and Windows. It reports processes started, sign-ins and failed sign-ins, sudo and su, new accounts and group members, persistence, SSH keys, kernel modules, listening ports, cleared logs and defences turned off. It runs in user mode on each system's own event sources, with no kernel driver. TillTell rules, TillHunt, incidents and the coverage map read host events like any other source.
• Twenty rules for hosts. The library now holds 41 rules. The new ones cover reverse shells, download-and-run, encoded PowerShell, web shells, proxy execution, LSASS reads, new admins and accounts, autostart entries, services, scheduled jobs, SSH keys, kernel modules, preload hijacks, cleared logs, defences turned off, malware detections, SSH brute force, remote admin sign-ins and an agent going silent. Host events are client-reported, so each suggests notifying people rather than acting alone.
• One signed command per host. The installer checks the release's signed checksum list and the binary before installing anything, then enrols the host and starts the service. Running it again upgrades in place.
• Approval by fingerprint. Shield → Endpoints makes enrolment tokens, shown once, that expire and can be limited to a number of hosts. A new host waits until an owner or admin types the fingerprint the host printed, unless its token approves hosts on its own. Revoking a host refuses its events and stops its agent for good.
• Honest about what it can't see. Each collector on each host is live, degraded or off, with the reason. On Windows a missing audit policy, command lines left out of process events, or a disabled log is named with the command that fixes it. A host that stops checking in for 30 minutes is marked silent, and a rule can act on it.
• Secrets stay on the host. Passwords, tokens, credentials in URLs and private keys are scrubbed from command lines and log text before anything is spooled.
• CLI 0.10.0: tilldev shield endpoints ls | show | approve | revoke | rename | rm | tokens. API: /api/shield/endpoints, documented in /openapi.json.

October 2026 · TillHunt: ask the stream a question

• Search your security events in the rule grammar. Shield → TillHunt takes field:value terms in a search bar, or selections and a condition in YAML for anything richer. The TillTell rule matcher decides every match, so what a hunt finds is exactly what a rule made from it would fire on. TillHunt docs.
• Find who stands out. Group matches by up to five fields and sort by most common or rarest, zoom into the histogram, and click any value to add it, exclude it, start a new search for it or group by it. Findings and incidents link straight to a hunt for their actor, address, session or target, a day either side.
• Honest about what it read. A run checks up to 10,000 candidate events, newest first, and spends up to 3 seconds matching. When it stops short, it says how many candidates it checked, how far back it reached, and lets you scan further back from there. Ranges run from an hour to 400 days. Drill events stay out unless you include them.
• Keep the questions, and turn answers into rules. Save up to 200 hunts per workspace, each with a hypothesis and the result of its last run, or start from five starter hunts. “Make it a rule” drafts a TillTell rule with tests made from the newest match and an event the hunt passed over; it opens in the rule editor and starts in shadow.
• Owners and admins only. Every run is written to the audit log with its query, range and counts.
• CLI 0.10.0: tilldev shield hunt run | check | overview | ls | show | save | update | rm | rule. API: /api/shield/hunts, /run, /validate, /overview, /rule and /:id, documented in /openapi.json.

October 2026 · TillTell: rules of your own

• Write detection for the attacks only you would recognise. Shield → TillTell → Rules → New rule opens an editor with a working rule to start from, and “copy as new rule” on any library rule gives you one to tune. Rules use the library's YAML format and run on the same stream. Writing TillTell rules.
• Every rule proves itself before it saves. It needs a test that fires and one that stays quiet, and all of them must pass. Check shows each problem where it is in the YAML, the test results, and the rule's cost against the limits. “Try on recent events” replays up to 5,000 of your events from the last hour to the last week and shows what the rule would have fired on, without saving anything.
• One workspace can't slow another. Regexes use RE2 syntax and run in linear time, so lookaround and backreferences are refused. A workspace holds up to 100 rules, each limited to 1,000 comparisons per event and a regex size of 2,000. A rule that still runs too long is paused, and owners and admins are notified. Resume it, or save a new version.
• Your rules earn their stage like the library's. A new rule starts in shadow. Each save is a new version, and a change to what it detects drops an advisory or live rule back to shadow and clears its automation confirmation. The editor won't overwrite a version someone saved after you opened it. Deleting a rule keeps its findings and history. Every change is written to the audit log.
• The rule library page is now Rules, with the library and your workspace's rules side by side. Playbooks list the workspace rules that suggest them, and the coverage map and incidents count your rules too.
• CLI 0.10.0: tilldev shield tell rules validate | backtest | create | update | rm | resume, reading a file or stdin. validate exits 1 when a rule has problems, so it fits CI. API: /api/shield/tell/rules, /validate, /backtest and /:id/resume, documented in /openapi.json.

October 2026 · Incidents: one case per attack

• Findings that belong together become one incident. An advisory or live finding joins an open incident when it shares an account, a public address, a session or a target with it within 24 hours, or when the incident holds a rule you've linked to the finding's rule. Shield → Incidents lists them; any finding can be escalated into one by hand. Incident docs.
• Triage in one place. Set the status, severity and assignee, and read one timeline of notes, findings, playbook runs and step decisions. “Assigned to me” shows your open cases. Attach or detach findings, and merge up to 20 incidents into one.
• Resolve with a reason. Close an incident as real, a false alarm or a duplicate, and name the ATT&CK techniques it used. A real incident no rule saw lands in the rule backlog, grouped by technique, and the coverage map marks those techniques with how many incidents went unexplained.
• One alert per incident. A finding that joins an incident no longer rings the bell on its own, and drill incidents never ring. Security webhooks now carry the finding's incident_id.
• Members limited to some projects see only those projects' incidents, findings and playbook runs. An incident can only be assigned to a workspace member. Every change a person makes is written to the audit log.
• CLI 0.9.0: tilldev shield incidents ls | show | open | note | set | resolve | attach | detach | merge | backlog | dismiss | undismiss, tilldev shield tell escalate and tilldev shield tell links. API: /api/shield/incidents/…, documented in /openapi.json.

October 2026 · Playbooks: from a finding to a response

• A live finding now proposes a response. Every live TillTell rule names a playbook: tell the security recipients, make the account prove its second factor, sign it out everywhere, block the address at the edge for a fixed time, or stop an app session from sending data. The run waits under Shield → Playbooks and in the notification bell until an owner or admin decides. Playbook docs.
• Automation is earned, one step at a time. By default every step waits for a person. Turn on “Run low-blast steps on their own” and notifications and second-factor challenges go ahead alone. A rule that has earned unattended runs, with the TillTell switch on and an admin's confirmation, runs every step. A waiting run reminds the recipients once, then expires.
• Built to resist the attacker it responds to. Account actions need evidence a Till service recorded itself. Nobody can turn down a run aimed at their own account. A block refuses private addresses and fails loudly when no edge key would enforce it. A workspace sign-out reaches pages already open within about 30 seconds. Drills simulate every step and touch nobody.
• Security alerts by email, Slack and a signed webhook. Shield → Settings sets the recipients; email falls back to the workspace's owners and admins. The webhook gets its own signing secret, shown once, verified like alert-rule webhooks.
• Inline WAF rules can carry an expires_at time and lift themselves, and can match a hashed client address with ip_hashes. Hashed-address rules need @tillstack/shield-core or @tillstack/shield-cloudflare 0.3.2; older versions skip them.
• CLI: tilldev shield playbooks ls | show | runs | run | approve | reject | start | settings. API: /api/shield/playbooks/…, documented in /openapi.json.

October 2026 · TillTell: every attack has a tell

• TillTell is the detection engine inside TillShield. Every Till product's server-side record now lands on one security stream: sign-ins and second factors, keys and roles, secret reads and exports, pushes and branch protection, backup deletions, and the decisions TillGate makes at the edge. A library of 21 rules reads it, each tied to a MITRE ATT&CK technique and shipped with fixtures that must both fire and stay quiet. TillTell docs.
• Rules earn their way. Every rule starts in shadow: recorded on the TillTell page, never alerting. Owners and admins promote to advisory and live; the system only ever demotes, and only when 20% of a rule's last 20 triaged findings were false positives. Unattended playbooks need 30 clean-enough triaged findings, the workspace switch, and an admin's confirmation.
• Verdicts are for keeps. Judge a finding real, false positive, benign or duplicate; each verdict is appended, never edited, and every stage change is written to the audit log with the numbers behind it. Client-reported events never satisfy a rule that demands server evidence, and drill traffic never counts.
• An ATT&CK coverage map you can trust. Shield → TillTell → Coverage lays the Enterprise and Mobile matrices out by tactic and marks each technique no rule, some sub-techniques, rule, or proven by drill. Draft rules never count. Techniques your connected Till products cannot see are faded, and the ones they can see with no rule running are listed as gaps, each naming the product whose records would close it. How coverage is scored.
• Security event retention is yours to set: 30, 90 or 400 days, under Shield → Settings → TillTell.
• CLI 0.9.0: tilldev shield tell findings | finding | verdict | rules ls | rules show | rules stage | rules automate | coverage | settings. API: /api/shield/tell/…, documented in /openapi.json.

September 2026 · TillGate: passes that stay where they were earned

• Passes are bound to the page that solved them. When a site key has a hostname allowlist, TillGate checks that the visitor's browser is really on a listed host, so a copy of your widget on someone else's site can't mint passes for yours. The widget has to run on a page with a real origin: a sandboxed iframe needs allow-same-origin. TillGate docs.
• One attestation, at most five checks. On Fortified sites a device attestation covers up to five checks while it's valid, so one device can't vouch for a fleet of clients. Attestations that would stay valid for more than an hour are refused, including ones that leave out when they were issued.
• WAF challenges bind the pass to the solver's IP. @tillstack/shield-cloudflare 0.3.2 sends the visitor's IP when it exchanges a TillGate token for a pass cookie, so a token solved from another address is refused.

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 @tillstack/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 modes — managed, 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 — @tillstack/shield-node (Express / Connect / Fastify + raw http) and @tillstack/shield-cloudflare (Cloudflare Workers).
• Drop-in edge worker — tillshield-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 full TillDev shipping log.