Don't Buy a New Tool to Monitor AI. Your SOC Already Can.

Over the past few months I've had roughly the same conversation with twenty different security leaders. It always starts with some version of: "we know our developers are using AI tools, we don't know what they're doing with them, and our board is starting to ask."

And it always lands in the same place. They don't want to buy yet another product. They've already invested in a SIEM, an EDR, a DLP, an egress proxy. They have a SOC that knows how to write rules, tune alerts, and run a hunting program. They want to monitor AI the way they monitor everything else – telemetry into the SIEM, detections in the alert queue, response from the team they already pay for.

For a while I'd tell them "yeah, that's the right instinct, but the tooling isn't quite there yet." That answer is now wrong.

What changed

In the last six months, the major AI vendors have quietly shipped enough telemetry for any security team that already speaks OpenTelemetry to do real detection work – without standing up a new platform. The pieces aren't equally good and some gaps remain, but the headline is: your AI tools are already speaking your SOC's language. You just have to point them at the collector you already have.

The short version: Claude Code and Codex CLI push real-time event streams covering tool calls, permission changes, and session activity. ChatGPT Enterprise exposes a compliance log feed with conversation content, file uploads, and audit events – but with minutes of latency, not real-time. GitHub Copilot gives you user-level audit events but no prompt or response content. And your existing egress proxy remains the only feed that catches the unsanctioned tools none of the others can see.

That is a very different picture than it was a year ago.

Use case 1: The developer who uploaded customer PII

A CISO I was talking with last month told me a developer uploaded a codebase containing customer PII to ChatGPT for "help refactoring it." Nothing in their stack caught it. The CISO only found out because the developer mentioned it to a friend.

If the user was on the corporate ChatGPT Enterprise account, the compliance log feed exposes file upload events with filename, content type, and conversation context. A simple poller forwarding those into your SIEM, with a rule that flags PII patterns, would have caught this. If the developer was using a CLI tool like Claude Code, you'd catch the same thing through tool output events, within seconds.

If the developer was using personal ChatGPT or an unmanaged API key, vendor-native telemetry tells you nothing. You catch it only at the egress proxy – and only the fact of an upload, not what was in it. That's where the network layer is your safety net.

The detection logic is identical across all configurations. The only thing that changes is the source feed and the latency. Your SOC writes SIEM rules; the rules port directly. You don't need a new platform.

Use case 2: The engineer who turned off the safety net

Claude Code and Codex CLI both have an interactive permission model – the AI asks for approval before taking actions like running commands or editing files. Both also have an "I know what I'm doing, just let it run" mode. Switching into that mode is the AI-tool equivalent of disabling UAC. There is no legitimate sustained use of it outside automated CI pipelines in sandboxes.

A rule that fires whenever a developer switches to bypass mode – especially followed by command execution shortly after – is one of the highest-leverage detections you can write. The same rule pattern your SOC already uses for privilege escalation events in EDR works directly against AI tool telemetry. No new tool. No new query language.

Use case 3: The shadow-IT tool you didn't license

Every vendor-native feed has one structural blind spot: it can only tell you about activity inside its own product. The only feed that catches unsanctioned AI tools is your egress proxy.

The detection is unsexy and effective: pull a week of proxy logs, filter to AI-tool domains, group by user, alert when someone starts hitting a domain you don't have a corporate license for. Your SOC has been writing this rule shape against new SaaS adoption for years. AI tools are just the next category.

Where this falls apart

Four gaps are real and the vendors should close them.

The ChatGPT Enterprise compliance feed is gated to Enterprise and Edu tiers only. Mid-market customers on lower tiers get workspace-level analytics, not the full audit feed. That's the difference between "I can audit my devs' AI use" and "I can't" – and it's the single most consequential AI security gap in the mid-market today.

CLI tools still have coverage gaps in non-interactive and server modes, which is exactly where security teams most want telemetry because those run unattended.

Every vendor should make telemetry on by default, with content redaction as the default profile. Asking security to convince every developer to manually enable logging is not a security model. Anthropic's approach – a managed settings file that admins can enforce centrally and users can't override – is the right shape. Every AI vendor needs an equivalent.

Finally, products like ChatGPT and Copilot don't have in-session permission events because they don't have an in-session permission concept. They should. Even a simplified version – "user granted this integration access to domain X" – is something a security team needs.

The takeaway

The instinct security leaders have – monitor AI use the same way I monitor everything else, in the SIEM I already paid for, with the SOC I already employ – is exactly the right instinct, and it is now technically achievable. ChatGPT Enterprise covers the content-and-audit category. CLI tools cover the in-session control plane. Your egress proxy covers shadow IT. None of them covers everything; all of them together cover roughly 90% of what a SOC would actually want to see.

There is no excuse for an organization with a functioning SIEM and SOC to have zero visibility into AI tool use in 2026. The telemetry is there. The rule patterns are the same ones your team already writes. Stop waiting for a vendor to sell you a magic AI-monitoring product, and instead point the telemetry at the platform you already trust.

The next conversation I want to have with a CISO is not "should we buy a new tool." It's "which of these five rules do we deploy first."

A final thought

Security isn't complicated. We make it complicated – by chasing the next shiny tool, by letting vendor noise drown out operational discipline, by forgetting that the fundamentals still work: log the right things, monitor what matters, ask better questions.

Your stack is more powerful than you're using it. The problem is rarely the technology – it's knowing what to look for, and where to look.

That's what we do at Mars Security. We don't replace what you've built. We help you get more out of it – mapping threat intelligence to your environment, telling your existing tools what to hunt for, and making sure the detections that matter are actually running. An intelligent agentic layer that hunts across your stack at machine speed.

Credit where it's due – the spark for this post came from Anshu Gupta's linkedin post and open-source claude-otel-siem OTLP receiver, which made me realize how close the practical story actually is. If you want to get from theory to a working pipeline in an afternoon, his repo is the fastest path.

https://github.com/anshug/claude-otel-siem

https://code.claude.com/docs/en/agent-sdk/observability

https://help.openai.com/en/articles/10875114-workspace-analytics-for-chatgpt-enterprise-and-edu