Cowork isn’t a coding agent. It’s a general-purpose desktop agent for knowledge work — research, analysis, operations, finance, legal — that moves across your local files, the apps you use, the browser, and your connected MCP tools to finish multi-step tasks. Its risk surface is different: less “tear down production,” more “read the wrong file, paste a customer’s card number into a prompt, or upload an export to the open web.”
This is the pack that draws that line for Cowork. It covers three layers — the data in your prompts, the files and shell actions on the machine, and the connectors Cowork can reach — using the exact values Unbound matches on.
Why Cowork needs a guardrail layer
Cowork is an autonomous agent, not a chatbot. It works across your local files, the browser, and connected MCP tools, and it acts under the user’s identity, on content it didn’t write. That is what makes it useful, and what makes it worth governing:
- It reads untrusted content and acts on it. An instruction hidden in a document, an email, or a web page can turn into a command the agent runs. Prompt injection is a known, unsolved class of attack, and a per-action approval prompt is a limited backstop once a user is clicking through a lot of them.
- Defense in depth. The controls that ship inside the tool are one layer. An independent layer at the endpoint — one that sees the actual tool calls and file reads — gives you a second.
- A record you control. For compliance and incident review, security teams want an independent, exportable trail of what the agent did, held outside the tool itself.
Unbound sits at that endpoint layer. Every Cowork session streams into your Logs and Analytics — an independent record you own — and the policies in this pack let you see and govern the specific actions that carry the most risk.
What you’re defending against
The pack below maps to the threat vectors that matter most for an autonomous desktop agent. Each row points to the policies that cover it.
Create these under Policies → Security Policies and Policies → Tool Policies. Each row below is a match to create — the action is yours to set based on the traffic you see. Leave User Groups empty to apply org-wide, or scope to a team.
Building for AI coding agents (Claude Code, Cursor, Codex, …) instead? See Recommended Starting Policies — the terminal-command pack for engineering work. Live in three steps
Create what fits
Add the rows that match how your teams use Cowork — the data in prompts, the files and shell on the machine, and the connectors it reaches.
Test each in seconds
Paste the Try it prompt into a Cowork session and watch the match land in Logs and Analytics, attributed to the user and session.
Tune from your traffic
After a few days of activity, tighten the rules that matter and relax anything noisy. Your controls end up shaped by how your team actually works, not generic defaults.
Protect the data in prompts
The fastest way sensitive data leaves your org through an AI agent isn’t a command — it’s a prompt. Cowork users paste configs, credentials, and customer details straight into the prompt for it to summarize, clean, or draft from. Two guardrails catch the highest-value data before it reaches the model.
Files and shell on the machine
Cowork’s headline skill is working directly on your machine — reading, organizing, rewriting, and deleting files, and (for roles that allow it) running shell commands. These rules cover the actions where that goes wrong: reading secrets, dumping the environment, overwriting or deleting at scale, uploading data off the box, and pulling in new software. The family and field values are exactly what Unbound matches on.
Connectors and the browser
Cowork reaches out through MCP connectors and a browser, and that’s where a task quietly becomes an exfiltration path — a query that dumps a table, a message that broadcasts customer data, an upload into a web form. MCP policies target a canonical group (a logical service, matched across whatever server name your users configured), then either specific tools or a tool action type (read / write / destructive).
One control covers every connector: the sanctioned-MCP allowlist. New MCP servers appear constantly and many are unverified. Set the allowlist so only approved servers are reachable and any unknown or unofficial one is caught — the single highest-leverage MCP control, and a clean complement to the per-tool rules above.
Go live
Create the rows that fit how your teams use Cowork and test each one in seconds with the prompt in the last column — every match lands in Logs and Analytics, attributed to the user and session. From there the action is yours: keep a rule on visibility, or turn it into an enforced boundary once you’ve seen the traffic. Your controls end up shaped by how your team actually works, not generic defaults. 
