Cursor hooks and Elastic Agent capture every tool call, shell command, file read and MCP request as structured events you can hunt with ES|QL.

Why AI coding agent activity is a blind spot

What are agent hooks?

How does the hook collector script work?

Configuring Cursor hooks

Deploying Cursor hooks without MDM

Sending hook logs to Elasticsearch with Elastic Agent

Hunting across agent activity with ES|QL

Hardening and privacy for agent audit logs

What 13 million tool calls reveal about AI coding agent behavior

What are the limitations of hook-based AI agent auditing?

Getting started: try it on one laptop

Learn how one 280-line bash script and Elastic Agent capture every Cursor tool call as searchable security telemetry across 1,100+ machines.

Cursor exposes hooks that run an external program on every tool call, and other coding agents offer equivalent hooks. A logging script can record each shell command, file edit, and MCP call as JSONL, and Elastic Agent ships those logs to Elasticsearch where they become searchable security telemetry. This gives you a per-event audit trail rather than an install inventory alone.

How do you audit what AI coding agents do on developer machines?

The collector logs metadata: timestamps, user, host, agent and IDE surface, tool name, command line, file path, MCP server, model, and session ID. It does not capture file contents, prompts, or model responses, which keeps the telemetry on par with process auditing rather than surveillance.

What data do agent hooks capture, and what do they leave out?

Yes. A user with admin rights can remove the hooks configuration, so treat this as workforce telemetry whose removal leaves a visible gap. A host that stays active while its hook events stop is itself a hunting signal, and pairing hooks with an osquery-based inventory detects machines where agents run unlogged.

Can developers bypass agent hook logging?

An Elastic Agent Custom Logs (filestream) integration tails the daily JSONL log files and a decode_json_fields processor parses each line into structured fields under one prefix. Events land in logs-ai_hooks-* data streams, queryable with ES|QL and ready for Kibana dashboards.

How do the logs get into Elasticsearch?

AI coding agent audit: Cursor hooks and Elastic Agent

13 million tool calls: auditing every AI coding agent action with Elastic Agent

A 40-line CEL integration snapshots .npmrc files every 6 hours to catch cooldown removals. This post walks through the three ways we broke filestream before landing on snapshot semantics.

Why developer workstations are the npm supply-chain  gap

What does an npm cooldown config file look like?

First approach: Monitoring .npmrc with the Custom Logs Filestream integration

Three filestream behaviours that don't fit config file monitoring

Native file identity beats fingerprint for small files

clean\_inactive and ignore\_older are coupled

Filestream emits on append, not on removal

Why nvm inflates npm version counts for cooldown adoption

Second approach: Monitoring .npmrc with CEL snapshot semantics

How the CEL integration evolved: emit-on-change, tombstones and heartbeat

How to filter .npmrc auth tokens before they leave the host

The npm cooldown ingest pipeline

CEL vs. filestream for config file monitoring

npm cooldown monitoring on Linux and Windows

Rollout status and extending beyond npm

What we learned about npm cooldown monitoring with Elastic Agent

Track npm cooldown (min-release-age) adoption and catch silent removals on developer workstations using a 40-line CEL integration in Elastic Agent.

Run a snapshot-based CEL integration in Elastic Agent that reads each `.npmrc` on a fixed interval and re-emits the host's current state as a heartbeat (we use 6 hours). A removed `min-release-age` line shows up as `cooldown.absent = true` in the next snapshot, and a deleted file drops out of subsequent snapshots. Log-tailing inputs like `filestream` can't produce this signal, because they emit on appended content and stay silent on retractions. Detection latency equals the heartbeat interval, which fits adoption tracking over days or weeks rather than real-time alerting.

How do I detect when an npm cooldown setting is removed with Elastic Agent?

An npm cooldown is a delay between a package version being published and npm being willing to install it, set with the `min-release-age` key (in days). Malicious releases are typically detected and pulled from the registry quickly, so a cooldown of days keeps fresh compromised versions out of `npm install` during the window when they do the most damage. It's a workstation-level guardrail against supply chain attacks, complementing the controls in CI/CD.

What is an npm cooldown and why does it matter for supply chain attacks?

npm 11.10 and later. Set it with `npm config set min-release-age 7` (the unit is days), which writes to the user-level `~/.npmrc`. Every npm installation on the machine reads that file, but versions older than 11.10 ignore the key.

What npm version supports min-release-age?

The setting is shared, but enforcement is per-version. `npm config set min-release-age 7` writes to the user-level `~/.npmrc`, which every npm installation on the machine reads, including the per-Node copies that nvm installs. Versions older than 11.10 ignore the key, so a machine with a mix of npm 10.x and 11.10+ installations is only protected when the active npm is 11.10 or later. Machines with nvm routinely report several npm versions (one machine in our test pulls reported 34), which is why we track the config file directly instead of inferring adoption from version counts.

Does an npm cooldown set in \~/.npmrc apply to every npm version installed through nvm?

The full file body sits in the `message` field before the event leaves the host, and `.npmrc` includes registry auth tokens alongside the cooldown setting. We add an agent-side script processor in the integration's Advanced options that keeps only `min-release-age` lines and drops everything else before transit. Tokens never reach the ingest pipeline. We verified by adding a test token to `.npmrc` and confirming zero hits for the token string in Elasticsearch after a full cycle.

How does the CEL integration keep `.npmrc` auth tokens off the wire?

Filebeat's default file identity strategy (fingerprint) requires files to be at least 1024 bytes before they're indexed. User-level config files like `.npmrc` are 10 to 50 bytes, so they sit in a deferred state with no error in the agent log. Switch the integration to native file identity (inode plus device) and the size floor goes away. The fingerprint length cannot be lowered below 64 bytes, so for files that small, native is the only path.

Why are my filestream events missing for small config files?

A Windows-specific variant is needed, but it shares the dataset and ingest pipeline with macOS and Linux. The Windows integration enumerates `C:/Users/*`, excludes the built-in profiles (`Public`, `Default`, `Default User`), and watches each user's `.npmrc` plus the globals under `C:/ProgramData`. The Grok pattern's `[^
]*` value capture already handles CRLF line endings, and the agent-side token filter is unchanged. We designed this variant but haven't deployed it in our own macOS-heavy fleet yet.

Author

Wieger van der Meulen

Articles

13 million tool calls: auditing every AI coding agent action with Elastic Agent

The security signal log tailing can't see: tracking npm cooldown removals with Elastic Agent