> ## Documentation Index
> Fetch the complete documentation index at: https://docs.promptguard.co/llms.txt
> Use this file to discover all available pages before exploring further.
# Custom Security Rules
> Create granular policy rules to enforce domain-specific security requirements
Custom security rules let you go beyond built-in detection. Define policies that match your exact business requirements - block specific topics, protect entity names, enforce natural-language constraints, and more.
## Policy Types
PromptGuard supports seven policy types. Each policy has a **type**, an **action** (`block`, `redact`, `flag`, `allow`), and either **rules** (condition-based) or a **system prompt** (LLM-judged).
| Type | How it works | When to use |
| ------------------ | -------------------------------------------------- | ------------------------------------------- |
| `input_filter` | Evaluates rules against incoming prompts | Block injection patterns, forbidden terms |
| `output_filter` | Evaluates rules against LLM responses | Redact PII in output, block toxic content |
| `topic_filter` | LLM judge evaluates a natural-language description | Keep conversations on-topic |
| `llm_guard` | LLM judge evaluates a natural-language description | Custom business logic too complex for regex |
| `entity_blocklist` | Pattern matching on both input and output | Block specific names, terms, or identifiers |
| `rate_limit` | Rate-based enforcement | Throttle requests per time window |
| `custom` | Flexible rule-based evaluation | Anything else |
## Creating Policies
Policies are created and edited in the dashboard. The public API exposes a read-only listing so you can verify which policies are active for your project.
### Create in the Dashboard
1. Navigate to [app.promptguard.co](https://app.promptguard.co) → your project → **Policies**
2. Click **"Create Policy"**
3. Select the policy type
4. Configure rules or system prompt description
5. Click **"Create Policy"**
For example, an `entity_blocklist` policy named "Block Competitor Mentions" with the rule:
```json theme={"system"}
{
"condition": "contains_text_any",
"value": "Acme Corp|Globex|Initech",
"action": "block"
}
```
### List via API
Verify your project's policies with the Developer API:
```bash theme={"system"}
curl https://api.promptguard.co/api/v1/policies \
-H "X-API-Key: $PROMPTGUARD_API_KEY"
```
Returns all policies attached to the project associated with your API key, including type, rules, and active status.
## Rule Conditions
Rule-based policies (`input_filter`, `output_filter`, `entity_blocklist`, `custom`) use condition/value/action triples:
| Condition | Description | Example Value |
| ------------------- | --------------------------------------- | ------------------------------ |
| `contains_pii` | Matches PII entities (email, SSN, etc.) | `true` |
| `prompt_injection` | Matches injection patterns | `true` |
| `contains_text` | Exact substring match | `confidential` |
| `contains_text_any` | Match any of pipe-separated terms | `password\|secret\|credential` |
| `natural_language` | LLM-judged condition | `Request asks about pricing` |
### Actions
Each rule specifies what happens when the condition matches:
| Action | Behavior |
| -------- | ---------------------------------------------- |
| `block` | Reject the request entirely (HTTP 400) |
| `redact` | Remove or mask the matched content |
| `flag` | Allow the request but log the violation |
| `allow` | Explicitly permit (useful for allowlist rules) |
## Topic Filter
Topic filters use natural language to define what a conversation should be about. An LLM judge evaluates each request against your description and blocks off-topic queries.
Create a `topic_filter` policy in the dashboard with a description like:
```json theme={"system"}
{
"name": "Support Bot Scope",
"policy_type": "topic_filter",
"is_active": true,
"system_prompt_details": "This bot handles Azure cloud infrastructure support only. Block questions about billing, HR, competitor products, or anything unrelated to Azure services, networking, and deployment."
}
```
**When to use topic\_filter vs. input\_filter:**
* Use `topic_filter` when the boundary is semantic ("stay on topic")
* Use `input_filter` with `contains_text` rules when the boundary is lexical ("block this exact word")
## LLM Guard
LLM Guard policies define custom business rules in natural language, evaluated by an LLM judge. Use these for constraints that are too nuanced for pattern matching.
Create an `llm_guard` policy in the dashboard with your business rule as the description:
```json theme={"system"}
{
"name": "No Financial Advice",
"policy_type": "llm_guard",
"is_active": true,
"system_prompt_details": "Block any response that provides specific financial advice, stock recommendations, or investment guidance. General financial education is acceptable."
}
```
**Self-hosting the judge?** `llm_guard` runs on a small open model — by default a
**non-thinking instruct** model, which is the right tool for a structured
flag/no-flag verdict. If you point `LLM_GUARD_MODEL` (or a local
`LLM_GUARD_BASE_URL` server) at a **reasoning / "thinking"** model, it emits a
long chain-of-thought before its answer and can run out of tokens *before* the
verdict — the guard then fails open (stops guarding) silently. If you must use
a reasoning model, raise `LLM_GUARD_MAX_TOKENS` well above its trace length;
otherwise stick with an instruct model. Watch the `llm_guard_truncated` log
marker to catch this, and use `python -m shared.security.evals.guard_model_bakeoff`
to compare candidate models on accuracy, latency, and truncation rate.
## Entity Blocklist
Entity blocklists protect specific names, terms, or identifiers from appearing in prompts or responses. They evaluate against both input and output.
Create an `entity_blocklist` policy in the dashboard with your protected terms:
```json theme={"system"}
{
"name": "Client Name Protection",
"policy_type": "entity_blocklist",
"is_active": true,
"rules": [
{
"condition": "contains_text_any",
"value": "Acuity Analytics|John Smith|Project Phoenix",
"action": "redact"
}
]
}
```
The `contains_text_any` condition accepts pipe-separated (`|`) terms and matches any of them. This is more efficient than creating multiple `contains_text` rules.
## Policy Presets
PromptGuard also provides six use-case-specific presets that combine multiple built-in detectors:
| Preset | Optimized For |
| -------------------- | -------------------------------------------- |
| **Default** | Balanced security for general AI apps |
| **Support Bot** | Strict PII and exfiltration protection |
| **Code Assistant** | Injection detection, API key/secret scanning |
| **RAG System** | Maximum security, enhanced leak prevention |
| **Data Analysis** | Strict PII, SSN/DOB detection |
| **Creative Writing** | Nuanced content filtering, higher thresholds |
See [Policy Presets](/security/policy-presets) for detailed configuration.
## Feature Comparison by Tier
| Feature | Free | Pro | Scale |
| ----------------------------- | ------------ | ----------- | ----------- |
| Policy Presets | Default only | All presets | All presets |
| Custom Policies (rules-based) | 5 policies | 25 policies | Unlimited |
| Topic Filter | -- | Yes | Yes |
| LLM Guard | -- | Yes | Yes |
| Entity Blocklist | Yes | Yes | Yes |
| Regex Detection | 70-80% | 70-80% | 70-80% |
| ML Detection | \~95% | \~95% | \~95% |
## Next Steps
Pre-configured security policies
Built-in detection capabilities
Trace policy decisions and debug
Full policy management API