DEV Community: Ajay Nyayapathi

I Taught My AI Agent to Write YARA-L Rules That Actually Compile

Ajay Nyayapathi — Sun, 25 Oct 2026 13:06:09 +0000

Ask a general AI model to write a YARA-L rule and you will usually get something that looks right and fails in the Rules Editor.

These five mistakes show up again and again:

metadata.event_type = "LOGIN". That value doesn't exist. The enum is USER_LOGIN.
target.port = "443". Port is an integer. Quoting it fails type checking.
Two event variables with no shared placeholder in match. The rule either won't compile or joins everything to everything.
Raw event fields in outcome inside a rule that has a match section. Every one needs an aggregate like count() or array_distinct().
Invented UDM fields. The model guesses a field name that sounds plausible and isn't in your parser's output.

None of these are hard problems. They're the kind of thing a senior detection engineer catches in review. The model just doesn't know the rules of the language well enough, and it has no way to check its own work.

So I wrote those rules down and packaged them as an Agent Skill.

Repo: https://github.com/ajaynyayapathi/yara-l-skill

What an Agent Skill is

A skill is a folder with a SKILL.md file in it. The file holds instructions the agent loads only when a task matches its description. You can add reference docs, examples, and scripts alongside it.

Anthropic released the format as an open standard in December 2025. The spec lives at agentskills.io, and Claude Code, GitHub Copilot, OpenAI Codex, Gemini CLI, and Cursor all read it. Write the skill once and it works across all of them.

What this skill does

Give your agent a threat description, an ATT&CK technique, a Sigma rule, or an SPL/KQL query. It follows an 8 step workflow and returns six things:

The detection logic in one sentence
A complete YARA-L 2.0 rule with full meta, outcome, and $risk_score
A list of UDM fields you need to verify against your own parser
The reference lists and data tables to create, with sample rows
One test case that should fire and one that should not
The two most likely false positive sources and how to tune them out

Item 3 matters most. Parsers differ in which UDM fields they fill and which values they write. A failed login might land as BLOCK in one feed and FAIL in another. The skill marks every uncertain field with a // VERIFY: comment instead of guessing, so you know exactly what to check before you deploy.

A real example: device code phishing

In February 2025 Microsoft reported that Storm-2372 had been running device code phishing campaigns against governments, NGOs, and defense, energy, and telecom organizations. The attacker sends a fake Teams meeting invite. The victim enters a code on the real Microsoft login page. The attacker walks away with valid tokens, and MFA never had a chance to stop it.

Here's the rule the skill produces for "alert on device code sign ins from users outside an approved list":

yara
rule entra_device_code_signin_unapproved_user {

  meta:
    author = "community"
    description = "Successful OAuth device code sign in by an account not approved for device code flow."
    severity = "HIGH"
    priority = "HIGH"
    mitre_attack_tactic = "Credential Access"
    mitre_attack_technique = "T1528"
    reference = "https://attack.mitre.org/techniques/T1528/"
    false_positives = "Azure CLI and PowerShell logins with --use-device-code, conference room and IoT devices."
    rule_version = "1.0"
    yara_version = "YL2.0"

  events:
    $e.metadata.event_type = "USER_LOGIN"
    // VERIFY: confirm log_type for your Entra ID sign in feed.
    $e.metadata.log_type = "AZURE_AD"
    // VERIFY: the field holding authenticationProtocol differs by parser version.
    $e.additional.fields["authenticationProtocol"] = "deviceCode" nocase
    $e.security_result.action = "ALLOW"
    $e.target.user.userid = $user
    not $e.target.user.userid in %device_code_approved_users.userid

  match:
    $user over 1h

  outcome:
    $risk_score = 75
    $risk_entity_to_score = $user
    $signin_count = count($e.metadata.id)
    $source_ips = array_distinct($e.principal.ip)
    $applications = array_distinct($e.target.application)
    $countries = array_distinct($e.principal.location.country_or_region)

  condition:
    $e
}

Three choices in this rule are worth pointing out:

The exclusion lives in a data table. Conference rooms and CLI users change every month. Your SOC updates a CSV and never touches the rule.
match: $user over 1h groups repeat sign ins. One user who signs in five times produces one alert with $signin_count = 5, not five alerts.
Every outcome field is aggregated. That's required once a match section exists, and it's the mistake models make most often.

The repo ships four example rules, one for each shape you'll write most: single event (certutil downloading a payload), sequence (brute force followed by success), absence (EDR sensor stopped and never came back), and data table lookup (the rule above).

The linter

Instructions only get you so far. The agent still needs a way to check its work before you see it.

The skill includes lint_rule.py, a Python script with no dependencies that catches structural mistakes offline:

$ python3 scripts/lint_rule.py bad_rule.yaral
[FAIL] bad_rule.yaral
  error:   sections out of order: ['events', 'meta', 'outcome', 'condition']; expected order ['meta', 'events', 'match', 'outcome', 'condition', 'options']
  error:   unknown metadata.event_type value "LOGIN"
  error:   integer field ending '.port' compared to a quoted string
  error:   multiple event variables but no match section
  error:   absence condition (!$var) requires a match section
  warning: no $risk_score in outcome

The skill tells the agent to lint every rule, fix every error, and pass the warnings along to you. When the agent can run code, you get a rule that has already been through one review pass.

A clean lint result doesn't mean the rule compiles. Only the SecOps compiler can tell you that. The linter catches the cheap mistakes so your time goes to the logic.

Install it

Copy one folder.

bash
git clone https://github.com/ajaynyayapathi/yara-l-skill.git
cp -r yara-l-skill/skills/yara-l-authoring ~/.claude/skills/

Agent                       Personal               Project
Claude Code               ~/.claude/skills/    .claude/skills/
GitHub Copilot/VS Code       ~/.copilot/skills/   .github/skills/
Codex and other clients      ~/.agents/skills/    .agents/skills/

For Claude.ai, zip the yara-l-authoring folder and upload it as a custom skill.

Then try a prompt like this:

Write a YARA-L rule for 10 failed logins followed by a success within 30 minutes.

How I'd roll out any rule it writes

Save the rule with alerting off.
Run a retrohunt over the last 7 to 30 days.
If a medium severity rule produces more than 20 detections a day, tune it before you go further.
Have an analyst review 10 sample detections.
Turn on alerting.

The skill includes this checklist, so the agent says the same thing every time. AI-written detection content needs the same review gate as human-written content. The skill makes that review faster. It doesn't replace it.

Contribute

The most useful contributions right now:

UDM field corrections from parsers you run in production
New example rules, each with a should fire and a should not fire case
New linter checks for mistakes you've seen in review

Open a PR on the repo. If you run it against your own tenant and a // VERIFY: field turns out wrong for your parser, I want to hear about it.

YARA-L, Google Security Operations, and Chronicle are trademarks of Google LLC. This project is not affiliated with or endorsed by Google.

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.