Claude’s three surfaces behave like separate platforms for admins

At a glance

What this is: Manifold Security shows that Claude’s terminal, cloud and Cowork surfaces behave like three different administrative platforms, not one unified control plane.

Why it matters: That matters because identity and policy controls cannot be assumed to propagate consistently across agent surfaces, which affects governance, enforcement and trust in reported state.

Context

The governance gap is not simply that Claude reaches users in multiple places. The problem is that the same agent behaves differently depending on whether it is running in the terminal, a hosted cloud sandbox, or Cowork, so administrators cannot assume one control model applies everywhere. In practice, delivery, configuration, hooks, updates and reporting all fragment across those surfaces.

This is a classic identity governance problem for AI-enabled software: policy is only useful if it reaches the runtime that actually executes the agent. AI coding agents security guide is relevant here because the article’s core lesson is about governing agent behaviour across endpoints, sandboxes and desktop environments without trusting a single client view.

Key questions

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. In this case, delivery, settings, hooks and reporting diverge by surface, so the same agent can be covered in one place and unmanaged in another. The fix is not better wording in policy but separate verification for each runtime surface and each control channel.

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. That creates false assurance and makes coverage look better than it is. Teams should verify plugin state, hook execution and configuration persistence from outside the client before they treat the environment as controlled.

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. Then separate plugin delivery, configuration and enforcement into different checks, because those functions do not move together across the terminal, cloud and desktop VM surfaces.

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.

Technical breakdown

Why the same build produces different governance surfaces

The article’s central finding is that the runtime surface, not the codebase alone, determines administrative behaviour. Claude Code on the terminal, Claude Code in the cloud, and Cowork share the same build, but each exposes different configuration paths, enforcement points and state visibility. That means the administrative model is surface-bound: a control that exists in one environment may not exist, persist or execute in another. In identity terms, the agent is not a single governed endpoint. It is a set of distinct execution surfaces with separate control boundaries, each requiring independent assurance.

Practical implication: Map controls to runtime surface, not product name, and verify each execution path separately.

How plugin delivery and settings split across channels

Plugin governance splits into two different channels. The catalogue can mark plugins Required, while managed settings can register a marketplace and force-enable plugins, but those mechanisms do not reach the same surfaces. Cowork only receives catalogue-delivered plugins, while the terminal and cloud sandbox only receive managed settings. That is why one plugin everywhere becomes two admin workflows that must stay aligned by hand. The configuration problem is worse because settings delivered through managed settings can bypass the expected secure storage path and land in plain text, while Cowork provides no usable place to set plugin configuration at all.

Practical implication: Treat plugin distribution and configuration as separate control domains and test where each setting is actually written.

Why hooks, updates and status reporting cannot be trusted uniformly

Enforcement and assurance drift further apart once hooks and updates enter the picture. A hook can deny a tool call consistently, but prompt-blocking behaviour diverges by surface, and one documented shape leaves Cowork stuck. Updates also move on different clocks: terminal installs may never refresh automatically, cloud sessions can run unprotected until a delayed marketplace sync completes, and Cowork depends on restarts for new versions. Status reporting is unreliable on top of that, because the client can claim a plugin is unavailable, disabled or loaded when the runtime says otherwise. The result is a control plane that reports confidence without proving coverage.

Practical implication: Validate enforcement from outside the client and measure actual runtime state rather than trusting self-reporting.

Threat narrative

Attacker objective: The objective is to exploit governance fragmentation so an agent can operate with inconsistent controls while appearing compliant to administrators.

1. Entry begins when administrators assume a single governance path applies across terminal, cloud and Cowork surfaces, even though each surface receives different policy inputs.
2. Escalation occurs when plugins, hooks and configuration drift apart, allowing a surface to run with incomplete or stale enforcement while reporting that it is covered.
3. Impact is governance failure: administrators cannot reliably prove what is installed, enabled or enforced, which weakens containment and auditability across the agent estate.

Breaches seen in the wild

• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
• Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Credential and policy propagation assumptions collapse when a single agent spans multiple runtimes. The expectation that one settings channel, one plugin catalog or one hook model will govern the whole estate is invalid here. The article’s strongest evidence is that configuration lands in different places, sometimes as plain text, and that status messages can be wrong. The implication is not merely incomplete coverage but broken assurance: the control plane cannot certify what it cannot observe.

Runtime observability must be external to the client. If the agent tells you whether it is installed, enabled or loaded, the answer is not trustworthy enough to serve as governance evidence. The article demonstrates that status reporting can diverge from actual runtime state, which creates a false sense of control closure. Practitioners should treat client-reported state as advisory only and build independent verification around the runtime.

Tooling fragmentation inside a single vendor is now an identity governance problem, not a product usability problem. The article’s named concept is a surface-fragmented agent control plane: one brand, one build, three distinct policy behaviours. That is a structural warning for AI and NHI governance programmes, because assurance models built for homogeneous runtimes do not survive when the same agent behaves differently by execution surface. The practitioner conclusion is to redesign governance around runtime-specific evidence.

From our research library:

• 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.
• Read next: AI Coding Agents Security Guide

What this signals

The likely next governance shift is away from product-level administration and toward runtime-specific assurance. When one agent family spans terminal, sandbox and desktop VM surfaces, identity and policy teams need surface-aware evidence, not a shared assumption that one control plane can reach every execution path.

Surface-fragmented agent control plane: when the same AI system behaves differently by runtime surface, governance has to move from documentation-led rollout to independent runtime verification. That pattern will matter for any organisation mixing local IDE agents, hosted sandboxes and desktop-based knowledge-work agents.

The broader warning is that status reporting can become a liability if it is treated as evidence. Administrators will increasingly need to prove coverage externally, especially where settings, hooks and plugin updates do not converge on the same clock.

For practitioners

• 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.
• Assume version skew between settings and runtime Treat settings, plugins and live sessions as moving on different clocks, and review whether older sessions are still executing against newer policy.
• Test prompt-blocking behaviour per surface Verify that the same hook response blocks, fails closed or fails open in each environment before you rely on it for enforcement.

Key takeaways

• The article shows that one agent brand can conceal multiple administrative surfaces with different control behaviour.
• Coverage gaps are amplified when plugin delivery, settings, hooks and status reporting each obey a different path.
• Practitioners need surface-by-surface verification, because client-reported state is not reliable enough to prove governance.

Related NHI Mgmt Group resources: AI Coding Agents Security Guide · Low-Code Agent Platform Security Guide · AI Governance Platform Buyer's Guide · Nx s1ngularity attack 2025

Key terms

• Surface-fragmented Agent Control Plane: A governance condition where the same AI system behaves differently depending on where it runs, so one administration model cannot reliably control every surface. In practice, plugin delivery, settings, hooks and status reporting must be validated per runtime, because the control plane is split by execution environment rather than by product branding.
• Runtime Surface: The specific environment in which an AI agent executes, such as a local terminal, a hosted sandbox or a desktop VM. Identity and policy controls attach to the surface, not just the software build, so the same agent can expose different trust, enforcement and configuration behaviour across surfaces.
• Independent Verification: A trust pattern in which an assertion is checked against a separate source before it is accepted. In identity and security programmes, this prevents fluent but unproven information from being treated as authoritative. It applies to AI outputs, certificates, and other machine-generated claims.
• Configuration Drift Across Surfaces: A state where settings, plugin versions and active sessions move on different schedules or through different channels, creating inconsistent enforcement. For AI agent governance, drift is not just a versioning nuisance. It can leave older sessions running under newer policy, or newer settings applied to runtimes that never receive them.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.