Four Steps to Make Claude Code and Claude Cowork Agents Safe for Enterprise Deployment

With the release of Claude Code and Claude Cowork, Anthropic suddenly emerged as the platform of choice for a variety of business users. Developers love how Claude Code can plan, write, test, and commit code straight from the terminal. And business users continue to experiment with Claude Cowork’s ability to automate increasingly complex tasks.

Through every use case users gave to Claude agents, the trend was clear: the more access agents are given to third-party applications and data, the more useful they become. GitHub is how Claude Code can write and publish code. Google is where Claude Cowork sends emails and creates calendar events on your behalf. Our data shows the most popular apps Claude agents are given access to are also your most business-critical:

• Data Warehouses: Databricks, Snowflake, BigQuerey
• CRM & Sales Apps: HubSpot, Salesforce
• Productivity & Collaboration SaaS: Microsoft, Google, Slack, Notion
• Developer Infrastructure: GitLab, GitHub

Gaps in security architecture break your ability to govern Claude Code and Claude Cowork

When users grant Claude Code and Cowork agents access to third-party apps, the integrations normally happen via MCP servers or OAuth and API keys. Once connected, agents are granted permissions to read data, write code, execute workflows, and take action on the user’s behalf. 

These integrations are also where the existing security model breaks down. API and MCP traffic happens over the open internet, bypassing network controls. Identity providers are focused on human authentication, not what actions an AI agent takes. And manual reviews don't scale when hundreds of new agents can appear across the enterprise in just a few months and run day and night.

The good news is that a repeatable security playbook is emerging. Leading organizations are converging on four strategies to ensure they always have the visibility, governance, and runtime protection needed to secure Claude Code and Claude Cowork. The four steps below form the foundation of an enterprise AI agent security program.

1. Discover and inventory every agent, connection, and MCP server

You can't govern what you can't see. The first challenge security teams need to solve is maintaining a continuously updated answer to three questions: What agents exist? What are they connected to? What risks do they introduce?

For Claude Code and Cowork, that inventory has to include MCP servers. This is where most inventories fall apart. Developers routinely run local MCP servers or build custom ones that never appear in a procurement record, a vendor review, or an app catalog. If your inventory only covers sanctioned integrations, you're seeing a fraction of the real surface.

Ownership matters just as much as existence. A list of risky agents is a report. A list of risky agents with named owners is a remediation plan. Knowing who stood up each agent and why it is a business risk is what turns visibility into action.

How Obsidian helps: Obsidian continuously discovers Claude Code and Claude Cowork agents across your environment, including the connections and MCP servers behind them, then maps each agent to its owner, permissions, and access. When an agent's authorizations create exploitable risk, assigned risk factors prioritize the most critical issues, giving teams an action plan instead of a list of alerts.

With this visibility, security teams can:

• Identify the most active agents, top users, and highest-risk activity to focus remediation efforts.
• See which MCP servers, skills, and hooks each agent relies on, ensuring every connection is known and approved.
• Track every action agents execute to understand not just what they can do, but what they're actually doing.

2. Govern what sensitive data agents can access

Blocking agents from accessing data may seem like the safest option—but it's also the fastest way to undermine the workflows that make them valuable. When security becomes a roadblock, users inevitably find ways around it.

The better approach is to govern access based on data sensitivity. A Claude Cowork agent summarizing public documentation is very different from one querying customer PII, financial records, source code, or credentials. Those use cases shouldn't be governed by the same policy.

Mature security programs classify the data agents can access, define where that data is allowed to flow, and continuously verify that agents aren't interacting with information beyond their intended purpose. Organizations that have already invested in DSPM or data classification have a significant advantage—they can extend those existing labels and policies directly to AI agents instead of starting from scratch.

How Obsidian helps: Obsidian flags if Claude Code and Claude Cowork agents can reach sensitive data. And not just visibility, security teams can enforce policies by defining what data agents can read, use, and transfer and stopping the rest.

With Obsidian, security teams can:

• Track every agent interaction with your data with complete audit trails showing which agents accessed which files and datasets.
• Extend existing data governance to AI agents by applying runtime guardrails to enforce compliance policies.
• Reduce data leakage risk by preventing sensitive information from flowing to unauthorized destinations or applications.

3. Enforce least privilege for every agent

Once security teams have visibility, they almost always find the same thing: agents have far more access than they need. It rarely happens intentionally. 

An agent provisioned under a developer's identity can inherit that developer's existing permissions. An agent running on a service account is granted scopes that were defined long before AI entered the picture. As a result, an agent that only needs to read one schema may also be able to modify dozens more.

The emerging best practice is to enforce least privilege for every agent—granting only the minimum permissions required for the task at hand—and continuously monitor for permission drift. As agents take on new responsibilities, connect to more applications, and gain new capabilities, their privileges expand quietly over time. Without continuous oversight, least privilege becomes a one-time project instead of an ongoing security control.

How Obsidian helps: Obsidian spots when Claude Code and Cowork agents are able to execute destructive actions or hold excessive access to your files, helping security teams right-size permissions without disrupting legitimate workflows.

With Obsidian, security teams can:

• Reduce unnecessary access by identifying when broad folder access or unsanctioned connections are given to Claude agents.
• Enforce least privilege by identifying risky commands to rightsize Claude’s’ ability to execute certain actions.
• Detect permission drift with risk factors that continuously update when Claude Code or Cowork agents are given new access and permissions that are excessive or dangerous.

4. Put runtime controls on high-consequence actions

Least privilege narrows what an agent can do. It can't tell you whether what the agent is doing right now is safe.

That's why leading security teams are adding runtime controls: policies that block or require human approval for high-consequence actions, regardless of an agent's permissions. Whether it's deleting production data, transferring sensitive information, or making large-scale changes across SaaS applications, runtime guardrails provide protection when permissions alone aren't enough.

The best rollout strategy isn't to enforce every policy on day one. Start in observe mode. Measure how often agents trigger proposed policies before introducing enforcement. That data helps tune policies based on real behavior instead of assumptions, while building the evidence needed to justify when human approval or blocking is appropriate.

How Obsidian helps: Obsidian applies runtime guardrails to agent activity, blocking or routing high-risk actions for human approval in real time. Every decision is recorded with a complete audit trail showing what the agent attempted, what policy was triggered, and whether the action was allowed, blocked, or approved.

With runtime controls, security teams can:

• Block policy violations before they become incidents by preventing high-risk actions in real time.
• Detect abnormal agent behavior by baselining activity and identifying agents operating outside their normal patterns.
• Prevent unsafe tool use by blocking tool calls triggered by misinterpreted prompts, prompt injection, or malicious instructions.

Security is the key to accelerating AI adoption, not the reason it slows down

A pattern we're seeing across our customers is that the security teams following these four steps are also the ones moving fastest with AI agents. Good governance isn't about saying no to AI. It's about having the confidence to say yes safely. 

When you can discover every agent, enforce least privilege, apply runtime guardrails, and govern access to sensitive data, security becomes an enabler instead of a bottleneck because you have the visibility and controls to manage the risk.

The organizations that get this right won't just avoid the incident that makes the headlines. They'll be the ones that safely scale AI across the business while everyone else is still debating whether it's too risky.

Ready to secure your Claude Code and Claude Cowork agents? Watch a demo to see how Obsidian helps enterprises secure AI agents without slowing innovation.

‍