Every attack has a tell.

What TillTell sees

Each product writes an event with the same shape: who (a user, a service or an unknown caller, with the address and country when known), did what (an action such as auth.login_failed or secret.reveal), to what, with what outcome. Two fields matter for trust:

• trust is server when a Till service recorded the event itself and client when an app SDK reported it. Most library rules demand server evidence; a rule that would revoke or block never fires on a client-reported record.
• drill marks traffic from a labelled exercise. Drill findings prove a rule sees the pattern; they never alert and never count toward a rule’s record.

Events are kept for detection and hunting for the workspace’s retention tier: 30, 90 or 400 days. Change it under Shield → Settings → TillTell; it applies to events recorded from then on.

The rules that ship

Every rule names the ATT&CK technique it covers, the false positives to expect, a playbook it would suggest, and fixtures that must both fire and stay quiet before it ships. Some rules match one event; others correlate a burst, an order of events, a count of distinct values or a first-time value per account. The library today:

Open any rule in the library page or with tilldev shield tell rules show to read its YAML, its fixtures and its record in your workspace.

Stages: a rule earns its way

Every rule is at one of four stages in your workspace. New library rules start in shadow.

Owners and admins move rules up. The system only ever moves a rule down, and only for one reason: too many false positives. When 20% or more of the last 20 triaged findings were judged false positive or benign (once at least 10 have been triaged), the rule falls back to shadow and the move is written to the workspace audit log with the numbers behind it.

Unattended playbooks

A live rule may run its playbook without a person once it has earned it: 30 or more triaged findings, 5% or fewer false positives, and none in the last 10. Even then two humans stand in the way: the workspace switch under Shield → Settings → TillTell must be on, and an owner or admin confirms automation for that rule. A demotion clears the confirmation. Both thresholds can be overridden per workspace and per rule through the API.

Triage feeds the lifecycle

Every finding takes a verdict from any member of the workspace. Verdicts are appended, never edited, so a rule’s record is a history nobody can tidy up after the fact.

The ATT&CK map, scored honestly

Shield → TillTell → Coverage lays out the MITRE ATT&CK Enterprise and Mobile matrices by tactic and scores every technique against the rules running in your workspace. A rule counts once it is out of draft; a draft runs nowhere, so it covers nothing.

What your sources can see

ATT&CK says which kinds of records each technique is detected from. TillTell checks that against the Till products that have written to your security stream in the last 90 days. Techniques none of them can see are faded rather than counted as gaps, and the ones they can see with no running rule are listed as gaps, each naming the Till product whose records would make it visible. Process injection, in-memory malware and other endpoint-only techniques stay faded until an endpoint source exists: the map never claims what the stream cannot observe.

From the terminal

# what fired, newest first (open findings by default)
tilldev shield tell findings
tilldev shield tell findings --rule tell-cred-stuffing --stage live --json

# read one, with its record and evidence, then judge it
tilldev shield tell finding <id>
tilldev shield tell verdict <id> fp --note "shared office egress during a password reset"

# the library as your workspace runs it
tilldev shield tell rules ls
tilldev shield tell rules show tell-secret-mass-read
tilldev shield tell rules stage tell-cred-stuffing advisory --reason "two weeks clean in shadow"
tilldev shield tell rules automate tell-cred-stuffing

# the ATT&CK map, and the techniques you can see but don't cover
tilldev shield tell coverage
tilldev shield tell coverage --domain mobile
tilldev shield tell coverage --gaps

# retention and the unattended-playbook switch
tilldev shield tell settings
tilldev shield tell settings set --retention long --automation

The same operations are on the HTTP API under /api/shield/tell/…, documented in the API reference. Stage changes, automation confirmations, verdicts and settings changes all land in the workspace audit log.