Part 2: A CISO's Guide to Securing Claude in the Enterprise
Jason Rebholz
Imagine trying to defend a loggia against an attack. Do you know what a loggia is? If you do, you’re an architecture nerd. If you don’t, that’s exactly what trying to secure Claude is like when you don’t know all of its components or how it works. That’s why in Part 1 of the series, we covered Claude’s various components and features. You can’t defend what you don’t understand.
No organization can escape the productivity paradox with agents. For agents to be more than a chatbot, you have to give them access. For Claude, this comes in the form of network access, connectors to other SaaS applications, Agent Skills, and the ability to generate and execute code. Those capabilities compound risk. The question for any security leader: how do you let users move fast without materially increasing risk to the business?
There’s good news and bad news with Anthropic’s enterprise controls. The good news: Anthropic enables management of Claude across the enterprise. The bad news: those management capabilities leave a lot to be desired.
The bottom line: you can set secure defaults in Anthropic, but you will still not be secure.
That doesn’t mean you should ignore it. Start with what Anthropic provides, understand the gaps, and then work to fill them.
Claude AI
When securing Claude AI, the focus is on which capabilities you want to enable for users. Think of this in terms of the general employee population vs developers, who will operate more in Claude Code.
Web search: Allows Claude to search the internet for up-to-date information, including accessing specific URLs users provide or making generic searches. Very powerful, but also opens you up to prompt injection and data exfiltration risks.
Code execution: Allows Claude to execute code and create files like documents, spreadsheets, and PDFs. The risk: you're allowing Claude to create and execute code on your system. With access to your local file system, that gets interesting fast, especially around network egress. Enabling this also enables a sandbox for Claude, but as I've written before, a sandbox is more like a public beach when it comes to agents.
Network egress: Enables Claude to access the internet to install packages and libraries for advanced tasks like data visualization and analytics. It's a toggle with three levels of control:
None: Claude can access only the domains you allow, forcing it to operate only with the pre-installed packages. It’s the most secure, but also the most limiting to the user experience.
Package managers only: Limited to common package managers (npm, PyPi, GitHub, Python, Rust, Ubuntu, Yarn, and Anthropic) plus any domains you add. A reasonable balance of security and functionality, but attackers can register malicious packages on any of these.
All domains: Claude can access any domain except what's on Anthropic's block list. Avoid this.
Anthropic's own guidance here is sound: start with network access disabled. If that's not robust enough, enable package managers. If you hit gaps, add specific domains to the allow list. Don't open the floodgates.
Claude Code
The agentic coding workhorse, and what powers Cowork. You’ll see that power comes with a lot of configuration options, which can be daunting. I’ve narrowed it down to the main things to think about, but a full review is warranted for your environment
Allow bypass permissions mode: One of the most consequential settings. When enabled, it bypasses all permission checks in Claude Code, meaning it won't ask users for approvals regardless of how risky the action is. Developers love it because they can move faster with less oversight. That's also exactly what makes it dangerous. The agent can do anything without a human-in-the-loop, like wiping files.
Remote Control: Lets you start a task at your desk and continue it from your phone or any browser. Everything runs locally on your machine. The web and mobile interfaces are just a window into that local session.
Tread carefully here. This feature creates a backdoor of sorts into your local system. It requires an active session and compromised credentials to exploit, but the risk is real. If you need to run this, you’re better off using Claude in a cloud-hosted container rather than running it locally.
Managed Settings: The most important enterprise controls. Without them, every user manages their own settings locally, which, as you can imagine, is an absolute disaster. With managed settings, you can centrally control:
Allowed marketplaces of skills and plug-ins
Allowed models
Allowed domains
Advanced sandbox settings
Tool permissions
It’s insanely powerful if you take the time to lock it down. Getting these controls right across an organization, with different configurations for different user populations, is not easy. Without visibility into how users are actually using Claude, you're guessing.
There are two approaches to deploying managed settings:
Server-managed settings are configured and deployed from Anthropic. If you don’t centrally manage devices in your organization, this is your only path. This comes with some key limitations:
No per-user or per-group configuration. It’s all or nothing (at least at the time of this writing).
These are client-side controls. On unmanaged devices, users with admin or sudo access can modify these configuration files to circumvent them, even if just temporarily (more on that in a second).
MCP server configurations can’t be distributed
Settings won’t apply if a user authenticates with a different organization or sets a non-default Anthropic Base URL (e.g., if you’re proxying traffic through an LLM gateway).
Claude Code fetches settings at startup and polls hourly during active sessions.
Certain high-risk settings (e.g., shell commands, custom environment variables, hook configurations) require explicit user approval before being applied. If a user rejects them, Claude Code exits.
Endpoint-managed settings are deployed via your MDM (e.g. Kanji, Jamf, Intune, etc.). You can deploy and lock these files so they can't be modified. One catch: if you run both, server-managed settings take precedence.
Claude Cowork
Cowork is essentially a user-friendly interface for Claude Code's functionality. From the admin portal, your controls are simpler:
Enable for your organization: On or off. Easy enough.
Monitoring: You can stream OpenTelemetry logs for observability. By default, prompts, MCP server/tool names, and skill names are excluded from logs. The critical caveat is that observability is passive. It's useful for post-mortems, but it won’t provide detection capabilities or the ability to block malicious or anomalous activity.
The biggest risks with Cowork are that you’re giving an agent (Claude Code) to a general population. It’s extremely powerful. If you don’t manage the connectors (MCPs), Skills, and Plug-ins, you have an entirely new attack surface to monitor and secure.
The biggest risk with Cowork is that you're giving Claude Code's full agentic power to a general user population. If you don't govern connectors (MCPs), Skills, and Plugins, you've opened an entirely new attack surface with minimal visibility.
Claude in Chrome
A browser extension that lets Claude interact with your browser directly. When Claude needs to take action in a browser, it opens a grouped tab in Chrome and operates as the logged-in user with all of their access.
Enable for your team: On or off.
Blocked sites: Manage a list of websites that Claude in Chrome cannot access.
The primary risk here is Claude acting on a user's behalf with access to sensitive data and susceptibility to prompt injection hidden on websites. A website with hidden prompt injection has full access to everything connected to Claude.
Libraries
The final configuration options in Organization Settings, these touch on similar concepts seen in Claude Code.
Plugins: Manage your organization's approved plugins, uploaded via ZIP archives or synced from GitHub. The main risk here are plugins that users pull from the internet with no vetting or controls in place.
Connectors: Control which web and desktop connectors (MCP servers) your team can use, including uploading custom ones. The more tools connected to Claude, the more risk compounds. Claude becomes a single conduit to every integrated system.
Skills: Enables Agent Skills across the organization, which also requires enabling code execution and file creation. Once enabled, you can manage the skills available to your organization. Allowing users to import their own skills gives a lot of freedom, but it is a major supply chain risk.
Claude Desktop
And you thought we were done. Nope, there’s more. You can also manage Claude Desktop configurations through system policies. On Macs, it’s through configuration profiles, and on Windows, it’s through Group Policies. Key controls include:
Manage automatic updates
Manage Claude Code access
Manage Cowork access
Manage allowed desktop extensions (allow interaction with your local system)
These are more limited than the settings Claude Code manages, but they are a necessary layer for endpoint governance.
Key Takeaways
With something as powerful as Claude, enterprise management is broad strokes rather than fine-tuned control. The biggest risks:
Connectors/MCP servers: Allow connections to external resources with minimal oversight
Agent Skills: A supply chain risk waiting to happen
Network access: Opens the aperture for prompt injection and data exfiltration
Claude in Chrome: Similar to network access, but worse. It inherits the logged-in user's permissions on every site
Most glaring of all is the limited visibility into what Claude is actually doing. Security teams are largely in the dark about user behavior, let alone what Claude is doing.
When you're this early in securing the agentic workforce, start with the basics:
Get an inventory of what's deployed in your environment. Every agent, every skill, every MCP, every tool.
Establish enforceable policies based on your business objectives and risk tolerance.
Build a Skills/MCP registry of approved and continuously scanned integrations. If you're not running a registry, every skill and MCP a user loads should be scanned and confirmed clean before it executes. This is freedom in a framework.
Get visibility and monitor agent activity for malicious, anomalous, or destructive behavior.
If you need help with any of these, Evoke is here to help.