Custom Regex Rules
Standard Entity Rules cover the categories most regulations care about. Custom Regex Rules cover everything else: internal customer IDs, project codes, employee numbers, support ticket references, anything proprietary that you would rather not have an employee’s AI carry into a third-party system.
Each rule is a name, a regex pattern, an optional set of context keywords, and an action.
Writing a rule
Open Security → PII detection and click Add rule on the custom rules card.
The rules table shows each rule’s pattern, its keywords, its action, and whether it is on, plus whether it is an override rather than an organization-level rule.
Three worked examples
Internal customer ID
Your CRM customer IDs look like CUST-12345: uppercase prefix, dash, five digits. They show up in prompts and tool arguments, and you do not want them written into systems outside your organization.
The \b word boundaries stop the pattern matching inside longer strings. The pattern is specific enough that no keyword is needed to make it trustworthy; the keywords are there to bias it further.
Internal email domain
You want to know whenever an internal email address (anything @acme-internal.com) leaves in a tool call, which is how employee identities end up in customer-facing systems.
The call is stopped before it reaches the third party and the detection lands in Alerts. Internal addresses never get written outward.
Project code with disambiguation
Your project codes look like P-A1B2. The pattern alone is loose, anything matching P- and four alphanumerics, so it will fire on unrelated strings. Context keywords are what tighten it.
A bare P-A1B2 in the middle of unrelated text does not clear the bar; the P-A1B2 project is on track does. Keywords solve the false-positive problem without making the regex unreadable.
How context keywords work
When the regex matches, Workforce scans the surrounding text, roughly 50 characters either side, for any of the keywords. Each one found raises the match’s confidence, and the action fires once the confidence clears the detection threshold.
Use keywords whenever your pattern alone is too loose. They are often the difference between a rule that fires constantly on legitimate traffic and one that fires precisely when it should. Keep them specific: keywords as generic as “id” or “number” appear near everything and undo the disambiguation you wanted.
Testing before it goes live
Run the rule through the Guardrail tester before you enforce it. Paste a couple of realistic samples, one you expect the rule to catch and one you expect it to ignore, and confirm it does both. The mistakes the tester catches:
- The pattern matches more than you intended (a missing word boundary)
- The pattern matches less than you intended (case sensitivity, a missing alternative)
- The keywords are wrong, either too narrow to ever appear or too generic to mean anything
Then set the action to Log for the first week and read Violations and alerts before switching it to Redact or Block.
Per-Tool-Pack overrides
Like Standard Entity Rules, Custom Regex Rules can be overridden per Tool Pack, and a pack’s overrides are authoritative for that pack. An override can change the action, enforce a pattern on one pack that the organization does not enforce anywhere else, or switch the rule off for one pack while it keeps applying to the rest. Useful when most packs need the pattern enforced but one legitimately needs the data through.
Configure overrides on the Tool Pack’s Rules tab.
When regex is the wrong tool
If the thing you want caught has no reliable shape, a topic, a tone, an unannounced project, no regex will hold it. That is what AI Guardrails are for. Regex also matches shape without validating it: it will not run a Luhn check on a card number or a checksum on an ID, so pair a loose pattern with keywords rather than trusting the match alone.
Next
Catch what has no pattern at all with AI Guardrails.