[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fjDEYJwtrwwioV50hAMzkakOgXpv6UDcoNZLSHkBgO_c":3},{"article":4,"iocs":47},{"id":5,"title":6,"slug":7,"summary":8,"ai_summary":9,"brief":10,"full_text":11,"url":12,"image_url":13,"published_at":14,"ingested_at":15,"relevance_score":16,"entities":17,"category_id":29,"category":30,"article_tags":34},"fe77daa8-9c0c-4af1-9814-1e98ab2780b8","Securing Claude Code: The New Compliance API, Local Visibility, and Identity Governance","securing-claude-code-the-new-compliance-api-local-visibility-and-identity-govern-dd23bc","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","Anthropic has released a new Compliance API for Claude Code, providing security teams with enhanced visibility into agent activity on developer endpoints. These agents can read files, run shell commands, and utilize local credentials, posing new security challenges as they move beyond browser tabs to local machines. While the API improves monitoring, it highlights the difficulty in distinguishing legitimate agent access from unauthorized activity, emphasizing the need for robust identity governance and endpoint telemetry.","Anthropic's new Compliance API offers better visibility into Claude Code agent activity on developer endpoints.","Securing Claude Code: The New Compliance API, Local Visibility, and Identity Governance The Hacker NewsAug 31, 2026Artificial Intelligence \u002F Endpoint Visibility 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\u002Fdeny 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: Endpoint Returns GET \u002Fv1\u002Fcompliance\u002Fapps\u002Fsessions\u002Flocal list of session metadata GET \u002Fv1\u002Fcompliance\u002Fapps\u002Fsessions\u002Flocal\u002F{session_id} one session's metadata GET \u002Fv1\u002Fcompliance\u002Fapps\u002Fsessions\u002Flocal\u002F{session_id}\u002Fmessages the transcript 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 \u002F 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. Neith","https:\u002F\u002Fthehackernews.com\u002F2026\u002F08\u002Fsecuring-claude-code-new-compliance-api.html","https:\u002F\u002Fblogger.googleusercontent.com\u002Fimg\u002Fb\u002FR29vZ2xl\u002FAVvXsEithkMoEFgk1IZj_h_hGp94DwzD4UyQGh2f-epiRD6fn_XcMyB44HkXe-7XaHzviE8sImzIctDBjibyY0Gdrt_OPFFeja3KnOd9KsPFP3PeTxUzlshseSyukl0-cmQWZctAeVQHTUpvW99C8FZrhCcwPDZWoYShfC9jTGqmj1Va2K-Mo2kK6GbSksGIbM4\u002Fs1600\u002Fdan.jpg","2026-08-31T11:31:47+00:00","2026-08-31T14:00:14.437166+00:00",7,[18,21,24,27],{"name":19,"type":20},"Claude Code","product",{"name":22,"type":23},"Anthropic","vendor",{"name":25,"type":26},"AI agents","technology",{"name":28,"type":26},"LLM","839da5c1-3c34-47e2-9499-f7201640e3ac",{"id":29,"icon":31,"name":32,"slug":33},null,"AI Security","ai-security",[35,40,42],{"category":36},{"id":37,"icon":31,"name":38,"slug":39},"2c8f44d4-b56e-47cf-9677-04f22c9ee78d","Identity & Access","identity-access",{"category":41},{"id":29,"icon":31,"name":32,"slug":33},{"category":43},{"id":44,"icon":31,"name":45,"slug":46},"e7b231c8-5f79-4465-8d38-1ef13aea5a14","Threat Intelligence","threat-intelligence",[]]