Topic starter
25/10/2026 11:10 am
TL;DR: Different plugin, hook and status paths make Claude’s surfaces hard to govern as one system, according to Manifold Security. Surface-by-surface checks are needed because client-reported state can look covered while runtime control is still uneven.
Editorial analysis by NHI Mgmt Group, based on content published by Manifold Security: “One vendor, three platforms: governing Claude Code and Cowork”.
Key questions
Q: Why should security teams distrust client-reported plugin and hook status?
A: Because the client can report availability, disablement or loading in ways that do not match actual runtime behaviour.
Q: What are the best practices for governing AI coding agents across desktops and sandboxes?
A: Treat each execution surface as its own platform, map which controls it actually accepts, and test behaviour rather than assuming documentation is accurate.
Q: Where does governance fail when one agent runs across multiple surfaces?
A: Governance fails when teams assume a single control model reaches every runtime.
Practitioner guidance
- Document each runtime surface separately Create a control inventory for terminal, hosted cloud and Cowork, then map which policy, plugin and hook mechanisms each one actually honours.
- Validate enforcement from outside the client Use external checks to confirm plugin loading, hook execution and configuration persistence instead of relying on client status output.
- Separate delivery from configuration governance Track plugin distribution, managed settings and storage location as distinct controls, because the article shows they do not converge naturally.
Bottom line: The article shows that one agent brand can conceal multiple administrative surfaces with different control behaviour.
Glossary terms: Surface-fragmented Agent Control Plane, Runtime Surface, Independent Verification, Configuration Drift Across Surfaces
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:17 pm
Surface-specific governance is the right control model for this class of agent. The article shows that Claude’s terminal, cloud sandbox and Cowork do not share a single administrative reality, even when they run the same build. That means policy inheritance is not the right assumption to optimise around; runtime surface is. The practitioner conclusion is to govern each execution surface as its own identity boundary rather than treat product lineage as control consistency.
A few things that frame the scale:
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What happens when settings and runtime versions drift apart?
A: Controls can be written for one version while another version or session is still executing, which creates inconsistent enforcement and stale policy outcomes. In practice, that means a plugin may run with newer settings, older hooks or no usable configuration path at all, depending on the surface and timing.
👉 Read our full editorial: Claude’s three surfaces behave like separate platforms for admins
This post was modified 7 days ago by NHI Mgmt Group