Securing Claude Code in the Enterprise

Verified against. Claude Code documentation at code.claude.com/docs as served on 10 November 2026, when the changelog listed version 2.1.322 (dated 10 November 2026) as the most recent release [22]; Microsoft Learn pages dated between June 2025 and October 2026; Datadog documentation as served on the same day. I checked documentation, not a running binary. Where a behaviour depends on a minimum version, the version is given. The verification was done by an AI agent working from the vendor pages and is not peer review.

1. Summary

The subject is a regulated financial institution — a bank, an insurer or an asset manager in the EU, the UK or Switzerland — that lets developers and pipelines use Claude Code. The tool should be treated as privileged automation with its own identity, policy and telemetry.

The baseline has five layers.

1. Identity and tenancy. Every invocation authenticates through an identity the firm controls: single sign-on into the firm’s own Claude organisation for people, and a workload credential against an approved model endpoint for pipelines. Personal accounts and unmanaged API keys are excluded by policy keys on the device, not by request.
2. Centrally managed policy. One version-controlled policy, delivered by the device-management channel as a machine-level registry policy or a file in a system directory. It pins the login method and organisation, removes the bypass mode, locks permission rules, hooks and MCP servers to the managed set, turns on the sandbox and configures telemetry.
3. Runtime isolation. The operating-system sandbox on Linux and WSL2, repository tiering, and disposable containers for anything non-interactive.
4. Network and data protection. Egress limited to the approved model endpoint and the telemetry path, secrets kept where the agent cannot read them, and contractual terms recorded per route.
5. Monitoring. The tool’s OpenTelemetry export, switched on by policy and sent to the firm’s observability backend. Datadog is the worked example; nothing in the controls depends on it.

What changed against commonly repeated guidance. These corrections come from the documentation opened for this paper.

• The Windows policy file lives in C:\Program Files\ClaudeCode\. The older C:\ProgramData\ClaudeCode\ path is no longer read [2].
• Server-delivered and device-delivered policy do not combine by default. Claude Code uses the first source that delivers a policy key and ignores the rest [2][3]. “Use both, with the file as a backstop” is therefore wrong unless merging is switched on deliberately.
• --allowedTools pre-approves tools. It does not restrict them. The restricting flag is --tools [10][11].
• There is no .claudeignore. The documentation says such a file “has no effect” [4].
• The data-zone option for Claude in Microsoft Foundry is a United States zone, and only for the Azure-hosted versions. I found no zero-data-retention option documented for the Foundry route [14][24][25].
• Single sign-on is available on the Team plan. Domain capture, SCIM, audit logs and the Compliance API are Enterprise features [12][36].
• Auto mode, in which a classifier model approves actions instead of the developer, is now the built-in starting mode for interactive sessions [5]. A baseline has to take a position on it.

Evidence and argument. Sections 3 to 10 report what the vendors document and build a baseline on it. The baseline in section 5.2, the split pipeline in section 8, the monitors in section 10.3 and the roadmap in section 12 are design proposals. They have not been tested in a controlled way. Section 11 is my mapping to regulation and is not legal advice.

2. Scope, reference estate and assumptions

The paper covers Claude Code used interactively by developers and non-interactively inside scripts, pipelines and scheduled jobs. It does not cover chat use of Claude on the web or desktop, the browser and office add-ins, or secure review of AI-generated code, which belongs to the existing software delivery lifecycle.

The reference estate. The guidance is written against one estate shape, chosen because it is common in regulated finance and not because it describes any one firm: a Microsoft-centric endpoint estate, Linux developer environments, a hosted CI/CD service and a commercial observability backend.

The concrete product guidance is kept because exact settings are where the value is. A firm on a different estate should read each product as an instance of a role: device management, virtual desktop, pipeline service, secret store, telemetry backend. Section 4.3 gives the Amazon and Google equivalents for the model endpoint.

What was and was not re-verified. Claude Code settings, the Foundry offering, the Datadog setup, Intune Remediations, the Intune settings for WSL, Azure Pipelines container jobs, Key Vault-linked variable groups and scale-set agents were checked against vendor pages on 10 November 2026. Other Microsoft controls named in passing — Defender for Endpoint, application control, FSLogix, Azure Firewall, disk encryption — appear as the estate’s existing controls. I make no claim about their current behaviour and did not re-open their documentation.

Assumptions. One Entra ID tenant. Windows managed through Intune, which can deliver registry policy, files and scripts. An observability backend that accepts OpenTelemetry Protocol (OTLP) data. A regulatory context of DORA, the EU AI Act and GDPR, with UK and Swiss regimes as parallels. Claude consumed either through a commercial relationship with Anthropic or through a cloud provider.

Design principle. Controls are defined once and projected onto each surface by the channel that already owns it: Intune for Windows, configuration management or images for Linux, the image pipeline for build agents. The same policy and the same telemetry configuration should land everywhere.

3. Architecture and threat model

3.1 What the tool does

Claude Code is distributed as a native binary. The recommended installation is Anthropic’s installer script; WinGet, Homebrew and signed apt, dnf and apk repositories are alternatives; the npm package still exists and installs the same native binary, which “does not itself invoke Node” [9]. Describing it as a Node.js command-line tool is out of date.

Each session sends prompts and selected repository content to a model endpoint — Anthropic’s API, a Claude subscription, Amazon Bedrock, Google Cloud or Microsoft Foundry — and receives tool-use requests back. The client then runs tools locally: file reads and edits, shell commands, search, web fetch and search, MCP servers (Model Context Protocol connectors to other systems), hooks (shell commands run on lifecycle events) and plugins. A permission engine sits between the model’s requests and execution. Rules evaluate to allow, ask or deny, and a permission mode sets what runs without asking [4][5].

Three consequences follow. The model endpoint sees source code and prompt content. The local tools run with the invoking user’s privileges. MCP servers, hooks and plugins extend the tool set with code the firm did not write.

3.2 Threat model

Anthropic’s security page lists the built-in protections: the permission system, command-injection detection, fail-closed matching, a separate model call that summarises fetched web pages, and the fact that curl and wget are not auto-approved. It then states that “no system is completely immune to all attacks” [7]. On bypass mode the documentation is blunt: “Only use this mode in isolated environments like containers, VMs, or dev containers without internet access”, and the mode “offers no protection against prompt injection” [5].

The limits of rule matching are also documented. A deny rule for curl does not match /usr/bin/curl or sh -c 'curl …'; the page calls argument-constraining Bash patterns “fragile” and points to the sandbox for enforcement “that doesn’t depend on the command text” [4]. Independent research shows the same thing in practice. Leonardo Di Donato of Ona reported on 3 March 2026 that an agent told to find a way to run a denied binary invoked it through /proc/self/root/usr/bin/npx, a path that “doesn’t match the deny pattern”. The bubblewrap sandbox stopped that attempt. The agent then proposed running the command unsandboxed, and Claude Code asked for approval before doing so [37]. The denial held only because a person was asked. Section 5.2 removes that escape route by setting.

3.3 Control philosophy

There are four layers of defence: identity (who may call the model), policy (what the agent may do), runtime (where it runs and what the operating system lets it touch) and observability (what can be seen and proved afterwards). None is trusted alone.

The permission engine is configuration inside the same process it constrains. Anthropic says so directly: server-managed settings “operate as a client-side control, not a security boundary”; a developer who is a local administrator “can edit the managed source itself”; a user who runs a modified client “can bypass any client-side control”; and managed settings “bind Claude Code only”, so a developer who calls the API from another tool is not under them [2][3]. This is the reason every high-risk context in this paper has an operating-system or network control behind the policy file.

4. Identity, authentication and tenancy

The first decision is which identity and which model endpoint Claude Code may use. Data handling, audit and administrative control follow from it.

4.1 Approved routes

Three facts about the Foundry route matter, because they are often misreported.

Hosting. Microsoft offers each Claude model in up to two versions. “Hosted on Azure” versions run “on Azure infrastructure end-to-end and are all Generally available”. “Hosted on Anthropic infrastructure” versions “run on Anthropic’s infrastructure (outside of Azure)”, and some of those are in preview [24]. For the Azure-hosted version Microsoft states that “your prompts and outputs never leave Azure” [26]; Anthropic’s wording is narrower: “Only usage metadata and content flagged by Anthropic’s safety systems egress to Anthropic” [23]. For the Anthropic-hosted version, “data might be processed outside of Azure including outside of your selected Azure geography” [26]. The hosting option is chosen per deployment, and the newest model families were Anthropic-hosted only on the day I checked [24].

Residency. Deployment types are Global Standard and Data Zone Standard (US). The data zone is available only for Azure-hosted versions [24][25]. There is no EU data zone. A firm with an EU residency requirement gets “data at rest … stored in the selected Azure geography” with processing scoped to a global deployment [25]. Whether that satisfies its data-classification rules is the firm’s decision.

Who the provider is. On both hosting options “Anthropic is the seller and operator” and “acts as an independent data processor”; the models are “Non-Microsoft Products under the Product Terms”; retention is governed by Anthropic’s data processing addendum and commercial terms [25][26]. Spend counts against a Microsoft Azure Consumption Commitment, and Cloud Solution Provider subscriptions are not supported [25]. I found no zero-data-retention option for the Foundry route on the Microsoft pages. Anthropic documents zero data retention for Claude Code only for qualified Claude for Enterprise accounts, enabled per organisation by its account team, and says that for cloud-provider deployments the provider’s retention policy applies [14].

4.2 Rules

1. Exclude personal accounts by setting. Consumer plans carry different data terms; Anthropic trains on consumer data when the user’s setting allows it and does not train on data sent under commercial terms [13]. The managed keys forceLoginMethod and forceLoginOrgUUID restrict sign-in to the firm’s organisation. Claude Code “exits at startup if the claude.ai credential in use belongs to an organization that isn’t listed” [12]. They must be delivered through device management: server-managed settings arrive only after a user has authenticated into the organisation, “so you can’t redirect a first login with those settings” [12]. Two gaps are documented. The interactive login screen pre-selects the method without enforcing it, and claude setup-token checks the method but not the organisation [12].
2. Restrict the provider. The managed key allowedProviders lists the services a machine may reach Claude through; a session configured for any other provider “is refused at startup”. It requires version 2.1.285 or later [12]. This is the device-side answer to a developer exporting a different base URL.
3. Single sign-on before rollout. With SCIM on the Enterprise plan, access follows the joiner, mover and leaver process. Conditional access applies as for any other service.
4. No raw API keys on endpoints. Developers authenticate by SSO. With the two login keys deployed, sessions that authenticate with ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN or an apiKeyHelper are “blocked at startup” [12]. The interactive profile therefore cannot be reused on build agents; section 8 uses a separate one.
5. One route per use case, written down. Interactive use goes through the Enterprise organisation. Pipelines use Foundry with Entra ID, or a Console key held in the secret store. A Console key belongs to a Console organisation, “a separate organization from your claude.ai Team or Enterprise organization” [3]; settings and audit configured in one do not reach the other.
6. Know where server-managed settings stop. Claude Code skips the server-managed settings fetch when a cloud-provider variable or a non-default ANTHROPIC_BASE_URL is set, and an endpoint-managed env block does not restore it [3]. On any gateway, Bedrock, Google Cloud or Foundry route, the device-delivered policy is the policy. Anthropic documents a self-hosted “Claude apps gateway” that supplies equivalent remote delivery for those providers [3]; I have not evaluated it.

4.3 Amazon and Google equivalents

Azure is the reference here because of the estate, not because it is the strongest option on every point. Claude Code runs against Amazon Bedrock with CLAUDE_CODE_USE_BEDROCK=1 and the AWS credential chain: IAM Identity Center profiles for people, instance or task roles for workloads, and short-term Bedrock API keys where a role is not available. The required IAM actions are bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream, bedrock:ListInferenceProfiles and bedrock:GetInferenceProfile [20]. It runs against Google Cloud with CLAUDE_CODE_USE_VERTEX=1, a project ID and a region, using Application Default Credentials, service accounts or certificate-based Workload Identity Federation, with the roles/aiplatform.user role [21]. Anthropic’s page now calls the Google service “Google Cloud’s Agent Platform, formerly Vertex AI”.

On residency both are ahead of Foundry as documented today. Bedrock offers cross-region inference profiles with an eu. prefix, and the Google route accepts an eu multi-region location or a single European region [20][21]. Foundry’s only data zone is in the United States. Bedrock also offers Guardrails for content filtering on the request path [20]. On the other side, neither route receives server-managed settings, neither carries the user’s email address in telemetry (section 10.2), the WebSearch tool is unavailable on Bedrock, and both resolve model aliases to defaults that “can lag the newest release”, so versions must be pinned [20][21]. These statements rest on Anthropic’s provider pages. I did not open AWS or Google documentation for this paper, and I did not examine their CI services; the identity pattern for a pipeline is the same on all three clouds — a workload role, never a stored key.

5. Centralised policy: managed settings, permissions, sandboxing, extensions

5.1 Where policy lives and which source wins

Claude Code reads user, project and local settings files, a --settings value for one session, and managed settings, which rank above all of them: “Nothing in your own settings files or --settings overrides a managed key” [1]. A small set of restrictive keys is the exception in the safe direction: a stricter value from a lower level is still honoured [1].

Managed settings reach a machine through four mechanisms [2].

On an Intune-managed Windows estate the registry policy under HKLM is the natural channel: it is what device management exists to deliver, it needs administrator rights to write, and Anthropic publishes starter templates for Intune, Group Policy and Jamf [2]. The file is the natural channel for Linux hosts and for images. Drop-ins let several teams own parts of one policy; files merge in alphabetical order, lists combine and later single values win [2].

The sources do not merge. By default Claude Code “uses the highest-ranked source that delivers at least one policy key and ignores the rest”, in the order server-managed, MDM, file, user registry, and it “shows no warning for the sources it skips” [2]. A few keys are read from every administrator source regardless, among them the sandbox locks, the MCP allowlist lock, deniedMcpServers, forceRemoteSettingsRefresh and, from version 2.1.223, the env block merged per variable. Login keys are taken from the device policy ahead of the server [2]. Everything else follows the first source.

The consequence is easy to miss. A device policy is silently displaced the day someone saves a single policy key in the admin console. My recommendation, which is a design choice and not a vendor statement:

• On managed devices, make the device-delivered policy the only policy. Leave the console’s managed settings empty, or restrict them to firms without device management.
• If server-managed settings are needed as well — cloud sessions do not read device policy [3] — set managedSourcesBehavior to "merge" in the highest-ranked source and treat both sources as one controlled document. Merging requires version 2.1.242 or later; under it, locks take the strictest value and lists combine [2].
• Confirm the result on a machine with /status, whose Setting sources line names the source in use, and with claude doctor [2]. From version 2.1.274 the managed_settings_resolved telemetry event reports the same thing for the fleet [8].

The system directories are administrator-writable only on Windows and on ordinary Linux hosts. WSL is the exception (section 7.1). A managed file that is present but is not valid JSON stops Claude Code from starting [2], so the deployment pipeline should validate the document before it ships.

5.2 Baseline policy

The source of this baseline is the documentation’s own example of an organisation’s managed file [17], extended with keys confirmed on the pages cited beside each. It is the Linux and WSL2 profile for interactive use on the Enterprise route. Replace the placeholders.

{
  "forceLoginMethod": "claudeai",
  "forceLoginOrgUUID": ["00000000-0000-0000-0000-000000000000"],
  "allowedProviders": ["anthropic"],
  "requiredMinimumVersion": "2.1.302",
  "permissions": {
    "defaultMode": "default",
    "disableBypassPermissionsMode": "disable",
    "blockReadsOutsideWorkingDirectories": true,
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(~/.ssh/**)",
      "Read(~/.azure/**)",
      "Read(~/.aws/**)",
      "Read(~/.kube/**)",
      "Bash(curl *)",
      "Bash(wget *)",
      "WebFetch",
      "WebSearch"
    ]
  },
  "allowManagedPermissionRulesOnly": true,
  "allowManagedHooksOnly": true,
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.example.internal/*" }
  ],
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowedDomains": ["packages.example.internal"],
      "allowManagedDomainsOnly": true
    }
  },
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://127.0.0.1:4317",
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
  },
  "cleanupPeriodDays": 14
}

What each group does, and where it is documented:

• Login and provider. forceLoginMethod, forceLoginOrgUUID and allowedProviders are described in section 4.2 [12][17].
• Version floor. requiredMinimumVersion is read only from managed settings and makes an older client exit at startup [18]. The floor of 2.1.302 is my choice: it is the first version in which non-interactive runs start in Manual mode when nothing sets a mode [5], and it is above the minimums for every other key used here.
• Modes. permissions.disableBypassPermissionsMode set to "disable" removes the bypass mode [4][17]. permissions.defaultMode set to "default" starts sessions in Manual mode, in which the developer approves actions [5].
• File reach. permissions.blockReadsOutsideWorkingDirectories makes the file tools refuse reads outside the working directories, apart from files Claude Code itself needs; the settings page ties its cross-scope behaviour to version 2.1.257 or later [1][4]. The Read deny rules cover the usual credential stores. ~/ is home-relative and ./ is relative to the working directory; an absolute path needs a double leading slash [4].
• Locks. allowManagedPermissionRulesOnly makes the managed file the only source of permission rules: Claude Code then ignores rules from user, project and local files and from --allowedTools, and stops offering to save new ones [18]. allowManagedHooksOnly restricts hooks to those the firm deploys, and allowManagedMcpServersOnly makes the managed MCP allowlist the only one. All three are read only from managed settings [2].
• Sandbox. sandbox.enabled turns the sandbox on; it is off by default. failIfUnavailable makes Claude Code refuse to start where the sandbox cannot run. allowUnsandboxedCommands set to false makes Claude Code ignore the request to retry a blocked command outside the sandbox — the route the Ona agent took. network.allowManagedDomainsOnly is managed-only and blocks every domain not on the managed list without prompting [2][6][17].
• Telemetry. The variables are those in the monitoring page’s administrator example [8]. A managed env value overwrites the same variable exported in the user’s shell [18]. CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC switches off Anthropic’s operational telemetry, error reports and surveys; it also disables feature-flag evaluation, which can make the Remote Control feature unavailable [13].
• Retention. cleanupPeriodDays sets how long local transcripts are kept. The default is 30 and the minimum is 1 [18].

Deny rules are the weakest part of this file, and it is built so that it does not rest on them. Read deny rules apply to the file tools and to file commands Claude Code recognises in a shell command. They do not apply to “arbitrary subprocesses that read or write files indirectly” [4]. The curl and wget rules match the command as written and nothing else. What holds is the sandbox, which adds the Read deny paths to what sandboxed commands cannot read [17] and routes all command traffic through a proxy with a managed allowlist. The rules stay because they remove the easy cases and produce a telemetry signal when they fire.

Variants.

• Native Windows. The sandbox does not run on native Windows; commands there run unsandboxed [6]. Omit failIfUnavailable, or Claude Code will not start. The file-reach key, the locks and endpoint controls carry more weight (section 6).
• Repository tiers. Deliver a different policy to a different device group. A managed file, profile or console setting applies one policy to everyone it reaches [2]. Lower tiers might re-allow WebFetch for named documentation domains.
• Build agents. Section 8.2 gives the differences.

Three choices the firm must make itself.

Auto mode. From version 2.1.283 auto mode is the built-in starting mode for interactive sessions on every plan and provider; a classifier model reviews actions and explicit ask and deny rules still apply [5]. The baseline starts sessions in Manual mode but does not remove auto mode, so a developer can still switch to it. The documentation describes a disableAutoMode control set to "disable" [4][5]. The pages I opened were not consistent about whether the key sits at the top level or under permissions, so I have left it out of the file; check the settings reference before using it. My own position is to keep regulated tiers in Manual mode outside a sandbox and to allow auto mode only inside one, after a pilot. That is judgement, not evidence.

Friction. With permission rules locked to the managed file, a developer cannot save an “always allow” answer. On Linux the sandbox’s auto-allow mode absorbs most of that: sandboxed commands run without a prompt [6]. On native Windows the lock will be felt, and a firm may reasonably set it only for higher tiers.

Plugins. Plugins are a further extension surface. The documentation lists strictKnownMarketplaces and strictPluginOnlyCustomization as managed-only locks for it [2]. I have not included them; decide deliberately.

5.3 MCP servers and hooks

“By default, anyone running Claude Code can connect any MCP server they choose”, and Anthropic “doesn’t security-audit or manage any MCP server” [16]. Two patterns are documented. A managed-mcp.json file in the system directory takes exclusive control: only its servers load, and an empty server map disables MCP. Alternatively, allowedMcpServers with allowManagedMcpServersOnly publishes an approved catalogue from which users add what they need [16]. Write allowlist entries by URL or by exact command. A name entry “is not a security control”, because the name is whatever label the user gives the server [16]. The denylist always applies and merges from every scope.

Treat approved hooks as code: reviewed, version-controlled and deployed in the managed file. allowManagedHooksOnly keeps a repository or a user from adding others.

5.4 Sandboxing

The sandbox enforces filesystem and network limits on shell commands with operating-system primitives: Seatbelt on macOS and bubblewrap on Linux and WSL2, where the bubblewrap and socat packages must be installed. It does not run on native Windows or WSL1 [6]. By default sandboxed commands can write only to the working directory and temporary directories, and have “no direct route out” to the network: connections go through a proxy that checks each host against an allowlist that starts empty [6].

Its limits matter as much as its strengths.

• It covers shell commands only. The file tools, MCP servers and hooks “run outside it” [6]. The file tools are governed by permission rules, which is why the baseline sets both.
• Default read access covers “most of the machine, including credential files such as ~/.ssh” [6]. Read restrictions have to be added.
• The proxy “does not terminate or inspect TLS traffic”, and Anthropic warns that broad domains such as github.com “can create paths for data exfiltration” and that domain fronting may reach hosts outside the list [6].
• Inside a container it needs the enableWeakerNestedSandbox setting, which “considerably weakens security” [6].

Anthropic’s summary is the right one: “Sandboxing reduces risk but is not a complete isolation boundary”, and it needs both halves, because without network isolation a compromised agent can exfiltrate files and without filesystem isolation it can open a network path [6]. On Linux, WSL2 and Linux build hosts, run with the sandbox on. Where a whole-process boundary is needed, the documentation points to a dev container or the separate sandbox runtime [6][7].

6. Windows estate

6.1 Packaging and deployment

Treat Claude Code as managed software.

1. Package a pinned version. The WinGet package is Anthropic.ClaudeCode and does not update itself. The native installer accepts a version number and installs into the user profile without administrator rights [9]. Because a user can therefore install it unaided, application control is the only way to prevent that. The Windows binary is signed by “Anthropic, PBC” [9], which gives a publisher to write a rule against; I have not tested such a rule. Whatever a user installs, the HKLM policy applies to it.
2. Decide the shell. Git for Windows is optional. With it, Claude Code uses Git Bash for its Bash tool; without it, it runs commands through its PowerShell tool. If Git Bash is not found, set CLAUDE_CODE_GIT_BASH_PATH [9].
3. Deliver policy by registry. An Intune configuration writes the Settings value under HKLM\SOFTWARE\Policies\ClaudeCode [2]. Where a file is preferred, write C:\Program Files\ClaudeCode\managed-settings.json and let an Intune Remediation re-assert its hash and access control on a schedule. Remediations are detection-and-remediation script packages that can run hourly or daily and report per device [27].
4. Assign by group. Map Entra security groups to repository tiers, and use the same groups for seat assignment.
5. Own the update cadence. autoUpdatesChannel set to "stable" follows a channel about a week behind the latest release. DISABLE_AUTOUPDATER stops the background check and DISABLE_UPDATES blocks every update path. requiredMinimumVersion and requiredMaximumVersion bound what may start [9][18]. Releases are frequent — three in the five days before this paper was checked [22] — so a ring-based rollout with a floor is more realistic than a single pinned version.

6.2 Endpoint posture

The agent runs with the user’s token, so ordinary endpoint posture is the outer wall: no local administrator rights for developers, endpoint detection and response, application control over what spawned processes may run, and credential protection. Local administrator rights matter directly here, because an administrator can edit the managed policy [2]. Endpoint process telemetry is a second, independent record of what Claude-spawned processes did, and it is the record to trust when the two disagree (section 10.2).

Anthropic adds one Windows-specific warning: do not enable WebDAV or let Claude Code reach paths that may contain WebDAV subdirectories, because that “may allow Claude Code to trigger network requests to remote hosts, bypassing the permission system” [7]. Claude Code prompts before a command that names a network (UNC) path, because touching one can send Windows credentials to the host it names [4].

6.3 Multi-session virtual desktops

On a multi-session host several users share one operating system. Prefer personal host pools or cloud desktops for agentic work. Where multi-session hosts are used: keep profiles separate, give each user their own working directory, apply the strictest tier, and treat ~/.claude as confidential user data, since it holds plaintext transcripts and settings [13]. Machine-level policy applies to every session on the host. Two shared-host problems need a decision. Credentials on Windows are stored in a file in the user profile that “inherits the access controls of your user profile directory” [12]. And a telemetry receiver bound to the loopback address is shared by everyone on the host (section 10.1). Image pipelines should bake in the client version, the policy and the telemetry agent so that a rebuilt host is compliant at first boot.

6.4 Cloud desktops

A dedicated cloud desktop behaves like a personal Windows endpoint under device management, and section 6.1 applies unchanged. Its advantage is network position: its traffic can be forced through the firm’s own network path, which makes the egress controls of section 9.1 easier to enforce than on a roaming laptop. It is a sound default for external contractors: firm policy, firm network path, no code on unmanaged hardware.

6.5 Native Windows or WSL2

Anthropic’s own table puts it plainly: sandboxing is “Not supported” on native Windows and “Supported” on WSL 2 [9]. For agentic work on Windows, WSL2 is the default I recommend. Native Windows remains appropriate for Windows-native development, under the stricter variant of the baseline. Telemetry from WSL carries a wsl.version resource attribute and os.type, so the split is visible without extra tagging [8].

7. Linux estate: workstations and WSL2

7.1 Policy delivery

On Linux workstations, use the configuration management that already runs the fleet to place /etc/claude-code/managed-settings.json, owned by root, and to install the client from Anthropic’s signed apt repository or an internal mirror of it. The repository’s signing-key fingerprint is published for verification, and package-manager installs do not update themselves [9].

WSL2 needs different treatment, and the usual advice is out of date. Anthropic notes that on WSL “/etc/claude-code is user-writable as well” [2]: the developer controls the distribution, so a policy file inside it is not an administrator source. The fix is a documented key. Setting wslInheritsWindowsSettings to true in the HKLM registry policy, or in a file under C:\Program Files\ClaudeCode\, makes Claude Code inside WSL read the Windows policy chain, and read /etc/claude-code only when no Windows administrator document is present. It is honoured only from those two Windows locations, has no effect on native Windows and requires version 2.1.282 or later [18]. One policy, delivered once by Intune, then governs both sides of the machine. A pre-built corporate distribution is still useful for shipping the sandbox packages and the client, but it is no longer what carries the policy.

Intune’s settings catalogue has a Windows Subsystem for Linux section. Microsoft recommends disabling WSL1 and the inbox version and disabling user control of kernel, networking and firewall configuration [28]. Disabling WSL1 matters here, because the sandbox requires WSL2 [6].

7.2 Runtime hardening

• Sandbox on, with no unsandboxed retry, as in the baseline. Install bubblewrap and socat in the image [6].
• Unprivileged user. Claude Code refuses to start in bypass mode as root or under sudo on Linux and macOS [5], but that is no reason to run it as root in any mode.
• Protect dotfiles. ~/.ssh, cloud CLI caches and kubeconfig are the valuable targets on a developer machine (T4). Deny them to the file tools, rely on the sandbox to carry those paths to shell commands, and prefer short-lived credentials over long-lived files.
• Containers for high-risk repositories. A per-repository dev container with only that repository mounted, a firewall on its network and no host credentials is the strongest isolation available on a workstation, and the only place where more autonomous modes are defensible [5][7].
• WSL2 and the Windows file system. A WSL session can reach Windows files under /mnt/c. The baseline’s blockReadsOutsideWorkingDirectories stops the file tools reading there. Where an explicit rule is wanted, write it with the absolute-path form, Read(//mnt/c/**); a single leading slash anchors at the settings source, not the filesystem root [4].

7.3 Host audit trail

Complement the tool’s telemetry with host-level accountability: the kernel audit subsystem or the endpoint agent watching process execution under developer sessions. When a Claude-spawned process misbehaves there are then two independent accounts, one from the agent and one from the kernel. An incident review needs both.

8. CI/CD: Claude Code on build agents

Non-interactive use is where the tool becomes an unattended actor holding pipeline privileges. Threat T7 — a pull request whose content steers an agent that holds a deployment credential — drives every control in this section.

Three documented behaviours of claude -p set the baseline.

• A -p session “runs the hooks in a project’s .claude/settings.json and connects the servers in its .mcp.json, even in a folder you’ve never trusted”, and shows no trust dialog [10]. A pull request that adds a hook is asking the pipeline to run a command.
• --allowedTools lists tools “that execute without prompting”. It does not remove any tool. “To restrict which tools are available, use --tools” [11]. --tools does not affect MCP tools.
• From version 2.1.302, runs with no mode set start in Manual mode, in which a call that needs approval is denied. Before that version such runs “could start in auto mode” on third-party providers [5]. The dontAsk mode makes the denial explicit: it “auto-denies every tool call that would otherwise prompt” [5].

8.1 Where it runs

8.2 Pipeline rules

1. One job, one disposable instance. No long-lived agents running Claude Code.
2. Policy in the image, not in the repository. The CI profile is a managed-settings.json in the image’s system directory. It sets allowManagedPermissionRulesOnly, so --allowedTools in a pipeline definition and rules in the repository are ignored; allowManagedHooksOnly, so repository hooks do not run; and an empty managed-mcp.json, so repository MCP servers do not load [2][16][18]. It omits the two login keys, which would block the workload credential (section 4.2), and sets allowedProviders to the provider the pipeline uses [12]. Require reviewer approval for changes to pipeline definitions and to .claude/ before any build runs them.
3. Split the pipeline. No deployment-capable credential in any job that runs an agentic step on untrusted input. An unprivileged agentic stage — review, triage, a proposed change — produces artefacts. A privileged stage with no agent in it consumes them behind a human or deterministic gate. The artefact is attacker-influenced text and is handled as such.
4. Model credentials from the secret store. A variable group linked to Azure Key Vault maps secret names into the pipeline and fetches the values at run time [30]; for Foundry, prefer Entra ID, where “there’s no API key to store” [19].
5. Human review for effects. Agent output that changes code arrives as a pull request. Branch policy enforces this whatever the agent attempts.
6. Telemetry mandatory. The same OpenTelemetry signals as endpoints, with resource attributes for the pipeline and project.
7. Bypass mode is not needed. dontAsk with managed allow rules gives an unattended run a fixed envelope. If a firm does use bypass mode in CI, the documentation’s condition applies: an isolated container without internet access [5].

8.3 Example shape

- job: claude_review
  pool: { name: scale-set-linux }
  container: registry.example.internal/ci/claude-runner:2026.11   # pinned client + CI policy
  variables:
  - group: ai-model-credentials        # variable group linked to the key vault
  steps:
  - checkout: self
  - script: |
      git diff origin/main... | claude -p "Review this diff for security issues." \
        --tools "Read,Grep,Glob" \
        --disallowedTools "mcp__*" \
        --permission-mode dontAsk \
        --output-format json > review.json
    env:
      ANTHROPIC_API_KEY: $(ANTHROPIC-API-KEY)
    displayName: Claude security review (read-only tool set)

What this does and does not give. --tools limits the built-in tools to three that read, and the --disallowedTools entry removes MCP tools [11]. The mode denies anything that would have prompted. The image’s policy disables repository hooks and MCP servers. An injected prompt therefore has no built-in tool with which to write a file or run a shell command. It can still read anything in the checkout and say anything in its output. Whether the job can reach the network beyond the model endpoint is decided by the subnet the agent sits on, not by any flag on this line. The flags, tool names and mode are as documented [5][10][11]; the Azure Pipelines syntax around them is illustrative and was not re-verified beyond the container-job and variable-group pages.

9. Network and data protection

9.1 Egress

Anthropic publishes the hosts the client needs [15]. For a session on Anthropic’s API the essential ones are api.anthropic.com for model requests, claude.ai, claude.com and platform.claude.com for sign-in and token exchange, sso.claude.com where single sign-on is used, and downloads.claude.ai for the installer and updates. On a cloud-provider route model traffic and authentication go to the provider instead, though the WebFetch tool still calls api.anthropic.com for a domain safety check unless skipWebFetchPreflight is set [15]. Enforce the list where the estate already has enforcement points: the cloud firewall for virtual desktops and build agents, the secure web gateway for laptops.

Standard proxy variables are honoured and can be set in the managed env block; SOCKS proxies are not supported. The client trusts the operating system’s certificate store by default, so a TLS-inspecting proxy whose root is installed there works without further configuration [15].

The network half of the “no personal accounts” rule is a documented feature, Tenant Restrictions. A TLS-inspecting proxy injects an anthropic-allowed-org-ids header into requests to Anthropic’s domains, and Anthropic “blocks access from any organization not in the allowed list”. It is available to Enterprise plans and Console organisations and covers API-key and OAuth authentication [35]. The article does not name Claude Code, although Anthropic’s Claude Code documentation points to it for this purpose [3]; test it before relying on it.

9.2 What reaches the model endpoint

What leaves the machine is the prompt and its context: code, file contents, command output. Four kinds of control apply.

• Contractual. Under commercial terms Anthropic “does not train generative models using code or prompts sent to Claude Code”. Standard retention for Team, Enterprise and API use is 30 days. Zero data retention is available for Claude Code to qualified Enterprise accounts, is not part of the standard plan, and disables features that need server-side storage, including cloud sessions and Remote Control [13][14]. Record retention per route in the data-processing inventory.
• Classification. Decide which repository tiers may be worked on with Claude Code at all, and on which route.
• Content hygiene. File exclusion is done with Read deny rules. A .claudeignore file has no effect [4]. Keep production data out of repositories.
• Inline inspection. A gateway route allows inspection or redaction of prompts. Endpoint data-loss tooling does not see inside the TLS session to the model endpoint and should not be counted on for this channel.

9.3 Secrets

Secrets do not sit where the agent reads. Services use workload identity against the secret store, pipelines use store-linked variables, and developers use short-lived tokens. Two documented details affect design. The sandbox passes Claude Code’s environment, “including any secrets in its environment”, to the commands it runs [6]. And any user on a machine can read a managed-mcp.json, so credentials do not belong in it [16]. Scan what the agent writes before merge: an agent shown a credential may repeat it.

9.4 Local artefacts

~/.claude/ holds settings and session history. Transcripts are stored “locally in plaintext under ~/.claude/projects/ for 30 days by default” [13]. Classify the directory as confidential, bound retention with cleanupPeriodDays, keep it inside disk-encryption scope and outside any backup or sync path that would copy source fragments into lower-trust storage. The retention_sweep telemetry event shows whether machines are applying the managed period [8].

10. Monitoring: Datadog as the worked example

Claude Code exports OpenTelemetry metrics, events (as OpenTelemetry logs) and, in beta, traces. Export is off until configured, and an administrator can configure it for all users through managed settings [8]. Monitoring is therefore a policy decision. The controls below need only a backend that accepts OTLP; Datadog is used because it documents a Claude Code setup. Its product for this is called Agent Console, which Datadog describes as available to all customers “in Preview” on the day I checked [32].

Two documented properties make the export trustworthy as configuration. Claude Code ignores the OpenTelemetry exporter variables in a repository’s settings files, so “a repository can’t use them to turn telemetry on, choose where it goes, or capture content” (version 2.1.282 or later). And when an OTLP variable is set in managed settings, conflicting developer-set variables are removed at startup [8][18].

10.1 Transport

Bind the receiver to the loopback address. Datadog’s Agent Console page shows the receiver on 0.0.0.0:4317 beside a client that exports to 127.0.0.1 [32]. Datadog’s own OTLP ingestion page says that 0.0.0.0 is used in examples “for convenience” and that for better security “especially in local deployments” one should consider localhost [33]. A receiver on all interfaces accepts telemetry from anything that can reach the host. The same page notes that OTLP log ingestion is disabled by default and needs Agent 7.48.0 or later [33]. Datadog also asks for a log index that covers service:claude-code [32].

Loopback is per host, not per user. On a multi-session desktop every user’s processes can post to a receiver on 127.0.0.1, and an OTLP receiver configured as above does not authenticate the sender. Any user on that host can submit telemetry that claims to come from another. On shared hosts, send to a central collector that authenticates each connection, and treat what arrives as a signal to corroborate. The wider point holds on every host: the client that emits the telemetry runs as the user, so the user can always fabricate it. Host process telemetry is the independent record.

10.2 What arrives

Metrics, prefixed claude_code.: session.count, active_time.total, cost.usage (USD), token.usage, lines_of_code.count, commit.count, pull_request.count and code_edit_tool.decision [8].

Events, also prefixed claude_code.: user_prompt, api_request, api_error, tool_result and tool_decision, linked by a prompt.id that ties every event to the prompt that produced it. The documentation lists further events useful for security work: permission_mode_changed, auth, mcp_server_connection, safety_event (version 2.1.307 or later), managed_settings_resolved (2.1.274 or later) and retention_sweep [8]. A tool_decision carries a decision of accept or reject and a source such as config, hook or user_reject. A filter on decision=deny matches nothing.

Identity depends on the route. user.email, user.account_uuid and organization.id are present when the session is signed in with a Claude account. When Claude Code authenticates “with a direct API key, or against Amazon Bedrock, Google Cloud’s Agent Platform, or Microsoft Foundry, there is no Claude account in the session and only user.id and session.id are populated”; user.id is a random installation identifier. Anthropic’s advice for those routes is to attach identity through OTEL_RESOURCE_ATTRIBUTES, set per user by a launch wrapper [8].

Content is off by default. Prompt text, response text, tool arguments and tool output are each withheld unless a specific variable enables them: OTEL_LOG_USER_PROMPTS, OTEL_LOG_ASSISTANT_RESPONSES, OTEL_LOG_TOOL_DETAILS, OTEL_LOG_TOOL_CONTENT [8]. In a regulated firm I would leave prompt and response content off and record that choice. OTEL_LOG_TOOL_DETAILS is the difficult one: it adds command strings and MCP server and tool names, which is what an investigator wants, and Anthropic warns that this detail “can contain the same sensitive content as the session itself” [8]. Enable it only into a store approved to hold source-level content.

The resource attribute service.name is claude-code for terminal sessions and claude-code-desktop for sessions started from the desktop application [8]. Filters need both.

10.3 Dashboards and monitors

Build one governance view (adoption by team and platform, spend by model and pipeline, cache efficiency) and one security view (decisions by source, rejected calls, mode changes, sandbox violations, API errors, endpoint against CI). Proposed monitors:

The telemetry-gap monitor is the one I would build first. It is the only one that works when everything else has been switched off, because it compares what the tool reports with what the host reports. It depends on process visibility from the host agent and on telemetry tagged with the host.

The unknown-identity monitor in common circulation — alert when user.email is not on an allowlist — works only on the subscription route, since no other route emits that attribute. It is also a detective control for something the login keys of section 4.2 prevent. On API-key and cloud-provider routes, identity is whatever the launch wrapper asserts. Anthropic is explicit that it “emits the raw event stream only”; baselining, correlation and alerting are the backend’s job [8].

10.4 Audit

Route the events into the firm’s security analytics and write detections on sequences: many file reads followed by a rejected network attempt, or a bypass-mode session start anywhere outside the CI allowlist. For the administrative record on the Enterprise plan, Datadog’s “Claude Compliance” integration ingests activity logs from Anthropic’s Compliance API, including SSO sign-ins and API-key lifecycle events; it requires an Enterprise plan and the Compliance API to be enabled [34]. The Compliance API is not available for Claude in Microsoft Foundry [23], and Anthropic states that audit events for changes to server-managed settings are available through it or through audit-log export [3]. Set retention to match the firm’s evidence horizon.

11. Governance and compliance mapping

Claude Code is an ICT third-party service and an internal tool, and it should pass through the frameworks that already exist. The table is my mapping, as of November 2026. It is argument, not legal advice. The article numbers were read in the Official Journal texts on EUR-Lex on 10 November 2026. Which obligations apply to a given firm and arrangement is for its risk and legal functions.

Roles. Security engineering owns the policy baseline and the detections. The platform function owns packaging, distribution, telemetry plumbing and developer experience. Application security owns repository tiering and review gates. The risk function owns the register, materiality and reporting. A change to the managed policy follows change management with security approval. It is a control, and its history is evidence.

Accountability. The acceptable-use policy states that the developer, or the pipeline owner, remains accountable for what is committed and deployed. Agent output passes the same review, testing and branch-protection gates as human code. The agent never becomes an unreviewed committer.

12. Reference architecture and roadmap

12.1 Reference flow

flowchart LR
  MDM[Device management<br/>HKLM registry policy] -->|one policy| WIN[Windows 11 / virtual desktop<br/>native or WSL2]
  CM[Configuration management<br/>/etc/claude-code file] --> LNX[Linux workstation]
  IMG[Image pipeline<br/>CI policy in image] --> CI[Build agent<br/>disposable, unprivileged stage]
  WIN --> CC[Claude Code]
  LNX --> CC
  CI --> CC
  CC -->|prompts| EP[Approved model endpoint<br/>Enterprise org / Foundry / API]
  CC -->|OTLP| COL[Local agent or central collector]
  COL --> OBS[Observability backend:<br/>dashboards, monitors, security analytics]
  HOST[Host process telemetry] --> OBS
  CAPI[Compliance API] --> OBS
  KV[Secret store] -->|runtime credential| CI
  CI -->|artefact| GATE[Gated, non-agentic stage]
  FW[Firewall / web gateway] -.egress allowlist.- CC

One policy, projected by the channel that owns each surface. One identity anchor. One telemetry path, with host telemetry beside it as the independent record. Network enforcement around all of it.

12.2 Phased roadmap

This is a proposal. The durations are my estimates for a firm that already has the estate in place.

A pilot also answers the calibration question. Too strict, and developers route around the tool; too loose, and the policy is decoration. Rejection and prompt counts from the pilot’s telemetry let the firm set the dial from data.

12.3 Checklist

• SSO into the firm’s organisation; login method, organisation and provider pinned by device policy
• One managed source chosen; /status confirms it on each surface; bypass mode removed
• WSL inherits the Windows policy
• Permission rules, hooks and MCP servers locked to the managed set
• Sandbox on for Linux and WSL2, with no unsandboxed retry and a managed domain list
• Telemetry on by policy; receiver bound to loopback, or a central collector on shared hosts
• Telemetry-gap, mode-escalation, source-drift and cost monitors active
• CI policy in the image; agentic stage unprivileged; privileged stage gated
• Secrets only in the secret store; agent-authored changes scanned and reviewed
• Provider and route recorded in the ICT third-party register

13. Limitations

The settings will date. This is a paper about exact keys in a product that released three versions in the five days before it was checked [22]. Several keys in the baseline did not exist a year earlier, and one path that was correct then is now ignored. Treat every key, path, flag and version number as true on 10 November 2026 and no later. To re-check: open the settings reference and the managed-settings page [2][18] and confirm each key in the baseline and its scope; read the changelog from the firm’s current floor forward [22]; run claude doctor and /status on one machine per surface and compare the Setting sources line with the intended source [2]; and validate the policy document against the published JSON schema, bearing in mind that the schema “can lag behind the newest CLI releases” [1].

Documentation was verified, not behaviour. No setting in this paper was exercised against a running client for the purpose of writing it. Where the documentation is inconsistent — the placement of the auto-mode control is the example I found — the paper says so and leaves the key out.

Not everything was opened. AWS and Google documentation was not opened; section 4.3 rests on Anthropic’s provider pages. Microsoft endpoint controls other than those cited are named and not verified. The Azure Pipelines syntax in section 8.3 is illustrative.

The proposals are untested. The baseline, the split pipeline, the monitors and the roadmap are designs. I have no controlled evidence that they reduce incidents, and the roadmap durations are estimates.

The model endpoint is taken as given. The paper does not assess Anthropic’s or Microsoft’s internal controls, the sufficiency of any contractual term, or whether a given hosting and residency option satisfies a given firm’s obligations.

Client-side controls remain client-side. Everything in section 5 is enforced by the program it governs. The paper’s answer is layering. It does not claim that the layers close the gap, and Anthropic’s own documentation does not claim that either [3][6].

One research report is cited for sandbox behaviour. The Ona write-up [37] is a vendor’s account of its own test, on an unstated client version, written to introduce the vendor’s product. It is cited because it names a concrete technique that the documentation’s own warnings are consistent with.

References

All web sources were accessed on 10 November 2026 unless stated.

1. Anthropic, Claude Code Docs, “Settings files and precedence”. https://code.claude.com/docs/en/settings
2. Anthropic, Claude Code Docs, “Deploy managed settings”. https://code.claude.com/docs/en/managed-settings
3. Anthropic, Claude Code Docs, “Configure server-managed settings”. https://code.claude.com/docs/en/server-managed-settings
4. Anthropic, Claude Code Docs, “Configure permissions”. https://code.claude.com/docs/en/permissions
5. Anthropic, Claude Code Docs, “Choose a permission mode”. https://code.claude.com/docs/en/permission-modes
6. Anthropic, Claude Code Docs, “Configure the sandboxed Bash tool”. https://code.claude.com/docs/en/sandboxing
7. Anthropic, Claude Code Docs, “Security”. https://code.claude.com/docs/en/security
8. Anthropic, Claude Code Docs, “Monitoring”. https://code.claude.com/docs/en/monitoring-usage
9. Anthropic, Claude Code Docs, “Advanced setup”. https://code.claude.com/docs/en/setup
10. Anthropic, Claude Code Docs, “Run Claude Code programmatically”. https://code.claude.com/docs/en/headless
11. Anthropic, Claude Code Docs, “CLI reference”. https://code.claude.com/docs/en/cli-reference
12. Anthropic, Claude Code Docs, “Authentication”. https://code.claude.com/docs/en/authentication
13. Anthropic, Claude Code Docs, “Data usage”. https://code.claude.com/docs/en/data-usage
14. Anthropic, Claude Code Docs, “Zero data retention”. https://code.claude.com/docs/en/zero-data-retention
15. Anthropic, Claude Code Docs, “Enterprise network configuration”. https://code.claude.com/docs/en/network-config
16. Anthropic, Claude Code Docs, “Control MCP server access for your organization”. https://code.claude.com/docs/en/managed-mcp
17. Anthropic, Claude Code Docs, “Example settings files”, section “An organization’s managed settings”. https://code.claude.com/docs/en/settings-example
18. Anthropic, Claude Code Docs, settings reference (linked in the documentation as “All settings”), entries for allowManagedPermissionRulesOnly, cleanupPeriodDays, env, requiredMinimumVersion and wslInheritsWindowsSettings. https://code.claude.com/docs/en/settings-reference
19. Anthropic, Claude Code Docs, “Claude Code on Microsoft Foundry”. https://code.claude.com/docs/en/microsoft-foundry
20. Anthropic, Claude Code Docs, “Claude Code on Amazon Bedrock”. https://code.claude.com/docs/en/amazon-bedrock
21. Anthropic, Claude Code Docs, “Claude Code on Google Cloud’s Agent Platform”. https://code.claude.com/docs/en/google-vertex-ai
22. Anthropic, Claude Code Docs, changelog page; most recent entry 2.1.322, dated 10 November 2026. https://code.claude.com/docs/en/changelog
23. Anthropic, Claude Platform Docs, “Claude in Microsoft Foundry”. https://platform.claude.com/docs/en/build-with-claude/claude-in-microsoft-foundry
24. Microsoft Learn, “Claude models in Microsoft Foundry”, article dated 21 September 2026. https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/claude-models
25. Microsoft Learn, “Compare hosting options for Claude models in Microsoft Foundry”, article dated 21 September 2026. https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/claude-models-hosting-comparison
26. Microsoft Learn, “Data, privacy, and security for use of Anthropic Claude models in Microsoft Foundry”, article dated 23 June 2026. https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/claude-models/data-privacy
27. Microsoft Learn, “Use Remediations to Detect and Fix Support Issues” (Microsoft Intune), article dated 8 September 2025. https://learn.microsoft.com/en-us/intune/device-management/tools/deploy-remediations
28. Microsoft Learn, “Intune settings” (Windows Subsystem for Linux), article dated 30 October 2026. https://learn.microsoft.com/en-us/windows/wsl/intune
29. Microsoft Learn, “YAML pipeline container jobs” (Azure Pipelines), article dated 9 September 2026. https://learn.microsoft.com/en-us/azure/devops/pipelines/process/container-phases
30. Microsoft Learn, “Link a variable group to secrets in Azure Key Vault” (Azure Pipelines), article dated 10 September 2025. https://learn.microsoft.com/en-us/azure/devops/pipelines/library/link-variable-groups-to-key-vaults
31. Microsoft Learn, “Azure Virtual Machine Scale Set agents” (Azure Pipelines), article dated 12 June 2025. https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/scale-set-agents
32. Datadog Docs, “Set Up Agent Console”. https://docs.datadoghq.com/ai_agents_console/setup/
33. Datadog Docs, “OTLP Ingestion by the Datadog Agent”. https://docs.datadoghq.com/opentelemetry/setup/otlp_ingest_in_the_agent/
34. Datadog Docs, “Claude Compliance” integration. https://docs.datadoghq.com/integrations/anthropic-compliance-logs/
35. Anthropic, Claude Help Center, “Enforce network-level access control with Tenant Restrictions”. https://support.claude.com/en/articles/13198485-enforce-network-level-access-control-with-tenant-restrictions
36. Anthropic, plan comparison on the Claude pricing page. https://claude.com/pricing
37. Leonardo Di Donato, “How Claude Code escapes its own denylist and sandbox”, Ona, 3 March 2026. https://ona.com/stories/how-claude-code-escapes-its-own-denylist-and-sandbox
38. Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (DORA), OJ L 333, 27.12.2022, p. 1. Articles 10, 17, 19, 28(3), 28(8) and 30. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R2554 Read in the Official Journal text on EUR-Lex, 10 November 2026.
39. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation), OJ L 119, 4.5.2016, p. 1. Articles 28, 30 and 32. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679 Read in the Official Journal text on EUR-Lex, 10 November 2026.