What to use instead, and when.

Anthropic ships native OTel from Claude Code: twelve event types including tool_result, tool_decision, mcp_server_connection and permission_mode_changed, plus a beta trace mode. Off by default, and an administrator can enforce it through managed settings so a developer cannot turn it back off.

does this better

claude_code.tool_decision carries a source attribute distinguishing user_permanent, user_temporary, user_reject and user_abort from config and hook. That is the observed human approval decision. Agentmetry infers approvals from timing and labels them inferred:, so on this specific field the telemetry is right and our inference is a guess. tool_result_size_bytes is a second one: it reports how much data a tool returned, which our trail does not.

does not do this

One agent. No hash chain, so there is no artifact to verify later. Command strings sit behind OTEL_LOG_TOOL_DETAILS, a flag whose purpose is sending more sensitive content to a central collector. And it emits events rather than findings: correlating a credential read with a later egress is detection engineering you write and maintain.

The most important alternative on this page, and the one we plan to ingest rather than compete with. Written up at length in the notes.

Since May 2026 Anthropic has shipped security and compliance integrations that route Claude Enterprise activity into tools including CrowdStrike Falcon Next-Gen SIEM and Datadog Cloud SIEM. Programmatic access to activity events, chats, files and projects.

does this better

Zero deployment on developer machines. Nothing to install, nothing to keep hooked, no coverage question. If you are a Claude Enterprise customer this is included and it is the shortest path to Claude activity appearing in your SOC.

does not do this

It is cloud side and Claude only. It does not see the tool boundary on the laptop, it does not see Cursor or Codex, and it does not see which MCP server schema an agent was handed locally.

If your fleet is Claude Enterprise and your risk model is account and usage governance rather than what ran on the endpoint, start here and stop.

An MCP gateway plus an Agent Monitor that, by their description, gives visibility into local non-MCP agent activity including bash commands, file reads and writes, and prompt submissions, through Claude Code and Cursor hooks. Detects PII, credential leakage, risky bash commands and prompt injection attempts.

does this better

SOC 2 Type II, audited with continuous monitoring via Drata, plus HIPAA compliance and signed BAAs. Enterprise SSO. Agentmetry has none of those and is not close. Their gateway also wraps local stdio MCP servers as hosted services with OAuth, which is a control surface a local sensor cannot offer.

does not do this

It is a SaaS control plane. Their public material does not state where the audit trail is stored, which is the first question to ask them. Converting locally-run MCP servers into hosted services is the opposite architectural choice to ours, deliberately on both sides.

The closest peer to our capture layer, and ahead on everything procurement measures. Pick them if you want a managed platform and a compliance certificate. Pick us if the trail must stay on the machine that produced it.

Acquired by SentinelOne in a deal announced August 2025 at approximately $250M. A lightweight endpoint agent plus browser extensions that discover sanctioned and unsanctioned GenAI use across browsers, desktop IDEs, terminal assistants and APIs, covering ChatGPT, Gemini, Claude and Cursor, with policy controls that block.

does this better

It covers the gap we name in our own documentation and refuse to claim: unmanaged ChatGPT, an agent nobody registered, a browser tab. It also blocks in real time, and it arrives through SentinelOne's enterprise channel.

does not do this

It is a commercial endpoint product with a vendor control plane. It is not built around producing a verifiable local artifact, and it does not publish a detection benchmark you can run before believing it.

Closer to a complement than a rival for the specific job, though it competes for the same budget line. If your board question is shadow AI, they answer it and we do not.

Static analysis of MCP server manifests for tool-poisoning patterns, plus a runtime proxy, plus tool pinning by hashing to detect a server changing its tools between versions.

does this better

They published the tool-poisoning research and got to rug pulls before we did. Their proxy can block dangerous MCP traffic; ours records it.

does not do this

It is scoped to MCP. It does not see a bash command in Cursor, it does not correlate a credential read with a later egress, and it is a separate tool rather than one field in a correlated trail.

Prior art we build on rather than around. If MCP is your entire threat model, use theirs.

Endpoint detection built for human attackers, watching processes, files and network activity on the same machines your developers use.

does this better

Everything below the agent. Process lineage, kernel visibility, memory, containment, and an incident response practice around it. Sophos telemetry from June 2026 records coding agents already tripping EDR rules written for human attackers, which is the whole reason this category exists.

does not do this

It sees powershell.exe. It cannot say which agent invoked it, which developer prompted it, which MCP server schema was in play, or which session the call belonged to. That context does not exist at the process layer.

Not a competitor. Agentmetry forwards into the SIEM your EDR already reports to, and the two answer different halves of the same alert.