Hire an AI threat detection rule planner

Everything it can hand back

Your task sets the actual outputs. The specialist picks the methods that cover them.

• A Sigma detection rule for the named technique, built against the log sources you actually have.
• A false-positive list: the normal activity most likely to trigger it, named before deployment, not after.
• A MITRE ATT&CK coverage note: where this technique sits, and what's still a gap nearby.
• A validation plan: how to confirm the rule fires on the real technique and stays quiet on normal activity.

How it does the job well

• Write the rule only against log sources the user says they actually collect. If a rule would need a source they don't have, say so plainly instead of writing a rule that will never fire.
• Always include false-positive cases. A rule with no stated false-positive analysis is not a finished deliverable here.
• Map every rule to a MITRE ATT&CK technique and tactic, so coverage can be tracked over time.
• Name the asset, the threat and the impact before recommending controls.
• Rank findings by real risk (likelihood and impact), with evidence for each.
• Prefer fixes that remove a problem over warnings that rely on people.
• Cite the exact law, standard or clause for compliance and legal points, and recommend qualified review.

Mistakes it avoids

• Writing a technique so broad ("detect ransomware") that the rule can't be specific or testable. Ask the user to name one technique.
• Copying the profile's sample Sigma rules or coverage tables as if they described the user's own environment.
• Long lists of generic issues with no evidence they apply.
• Testing or scanning systems without permission.
• Presenting a legal opinion as final.

What a good result looks like

An example, not your task: You know the attacker technique you want to detect (from a MITRE ATT&CK ID, a threat report, or your own incident) and want a rule for it.

• Detection rule. A Sigma rule for the named technique, built against the log sources you have.
• False positive cases. Normal activity most likely to trigger the rule, and how to exclude it.
• MITRE ATT&CK mapping. Where the technique sits on the framework, and nearby coverage gaps.
• Validation plan. How to confirm the rule fires on the real technique and stays quiet on normal activity.
• Assumptions and checks. What the agent assumed and which facts you still need to confirm.

How the work is checked

• Each finding has a location, evidence, severity and a specific fix.
• Likely false positives are checked and removed.
• Items that need a lawyer or auditor are clearly marked.
• States which checks passed, failed or could not run, and names missing inputs.

These checks have not been run against a model yet. Your AI uses them to check its own work.

Capabilities

• Confirm the technique and log sources. It names the exact technique to detect and checks it against the log sources you say you actually collect.
• Write the Sigma rule. It builds a vendor-neutral detection rule for that technique, so it isn't locked to one SIEM.
• Name the false positives. It lists the normal activity most likely to look like the technique, before the rule ever reaches production.
• Map to MITRE ATT&CK. It places the technique on the framework and notes nearby techniques that are still a gap.
• Plan validation. It describes how to confirm the rule fires on the real technique (via a known-bad sample or simulation) and stays quiet otherwise.

How the role works

1. Checks your task, context and available tools.
2. Picks the methods needed and prepares a work plan.
3. Carries out supported tasks, with each method's limits and review gates.
4. Checks the real deliverables and corrects supported faults.
5. Hands back files, evidence and unresolved gaps.

Your specialist's working setup

Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.

Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.

Use this specialist through MCP or the API

Call prepare_specialist with role_id security-threat-detection-engineer only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.

For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.

Complete ZIP: Download base specialist. API: GET /api/v1/specialists/security-threat-detection-engineer/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.

Inputs and helpful context

The specialist starts from the task brief. Only active methods require their inputs.

For the primary method, when used

• The technique you want to detect, named plainly or by its MITRE ATT&CK ID, and why (a threat report, a past incident, a known gap).
• The log sources you actually collect (process logs, PowerShell logging, cloud audit logs, and so on) and how long you keep them.
• Your SIEM or detection platform, if you want the rule compiled to a specific query language (optional, Sigma works everywhere).
• Any known-benign activity that looks similar to the technique, so false positives can be named up front (optional).

Helpful context (optional)

• A sample of the actual log lines you'd expect the technique to produce.
• Your current detection rule list, so new coverage doesn't duplicate an existing rule.
• A recent threat report or incident that named the technique.

Tools and access

• Claude, ChatGPT or Gemini: Any good chat AI can write the Sigma rule and the ATT&CK mapping from what you describe.

Functions and deliverables

• Threat detection rule planner: Name the technique and your log sources. Get a Sigma detection rule, its false-positive cases, and where it sits in your MITRE ATT&CK coverage.
  • A Sigma detection rule for the named technique, built against the log sources you actually have.
  • A false-positive list: the normal activity most likely to trigger it, named before deployment, not after.
  • A MITRE ATT&CK coverage note: where this technique sits, and what's still a gap nearby.
  • A validation plan: how to confirm the rule fires on the real technique and stays quiet on normal activity.
  Source: Michael Sitarzewski and Agency Agents contributors.
• Security alert rule builder: Build a detection rule from one threat behavior and redacted logs. You get test cases and a report that says which checks were actually run.
  • A draft detection rule.
  • A map from each rule condition to a log field.
  • Test events that should match, should not match, or look similar, with expected results.
  • Real test results, or a clear list of checks that were not run.
  Source: Michael Sitarzewski and Agency Agents contributors.
• AI error detection lesson planner: Plan a classroom activity where students catch what AI gets wrong about a subject they know well. Name the topic and age group to start.
  • A step-by-step student activity
  • Question prompts for the AI
  • A checklist of error types to look for
  • A discussion plan
  • Reflection questions
  Source: Gareth Manning.
• Threat model writer: Share your repository and deployment context. Get a Markdown report with ranked threats and fixes.
  • A map of components and trust boundaries
  • Ranked abuse paths
  • Fixes for each threat
  • A Markdown threat model
  • A list of assumptions you confirmed
  Source: OpenAI.
• AI project context organiser: Share your project and next task. Get a short rules file, a focused file list and a clear handoff for later sessions.
  • A ready rules file for your project
  • A list of which files to load for each task
  • Rules for when to reset or trim the session
  • A checklist for spotting drifting answers
  Source: Addy Osmani.

Tasks you can use it for

• You know the attacker technique you want to detect (from a MITRE ATT&CK ID, a threat report, or your own incident) and want a rule for it.
• You want to know which MITRE ATT&CK techniques your current detections actually cover, and which are gaps.
• A detection rule is too noisy and you want its false-positive cases named so it can be tuned, not just muted.
• You're setting up detection-as-code and want rules written in Sigma so they aren't locked to one SIEM.

Limits to check before starting

• You have an active incident right now, not a detection gap to close. Use the Security incident responder.
• You want to test whether an attack actually gets through your defenses. Use the Penetration test planner.
• You want a one-time snapshot of your overall security posture, not an ongoing detection rule. Use the Security posture auditor.

Best way to use this role

Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.

• Download the pack from this page and add it to your AI as a skill, or paste SKILL.md then references/source-agent.md into a new chat.
• Name the technique you want to detect and the log sources you actually collect.
• Say which SIEM you use if you want the rule compiled to its query language; otherwise you'll get Sigma.
• Say "Write the detection rule, its false-positive cases, and where this sits in my ATT&CK coverage."
• Check the log sources it assumes against what you actually collect. A rule needing a log you don't have won't fire.
• Run the validation plan against real or simulated activity before you trust the rule in production.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/security-threat-detection-engineer for its role instructions and pinned sources.

This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.