Security Hardening for Claude Cowork: Sandboxing & Least Privilege

An agent that can read your documents, call your APIs, and take actions on your behalf is, by design, a powerful insider. That is the whole point — and the whole risk. The moment a Claude Cowork agent ingests untrusted content (a customer email, a web page, a shared document), an attacker has a channel to whisper instructions to it. Security for agentic systems is not an afterthought you bolt on at the end; it is a set of architectural choices you make up front. This post lays out the four pillars: sandboxing, least privilege, secrets handling, and prompt-injection defense.

Here is the threat model in one sentence. Prompt injection is an attack in which untrusted content fed to an AI agent contains hidden instructions that hijack the agent into taking unintended actions. Because a language model cannot perfectly separate "data to process" from "instructions to follow," any content the agent reads is a potential command channel. Every defense below exists to limit what happens when — not if — the model is fooled.

Pillar one: sandbox the blast radius

Assume the agent will, at some point, try to do something it shouldn't. Your job is to make that harmless. Run tool execution in a constrained environment: no ambient network access beyond the specific endpoints a task needs, a filesystem scoped to a working directory rather than the whole machine, and no path to escalate privileges. If an agent generates and runs code, that code should execute in an isolated sandbox, not on your production host.

The principle is containment. A sandbox doesn't prevent the model from being tricked; it ensures that when it is tricked, the damage is bounded to a space you control and can wipe. Treat every agent environment as disposable and untrusted, the way you'd treat a CI runner executing a stranger's pull request.

Pillar two: least privilege for every connector

Each MCP connector and skill you attach to a Cowork plugin is a capability you are handing the agent. The default should be the narrowest grant that still lets the task succeed. An agent that summarizes tickets needs read access to tickets — not write access, not admin, not the billing API. Scope credentials per connector, prefer read-only tokens wherever a workflow only reads, and never reuse one all-powerful key across every tool.

The flow below shows how a single tool call should be gated before it ever reaches a real system.

flowchart TD
  A["Agent requests tool call"] --> B{"Action within granted scope?"}
  B -->|No| C["Deny & log"]
  B -->|Yes| D{"Destructive or high-value?"}
  D -->|Yes| E["Require human approval"]
  D -->|No| F["Validate args against schema"]
  E --> F
  F --> G["Execute with scoped credential"]
  G --> H["Log action & result"]

Note the human-approval gate for destructive or high-value actions. Sending money, deleting records, or emailing customers should pause for a person, especially while a workflow is new. This is not a lack of trust in the model; it is the same change-control you'd put on any system that can act irreversibly. As confidence grows, you can widen the set of auto-approved actions deliberately rather than by default.

Pillar three: keep secrets out of the model's mouth

An API key or password that passes through the model's context can leak — into a transcript, into a tool argument, into a response the agent shows a user who shouldn't see it. The defense is to never put raw secrets in the prompt or context at all. The agent should reference a credential by name ("use the billing-api credential"); the actual secret lives in your execution layer and is injected when the tool runs, after the model has decided what to do but before the request leaves your infrastructure.

This separation also makes rotation and auditing sane. When a key changes you update one place, not a pile of prompts. When you review what the agent did, the transcript shows intentions and tool names, not live secrets you now have to scrub. Secrets belong to the runtime, never to the conversation.

Pillar four: defend against prompt injection

Because you cannot make a model immune to injection, you layer defenses that make a successful injection useless. First, untrusted content should be clearly demarcated when it reaches the model, so instructions buried inside a document are treated as data to analyze rather than commands to obey. Second — and more importantly — the least-privilege and approval gates above mean that even if the model is convinced to attempt something malicious, it lacks the permissions to carry it out. A hijacked agent with read-only access to one mailbox is an annoyance; the same hijack with write access to your payment API is a breach.

Add output checks for the highest-risk actions. Before the agent exfiltrates data or sends an external message, a validation step (rule-based or a separate model call) can flag content that smells like a leak — credentials, large data dumps, or instructions that don't match the task. Defense in depth means no single trick — fooling the model — is enough to cause real harm.

Make security observable

Hardening you can't see is hardening you can't trust. Log every tool call with its arguments, the credential used, and the outcome, and keep those logs where the agent cannot edit them. When something goes wrong you want a clear, tamper-evident record of what the agent attempted and what your gates allowed. Good logging turns a scary "the agent did something" incident into a five-minute forensic read.

Frequently asked questions

What is prompt injection in an agentic system?

Prompt injection is an attack where untrusted content the agent reads — an email, a web page, a document — contains hidden instructions that hijack the agent into actions you didn't intend. Since a model can't perfectly separate data from instructions, the defense is to limit what a tricked agent can actually do.

How do I apply least privilege to a Claude Cowork agent?

Grant each connector and skill the narrowest capability that lets the task succeed — read-only where possible, scoped per-tool credentials, and no shared all-powerful keys. Gate destructive or high-value actions behind human approval until you've earned confidence in the workflow.

Where should API keys and secrets live?

In your execution layer, never in the prompt or model context. The agent should reference a credential by name and have the real secret injected at tool-execution time, so secrets don't leak into transcripts or responses and rotation stays simple.

Can I fully prevent prompt injection?

No defense makes a model immune. The realistic goal is to make a successful injection harmless: sandbox execution, least-privilege permissions, human approval for risky actions, and output checks together ensure that fooling the model doesn't grant it the power to do real damage.

Hardened agents for voice and chat

These same guardrails — sandboxing, least privilege, runtime secrets, and injection defense — are exactly what a customer-facing voice agent needs. CallSphere builds multi-agent voice and chat assistants that answer every call and message, use tools safely mid-conversation, and book work 24/7. See it live at callsphere.ai.

---

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.