Security Rule Templates for AI Agents

Part of Security rules.

Rule templates are curated sets of rules you can start from instead of a blank rule. Open Rule templates above the rule list (Owners, Admins, and Security Admins), choose Preview and use, read what the template creates and what it cannot do, adjust its few settings, and choose Create draft rules.

Applying a template creates ordinary draft rules in Monitor mode and nothing else. Nothing is active until you publish each rule. Templates never publish, enable, or send anything; you review, edit, test, and publish every rule yourself, exactly as for a rule you wrote. Applying the same template twice creates a second, separate set of drafts. Each draft records the template and version it came from, which you can see in the rule list and the editor, and is yours to change; the template never alters it afterwards.

Protect payment and credential data outbound creates six Monitor rules: payment card numbers (detector version 2) and credentials in outgoing content, in tool-call arguments, and, if you leave the option on, in what is sent to AI models. These are pattern detectors, not guarantees: they miss values written in unusual ways, kept in images or unsupported attachments, or split across fields, and they can flag values that are not real. The model-request rules share the platform's short screening time budget with your other active content rules. The template needs the detector library: it is hidden while your deployment administrator has not opened it.

PII leaving the organization creates up to four Monitor rules: Social Security, ITIN, UK National Insurance, Canadian SIN, Australian TFN, and IBAN numbers in outgoing content, in tool-call arguments, and, if you leave the option on, in what is sent to AI models; and a low-severity rule that reports when one outgoing action carries at least a chosen number (25 by default) of different email addresses or phone numbers. Canadian SIN and Australian TFN numbers without separators are found only next to a word such as SIN or TFN. These are pattern detectors, not guarantees. The template needs the detector library and is hidden while it is closed.

Marked material leaving the boundary creates up to four Monitor rules: the built-in CUI, classification, export-control, distribution-statement, and TLP markings in outgoing content, in tool-call arguments, and, if you leave the option on, in what is sent to AI models; and, only if you enter terms, a rule for your own terms in outgoing content. It recognizes marking text and does not determine what any content is. Its rules that use the built-in families cannot be published until your deployment's operator records the review described under marking detectors; the preview says so for each rule.

Injection attempts in inbound content creates two Monitor rules, one for incoming messages and one for returned tool results, using the prompt-injection signals above with severity and the number of required families as settings. It is a tripwire for review, not protection, and its copy says to pair it with outgoing-content rules, approved destinations and tool restrictions. It is hidden until your deployment administrator has opened both the detector library and prompt-injection detection.

Require approval for external HTTP writes creates one Block rule with the Require approval response for HTTP writes to hosts outside the list you enter, and a second for tools you name if you list any. Hosts are exact, without subdomains. See Require approval for what approvers can and cannot do.

Template updates. When a newer template version ships, rules made from the older version say "Template update available" and list what changed. Choose Review update to create a new set of drafts from the latest version beside your existing rules. There is no in-place merge: your existing drafts and published revisions are never changed, whatever you have edited in them. Compare the new rules, publish the ones you want, and disable the old ones. Once you hold a set of drafts from the latest version, the older rules stop asking for review and say a newer set exists. If a template is later retired, rules made from it keep working and stay editable; the list explains that the template is retired and, where there is one, points to its replacement. Retired templates cannot be applied again.

Templates are fixed data shipped with the platform. They run no code, fetch nothing, and update only when you upgrade the platform.

Back to Security rules.