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

Ajay Nyayapathi — Sat, 12 Sep 2026 21:02:36 +0000

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.

Gmail AI Threat Scanner: An Open‑Source Security Layer for Your Inbox

Ajay Nyayapathi — Sat, 12 Sep 2026 01:33:22 +0000

Email remains the most common entry point for cyberattacks, yet most people rely entirely on whatever built‑in filtering their provider offers. I wanted something more transparent, more customizable, and more aligned with modern AI‑driven threat analysis. So I built Gmail AI Threat Scanner.

This project connects to your Gmail inbox, analyzes messages using AI‑powered threat detection, and flags suspicious content — all while running locally so you stay in control.

What it does
Scans Gmail messages using AI models for phishing, fraud, and social engineering indicators

Highlights risky emails with clear explanations

Works entirely client‑side using OAuth (no passwords, no server storage)

Lets you review threats in a simple, readable interface

Why I built it
I wanted a lightweight, open‑source tool that gives users visibility into potential threats without requiring enterprise‑grade infrastructure. Security shouldn’t be locked behind corporate paywalls — especially when AI can help individuals defend themselves.

Roadmap

Add multi‑model ensemble scoring
Add attachment scanning
Learning from False Positives

GitHub Repo
🔗 https://github.com/ajaynyayapathi/Gmail-AI-Threat-Scanner

If you try it, I’d love feedback, issues, or PRs.

DEV Community: Ajay Nyayapathi

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

Gmail AI Threat Scanner: An Open‑Source Security Layer for Your Inbox