SigmaHQ carries 3,783 rules. Searched for copilot, gemini, mcp, prompt injection, or model context protocol, it returns zero. Google's public detection repository carries 917 rules and returns zero for the same terms. If your team has been told to write AI detections and has gone looking for prior art, that absence is what you found, and it is not your search being bad.
This article is the content, not the plumbing. Getting agent logs into a SIEM is a separate job, covered in what each platform exports and how to ship it. What follows assumes the data has landed and asks the next question: what do you actually write against it.
Why endpoint and network rules miss agent abuse
An agent does not do anything your existing rules recognize as suspicious. It authenticates as a legitimate identity, calls sanctioned APIs, and reads data it has been granted access to. Every individual action is authorized. The abuse lives in the sequence and the volume, and neither is visible to a rule that evaluates one event at a time.
There is a second, more structural problem. Much of what an agent does never crosses a network boundary you monitor. A local process talking to an MCP server over stdio opens no socket. A server-side browsing tool makes its request from the vendor's infrastructure, not from your estate. Your network sensors see a single TLS session to an approved domain, and everything interesting happens inside it.
Which means the telemetry has to come from the application layer, and the application layer is where the field names get specific.
Which log fields do you need before any rule will fire?
Start here, because a rule written against a field name that does not exist fails silently and looks like an absence of threats.
| Source | What identifies an AI event | Where the detail lives |
|---|---|---|
| Microsoft 365 Copilot via Purview | RecordType CopilotInteraction, numeric 261 | AuditData.CopilotEventData |
| Other AI apps in Purview | AIAppInteraction, ConnectedAIAppInteraction | Same envelope |
| Google Workspace Gemini | applicationName=gemini_in_workspace_apps, event ai_usage_event | Four parameters, and that is all |
| Anthropic Compliance API | Activity type, for example claude_chat_created | actor, discriminated on actor.type |
Inside CopilotEventData the members worth knowing are AccessedResources, Messages, Contexts, AppHost and ThreadId. AccessedResources[] is the one that carries detection value, because it names every item the assistant read to answer a prompt, with SiteUrl, Type, SensitivityLabelId and a per-resource Action.
Three casing traps will break your rules, and Microsoft's own documentation is the reason they exist.
AISystemPluginData is not a field name. It is the schema type. The JSON key is AISystemPlugin, and the same trap applies to EventData, MessageData and CopilotId. Next, listItemUniqueId begins with a lowercase l and isPrompt with a lowercase i in the published schema and in the raw audit samples, while Microsoft's prose table writes both capitalized. Finally, the same page renders ConnectedAiAppInteraction and ConnectedAIAppInteraction in different places. Follow the schema and the raw JSON, not the prose.
Anthropic's advice on its own feed is worth adopting as a rule-writing habit: pass through unrecognized type and actor.type values rather than matching an allowlist, because new activity types ship continuously and a strict match quietly stops covering them.
The detection gap is a configuration gap first
Before any logic, one setting decides whether half of this is possible at all.
Claude Code telemetry is off unless CLAUDE_CODE_ENABLE_TELEMETRY=1. Even switched on, tool input arguments are not logged unless OTEL_LOG_TOOL_DETAILS=1, prompt content is not collected, and only prompt length is recorded. The consequence is specific and severe: without that second variable, every user-configured MCP tool call in your estate logs with a tool name of the literal string mcp_tool, attributable to no server and no tool.
So the common complaint that agent abuse cannot be detected is, for one of the most widely deployed coding agents, one environment variable. Check that before you write a line of detection logic, because every MCP rule below depends on it.
What to actually write
Six rules, ordered by the ratio of signal to effort rather than by sophistication.
1. Logging was turned off. Anthropic emits org_compliance_api_settings_updated when compliance recording settings change, which makes disabling the feed the one action that is still recorded as it happens. Alert on it unconditionally. This is the cheapest high-fidelity rule available and almost nobody has it.
2. A vendor already told you it was prompt injection. Microsoft's Copilot audit documentation describes an XPIADetected flag on accessed resources, a vendor-computed cross-prompt injection verdict sitting in the record. Alert where it is true, then group by SiteUrl. The grouping is the point: one hit is an event, several hits against the same site is a poisoned document library, and the second finding is worth far more than the first.
3. The guardrail was disabled by a human. Elastic ships a rule called GenAI CLI Started with Unsafe Permission Bypass, created in June 2026, matching process arguments including permission-skip and full-auto flags across several coding agents. It catches the person who turned off approvals rather than the agent that then acted without them, which is usually the earlier and more actionable event. Elastic tags it high noise, so tune by user and host rather than expecting it clean out of the box.
4. Read volume no human would produce. Count distinct entries in AccessedResources[] per ThreadId and per identity over a short window, and alert above a baseline you measure rather than guess. The false positive is legitimate bulk work: a genuine research task, a migration, a new starter reading widely. Tune with a floor on sensitivity label rather than on raw count, because a hundred public pages and ten restricted ones are different events.
5. The sequence, not the actions. Chain detection on an identity that reads internal resources and then, within the same session, invokes a tool with outbound reach. Each half is authorized. Together they are the shape of exfiltration, and the four paths that data actually takes out are set out in the exfiltration piece. Expect false positives from any legitimate summarize-and-send workflow, which is why this rule wants an approval-state field alongside it rather than firing alone.
6. An agent that should not still exist. Alert on activity from an agent identity with no recent legitimate activity, or one whose owner has left. The reasoning behind this one is set out in agents nobody retired, and its false-positive profile is unusually good because seasonal or quarterly automation is a small, enumerable set you can allowlist once.
Every one of these needs a stable event schema underneath it. If your logs do not carry an actor, an action, a target and an outcome per event, the rules have nothing to bind to, which is the argument for a fixed field schema before rule-writing rather than after.
How do you baseline a single agent?
Human baselines do not transfer. A person has working hours, a rhythm, and a ceiling on how fast they read. An agent has none of those, and an off-hours alert on an agent that runs a nightly job is noise by design.
Baseline three things per agent identity instead of per user: the set of tools it has ever called, the systems it has ever touched, and its volume distribution by hour. The first is the most valuable and the least used. An agent that has called four tools for three months and suddenly calls a fifth is a high-signal event, because agents do not get curious. Something changed in its configuration, its prompt, or its instructions.
That rule has one predictable false positive, and it is worth naming because it will be your first alert: a legitimate deployment that added a tool. Feed change records in, or accept a known burst of alerts on release days.
What you cannot detect with today's logs
This is the section that decides whether your detection program is honest about its coverage.
Microsoft's Copilot audit record does not carry prompt or response text. Messages[] gives you an identifier, whether the message was a prompt, and a size field that the documentation says is currently unused. The content lives in the user's mailbox and is reachable through eDiscovery, not through your SIEM feed. Microsoft's own prose elsewhere says prompts and responses are captured in the unified audit log, which is about activity capture rather than schema content, and reading it literally will lead you to write a rule against a field that is not there.
Google's Gemini audit events carry exactly four parameters: an action, an app name, an event category and a feature source. No content, no resource list, no prompt. Anything more specific than "this person used Gemini in Docs" is not available from that source.
Anthropic is the exception. Session transcripts do carry tool inputs and results, retained by default for six years, but with named gaps you should write down: sessions authenticated with a Console API key, sessions run through a third-party cloud platform, and cloud sessions are not captured, and organizations with zero data retention in effect are excluded entirely.
Retention sets your hunt window. Copilot audit records expire at 180 days by default because the Copilot workload is not in the set that gets a year, which means an investigation into something that started seven months ago has no data, regardless of how good your rules are.
And MCP itself will not help. Its logging feature was a three-field debugging channel with no timestamp, no server identity and no correlation identifier, and it was deprecated in the July 2026 protocol revision in favor of stderr and OpenTelemetry. The specification requires hosts to obtain user consent before invoking a tool and requires nothing about recording that consent. There is no protocol-level audit obligation to standardize on, which is why the handful of vendors shipping MCP detections have mutually incompatible schemas. Detection for MCP is a host-telemetry and endpoint-file problem, and it is going to stay one.
Where detection ends, prevention is the honest answer. A rule tells you an agent read four thousand records; a control that evaluates the tool call against policy and holds it for human approval is what stops the four thousandth, which is the case for inspecting the tool call itself rather than reconstructing it afterwards.
Where these rules sit against OWASP
Giving each rule a risk identifier is what turns a set of alerts into something an auditor can follow, and the agentic list is the right vocabulary for it. Rules 1 and 3 map to privilege and identity abuse. Rule 2 maps to goal hijack through injected content. Rules 4 and 5 map to tool misuse and its consequences. Rule 6 maps to rogue agents. The full annotated list is in our reading of ASI01 through ASI10.
The state of the art, stated plainly
You can name the global inventory of published coding-agent behavioral rules in one sentence, and it is four rules from two vendors, every one written between late 2025 and mid 2026. The most widely shipped prompt-injection detection at any vendor is a string match on a short list of phrases including ignore previous instructions and system prompt override, which catches the careless attacker and nobody else.
The useful conclusion is not that detection is hopeless. It is that the detections which work today are configuration and tamper detections rather than behavioral ones. Logging switched off, a guardrail flag disabled, a vendor's own injection verdict, an inventory that gained an agent nobody added. These are cheap, they have near-zero false-positive rates, and they are sitting unimplemented in most environments while teams wait for behavioral analytics that are still aspirational.
Write those four first. Then baseline tool calls per agent, and build the behavioral set on top of a population you can actually see.