Book Launch: A Security Field Guide to AI Tooling Visibility

We wrote a field guide to AI tooling visibility. It's free.

AI tools now read and write code, run commands, search business data, and act through connected systems. When one of them does something unexpected, the first question is almost always the same: what did the tool actually log?

The answer changes with every product. One source records prompts and tool decisions. Another records only the policy change that made a later action possible. A third proves a feature was used while omitting the prompt, the file, and the result. Knowing where those records live, what they capture, which identifiers matter, and what never shows up is most of the work, and there hasn't been a single place to look it up.

So we wrote one. A Security Field Guide to AI Tooling Visibility maps the security-relevant records across eight AI sources: Claude Code, Claude Cowork, OpenAI Codex, Cursor, GitHub Copilot, the Anthropic and OpenAI enterprise platforms, and Gemini in Google Workspace, and puts the data in context across monitoring, detection, threat hunting, investigations, incident response, governance, and AI asset inventory.

It's free and ungated. Download the book — no form, no email wall. If you'd rather have it on your desk, you can also request a printed copy.

What's inside

Across eight sources, each chapter answers the same questions: what the source records, what it misses, which fields matter, what the data can support, and where its limits begin. Detection is one use. The same records can support hunting, investigation, incident response, governance, baselining, and inventory.

The guide is organized around four things per source:

1. What each tool logs, surface by surface
2. The fields and identifiers that matter
3. Collection, retention, privacy, and API quirks
4. Security use cases, evidence limits, and supporting sources

Here's the map at a glance. Choose the source from the question you need to answer, an audit log is not automatically a detection feed.

No source tells the whole story. By the end you'll know which records to collect, how to interpret them, which security questions they can answer, and where endpoint, identity, Git, SaaS, and network data have to fill the gaps.

To give you a sense of the approach, here are two excerpts: the bridge that closes Part 1, and the closing chapter.

Excerpt: Across local AI agents and developer tools

Part 1 gives you two evidence classes. Claude Code, Claude Cowork, and Codex export runtime OpenTelemetry. Cursor and GitHub Copilot primarily expose control-plane records. The risks overlap, but the evidence does not. Port detections by required fields, not by product category.

What each source can establish. Claude Code, Claude Cowork, and Codex record session, prompt, decision, and result context. Cursor records changes to the controls around its agent. GitHub adds access and policy changes plus supported agent actions on GitHub. A tool_decision can answer who approved an action. A policy-change record can answer who changed the control. Neither substitutes for the other.

Patterns that carry across sources. The investigation questions repeat; the available evidence does not.

Sensitive access and possible egress. Runtime records may show a sensitive read or an outbound command, and session and network evidence can support a candidate match. Cursor and standard Copilot audit records do not contain the local runtime events that method needs.

Approval and control changes. Claude Code, Claude Cowork, and Codex can expose an approval source. Cursor and Copilot can expose the policy change that governs later actions. Those are different facts.

Deployment and policy drift. Originators, service names, versions, roles, privacy settings, and repo policies all surface drift. First-seen and out-of-policy checks need either history or an approved inventory. Without either, the same fields are what you use to build the inventory in the first place.

Prompt injection. Direct injection may appear when prompt content is collected. Indirect injection often does not, and the tool's own actions may be the only recorded evidence.

Handle content as sensitive data. Prompt and tool content can be as sensitive as the system the agent touched. Use metadata when it answers the question, and put raw content behind tighter redaction, access, and retention before it reaches broad downstream systems.

Supporting telemetry. Runtime logs show attempted actions. Control-plane logs show guardrail changes. Endpoint logs can confirm process and file effects, network logs can confirm connections, Git and CI/CD can confirm repository and build impact, and connected systems can confirm MCP side effects. Use only what your environment actually has.

Part 2 moves farther from runtime behavior. Its sources cover identity, administration, control changes, content-activity timelines, and feature use. There, you start with what the audit record proves, then add identity, asset, and change context if those sources exist.

Excerpt: Operationalizing AI tooling logs

A log source has no operational value while it sits in a vendor API or a nested OTLP payload. Collection is what decides whether the evidence works: parsing, normalization, enrichment, filtering, routing, and access control.

The eight sources do not behave alike. Claude Code, Cowork, and Codex emit nested OTel. Cursor has pagination, rate limits, and a 30-day request window. OpenAI exposes one structured audit endpoint. Gemini reports use without content. Anthropic uses another activity schema. Every source brings its own failure modes. A vendor API is only potential evidence; the record has to reach something the team can search, alert on, hunt through, and use during an incident. Without a shared collection layer, every source becomes another collector, parser, cursor, and silent failure mode.

The pipeline control layer. Use the pipeline as the shared chokepoint. Collect each source once, parse and normalize it once, and attach identity, HR, asset, or network context there if it exists. SIEM rules, analyst searches, manual response, SOAR, AI SOC systems, and other destinations then receive the same event. In-SIEM joins and response-time lookups remain fallbacks, but they duplicate logic and drift. That chokepoint is also where redaction, filtering, access, and routing belong, so raw prompt and tool content can get tighter access and shorter retention before it reaches broad downstream systems.

Monad is built for this layer: collection, parsing, normalization, pre-SIEM enrichment, filtering, and routing. The Claude Code and Codex transforms in the book are public. Cowork uses the Claude Code input and routes separately on service.name=cowork.

Where to start. Start with the question your team cannot answer today. Runtime action needs runtime evidence. Administrative change needs an audit record. Adoption and usage need activity data. Don't ask one class of log to prove another. Collect what the source can prove, keep its limits intact, and put the evidence where the team already works.

A note for security leaders. AI tooling is a new security log surface, not a single product category. Specialist AI security tools may cover part of it, but every environment has its own identities, repositories, connected systems, policies, and data paths. Teams still need to know which native sources exist, what each can prove, and where endpoint, identity, network, Git, or SaaS evidence has to fill the gaps. Use vendor solutions where they help, but don't outsource your understanding of what these tools emit natively.

Get your copy

The full book covers all eight sources in this depth, plus the collection, retention, and privacy quirks for each.

Download it free, or request a printed copy.

If one of these sources is stuck in an API, buried in OTel, or arriving without usable context, bring it to Monad and we'll show you the collection, normalization, and routing path. Collect it before you need it. Know what it can prove before someone asks.

‍