Today the SecOps MCP server exposes Chronicle rule management primitives (list_security_rules, search, rule_exclusions, etc.) that operate on rules already deployed in a customer Chronicle tenant. There is currently no tool that helps a SOC analyst pull in an external open detection rule pack and load it into Chronicle through the MCP interface.
I would like to propose a new tool, ingest_external_rule_pack, that takes a URL or file path to an open rule pack (initially supporting the Agent Threat Rules YAML format), validates the rules, and surfaces them to the analyst as a structured payload that downstream MCP clients can review before the analyst chooses to push them to Chronicle via the existing rule management tools.
For background, Agent Threat Rules (ATR) is an open detection standard for AI agent threats licensed Apache-2.0. The repository is at https://github.com/Agent-Threat-Rule/agent-threat-rules. ATR currently ships 330 rules across nine attack categories (prompt-injection, tool-poisoning, skill-compromise, agent-manipulation, context-exfiltration, data-poisoning, excessive-autonomy, model-abuse, privilege-escalation) and has 97.1 percent recall on the NVIDIA garak red-team dataset. ATR rule packs are shipped in production at Cisco AI Defense and Microsoft agent-governance-toolkit, so the precedent for treating it as an upstream rule source already exists.
Proposed shape, deliberately conservative:
The new tool would live next to security_rules.py and curated_rules_management.py and would not push rules to Chronicle directly. It would only fetch, validate against a known schema, and return a normalized list with rule id, title, description, severity, taxonomy mapping, and detection pattern fields. The analyst (or downstream agent) would then decide which rules to convert to Chronicle YARA-L and submit through the existing tools. This keeps the trust boundary intact and avoids opinionated remote-rule loading inside the MCP server.
Before opening a PR I wanted to check direction:
- Is this scope consistent with how the team thinks about external rule sources, or do you prefer external rules to come through Chronicle Marketplace and not through the MCP server?
- Should the loader be ATR-specific or generic over any open YAML rule format that ships with a known schema?
- Are there existing internal patterns for rule schema validation that I should reuse?
Happy to build the implementation if the team is open to this direction. Pure-Python loader, no new heavy dependencies, follows the existing tools/ pattern.
Today the SecOps MCP server exposes Chronicle rule management primitives (list_security_rules, search, rule_exclusions, etc.) that operate on rules already deployed in a customer Chronicle tenant. There is currently no tool that helps a SOC analyst pull in an external open detection rule pack and load it into Chronicle through the MCP interface.
I would like to propose a new tool, ingest_external_rule_pack, that takes a URL or file path to an open rule pack (initially supporting the Agent Threat Rules YAML format), validates the rules, and surfaces them to the analyst as a structured payload that downstream MCP clients can review before the analyst chooses to push them to Chronicle via the existing rule management tools.
For background, Agent Threat Rules (ATR) is an open detection standard for AI agent threats licensed Apache-2.0. The repository is at https://github.com/Agent-Threat-Rule/agent-threat-rules. ATR currently ships 330 rules across nine attack categories (prompt-injection, tool-poisoning, skill-compromise, agent-manipulation, context-exfiltration, data-poisoning, excessive-autonomy, model-abuse, privilege-escalation) and has 97.1 percent recall on the NVIDIA garak red-team dataset. ATR rule packs are shipped in production at Cisco AI Defense and Microsoft agent-governance-toolkit, so the precedent for treating it as an upstream rule source already exists.
Proposed shape, deliberately conservative:
The new tool would live next to security_rules.py and curated_rules_management.py and would not push rules to Chronicle directly. It would only fetch, validate against a known schema, and return a normalized list with rule id, title, description, severity, taxonomy mapping, and detection pattern fields. The analyst (or downstream agent) would then decide which rules to convert to Chronicle YARA-L and submit through the existing tools. This keeps the trust boundary intact and avoids opinionated remote-rule loading inside the MCP server.
Before opening a PR I wanted to check direction:
Happy to build the implementation if the team is open to this direction. Pure-Python loader, no new heavy dependencies, follows the existing tools/ pattern.