> ## Documentation Index
> Fetch the complete documentation index at: https://www.osohq.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Content Tags

> Classify sensitive content in agent sessions, then reference it directly in policies.

A content tag is a classification you can reference when [writing a policy](/docs/oso-for-agents/policies). Once a policy references a tag, Oso runs that tag's detectors against prompts, completions, and tool calls to check for a match. Policies reference the tag, not the individual detectors, so you can tune what a tag matches without rewriting the policies that depend on it.

## 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}\b` to 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.

Give the tag a name (for example, "Customer SSNs"), then add one or more detectors. A tag with a single detector uses a simplified form; add a second detector to a tag and Oso reveals per-detector name fields so you can tell them apart.

## Using tags in policies

Once a tag exists, you can add it as a **Content type** condition when [writing a policy](/docs/oso-for-agents/policies): match on one or more content tags, then configure a response - Alert, Enforce, or both.

<Note>
  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.
</Note>

For example, to block any tool call whose content matches your "API keys" tag:

<Steps>
  <Step title="Name your policy">
    ```yaml theme={null}
    Name: Block API key leaks
    ```
  </Step>

  <Step title="Set conditions">
    ```yaml theme={null}
    Resource:
      Content type: API keys
    ```
  </Step>

  <Step title="Configure response">
    ```yaml theme={null}
    Enforce: Block
    ```
  </Step>
</Steps>

<Note>
  On self-hosted deployments, content-type conditions currently support **Alert** only. Block enforcement for content-type conditions isn't available self-hosted yet.
</Note>

## Managing tags

You can't delete a tag that's still referenced by a policy; remove it from those policies first.

## Where to find it

Content tags live under **Classify → Content tags** in the Oso dashboard.