[New Rule] Expand LLM and MCP agent detection coverage under rules/integrations/llm/

Following CONTRIBUTING.md guidance to file an issue before opening a PR.

This is a meta proposal to expand detection coverage for AI agent and MCP (Model Context Protocol) attacks within rules/integrations/. Existing aws_bedrock and azure_openai integrations already detect provider-side guardrail signals. This proposal covers the agent-runtime layer where MCP tool dispatch, prompt injection, and skill compromise occur, which is the layer most LLM observability stacks now ship logs for.

What we would add

8 to 12 new rules under rules/integrations/llm/ derived from the open Agent Threat Rules catalog (Apache 2.0). The catalog has 330 rules across 9 categories with 100% NIST AI RMF (AI 600 to 1) coverage and 97.1% recall on garak prompt injection benchmarks. Cisco AI Defense and Microsoft Agent Governance Toolkit have merged ATR rule packs in 2026.

Coverage targets for the v0 PR

MCP tool dispatch with parameter manipulation matching known prompt injection signatures
Indirect prompt injection via fetched content that triggers tool call loops
Skill or system prompt extraction attempts via probing patterns
Excessive tool invocation rate from a single agent session indicating agent loop attack
Attempted egress to attacker controlled domains via agent fetch tools
Tool definition tampering between sessions for persistent prompt injection
Sensitive data exfiltration via agent summarization tools
MCP server impersonation via untrusted server registration
Subagent spawning with elevated tool permissions

Schema fit

Each rule would use ESQL or KQL with ECS fields. Where new event categories are needed (gen_ai.tool.call, gen_ai.tool.parameters, mcp.server.id) we would link to the corresponding elastic ecs PR rather than introducing schema gaps. The aws_bedrock integration already uses gen_ai.policy.name and gen_ai.compliance.violation_code, so extending into MCP and agent runtime fields follows the existing precedent.

MITRE mapping

All rules map to MITRE ATLAS techniques (T0051 LLM Prompt Injection, T0054 LLM Jailbreak, T0061 LLM Plugin Compromise) and where applicable to MITRE ATT&CK Initial Access (T1190) and Defense Evasion subtechniques.

Maturity and noise expectations

We would propose maturity = development for the initial PR with documented FP rates from a 53,577 sample benign skill corpus. The rules with measured wild_fp_rate = 0 across that corpus would be candidates for production after Elastic team review.

Why this is worth a separate integration directory

LLM and agent attacks are operationally distinct from cloud infra attacks. Practitioners running OpenTelemetry GenAI semantic conventions or LangSmith ship the same gen_ai.* fields regardless of provider, so a provider neutral rules/integrations/llm/ directory would be reusable across aws_bedrock, azure_openai, and self hosted inference setups.

Open questions for the team before opening a PR

Is rules/integrations/llm/ the right path, or should this nest under each provider integration?
Are there in flight ECS PRs we should align with for gen_ai.tool.* fields?
Would you prefer 8 to 12 rules in one PR or split into smaller PRs by attack technique family?
Any precedent for tagging rules with framework references beyond MITRE ATLAS (e.g. NIST AI RMF, OWASP Agentic AI Top 10)?

Related work

Sigma rules submission filed at SigmaHQ/sigma#5994 for the same rule families in Sigma format.
Semgrep code scanning rules filed at semgrep/semgrep-rules#3842.
ATR catalog at https://github.com/Agent-Threat-Rule/agent-threat-rules
NIST AI RMF cross walk in OSCAL format at https://github.com/Agent-Threat-Rule/ai-rmf-oscal-catalog (CC0)

Happy to scope this down or split per the team's guidance. CLA can be signed as soon as we have a green light on the directory location.