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

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. 

With the new local session transcript endpoints in the Anthropic compliance API, you can better govern your local agents while understanding which limitations still exist.

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. The brain runs in Anthropic’s cloud, but the hands run on your endpoints, and that is where your visibility and control have to live.

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.

Riddle me this: I live on your host as an agent, but I was here long before any LLM. I know more about your Claude Code than Anthropic does, because endpoints are my realm.

Because much of Claude Code’s execution happens locally, endpoint telemetry can reveal processes, files, and configurations that cloud services cannot see. But EDR provides evidence, not a governance model. It cannot connect an agent’s activity to its owner, intent, credentials, and permissions. 

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. I expect that to widen over time.

Why you might still need OpenTelemetry

OpenTelemetry (or OTel) is an open-source standard for traces, metrics, and event logs, and every common harness has it built-in, only needing to be configured.

Some actions on the endpoint never reach the LLM, so the Compliance API never sees them. Hooks are the clearest case: they run locally, between the model’s decision and the tool actually running, and can block a tool from executing or a prompt from being sent. 

OTel also records tool-permission decisions and who made them, whether a policy, a hook, or the user waving it through. Also, permissions changes moved into bypassPermissions / auto mode will be logged in OTel but not the compliance API.

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.

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.

A little about parsing transcripts

To get atomic-action logging out of your Claude Code sessions, you process the Compliance API transcripts. As above, each message is only text, tool_use, or tool_result, wrapped in fields like user, assistant (the LLM’s responses), and more. Finding the actual plugins, skills, and MCP servers takes a few extra techniques.

Bash commands

The easy case: every command shows up as a tool_use with “name”: “Bash”, and the full command line sits in the input value.

MCP servers

These appear as a tool_use whose name is mcp____. First-party servers use readable names, so you can often tell the type at a glance: Jira, Slack, Notion. User-connected servers show up as a UUID instead, and you recover the service from the command suffix (slack_send_message) or from a UUID-to-name map you maintain.

Every one of these represents a standing credential on that endpoint, and roughly a third come from outside the vendor ecosystem: 35.1% of MCP servers Token Security discovers are community-built or of unknown origin.

Skills

Skills aren’t named in a field the way MCP commands are, but you can infer them. When a skill fires, the LLM can’t use it without context, so the harness sends the SKILL.md over the API, either by injecting the skill content directly or by issuing a Read on its path. That Read gives away both the skill name and its location: the tool_use input holds the path, and the tool_result text holds the skill’s content.

Plugins

Plugins are harder, because a plugin isn’t a single file. It bundles different extension types, including skills and scripts. You recover plugin names through path conventions, when one of a plugin’s script or .md files is Read into context.

All of this works without touching user prompts, on tool_use blocks and command lines alone.

Managed settings + local session transcripts + endpoint collection = Good but not enough

Claude Code’s design creates challenges that no single layer can answer. Together, the three do a better job, but still fall short:

Even all three are not enough because none of them captures the context of your enterprise, and they don’t go deep enough in tying access to intent. An admin reviewing the transcripts can’t tell the difference between a malicious plugin pulled from the internet and a legitimate one written by an engineer. Closing that gap requires context from elsewhere in the organization, such as correlating the skills and plugins running on endpoints with those your internal repositories actually manage, which increases legitimacy. Once you have that context across the org, detecting a single malicious skill gives you a heat map of where it runs, and mitigation moves fast.

Telemetry can show what happened. Governance requires connecting those signals to an agent’s owner, purpose, identities, credentials, permissions, and access paths. That context makes it possible to determine whether access is justified, right-size it to least privilege, and revoke it when the agent’s purpose ends. Identity is the control plane that turns endpoint and session data into enforceable AI agent security.

Learn how Token secures AI agents across endpoints, cloud, SaaS, and developer environments with a quick demo, anytime.

Note: This article has been expertly written and contributed by Dan Abramov, Security Researcher.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.