Runtime policy for Claude Code and Cowork: decide what Claude agents do with the access they inherit

Claude Code and Cowork have become everyday tools, for code and for the rest of the work around it. Both act through the credentials of the person behind them, with every permission that account holds in apps like Salesforce, Snowflake, and GitHub. Employees connect them to company apps and MCP tools in minutes, usually without a security review.

Most of what a Claude agent does is exactly what the user asked for. The risk sits in a few moments: Claude Code reading SSH keys or cloud credentials into its context, Cowork posting the results of a Snowflake query to Slack, or an agent working through a user account that holds admin rights in production. Each of those actions is something the user’s account is allowed to take, so identity and app permissions let them through. Obsidian decides whether they should.

Obsidian for Claude agents: narrow the access, then decide the actions

Obsidian covers Claude Code and Cowork with three capabilities that work together:

• Discovery: inventories the models, skills, hooks, plugins, and MCP servers each Claude agent uses, including MCP servers a user has configured but not used yet. It flags local MCP servers, unsanctioned plugins and marketplaces, and folder grants far broader than the project needs.
• AI Access: reads your third-party apps’ audit logs to find where Claude is acting through a user’s account, and flags accounts that hold admin rights on a production tenant.
• Runtime policy: an Obsidian sidecar checks each tool call with the Obsidian Runtime Policy Decision Engine before it runs, and allows it, holds it for approval, or stops it.

Runtime policy: decide each Claude action before it runs

The sidecar is a command-line binary that runs only during Claude Code and Cowork sessions, beside Claude on the user’s machine. When Claude calls a tool, the sidecar pauses the call and sends the agent, the person behind it, the tool, and its arguments to the Policy Decision Engine. The engine checks your policies and returns a decision with a reason. In Claude Code, the user sees a message your security team wrote, so they know why an action stopped and who to ask.

A policy is a set of conditions and an outcome. To keep credentials out of Claude’s context, for example, a policy can match file-read tools whose arguments point at .ssh, .aws/credentials, or .env files, and block them with a message pointing to your approved secrets workflow.

Not every risky action should simply stop. In Claude Code, a policy that runs before an operation can require approval instead, holding the action until the user signs off. A production infrastructure change can wait for a deliberate yes rather than run on auto-approve, and the log records who approved it.

Cowork policies flag or block. Flag records matches on real traffic without stopping anything, so you can test a policy before it enforces. Once the sidecar is in place, Obsidian logs each tool call even before you write a policy, so a team that isn’t ready to block anything still has a record of what Claude did and who asked for it.

Runtime policy is one layer of protection, not the whole stack. It decides actions that pass through the sidecar, and it works best alongside the access you’ve already narrowed with discovery and AI Access.

Your own context, a governed MCP path, and one console

Three capabilities extend what those policies can do. First, your own context: security teams can supply context such as data classification labels, and the engine evaluates it alongside identity, HR, and application data, so a policy that blocks Highly Sensitive files for anyone outside the Executive team follows your company’s own definition of sensitive. Second, a governed path for MCP: when Claude reaches supported apps through MCP, the MCP Security Proxy identifies the user, keeps the app’s token out of Claude, and checks each tool call against the same policies. Third, one console: the same policies apply to Claude Code, Cowork, Codex, and Microsoft Copilot.

Context Claude doesn’t have

A Claude agent can hold valid credentials, use an approved tool, and take an action its account is allowed to take, and still put the business at risk. Claude can’t see that the person behind a Cowork session left the company this morning, or that a file carries your Highly Sensitive label. Obsidian can.

Obsidian’s foundation has always been third-party apps. Through connectors into more than 200 of them, it understands who can access what and what they can do with that access, and the Policy Decision Engine draws on that knowledge for every decision. If your HR system shows a user is no longer employed, a policy can block the next tool calls from a session still running on their credentials. If your policy holds email to outside domains for review, Claude Code can pause the send until the user approves it.

Rolls out without changing how people work

Employees keep using Claude as they do today. The sidecar deploys per user or per device, so you can start with a small group, such as IT and security, before it reaches everyone. For MCP, a common pattern is to block any MCP server that isn’t on your approved list and route the approved ones through the MCP Security Proxy. Teams that already run an API gateway or agent harness can request the same decisions through the Policy Decision API.