Securing Claude Code: The New Compliance API, Local Visibility, and Identity Governance

Anthropic’s Claude Code, a local AI agent harness, presents significant security challenges due to its ability to execute commands and connect to third parties on developer machines. While Anthropic’s Compliance API offers some visibility into agent activity, it falls short of providing comprehensive governance due to its focus on what agents *do* rather than *who* is using them and *why*. To effectively manage Claude Code’s security, a layered approach is needed, combining managed settings to enforce a baseline, the Compliance API for session transcript analysis, and endpoint telemetry to uncover hidden skills, plugins, and MCP servers. Crucially, connecting endpoint data with organizational context – like correlating skills with managed repositories – is essential for determining legitimate access and mitigating risks. Without this broader context, simply logging agent activity is insufficient for robust AI agent security.

Claude Code reads files, runs shell commands, invokes MCP tools, and acts through the credentials available on a developer’s machine. Anthropic’s new Compliance API endpoints give security teams their clearest view yet into that activity. They also expose a larger problem: activity logs alone cannot tell you whether an agent’s access is legitimate. AI has moved from the browser tab to the endpoint with harnesses like Claude Code. They run on developers' machines, execute bash commands locally, and connect to third parties via MCP servers, skills, and plugins. All this so the user can outsource labor to the machine and focus on designing, thinking, and creating.

Local agents are not a niche category. They account for 68.6% of the AI agents Token Security discovers in customer environments, and they often inherit the employee’s credentials, network position, and permissions. The shift to the endpoint has major implications for security. With Claude Code, there is no centralized console to monitor endpoint agents across local configurations, identity and access, and runtime. Before August 2026, Anthropic’s native controls had limited visibility into what those agents were actually doing, forcing teams to use third-party extensions just to achieve the bare minimum of governance.

A harness is not a chatbot. A harness is a sophisticated orchestrator. It takes user input and sends it to the LLM along with the full session context. The LLM itself doesn’t maintain state; it receives everything it needs from the harness to respond on an ad hoc basis. The component that actually runs commands, authenticates to third parties, and connects to MCP servers is the harness, not the LLM. Compare an endpoint agent to a human body. The LLM is the brain: it processes the data and calls the shots. Everything else is the harness, from the hands and the legs to the sensory organs. It's a weird hybrid, and our security model has to adapt to fit it.

Unorthodox design: It’s en vogue to say that SaaS is dead, and it's a little SaaD, because classic SaaS took care of a lot of things for us. We expect a service to let us manage and monitor our enterprise from a central dashboard, control organizational policies, and clearly see what the agents within our enterprise can do. That is not the case with local harnesses. Claude Code challenges the classic shared-responsibility model and puts more load on admins. In a Token-commissioned Cloud Security Alliance survey of 418 IT and security professionals, 68% rated their visibility into AI agents as high. In the same survey, 82% had discovered an agent in the past year that security, IT, or governance did not know existed.

One important note: local session transcripts can contain sensitive data, including PII, secrets, and customer data. Their storage becomes a sensitive data source in its own right. Treat it like one.

Anthropic's own tooling helps, but it isn't enough to prevent LLMs from performing destructive actions, even if those actions may be legitimate. There are three key layers for gathering data to govern local AI agents effectively. You need to understand what Anthropic gives you, what only an endpoint agent can collect, and what you need to do with the data.

Layer 1: Managed settings, the policy baseline. Anthropic’s enforcement mechanism is managed settings. Every endpoint that installs Claude Code has a managed-settings record: a JSON file on Mac and Linux, and registry records on Windows. Its rules take precedence over global, project, and user settings, allowing you to enforce a baseline over every Claude Code session in the organization. On a Claude Code enterprise plan, you apply policies through the GUI; without one, your MDM can write the managed-settings record across endpoints.

The available rules cover a lot: - Allow and deny lists for specific MCP servers - Regexes over bash commands - Disabling skills from running commands, and more. They help, but they take a lot of maneuvering room away from your developers, and static allow/deny policies aren't built for the pace of modern AI. Worse, they don't know context or intent. In effect, they're a big boulder in the middle of a river, disrupting the stream but not stopping it.

Layer 2: The Compliance API. Until recently, Anthropic’s Compliance API mainly covered claude.ai actions, meaning activity from the web interface and Claude Desktop, with very thin coverage of Claude Code. On August 11, 2026, Anthropic introduced new endpoints for local sessions:

These give you visibility into agents running on endpoints, based on their interaction with Anthropic’s models. Whatever is communicated to the model is logged in three block types: text, tool_use, and tool_result. Between them, they cover user prompts, bash commands, reads and writes, and even MCP commands.

The model holds no state server-side. The skill and plugin .md files only exist on the endpoint, so the harness resends the full context to the model on every turn. Anything that reaches the model reaches the Compliance API, which is pretty amazing for governance and monitoring.

Parsed the right way, session transcripts let you log tool usage and build an inventory of your agents: each one’s skills, the MCP servers it uses, and its plugins. The Compliance API also covers administrative actions, mostly at the organization level and less so for individual users changing configs.

Layer 3: What only the endpoint can tell you. The Compliance API and OTel capture what agents *do*. Neither can see what sits on disk: config files, installed skills and plugins and their .md files (unless they were used in a session), or processes launched outside a session. This is where an endpoint agent earns its keep. Harvest config files, retrieve skill and plugin .mds, and correlate EDR logs to catch risky bash commands coming from agents. Token Security finds an average of more than 10 configuration files per local agent, scattered across the endpoint.

One more thing lives on disk that you can also pull from the Compliance API: session transcripts. Claude Code stores all session history locally for 30 days by default, so users can quickly resume previous work. A malicious actor who gains access to the endpoint can also read those files, so the same caution applies.

Don't forget transcripts when you build a coverage plan. Start with responsible use: keep users from writing raw secrets into sessions, label projects and sessions that hold customer or sensitive data, and delete them on a schedule. Then add detection and response: find user prompts that contain cleartext secrets, and act on sessions that could compromise customer data.

Transcripts vs. logs. OTel was built for logging atomic actions. Session transcripts are long, deeply descriptive JSON with no verbosity dial, and you have to process them to get the same logging outcome. If you don't want to collect and store extremely dense transcripts, OTel might be the easier tool (until a better one exists).

And there’s a hard boundary: If you run Claude Code on a model that isn't Anthropic’s, you get no Compliance API coverage at all, because it only logs interactions with Anthropic’s models. Sessions running on Bedrock, Foundry, or Google Cloud won't be covered.

One important note: local session transcripts can contain sensitive data, including PII, secrets, and customer data. Their storage becomes a sensitive data source in its own right. Treat it like one.

Claude Code stores all session history locally for 30 days by default, so users can quickly resume previous work. A malicious actor who gains access to the endpoint can also read those files, so the same caution applies.

Learn how Token secures AI agents across endpoints, cloud, SaaS, and developer envir