I found an open issue on Google's own security repo, so I built the missing piece

In May 2026, Microsoft's Semantic Kernel shipped two CVEs in the same week. CVE-2026-26030 let an attacker chain a lambda expression into arbitrary code execution through an AI agent's tool-call handling. The fix landed inside 48 hours because a detection rule already existed for it, an open, community-maintained standard called Agent Threat Rules (ATR) had a rule live and merged into Microsoft's own Agent Governance Toolkit within hours of the CVE disclosure.

ATR has grown fast. 680+ rules, adopted into Microsoft's Agent Governance Toolkit, Cisco AI Defense, MISP, and cross-listed by SigmaHQ as a sibling format to Sigma itself. Think Sigma for SIEM detection, YARA for malware signatures, ATR for AI agent threats: prompt injection, tool poisoning, context exfiltration, skill supply-chain attacks.

Here's what stopped me: Google Security Operations (Chronicle) had no way to use any of it.

The gap was already documented, just unsolved

I went looking and found an open issue on Google's own google/mcp-security repository, someone had asked for exactly this: a way to pull external rule packs like ATR into Chronicle through the SecOps MCP server. The issue laid out the shape of the tool needed. Nobody had built the piece it depended on: something that actually translates ATR's rule format into Chronicle's detection language, YARA-L.

So I built it.

What atr-to-yaral does

It's a small Python tool. You point it at an ATR rule:

yaml
title: Direct Prompt Injection via User Input
id: ATR-2026-00001
severity: high
detection:
  condition: any
  conditions:
    - field: content
      operator: regex
      value: "(?i)ignore\\s+(all\\s+)?(previous|prior|above)\\s+instructions"
    - field: content
      operator: regex
      value: "(?i)disregard\\s+(your|the)\\s+system\\s+prompt"

And it produces a working YARA-L 2.0 rule:

rule ATR_2026_00001 {
  meta:
    atr_id = "ATR-2026-00001"
    title = "Direct Prompt Injection via User Input"
    severity = "HIGH"
    mitre_atlas = "AML.T0051 - LLM Prompt Injection"
    source = "Converted from Agent Threat Rules (ATR)"

  events:
    $e.metadata.description = /(?:(?i)ignore\s+(all\s+)?(previous|prior|above)\s+instructions)|(?:(?i)disregard\s+(your|the)\s+system\s+prompt)/ nocase

  condition:
    $e
}

Point it at a whole directory of ATR rules and it batch-converts everything it can, skipping and reporting anything outside its current scope rather than failing the whole run.

The honest limitation, stated up front

ATR rules match against LLM input, tool-call arguments, and SKILL.md content. Chronicle's UDM has no standard field for any of that yet, because there's no standard way to ingest AI agent telemetry into Chronicle today. That's a real, unsolved problem industry-wide, not a gap in this tool specifically.

The converter defaults to a placeholder UDM field and makes you configure the real one for your ingestion pipeline. I'd rather ship something that says plainly what it doesn't know than something that looks finished and quietly fires on the wrong field forever.

For the deployment step, once you have .yaral files, I pointed the README at Google's own chronicle/detection-rules tool, content_manager, which validates and pushes rules into a live Chronicle instance. The full path looks like this:

ATR YAML rules → atr-to-yaral → .yaral files → content_manager → live in Chronicle

What's next

I opened an integration request on ATR's own repository, and I'm planning to comment on the original Google issue once there's more real-world usage to point to. If you run Chronicle and want to try converting a batch of ATR rules against your own pipeline, I'd genuinely like to hear what breaks.

Repo: https://github.com/ajaynyayapathi/ATR-to-Yara-L-Converter

Currently supports regex-based ATR conditions (the majority of the published rule set) with both AND and OR condition logic. Non-regex operators and multi-event correlation rules are documented as out of scope for now, not silently dropped.