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 Content type condition when writing a policy: match on one or more content tags, then configure a response - Alert, Enforce, or both.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.
1
Name your policy
2
Set conditions
3
Configure response
On self-hosted deployments, content-type conditions currently support Alert only. Block enforcement for content-type conditions isn’t available self-hosted yet.