How Teams Should Audit Claude Code Usage After the Leak

Start With an Inventory, Not an Opinion

Most teams will instinctively debate whether Claude Code is still trustworthy. That debate is too abstract to be useful. Your first step is an inventory. Find every place Claude Code is used: individual laptops, shared jump boxes, development containers, CI-adjacent experiments, and any cloud-hosted Claude Code sessions. Anthropic’s own docs make clear that Claude Code can operate locally, can use project and user scoped settings, and can connect to external tools through MCP. That means one engineer’s “just a coding helper” may already be another engineer’s semi-privileged automation surface.

In practice, the inventory should answer four questions. Which repositories are touched by Claude Code? Which users or teams rely on it daily? Which settings are stored per-project versus per-user? Which external integrations are enabled? If you cannot answer those questions within a few hours, your problem is already larger than the leak headline.

Review Permission Drift

Anthropic documents Claude Code as read-only by default, with explicit approval for editing files, running tests, and executing commands. That is a good baseline. The operational risk is not the default. The risk is permission drift over time. Developers get tired of prompts, teams allowlist commands for speed, and what began as a careful tool ends up with looser approval patterns than anyone intended. After a leak, you should assume your accumulated convenience settings deserve scrutiny.

Audit every allowlist and every project-level configuration that reduces friction. Look for broad shell approvals, network approvals that no longer make sense, and settings that effectively turned Claude Code into an ambient command runner. Anthropic also notes that suspicious bash commands may still require approval even if previously allowlisted, which is useful, but teams should not outsource all judgment to that safety net. The audit should explicitly ask whether Claude Code still has only the minimum authority needed for the team’s real workflows.

Inspect MCP Servers as Their Own Trust Surface

This is where many teams will miss the point. Anthropic’s MCP documentation is powerful because it shows Claude Code can connect to issue trackers, monitoring systems, databases, design tools, and remote services over HTTP, SSE, or local stdio servers. The same documentation also warns that third-party MCP servers are used at your own risk, that Anthropic does not verify every server, and that prompt injection risks increase when servers can fetch untrusted content. In the security docs, Anthropic goes further and states plainly that Anthropic does not manage or audit MCP servers.

That means your post-leak audit cannot stop at the core Claude Code binary. You need to review each MCP connector like a separate trust boundary. Which servers are project-scoped and committed into source control? Which are user-scoped and quietly attached by individuals? Which tokens do they hold? Which servers can retrieve external content, issue write operations, or push events back into sessions? A well-governed team should be able to answer those questions in a spreadsheet, not in a Slack scavenger hunt.

Audit What Can Reach Sensitive Repositories

Claude Code’s write restrictions are designed around the folder where it starts, and Anthropic emphasizes that writes are confined to the project scope unless you grant more. That is a sensible model. The audit task is to verify that your actual usage still fits that model. Teams should review where Claude Code is started, whether developers launch it from oversized monorepo roots, whether local symlinks or helper scripts widen its effective reach, and whether sensitive secrets or deployment files sit inside the same reachable workspace as ordinary feature code.

This is also the moment to separate high-risk repositories from ordinary feature work. If production infrastructure, credential material, or security tooling lives next to routine application code, an approval-based coding agent becomes harder to reason about. Your audit should recommend narrower repo boundaries, more isolated sandboxes, or stricter development containers where appropriate. The leak did not create those architectural problems. It just made them harder to ignore.

Check Telemetry, Logs, and Hooks

Anthropic’s security docs specifically call out OpenTelemetry metrics, managed settings, and config-change hooks as ways teams can monitor Claude Code usage and audit settings changes. If your team has those features available and has not enabled them, this is the point to fix that. A security review without evidence is mostly guesswork. You want to know how often Claude Code is invoked, which environments use it most, whether settings change during sessions, and whether specific teams are bypassing the governance model you thought you had.

The best audit outcome is not just a cleanup document. It is a monitoring baseline. After the leak, teams should know what normal Claude Code activity looks like so they can recognize unusual spikes in command approvals, new MCP server additions, or changes in project-level configuration. Incidents are easier to contain when the surrounding system is observable.

Run a Short Red-Team Exercise

Do not wait for a formal annual security review. Run a fast internal exercise now. Use a non-production repository, wire in one or two representative MCP servers, and test the edges: untrusted content, risky commands, external fetches, prompt injection attempts, and approval fatigue scenarios. Anthropic’s docs are explicit that no system is immune to all attacks and that users still need to review commands and maintain good security practice. Your audit should translate that broad warning into something concrete for your own environment.

The goal is not to prove Claude Code is bad. The goal is to identify where your team would grant authority too casually, where the prompt-and-permission model becomes noisy, and where your internal workflows assume the tool will remain conservative even when the session context is messy. Those assumptions should be tested, not admired.

A Practical Audit Checklist

1. List every developer, repository, container, and machine where Claude Code is in active use.
2. Export or inspect user, project, and local settings for permission drift.
3. Review every MCP server by scope, owner, token, and external data access.
4. Map which repositories contain secrets, infra code, or sensitive operational logic.
5. Enable monitoring for usage, settings changes, and unusual approval patterns.
6. Run a scoped adversarial exercise with untrusted content and risky commands.
7. Document which workflows remain approved and which need tighter controls.

This checklist is deliberately operational. Post-leak security work should end with fewer unknowns, not more commentary.

Bottom Line

The Claude Code leak should not force every team into a blanket ban. It should force every serious team into a real audit. Anthropic’s own docs already describe a permissioned, scoped, and monitorable system. Your job is to verify that your implementation of Claude Code still resembles that design and has not quietly drifted into something broader, looser, and harder to trust.

Teams that respond with inventory, permission review, MCP scrutiny, and monitoring will come out stronger. Teams that respond with only hot takes will not have fixed anything.

Author Note