Built-in tags
Oso ships with built-in tags for API keys and credentials, and flags sensitive data and documents moving through agent sessions. Built-in tags are managed by Oso and can’t be edited or deleted, but you can still reference them in a policy the same way you’d reference a custom tag.Custom tags
Create a custom tag to detect sensitive information specific to your application or organization - things Oso’s built-in tags don’t cover, like a social security number format, an internal project identifier, or another application-specific data pattern. A tag is one or more detectors. Each detector has:- A regex pattern matched against session content (for example,
\b\d{3}-\d{2}-\d{4}\bto match a social security number) - An optional description
- A Reduce false positives toggle. When on, an LLM reviews each match before it counts, at the cost of added latency since every match waits on the model.
Using tags in policies
Once a tag exists, you can add it as a condition when writing a policy: match on one or more content tags, then choose an action.Content-tag conditions currently support Block and Alert actions. Require human approval and Security escalation aren’t available for content-tag conditions yet.
1
Name your policy
2
Set conditions
3
Apply action
On self-hosted deployments, content-tag conditions currently support Alert only. Block enforcement for content tags isn’t available self-hosted yet.