threats: bridge to ATR upstream + 7 new privilege_escalation rules

[Adam Lin (eeee2345)]

Proposes an opt-in bridge to the ATR (Agent Threat Rules) upstream project, plus 7 new agent-layer rules in privilege_escalation as a concrete demonstration. Follow-up to PR #33.

What this PR adds

scripts/sync-with-atr.ts — sync script that converts ATR rules to Sage's schema and writes them to a separate file threats/agent-layer.atr-generated.yaml (never touches agent-layer.yaml directly). Opt-in: gated by enabled: true in the config.

.github/workflows/atr-sync.yml — weekly cron workflow that runs the sync and opens a DRAFT PR. Disabled by default (if: false). When enabled, the workflow opens DRAFT PRs only; no PR is ever auto-merged.

threats/.atr-bridge-config.yaml — config controlling the bridge. Lists ATR rule ids to include, ids to exclude, manual overrides, and per-category id offset (so generated ids start after Sage's existing rules in each category).

docs/INTEROP.md — explains the bridge architecture, what it handles vs what it skips, license handling, and how Sage maintainers stay in editorial control.

threats/agent-layer.yaml — 7 new rules in privilege_escalation:

• CLT-PRV-001a..e: Microsoft Semantic Kernel SessionsPythonPlugin CVE-2026-25592. MSRC disclosed 2026-05-07; five sister rules covering autostart paths (Windows Startup, /etc/cron, /etc/systemd, /Library/LaunchAgents), SK-specific tool identifiers, descriptor patterns advertising arbitrary file-write, file-write call sites, and Windows registry Run-key persistence.
• CLT-PRV-002: eval() / new Function / vm.runIn dynamic code injection with untrusted-input context.
• CLT-PRV-003: Shell metacharacter injection in tool arguments — pipe-to-shell, \$(...) with dangerous binaries, and |-chained interpreters.

How Sage maintainers stay in control

The bridge is fully opt-in. Two safety gates:

1. threats/.atr-bridge-config.yaml ships with enabled: false. The sync script refuses to run until a maintainer changes this.
2. .github/workflows/atr-sync.yml has if: false on the job. The workflow won't run on schedule until a maintainer flips this.

Even when both are enabled, the script writes to a separate file threats/agent-layer.atr-generated.yaml. Sage maintainers manually copy desired rules into the production agent-layer.yaml. The workflow opens DRAFT pull requests only.

Specific rules can be excluded via exclude_ids: [...] in the config. Specific rules can be marked manual_overrides: so a maintainer-edited version in agent-layer.yaml is never overwritten by future sync runs.

Validation

All 34 rules (27 existing from PR #33 + 7 new in this PR) parse via js-yaml and every regex compiles under the JavaScript RegExp engine that packages/core/src/threat-loader.ts uses at runtime.

Conversion validated against ATR's 432-sample benign corpus (0 FP on the source rules; the bridge preserves the patterns verbatim). I have not yet validated against Sage's 1521 test corpus — Sage maintainers should run that locally before merging.

License

Bridge code: MIT (consistent with ATR's repo license).
Rule content in threats/agent-layer.yaml: Detection Rule License 1.1 (Sage threats/ convention).
Upstream MIT attribution preserved per-rule in the # Upstream: ATR-2026-NNNNN (MIT) — <url> comment.

How the bridge handles ATR's multi-condition rules

ATR rules typically have 5-10 detection conditions per rule. The converter:

• Collapses ATR's text-channel fields (user_input, agent_output, tool_response, tool_args, tool_name, tool_description, content) to Sage's single content channel.
• Combines same-channel conditions via non-capturing regex alternation (?:r1)|(?:r2)|... when the combined regex stays under 500 chars.
• Splits into N sister Sage rules (CLT-XXX-001a, -001b, ...) when the combined regex would exceed 500 chars, so each rule's pattern stays readable and debuggable. CLT-PRV-001a..e in this PR is the result of this split applied to the SK CVE rule's 5 detection conditions.
• Extracts (?i) inline flag into Sage's rule-level case_insensitive: true.
• Downgrades action: block to require_approval when ATR confidence is below 0.85, matching Sage's existing convention.

ATR semantic-tier rules, behavioral rules, and deprecated rules are skipped with warnings; they don't appear in the output.

Reference

ATR project: https://github.com/Agent-Threat-Rule/agent-threat-rules
Bridge converter: agent-threat-rules/converters/sage (npm subpath in agent-threat-rules@2.1.3+)

[Adam Lin (eeee2345)]

Noting the PR shows mergeable_state: blocked in the GitHub API, but there are no reported CI checks and no branch protection rule visible from the outside. Is there a specific CI pipeline or review gate I should know about, or is this just waiting on a maintainer review pass? Happy to address anything that needs changes before this can merge.

[Vaclav Belak (vaclavbelak)]

Hi Adam Lin (@eeee2345), thanks for the work here, really appreciated! The ATR bridge concept is solid, and several of the new rules are genuinely useful. To answer your question first, the CI check was broken, but should be fixed now, apart from the CI tests/checks, only a review is needed. We have three blockers before this can merge.

Blocker 1: The GH Actions workflow needs to be removed

.github/workflows/atr-sync.yml grants the agent-threat-rules npm package (and peter-evans/create-pull-request@v6, pinned by tag not SHA) code execution with contents: write and pull-requests: write on this repo. If either package is compromised, the draft PR review gate is bypassed entirely. For a security tool whose threat definitions are themselves an attack surface, that's not an acceptable risk. The if: false gate doesn't help, it's one line in a file we've already merged.

The sync script (sync-with-atr.ts) is fine, running it locally and opening a PR manually is a workflow we can support. Please drop the workflow YAML from this PR.

Blocker 2: No tests

Every threat category in this repo has a dedicated *-threats.test.ts file with explicit match cases (inputs that should fire) and benign non-match cases (inputs that should not). The seven new rules in this PR have none. This is a hard requirement, we won't merge rules we can't verify won't regress under future refactors, and writing the benign cases is also the fastest way to discover false-positive problems before they ship.

Blocker 3: Three of the seven new rules need rework

CLT-PRV-001a/b/d/e look good, specific, CVE-anchored, block at 0.9 confidence is justified. The other three have FP problems that would be immediately obvious from benign test cases:

• CLT-PRV-001c (matches "arbitrary"/"user-supplied"/"unvalidated" path language): this is documentation and error-handling vocabulary. Any codebase that handles user input paths triggers it, including Sage's own.
• CLT-PRV-002 (eval(), Function(), vm.runInNewContext() on content): these appear in React, build tools, test fixtures, and template engines. Will generate require_approval noise on legitimate daily work for any JS/TS developer.
• CLT-PRV-003 (shell metacharacters on content): writing any shell script fires this. The 0.65 confidence suggests ATR itself wasn't confident here either.

ATR's 432-sample benign corpus might not be calibrated against developer workflows, Sage's user population writes code with an AI agent, which presumably looks very different from that corpus. We've had to remove some rules from the previous contribution for the same reason.

For these three: either tighten the pattern to anchor it to a specific attack context, or drop them from this PR and revisit when the patterns are ready. In both cases, tests are required.

The four CVE-specific rules plus the script, config, and docs can merge once the workflow is dropped and tests are added for them.

Thanks again for your contribution, some of the rules you previously contributed are genuinely useful and will likely ship in the next release, this is just to make sure we don't break anything for our users. Let me know pls if I can be of any help.

Best wishes, Vaclav

[Adam Lin (eeee2345)]

Thanks Vaclav — sharp review, and the FP point on the dev corpus is fair. All three addressed:

B1 — dropped the workflow. Agreed: handing the npm package and the PR-creation action write access is the wrong trade for a security repo. The sync script stays as a local opt-in; I'll run it and open PRs by hand. Also cleaned up the three docs that referenced the removed workflow.

B3 — dropped CLT-PRV-001c (path vocabulary), 002 (eval/Function), and 003 (shell metacharacters). They fire on ordinary developer work, and the 432-sample benign corpus doesn't represent users who write code with an agent. Kept the four CVE-anchored rules (001a/b/d/e): the SK SessionsPythonPlugin file-write into autostart paths and the Run-key persistence, each anchored to a specific call site or path.

B2 — added agent-layer-threats.test.ts with match and benign cases for all four kept rules. The benign cases cover the exact FP shapes you flagged: ordinary build paths, normal fs.writeFile targets, session-management vocabulary, and the words register/regex.

So this PR is now the four CVE rules plus the script, config, and docs. Happy to revisit the three dropped rules later with tighter, context-anchored patterns. Thanks for shepherding this.