Agent Threat Rules
Trefur ships the open Agent Threat Rules corpus — a community rule set for AI-agent attacks — and evaluates it against the text your agents actually handled. Matches become findings in the Risk Center.
The corpus
Agent Threat Rules is an open, MIT-licensed detection-rule corpus for AI agents, maintained at github.com/Agent-Threat-Rule/agent-threat-rules. Trefur vendors it at a pinned commit — 825 rules as of the snapshot dated 19 September 2026 — and verifies every file against a checksum manifest before a single rule is trusted. It does not auto-update: a refresh is a reviewed change, so the rules running today are the rules that were reviewed.
The rules are grouped into ten categories:
prompt-injection, context-exfiltration, tool-poisoning, agent-manipulation, privilege-escalation, skill-compromise, model-abuse, excessive-autonomy, data-poisoning, model-security.
Rule ids look like ATR-2026-00001.
Attribution
The corpus is used under the MIT licence, reproduced here in full as the licence requires:
MIT License
Copyright (c) 2026 ATR Contributors
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.Which rules run
Not every rule in the corpus can run, and not every rule that can run is on. Four things decide it, in order.
- Can this engine run it? Trefur evaluates pattern rules. Rules the corpus marks semantic, trace or behavioural are loaded so you can see them, and reported as unsupported with the reason. Patterns are compiled with Go's RE2 engine, which has no lookaround or backreferences; a rule needing one is unsupported. A rule that matches if any of its conditions hit, and lost one to the engine, runs degraded on the conditions that survived — that loses recall, never precision, because the surviving conditions are the rule author's own. A rule that needs all of its conditions is never partially run; losing one would make it over-match, so it is unsupported instead.
- Does it pass its own examples? Every rule ships true-positive and true-negative cases. Rules that fail their own cases under this engine are listed and never run for anyone — 67 of them in the current snapshot.
- Stable or experimental? The corpus marks each rule. Stable rules run by default. Experimental rules run only if you turn the tier on. Draft and deprecated rules never run and cannot be enabled.
- Your overrides. Per rule, you can switch a runnable rule on or off regardless of its tier.
Worth knowing before you plan around it: in the current snapshot 59 rules are stable and 759 are experimental. The default posture is deliberately quiet; the bulk of the corpus is behind the experimental switch. The live counts for your workspace — how many run as written, how many run degraded, how many cannot run here, how many fail their own examples — come back with every rules or settings request, and are shown above the list in the dashboard.
Turning rules on
Settings → Detection & rules → Sigma rules, then the Threat rules tab. It lists the corpus with its status, whether the engine supports it, its category, and whether it is effectively enabled for you. Filter and search there, flip the experimental tier, or override an individual rule.
The tab is part of the Team plan and above. On Free and Pro it shows an upgrade card instead of the list.
Changing which rules run is a person's decision, and only the dashboard can do it. Both writes require a signed-in admin or owner: every API credential is refused outright, so no key of any kind can change which threat rules run, and the API surface that does accept keys does not accept a session. Both writes are recorded in your audit ledger. Trying to enable a rule the corpus or the engine refuses answers 409 and explains which of the three reasons applies.
Reading the corpus is open, to any workspace member in the dashboard and to a workspace API key over the API:
| Route | Does |
|---|---|
GET /platform/v1/atr/rules | List and search, filtered by status, support, category, enabled, or free text q. Paged with page and per_page (50 by default, 500 at most). |
GET /platform/v1/atr/rules/{ruleId} | One rule in full. |
GET /platform/v1/atr/settings | The experimental switch and the counts. |
# The corpus as your workspace sees it, with the live counts.
curl -sS "https://api.trefur.com/platform/v1/atr/rules?status=stable&per_page=50" \
-H "Authorization: Bearer trf_live_<your-key>"
# One rule in full.
curl -sS https://api.trefur.com/platform/v1/atr/rules/ATR-2026-00001 \
-H "Authorization: Bearer trf_live_<your-key>"
# The experimental switch and the counts.
curl -sS https://api.trefur.com/platform/v1/atr/settings \
-H "Authorization: Bearer trf_live_<your-key>"What is evaluated
A background pass picks up finished runs — completed, failed or timed out — and evaluates the effective rule set against the text of their steps. It is not an ingest-time check: a finding appears a few minutes after the run ends, not while it is running.
Rule conditions are matched against these surfaces:
| Rule field | Trefur text |
|---|---|
user_input | Step input and tool arguments — what the caller controlled. |
tool_response | Tool results, step output and query text — what the model was asked to trust. |
tool_args, agent_output, tool_name | Exactly those. |
content | All of the above, each evaluated once. |
Text is matched both as written and after Unicode normalisation — zero-width characters stripped, look-alike Cyrillic and Greek letters folded — so the obvious evasions do not work. Normalisation can only add a match, never suppress one. A rule field the corpus defines but Trefur has no equivalent for (a tool's description, for example) is reported as having no surface rather than quietly never firing.
What a finding carries
- Category — the rule's category with an
atr_prefix:atr_prompt_injection,atr_tool_poisoning, and so on for the ten above. Filter the Risk Center on the prefix to see all of them. - Severity — the rule's own.
- A description built from the rule's identity, not from your text: which rule matched, its title, and which surface it matched on.
- Structural metadata — the detector, the corpus version, the rule id, version, status, category and subcategory, which condition matched and the rule author's description of it, the field, and the step.
- The matched excerpt, treated as customer content: a short window around the hit, subject to your workspace's redaction setting like any other content, and never included in the OCSF export.
- The rule author's recommended actions, recorded for you to read. Trefur does not execute them.
One finding per rule per run: a rule that matches in every step of a long run produces one finding, not forty.
Limits
- Pattern rules only. Semantic, trace and behavioural rules in the corpus are listed but never evaluated.
- No lookaround or backreferences — a rule that needs them cannot run here, and says so.
- A long text surface is evaluated up to a cap; a match past the cap is missed. This can lose a match, never invent one.
- Findings are advisory. A match does not block, deny or revoke anything, and the rule's recommended actions are recorded rather than performed. Enforcement is the policy layer's decision.
- Detection is after the fact. A rule cannot stop a tool call that already ran.
- Changes to the experimental switch or an override take effect from the next pass, not retroactively: runs already evaluated are not re-scanned.
- The corpus is pinned and does not update itself.
- The Threat rules tab is Team and above. Reading the corpus over the API is not gated by plan; the tab is.
- Enabling a rule, or flipping the experimental tier, is a dashboard action. There is no credential that can do it.
- Most rules in the corpus carry high or critical severity. Enabling the experimental tier broadly will produce a lot of high-severity findings; start narrow.