Writing a policy
A policy has conditions, grouped into three fields - Actor, Operation, and Resource - and a Response for what Oso does when it matches. Only Actor and Response are required; Operation and Resource conditions are optional and addable.Actor
Who’s involved:- Agent name - a specific agent, like Claude or Codex
- Agent review status - Unreviewed, Allowed, or Disallowed
Operation
What kind of call it is:- Type - the kind of operation: Read, Write, Destructive, or Unknown
- Tools - one or more specific tools, searchable, each tied to its integration (Gmail, GitHub, etc.); tools with no known integration show up as Unclassified
- Connectors - matches every call made through a specific CLI or MCP integration point (for example, Linear accessed through Claude.ai’s MCP connector)
Resource
What it touches:- Provider - the upstream system a tool belongs to (GitHub, Gmail, etc.), or all providers
- Content type - matches a content tag you’ve defined (for example, “PHI” for a healthcare company) - scans both the request and the response
Response
Choose Alert, Enforce, or both:- Alert - notify your team. Set a severity (Low, Medium, High, Critical) and a cadence (every time, or throttled to once every 5 minutes, 15 minutes, 30 minutes, 1 hour, or 24 hours). Alerts route to the Slack channel you’ve already connected under Connections.
-
Enforce - restrict the matching call. Choose one:
- None - monitor only
- Block - prevent the call from proceeding. For a policy that scans a tool’s response (a content-type condition), the call has already run by the time it’s scanned, so Block instead redacts the response.
- Require user approval - pause until the end user allows or denies it.
- Require security approval - block until your security team grants a one-time exception.
Content-type conditions support Alert as usual, but Enforce is limited to Block - content that’s already entered the model’s context can’t be held for user or security approval.
Policy preview
As you build a policy, the preview panel shows exactly how it’ll behave:- Runs on - which event types the policy is evaluated against, derived automatically from your conditions: a policy scoped to a specific tool (by Type, Tools, Connectors, or Provider) runs on the tool request; add a Content type condition to that same policy and it also runs on the tool response; a policy with no tool-scoping condition (matching only on Actor or Content type) runs on all three - user prompt, tool request, and tool response
- Matches - the specific tools and agents the policy currently matches
- Then - the resulting action
Supported integrations
This isn’t exhaustive - Oso supports more integrations than shown here, with new ones added regularly.

rm, chmod, mv, tar, and similar) as a built-in System integration, for CLI activity that isn’t tied to one of the integrations above.
More integrations are being added regularly, and we’re building the ability to automatically identify integrations Oso hasn’t cataloged yet - not just the ones listed here. If you need support for a specific one now, reach out.
Example policies
Require security approval for GitHub writes and deletions
1
Name your policy
2
Set conditions
3
Configure response
Require user approval before deleting a Linear issue
1
Name your policy
2
Set conditions
3
Configure response
Alert when Cursor makes any destructive call
1
Name your policy
2
Set conditions
3
Configure response
Alert when an unsanctioned agent is discovered
1
Name your policy
2
Set conditions
3
Configure response
Block and alert on a custom regex match
1
Name your policy
2
Set conditions
3
Configure response
Block API key leaks in any session
1
Name your policy
2
Set conditions
3
Configure response