4. Indicators

FM-4.1 Grading records#

Indicators are rules kept as data, versioned, and shared by every tool that grades records. Before rules run, each recorded URL is unwrapped: relays, translate proxies, URL-valued parameters, data: URLs and base64 values are peeled into layers, so rules see every hop and the real target (methodology).

• Each rule counts at most once per record, whichever layer it matched.
• A record's score adds the weights of the distinct rules that fired. Rules that read the same artifact are one piece of evidence, not several, and count once per independence group; context kinds together count at most one below the suggestive threshold (FM-4.11).
• The score is graded against two thresholds into a tier (FM-1.5). A rule marked significant puts a record in the top tier on its own.
• One relay hit is never enough. No rule for something ordinary users do may reach the suggestive threshold alone. A relay, a cache-buster or a self-identification needs a second, independent indicator, and that indicator is not another context hit (FM-4.11).
• A tier measures payload and tool use. It says what a record contains, not whether an agent sent it or whether the agent went beyond its task. Those are separate questions with their own evidence (chapter 15).

FM-4.2 Rule anatomy#

A check exists because some shapes need counting or comparing. repeated_token (on a parameter value) wants one word of three characters or more, or a phrase of two or three words, repeated five or more times in a row (FM-4.5); short refrains and one long run of a letter fail it. ua_platform_mismatch (on a Sec-CH-UA-Platform header) passes when the header's platform hint names another desktop system than the request's user agent, the mark of a browser presenting a borrowed user agent; mobile systems are never compared.

Toolkit: each rule in the rules file names its tactic (T1 to T7) or is marked artifact, and a file naming an unknown tactic, or the cluster-level T8 or T9, fails to load. A check on a rule whose target is not the one the check reads, or an unknown check, also stops the file loading. Evaluation groups recall by the tactics of the rules that fired (statistics). The STIX run object derives its tactics from each rule's kind, using the defaults in FM-4.4.

FM-4.3 The SC-T tactic taxonomy#

Tactics say what an agent was doing, independent of how a rule detected it. Reports and notices group evidence by tactic.

SC-T8 and SC-T9 are cluster- and fleet-level judgments. They are reported as Inference (FM-7.6) with the evidence listed, never as a rule match. The signals for SC-T9 are in FM-4.10.

FM-4.4 Default tactics by rule kind#

The tactic a rule of each kind is evidence of when nothing more specific is known. A rule's own tactic may differ where its match shows more, and a report cites the rule's own.

FM-4.5 Artifact families#

Artifacts are traces of how an agent was built, not of what it tried to do. They help separate agents from people and link runs, but each is shared by many unrelated clients, so most never score or link.

Why hints never score or link: letting a widely shared trait raise a score flags ordinary clients, and letting it link merges unrelated clusters, an error every later step inherits (FM-14.6).

Stale knowledge and prose language say something about where the requests were written: a model writes from what its training data knew, and an agent prompted in one language often searches a foreign site in it. Both are inputs to the model-family and operator layers at most (FM-7.5), never a name.

Toolkit: retired endpoints and old clients are listed under [[stale]] in the rules file, each with its source; a cluster lists each entry two or more members carry (stale_knowledge), with older API versions as older_api_version. Prose is at least six words with letters, or twelve characters of a script written without spaces; each cluster counts its prose values, their languages and how many mismatch their target's country domain (prose). Each cluster counts its members' relay stacks (relay_stacks), and reports list those of two or more hops (methodology).

FM-4.6 Cross-walk to MITRE ATLAS and ATT&CK#

The table maps each SC-T tactic to the closest ATLAS technique (data version 2026.09) and ATT&CK technique where the mapping is defensible. Fit says how closely: close (same behaviour), partial (overlaps; the framework's technique assumes a different actor or scope), none.

ATLAS and ATT&CK describe adversaries using systems. Swarmchasing describes agents whose operator may not intend the behaviour, so a mapping says what the agent did, not that anyone intended it. ATLAS notes this itself for attack-path adaptation, which agents can show while pursuing a benign objective.

The OWASP Top 10 for Agentic Applications column, and the agent-specific ATLAS techniques, are in FM-12.4. A STIX or MISP export carries both tables' entries for each tactic (FM-12.2). ATLAS ids and names are taken from the published ATLAS data file; ATT&CK ids from the ATT&CK technique pages (references). Re-check both when either framework releases a new version, since techniques are renamed and merged.

FM-4.7 Rule-writing standard#

A rule enters the shared set only when:

1. It has a basis. Either a public reference that documents the behaviour (an incident report, a vendor advisory), or reviewed examples from casework. The reference goes in the rule's comment or the change's description.
2. It has positives and hard negatives. At least one labelled agent record it should catch, and at least one benign record built to trip it (the same words in a search, the same service used normally) go into the evaluation set with the rule.
3. It passes the eval gate. Precision and recall on the evaluation set stay at or above the floors, and the floors never go down to land a rule (FM-9.2).
4. Its numbers are recorded. The change records before and after precision and recall at both tiers, and the rule's own precision.
5. Its weight is honest. Anything ordinary users do stays below the suggestive threshold alone. significant is for payloads with no ordinary use. link is for values one operator would hold, never for values many share.

Synthetic examples are allowed and marked synthetic. Examples are never copied from a source whose terms forbid redistribution (FM-3.4).

FM-4.8 Rule versions and pinning#

A rules set carries a version. Each case pins the version it was opened with, so its reports, notices and evidence bundles use one set throughout, and a rules change cannot silently move a tier between drafting and sending. Re-pinning is an admin decision, logged in the case, after listing the records whose tier would change (cases).

FM-4.9 Benchmark targets and declared testing#

Two hints bear on how a case is handled rather than on what the agent did. Neither scores, and neither lowers a score.

• Benchmark targets. Public sites built to be tested against: intentionally vulnerable demo sites, and the environments agent benchmarks run in. A cluster probing one is likely evaluation or training activity, and reports say so. It keeps its tier, because an agent under evaluation can still misbehave in the same run, and its requests to other hosts are what matter.
• Declared testing. Text in a request announcing a test: "authorized security test" in a user agent, a bug-bounty header, "pentest" next to an email address or bounty handle. It is self-identification, which anyone can write and an agent can copy from its prompt (FM-14.1). The admin checks the claim with the owner it names (FM-10.6). The declaring text and contact stay in case notes: they never appear in a report to a provider, a notice or a public page, because the claim is unchecked and the contact may be a person.

Toolkit: benchmark targets are listed under [[benchmark]] in the rules file, each with its source, and counted per cluster by entry (benchmarks). Declared testing is listed per cluster with its contact (declared) and appears in internal reports only; the browser workbench does not show it.

FM-4.10 Interaction signals#

Interaction between agents rarely leaves a direct trace in public records. A record shows one request; it does not show who read its result. No published case detects agent-to-agent coordination from public traffic alone; the strongest published reconstructions match activity timing against a provider's own account. The standard therefore treats every SC-T9 signal as weak to moderate, and a swarm claim as several signals together.

Identifiers are matched as strings already in the records. Reading an artifact, an inbox or a channel to see what was written is never part of the method (FM-3.2). How the signals are found and recorded is in FM-5.12.

FM-4.11 Independence groups and the context cap#

A score adds weights as if each rule were a separate observation. Rules that read the same artifact are not. One fetch program carried through an echo service fires the echo rule, the script rule, the fetch rule and the title-write rule together, and a benign data task done that way (a program that fetches a TV schedule) reaches the top tier on its tool use alone. Two relays in one route, or a relay and a vendor name in the same query, are two context hits that ordinary clients produce together. Summing them grades how a request was written, not how much evidence it holds.

The standard therefore scores with two constraints:

• Independence groups. Rules that read the same artifact in the same request must share a group. A group counts once per record, at the largest weight among its rules that fired. Ungrouped rules count as before. A significant rule still sets the top tier on its own.
• Context cap. Context kinds (relay, cache buster, self-identification, header, outcome) together contribute at most one less than the suggestive threshold. A record whose only hits are context kinds stays noise, however many it has.

A group is a statement about correlation, so it is set from evidence: two rules belong together when, on labelled records, one rarely fires without the other on the same request. The default groups:

The echo service (carrier.httpbin) is in program: its base64 endpoint serves the page the URL carries, so the echo rule and the script rule read one artifact. Counted apart, a page with a script served from the echo service's own endpoints, an ordinary developer test, reaches suggestive with no other indicator, and the pre-era negative control (FM-9.13) shows it doing so on real captures. A program that makes requests (a fetch, a request object, a self-submitting form) still reaches suggestive through the group's heavier rules. A change of groups is a rule change and passes the FM-4.7 standard, with its before and after numbers.

What changes: a program through an echo service is suggestive, not significant, unless a payload or a channel comes with it, and a script page with no request through one is noise; a run tag with its own parameter name is one indicator; two relays, or a relay and a vendor name, are noise. Records with an attack payload are unaffected, because payload rules are significant. Toolkit: Rules::score counts each group once at its largest fired weight and caps the context kinds together at one below suggestive; the default groups are set in rules/default.toml, and the group field and the cap are normative in SC-Rules v1, with conformance vectors for the records whose tier they decide.

Every section by id, with search

Source: docs/manual/04-indicators.md