Policy by Topic. Governance Beyond Pattern Matching.
Enterprise AI governance requires more than entity detection. A prompt can contain no PII, no credentials, no structured sensitive data — and still violate acceptable use policy because of its topic. Investment advice from a non-finance user. Legal contract drafting from an engineering intern. Competitor pricing analysis from a customer-facing team. Content Categories add topic-level classification as a policy engine condition, enabling governance rules that fire on what the prompt is about — not just what structured data it contains.
Capabilities
8 Content Domains, 26 Sub-Categories
A hierarchical taxonomy covering legal, financial, security, medical, political, adult, competitive intelligence, and prompt safety. Each domain has 2–4 sub-categories for granular policy targeting. Dot-notation slugs — legal.contracts, financial.investment — let rules match at any level of the hierarchy.
First-Class Policy Engine Condition
content_category is a native condition type evaluated alongside user groups, entity types, and model providers. Write rules like "BLOCK if financial.investment AND user NOT in finance-team." Combining algorithms — permit-overrides, deny-overrides, first-applicable — apply the same way they do for any other condition.
Custom Categories, Org-Scoped
Governance administrators create custom categories with org-specific keyword lists. Custom categories operate in the same taxonomy framework as built-in domains — same dot-notation, same policy conditions, same audit trail. All classification activity is HMAC-chained in the tamper-proof audit log.
8 Content Domains
Each domain covers a governance topic with 2–4 sub-categories. Rules can target a specific sub-category or match at the domain level — a rule on legal fires for any legal.* sub-category.
legalcontracts, litigation, regulatory, ip
financialinvestment, trading, earnings, crypto
securityoffensive, defensive, social_eng
medicaldiagnosis, prescription, clinical, mental_health
politicalelections, policy, figures
adultexplicit, violence
competitivenames, pricing, strategy
safetyjailbreak, prompt_leak, off_topic
Prompt Safety Domain
The safety domain covers governance-critical prompt patterns that operate independently of topic or entity detection. These classifiers fire as policy conditions before the request reaches any model.
safety.jailbreakKeyword classification for common jailbreak patterns — instruction override attempts, DAN-style prompts, and "ignore previous instructions" variants.
safety.prompt_leakDetects system prompt extraction attempts — "what is your system prompt," "show your instructions," and similar exfiltration patterns.
safety.off_topicConfigurable per org. Administrators define what "on-topic" means for their AI deployment, enabling guardrail rules that keep usage within intended scope.
How It Works
Classification runs before policy evaluation
Before evaluate_policy_chain() is called, the content classifier evaluates prompt text against the category keyword registry. Matched category slugs populate PolicyContext.content_categories. Classification is keyword-based — sub-millisecond, no microservice round-trip.
Policy rules evaluate categories as conditions
A content_category condition checks whether any specified category slugs appear in the classification result. Hierarchical prefix matching means a rule conditioned on legal fires for any legal.* sub-category. Multi-category matching lets a single prompt trigger multiple category conditions simultaneously.
Results appear in audit and simulate
Matched categories appear in HMAC-chained governance events alongside DLP results. Use simulation mode to test content category rules against sample traffic before deploying to production — verify that your rules fire correctly without affecting live requests.
Admin and Customization
The built-in taxonomy covers the 8 domains enterprises govern most often. Every organization also has governance requirements specific to their industry, risk posture, and acceptable use policies.
Custom Categories (Org-Scoped)
Governance administrators create custom categories with org-specific keyword lists. Custom categories operate in the same taxonomy framework as built-in domains — same dot-notation slugs, same content_category policy conditions, same HMAC-chained audit trail. Custom categories are visible only to the organization that created them.
Portal Category Management
The admin portal provides a category management UI for viewing the full taxonomy tree, managing keyword lists per category, enabling or disabling categories, and testing classification against sample prompts. Category changes are audited and attributed to the admin who made them.
Non-Suppressible Built-In Categories
The 8 built-in domains and their 26 sub-categories cannot be deleted by org admins. The core taxonomy structure is platform-managed. Org admins can add custom categories and extend keyword lists, but the built-in detection surface is always active.