--- title: Three harness permissions your security team should have locked down by now slug: permissions-security-lock-down date: 2026-04-15 excerpt: "Two Claude Code CVEs and a 513,000-line source leak are signaling the real problem: coding harnesses are configuration surfaces, and config ships with the repo. Here is what to scope, sandbox, and allowlist before the next disclosure lands." featured_image: "https://bbtxujdxvidaghmhxkqs.supabase.co/storage/v1/object/public/generated-images/blog-1776236487076-permissions-security-lock-down.webp" canonical_url: https://cerevisor.com/blog/permissions-security-lock-down updated_at: 2026-04-15T07:01:31.472592+00:00 --- # Three harness permissions your security team should have locked down by now TLDR Two Claude Code CVEs disclosed in February, plus a source code leak on March 31, are the preview. The real finding is that coding harnesses are configuration surfaces, and configuration ships with the repo. The fix is boring and familiar: sandboxing, credential scoping, and an MCP allowlist, borrowed directly from the CI playbook. On April 1st, Zscaler’s ThreatLabz team published their postmortem on the Claude Code source code leak. Roughly half a million lines of TypeScript across nearly two thousand files, 44 feature flags including 20 unshipped ones, all bundled into a public npm package for two weeks before anyone noticed. > "approximately 513,000 lines of unobfuscated TypeScript across 1,906 files" Zscaler ThreatLabz, April 2026 The board probably saw the headline. My inbox saw the quieter question: what are we supposed to do about this on Monday? The honest answer is that the leak itself does not change the security posture much. The code was partially reverse-engineered anyway. What changes is that two CVEs disclosed in February, CVE-2025-59536 and CVE-2026-21852, just got dramatically easier to weaponize. Those CVEs are the warning shot, not the attack. --- ## What it actually means Both CVEs exploited the same quiet truth about coding harnesses: they are configuration surfaces, not chat windows. Check Point Research, which disclosed both bugs on February 25, demonstrated an attack where simply opening a crafted repository exposed a developer’s entire Anthropic API key in plaintext. That was the consequence of a single environment variable in a project’s settings file. 8.7 CVSS score for CVE-2025-59536, the Claude Code hooks and MCP consent bypass Check Point documented three distinct vectors. Hooks in `.claude/settings.json` that execute shell commands before any [trust](/blog/ai-adoption-trust-not-training) dialog fires. An `enableAllProjectMcpServers` setting that silently skips user consent on attacker-controlled MCP servers. And an `ANTHROPIC_BASE_URL` environment variable that redirects every API request to an endpoint of the repository author’s choosing, API key attached. Anthropic patched all three by the time the researchers published. The shape of the problem is not something a patch can fix. Think about what that shape looks like in real workflow. Someone clones a repo from a stranger’s GitHub. Maybe a reference implementation, maybe a pull request from a new contributor, maybe a tutorial linked in a Slack channel. They open it in the harness. The harness reads `.claude/settings.json` or `.mcp.json` or `.cursorrules`, whichever applies. And now a piece of config written by someone else is running inside the agent’s [trust](/blog/ai-resistance-trust-not-training) boundary, sometimes before a consent dialog even shows. Key Insight The specific bugs are patched. The shape of the problem is not patchable. Any harness that can be configured from inside a repository can be weaponized from inside a repository. I have watched this play out across four engineering orgs in the last six weeks. Every one of them had MCP servers installed with no review trail. Every one of them had developers running agents in environments that inherited production credentials. Every one of them had at least one engineer who had, in perfect good faith, opened a hostile-looking repo just to see what it did. --- ## Three questions your board will ask **“Are we exposed?”** The right answer is not yes or no. It is a list of permission boundaries. Which credentials sit in the process environment where the harness runs. Which MCP servers the team has installed without approval. Whether the harness has network access to internal systems. If the security team cannot produce that list in under an hour, the exposure is real, and it is not a specific CVE, it is the absence of an inventory. **“Why didn’t security catch this earlier?”** Because most security teams are scanning container images and endpoint telemetry. Harness configuration lives in developer repos, in `.claude/` and `.vscode/` directories, in personal dotfiles. MintMCP’s March 26 write-up put it cleanly: treat `.claude/`, `.mcp.json`, and similar files as executable logic. If scanners do not treat them that way, the blind spot is the size of every repo on every engineer’s laptop. **“What do we do about it?”** Three moves, in order of leverage. Scope the harness to a containerized environment with no production credentials. Maintain an allowlist of approved MCP servers and refuse to install others without a review ticket. Add a pre-flight check that treats any repository’s config files as untrusted input until explicitly accepted. None of this is exotic. All of it is the boring operational hygiene that did not exist as a category eighteen months ago. --- ## 60-second brief The harness is a new class of attack surface. It is not an IDE, not a CI runner, not a SaaS. It is configuration-driven code execution inside an engineer’s trust boundary, and the configuration can come from anywhere. No new product is required to address this. The same three controls already applied to CI runners and build pipelines map cleanly onto harnesses. Least-privilege credentials. A sandboxed execution environment. A reviewable inventory of what the tool can do and who authorized each permission. Assume the next CVE is 90 days away. Build for that now. --- ## What to watch MCP server registries and the emerging practice of signed configurations. If this space matures the way package registries did after the npm incidents, expect a verified-publisher model by the end of the year. That would be the good ending. It is also the likely one, given how fast this category is learning to clean up after itself. #### Sources - [Caught in the Hook: RCE and API Token Exfiltration Through Claude Code Project Files](https://research.checkpoint.com/2026/rce-and-api-token-exfiltration-through-claude-code-project-files-cve-2025-59536/) - Check Point Research, 2026-02-25 - [Claude Code CVE-2025-59536 & CVE-2026-21852: What Enterprise Teams Must Know](https://www.mintmcp.com/blog/claude-code-cve) - MintMCP, 2026-03-26 - [Anthropic Claude Code Leak](https://www.zscaler.com/blogs/security-research/anthropic-claude-code-leak) - Zscaler ThreatLabz, 2026-04-01