> ## Documentation Index > Fetch the complete documentation index at: https://docs.contraforce.com/llms.txt > Use this file to discover all available pages before exploring further. # Workspace Policies > Govern what runs in each workspace with ordered allow and block rules for gamebook runs and agent investigations. Workspace Policies let you decide, per workspace, what is allowed to run before it runs. Build each policy as a plain sentence from your own actions, people, and devices, put the policies in the order you want them checked, and ContraForce enforces them on every gamebook action and agent investigation. **Who is this for?** Workspace Owners manage policies. Other roles can read the policy lists, and everyone benefits from the results: blocked actions are stopped before they run, and approval-gated actions wait for a decision. Policies live in **Workspace Manager**: open a workspace, then use the **Gamebooks** tab for run policies and the **Agents** tab for investigation policies. *** ## How policies are checked Every policy list works the same way: 1. Policies are checked **in order, top to bottom**. 2. The **first policy that fits** the action decides: allow it, block it, or send it for approval. 3. If **no policy fits, the action is allowed**. Policies are an exception mechanism; a workspace with none behaves exactly as before. The position number next to each policy is its place in that order. Use the arrows to move a policy up or down, and the toggle to turn one off without deleting it. Order is how you express exceptions. A narrow **Allow** placed above a broad **Block** means "block this category, except these cases". The builder warns you when a new policy sits below a catch-all that would decide every run before your policy gets a turn. *** ## Gamebook run policies Run policies govern gamebook actions: what may execute, against what, and whether an approver must sign off first. ### What a policy can do | Effect | Result | | ------------------------- | -------------------------------------------------------------- | | **Allow the action** | The action runs. Useful as an exception above a broader block. | | **Block the action** | The action does not run. | | **Ask an approver first** | The action pauses until an approver decides. | ### Who it applies to A run policy can apply to anyone, only to people in the workspace, only to Security Delivery Agents, or only to service providers managing the workspace. This lets you, for example, require approval for agent-initiated response actions while leaving your analysts unrestricted. ### Conditions Conditions decide when a policy fits an action. Pick them from your own data rather than typing identifiers: * **The action**: one or more of the workspace's actions (isolate endpoint, reset user password, and so on). * **The action's target**: specific people or devices the action would act on. * **The incident involves**: specific people or devices anywhere in the incident, protecting your VIPs and critical servers no matter which action is attempted. * **The incident title**: contains, is exactly, starts with, or is any of the values you list. * **The incident severity** and **the incident source**. Everything inside one condition group must be true together. Add an "or" group to give the policy a second, independent way to apply. ### Creating a run policy In **Workspace Manager**, open the workspace and select the **Gamebooks** tab. The **Run policies** card lists the workspace's policies in evaluation order. Click **Add policy**, then choose **Blank policy**. The builder opens as a drawer. Name the policy, choose what it does and who it applies to, then add conditions. The live preview reads the policy back as one sentence, exactly as the list will show it. New policies start at the bottom of the list. Move them up with the arrows if they need to win over broader rules below. ### Switching to an allow-list posture By default, anything no policy covers is allowed. To flip that, use **Add policy → Block anything not allowed**. This adds a catch-all block at the bottom of the list, so only actions an **Allow** policy above it lets through will keep running. Delete it at any time to return to allowing everything. ### Policies in the action menus Action menus show policy outcomes before anyone clicks: an action a policy would block is disabled with a tooltip naming the policy, and an action that needs sign-off carries an approval badge. Enforcement still happens at run time, so the menu is a preview, never the decision. *** ## Agent investigation policies Investigation policies govern whether an agent investigates an incident at all. They live on the **Agents** tab of workspace settings, and the same list appears on each agent's **Policies** tab, so an edit made on either surface is immediately true on the other. Investigation policies **allow or block**; there is no approval option. Conditions cover the incident (who it involves, its title, severity, and source) plus schedules, which are best created as [Agent Shifts](/guides/agent-center/agent-shifts). When a policy blocks an **automatic** investigation, the incident simply stays in your team's queue and the verdict is recorded in the workspace audit trail. When a policy blocks a **manually triggered** investigation, the person triggering it sees a message naming the policy. *** ## Managing the list * **Edit** reopens a policy in the builder. What a policy covers is fixed at creation; everything else can change. * **Turn off** a policy to take it out of evaluation without losing it. * **Delete** removes it permanently. Actions it covered follow the remaining policies, and if none fit, they are allowed. * **Reorder** with the arrows. The confirmation and numbering always reflect the list you are looking at. *** ## Roles and permissions | Role | Permissions | | -------------------------------------- | ------------------------------------------------------------- | | Workspace Owner | Create, edit, reorder, enable or disable, and delete policies | | Other workspace and organization roles | Read the policy lists; see policy outcomes in action menus | *** ## Frequently asked questions The action or investigation is allowed. Policies only change behavior where you write rules; an empty list changes nothing. No. Gamebook run policies and agent investigation policies are separate lists with separate ordering. They never affect each other's decisions. A catch-all policy earlier in the order decides every run before yours is reached, so your policy would never do anything unless you move it above that one. The warning names the policy and its position. Yes, deliberately. Overlap plus ordering is how exceptions work: the first fit wins, so put the narrow exception above the broad rule. The workspace audit trail records policy verdicts, including investigations that were blocked automatically. For gamebook runs that need approval, the run appears in the approval flow as usual. *** ## Related guides Schedule when agents investigate on their own with a weekly working-hours grid. Understand the guided response workflows that run policies govern. Set up and configure agents using the three-phase adoption model. Manage workspace settings, modules, and access. *** Questions about Workspace Policies? Contact us at [support@contraforce.com](mailto:support@contraforce.com).