> ## Documentation Index > Fetch the complete documentation index at: https://docs.insight.nobly.dk/llms.txt > Use this file to discover all available pages before exploring further. # Security keyword rules > Restrict document operations when metadata matches a rule, and test how rules combine across groups and keyword types. ## Prerequisites Open **Admin settings → Keywords → Security keywords**. Reading rules requires both `keyword-configuration.view` and `iam.user-groups.view`; maintaining rules requires both corresponding `manage` permissions. The current security-keyword feature must be available in the environment. If the screen reports that it is disabled, do not assume rules entered here are active. Security keywords add record-level restrictions to document-type rights. They do not grant access to a document type that a user otherwise cannot access. ## Understand what a match means A rule is a conditional restriction, not an allowlist. When its condition does not match, that rule imposes no restriction. A rule matching Department = Finance does not, by itself, deny access to other departments. For an applicable keyword type, the allowed operations of all matching rules from the user's groups are combined. A second matching rule can therefore allow an operation restricted by the first. Restrictions from different keyword types are then combined: an operation must survive each applicable keyword type's restrictions. For example, a rule matching Classification = Confidential with only **View** selected restricts matching records to viewing at this layer. It does not remove the need for document-type view access, and it does not restrict records whose classification does not match. ## Create a rule 1. Choose **Add Rule** and select the user group and keyword type. 2. Choose a supported operator and values. Operators offered depend on the keyword's data type; ranges require appropriate numeric or date values. 3. Select specific document types, or deliberately choose **Apply to all document types**. 4. Select **Allowed Operations**, review **Enabled**, and save. The group and keyword type cannot be changed after creation. Create a replacement rule if those need to change. The editor also offers dynamic placeholders; use its supported placeholder picker rather than inventing placeholder names. A rule combines a group, keyword condition, document scope, and allowed operations. Complete all required selections before saving. ## Validate effective access Use representative accounts and documents in a test environment. Include a matching value, a nonmatching value, missing metadata, multiple values, and a person belonging to more than one relevant group. Check search visibility and direct document access, plus each operation the policy should restrict. Do not validate only with an unrestricted administrator. An additional group or matching rule can change the effective result. Check the feature's enabled state and document-type scope before concluding that a saved rule is enforced. ## Maintain and investigate Filter the rule list by group or keyword type. Use **Enable Selected** or **Disable Selected** for deliberate batch changes, then inspect the results and **Audit History**. The page also provides **Clear Cache** for rule-cache troubleshooting; verify the saved rule and the account's group membership first. Removing or disabling a restriction can broaden access. Re-run the representative access checks after changing a rule, including AI search when your environment uses it. AI indexing must preserve the security metadata needed for filtering; see [AI search index administration](/ai-search/index-administration). ## Where to read next Preview and replace a stored alphanumeric keyword value across a selected document scope, then monitor the background job.