I love efficiency. Any task or workflow I run more than once, I turn into in a script, a skill, an agent or a combination of it. It is converted into repeatable and reusable set of instructions, depending on what it needs, while balancing the use of agentic AI/LLMs vs. good old scripting (why burn tokens, when you can just run a script).

I rarely download skills, but build them myself, because no one understands my context and business needs better than me. Python is my favourite scripting tool (used to be PowerShell on Mac, since I did a lot of hacking with PowerShell popping proprietary products). Now, there is nothing that beats Claude for most of my business and work. OpenClaw is still restricted for non-enterprise non-sensitive work. On the UX-side my absolute favourite tool used to be Notion. But since agentic AI became a regular part of my work, now it’s Claude Cowork integrated with Notion.

Recently, a tech manager asked me my best practices to use Claude Cowork, securely within an enterprise context.

The integration of Claude in general into business has been massive. Claude Cowork is available for enterprise, and it’s being integrated immensely into enterprise workflows, also including into MS apps, Google apps and more. I know others that I know have been integrating it with tools like Microsoft, Google Drive, etc. within their enterprise but without paying any attention to the security aspect of it. A lot of the times as shadow AI.

So, I decided to share my experiences and how I secure my agents.

This one’s for you (you know who you are) and for anyone who wants to use the power of Claude Cowork within your organisation safely, securely and without needing to click “Allow” every two minutes.

This one covers mainly Claude Cowork as the primary example, however, all almost of these principles are valid for any agentic AI tool you may be using.

My top most important security best practices that matter, specifically around Claude Cowork, however, they are true for any agentic AI. Let’s dig in.

Chrome extensions in general increase the attack surface drastically, e.g. in 2024 one was silently updated with malicious code that harvested OAuth tokens from users' active Google Workspace, Slack, and Jira browser sessions, affecting 400,000+ users across 2.6 million total. When it is an AI agent it gets worse.

I use developers tool in a browser quite often to be more productive, download certain info programmatically using scripts, or just analyse the https requests/responses and how the information is flowing, etc. But it still requires me to use those scripts through different page loads.

Sometimes, I just want an authenticated browser session to find me information that I am looking for without having to scroll through and click-through all buttons and hyperlinks, without manually running Javascript inside the browser console, and often do that simultaneously across multiple sessions, and gather and correlate that info for me. There are many ways to do this programmatically. But, I automated most of my browser related tasks using Claude in Chrome extension to do that work for me.

I am comfortable with code in browser, dissecting pages and finding things that I need. But here’s the catch, Cowork reads the full content of every authenticated session open in your browser: Your internal wiki, your ITSM platform, your finance dashboards, your HR system. None of those sessions authenticate separately to Cowork. They inherit from the browser. So, be mindful of all authenticated sessions in the browser when the extension is running.

In March 2026, a zero-click vulnerability in the Claude Chrome extension allowed any malicious website to inject prompts silently and steal Google OAuth tokens, Gmail contents, and Drive files from authenticated sessions already open in the browser. No user action required. The extension's browser session access was the entire attack surface.

Every document uploaded, every page Claude in Chrome loads, and every MCP response is content the agent reads and acts on, including hidden instructions from a malicious source.

OWASP ranks prompt injection as the #1 LLM security risk for exactly this reason. Two days after Cowork launched in January 2026, PromptArmor disclosed that a Word document with invisible white-on-white text caused Cowork to silently run shell commands uploading sensitive files, including partial Social Security numbers, to an attacker's Anthropic account via the Files API, with no approval prompt and nothing visible to the user. The shell executed the instruction and the data left the workspace unnoticed.

A Cowork plugin is not just a tool extension: it is an instruction set the agent follows without displaying to the user. An unvetted plugin can carry hidden instructions in its metadata that override default Cowork behaviour with no visible change to the interface. In early 2026, attackers distributed 341 malicious skills across OpenClaw's ClawHub marketplace using professional documentation and innocuous names, with hidden instructions silently installing keyloggers and Atomic Stealer malware on enterprise devices before discovery. Add to that, researchers found zero-day RCE (Remote Code Execution) vulnerability in Claude Desktop Extensions. Unlike skills, extensions run by default in non-sandboxed mode with full privileges.

Every MCP connector extends Cowork’s reach massively. Even MCP installed in Cowork stores an OAuth token on the device carrying the full permissions of the user who authorised it. It add to the attack surface. MCP connectors, web fetch, and web search are not subject to network egress controls. MCP tools can update their own metadata after you approve them, meaning a connector that looked safe on day one can quietly reroute your credentials by day seven with your monitoring seeing nothing anomalous. JFrog disclosed CVE-2025-6514, a critical command injection vulnerability in mcp-remote, a widely used OAuth proxy for MCP clients. In April 2026, one employee connecting an AI tool via OAuth handed attackers access to Vercel's internal systems, customer API keys, and source code, with ShinyHunters listing the data for sale and Vercel warning of downstream breaches across hundreds of organisations.

A Cowork scheduled task runs without the user present, without re-authentication, and carries the full permissions of whoever created it. It does not expire when that person logs off, takes leave, or leaves the organisation. In September 2025, Anthropic disrupted a Chinese state-sponsored group that had weaponised Claude Code to execute autonomous attacks against thirty global targets with minimal human intervention. It was the first documented AI-orchestrated espionage campaign where the agent ran entirely on its own permissions. As AI agents and orchestrated workflows have become more autonomous, their validation throughout the agentic lifecycle has become more critical. Scheduled agentic tasks are the stepping stone into a bigger, orchestrated and autonomous AI workflow across your enterprise.

Mounting a folder in Cowork gives the agent read and write access to every file within it, with no granular permission layer between connected and fully accessible.

Most users mount their entire working directory by default because that is the path of least friction. In March 2023, Samsung engineers uploaded source code, internal meeting transcripts, and chip test sequences into ChatGPT, leading Samsung to ban all generative AI tools organisation-wide. That was just a chatbot. This is a your AI agent.

Using an AI agent, makes this even worse, because now it doesn’t just have access to your data, but also privileges to execute on that data and take further actions doing potentially more harm.

Most people forget to scrutinise the output that your agents generate. Just because it ran and executed successfully doesn’t mean it executed securely.

Cowork's sandboxed shell isolates code execution from the host, but the output files written during a session land in the workspace folder, transferable like any other file.

Data generated from sensitive inputs does not disappear when the session closes. It may have malicious code hidden inside. It may generate more sensitive data that requires further measures.

Claude doesn’t check for it. It doesn’t classify the output for you. It does not protect against data leaking through the output files it writes. The EDR tools cannot inspect activity inside the Cowork VM by design, because the VM is isolated from host-based security tools. What the shell processes and writes, your endpoint detection never sees.

You cannot manage the risks around that output adequately, until you add the necessary level of classification along with the necessary controls. Your output files are not automatically protected by adequate controls, until you apply them.

A skill is reusable set of instructions for any repeated workflow. Think of it like telling your agent how it should think. I use skills all the time.

A Cowork skill is an instruction file with a set of reusable instructions across a repeatable workflow, that the agent follows alongside your prompts.

Even just one sourced from an unvetted repository can modify agent behaviour with no visible change to the interface and no alert to the user. The user installs it for productivity. The agent follows instructions they have never read. Malicious skills are everywhere. OpenClaw’s own marketplace had about 341 of them. SentinelOne demonstrated that a single Claude skill from an unofficial marketplace silently redirected dependency installs to attacker-controlled sources, embedding trojanized libraries with no visible error, with the skill persisting that behaviour across every future session in which it remained installed.

BTW, this is not a build vs. buy argument. Eventually you’ll need both, depending on what you are using them for and how complex of an agentic AI system you are building. As a thumb rule, build whenever you can, buy / integrate from external sources when you must.

This is so overlooked. Every Cowork session generates a local conversation transcript on the user's device containing everything discussed, every file processed, and every output generated.

Your strategy documents, legal correspondence, financial models, anything a user brought into that session now lives in a local file that Anthropic's own documentation confirms cannot be centrally managed, exported by admins, or accessed through the Compliance API. It sits outside your standard data retention framework entirely.

Most organisations have never looked at what is in those transcripts, because nothing in the default setup prompts them to and they don’t think of them as data stores, but they are one. If you aren’t careful with where your session outputs are stored, how are they accessible and by whom, you may be leaking data without realising. In March 2026, Oasis Security's "Claudy Day" attack demonstrated against Claude that session conversation history containing pending acquisitions, health diagnoses, and financial strategy could be silently exfiltrated in a single request. Cowork session transcripts hold the same content, stored locally, with fewer central controls than Claude.ai's server-side architecture.

Most security conversations about AI agents focus on sandbox escapes.

Claude Cowork requires a desktop app. In Cowork, the more significant exposure is not the code execution sandbox. It is the native agent loop, which runs directly on your host device with your full OS user permissions by design.

For file read/writes, MCPs, etc. there is no sandbox to escape from. Every component in Cowork, skills, plugins, MCP connectors, the sandboxed shell, scheduled tasks, runs under the exact same OS user account context as the process that launched the application. There is no internal permission boundary between features.

File reads and writes, MCP server connections, web fetches, and every connected folder operation happen as you, with everything your account can reach.

A compromised plugin, a poisoned MCP connector, or an injected prompt that triggers a shell command all operate with the same access: Your file system, your environment variables, your credentials on disk, your internal network. This means the blast radius of any Cowork session is defined entirely by the privilege level of the account that launched it. If that account has access to finance folders, HR records, infrastructure credentials, or connected services, Cowork does too, from the moment it opens. This makes the account you launch it under the single most important security decision in your entire deployment.

The PromptArmor example that I shared with you earlier, where Cowork silently uploaded sensitive files to an attacker's account, it did that using the user's own API credentials and filesystem access. No privilege escalation required, because the agent loop already ran with everything it needed.

Until next time, this is Monica, signing off!

— Monica Verma

P.S. Please follow me/subscribe on Youtube, Linkedin, Spotify and Apple. It truly helps. Or book a 1-1 advisory call, if I can help you.

***