> ## Documentation Index
> Fetch the complete documentation index at: https://docs.myrmex.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Managing Security Policies

> Step-by-step guide to creating, editing, activating, and organizing ABAC security policies in the Myrmex interface.

import {
  CardGroup,
  Card,
  Steps,
  Step,
  Note,
  Warning,
  Accordion,
  AccordionGroup,
  Tabs,
  Tab,
} from "@mintlify/components";

This guide walks you through managing security policies in the Myrmex platform. Policies are configured through **Organization Settings → Security Policies**.

<Note>
  To manage security policies, you need the `core.asset_groups.read` permission. By default, the [Super Admin](/es/documentation/management/rbac/native-roles) and [Admin](/es/documentation/management/rbac/native-roles) roles have this permission.
</Note>

***

## Creating a Policy

The policy creation form uses a three-step wizard to guide you through the configuration:

<Steps>
  <Step title="Basic Information">
    Configure the policy's identity and behavior:

    | Field           | Description                                                                                       | Required |
    | --------------- | ------------------------------------------------------------------------------------------------- | -------- |
    | **Name**        | A descriptive name (e.g., "Business Hours Only")                                                  | Yes      |
    | **Description** | Explain the business reason for this policy                                                       | No       |
    | **Effect**      | `Deny` or `Allow` — see [policy effects](/es/documentation/management/security-policies/overview) | Yes      |
    | **Priority**    | Numeric value (higher = evaluated first)                                                          | Yes      |
    | **Active**      | Toggle to enable/disable the policy                                                               | Yes      |

    <Note>
      **Naming Convention:** Use descriptive names that indicate the restriction. Examples: "VPN-Only Firewall Access", "MFA Required for Production", "Weekday-Only Viewer Access".
    </Note>
  </Step>

  <Step title="Scope & Targeting">
    Define which requests this policy applies to. **Leaving a field empty means "all":**

    **Permissions & Roles:**

    * **Target Permissions** — Select specific [permissions](/es/documentation/management/rbac/permissions-reference) this policy affects (e.g., `devices.read`, `integrations.execute`). Leave empty to apply to all permissions.
    * **Target Roles** — Select which [roles](/es/documentation/management/rbac/native-roles) are affected. Leave empty to apply to all roles.

    **Device Targeting** *(only visible when device permissions are selected):*

    * **Device Names (Regex)** — Regex patterns to match device names (e.g., `.*prod.*`).
    * **Device OS** — Select from available operating systems: Windows, Ubuntu, Darwin, Amazon Linux. You can also type custom OS values.

    **Integration Targeting** *(only visible when integration permissions are selected):*

    * **Integration Names (Regex)** — Regex patterns to match integration names.
    * **Integration Bases** — Select from a dropdown of all available integration types (e.g., Fortigate, AWS, Palo Alto). Integrations already registered in your environment appear first in the list.
  </Step>

  <Step title="Conditions">
    Add one or more [conditions](/es/documentation/management/security-policies/conditions) that define the environmental requirements:

    1. Click **"Add Condition"**
    2. Select the **Attribute** (source\_ip, time\_of\_day, etc.)
    3. Select the **Operator** (compatible operators appear based on attribute)
    4. Enter the **Value**
    5. Repeat to add more conditions (all conditions use AND logic)

    <Warning>
      Every policy must have at least one condition. The form will not allow saving without a condition defined.
    </Warning>
  </Step>
</Steps>

***

## Managing Existing Policies

### Policy List

The Security Policies tab shows all policies for your organization with key information at a glance:

* **Status indicator** — Active (green) or Inactive (gray)
* **Effect badge** — Deny (red) or Allow (green)
* **Priority number**
* **Description** — Business context for the policy

### Quick Actions

<CardGroup cols={3}>
  <Card title="Toggle Active" icon="toggle-on">
    Quickly enable or disable a policy without editing it. Useful for temporary overrides or maintenance windows.
  </Card>

  <Card title="Edit Policy" icon="pen-to-square">
    Open the policy wizard to modify any field. All three steps are immediately navigable when editing.
  </Card>

  <Card title="Delete Policy" icon="trash">
    Permanently remove a policy. This action cannot be undone.
  </Card>
</CardGroup>

***

## Policy Organization Tips

### Priority Strategy

Organize your policies using a consistent priority scheme:

| Priority Range | Purpose                                    | Example                              |
| -------------- | ------------------------------------------ | ------------------------------------ |
| **90–100**     | Critical security (MFA, IP restrictions)   | "MFA Required for All Admin Actions" |
| **50–89**      | Operational controls (business hours, VPN) | "Business Hours Only for SOC"        |
| **10–49**      | Compliance and auditing                    | "Weekday-Only Viewer Access"         |
| **1–9**        | Informational / soft restrictions          | "Warn on Mobile Access"              |

<Note>
  When two policies have the **same priority** and both match a request, **Deny policies take precedence** over Allow policies. This follows the security principle of "deny by default."
</Note>

### Combining Policies

Policies are independent — they don't inherit from or conflict with each other. This means you can layer policies for different dimensions:

<AccordionGroup>
  <Accordion title="Example: Layered Security for Production" icon="layer-group">
    **Policy 1: Corporate VPN Required** (Priority: 100)

    * Effect: Deny
    * Target: All permissions
    * Condition: `source_ip` in `203.0.113.0/24`

    **Policy 2: Business Hours for Analysts** (Priority: 50)

    * Effect: Deny
    * Target Roles: Analyst
    * Conditions: `time_of_day` between `08:00`–`18:00` AND `day_of_week` in Mon–Fri

    **Policy 3: MFA for Production Devices** (Priority: 90)

    * Effect: Deny
    * Target Device Names: `.*prod.*`
    * Condition: `mfa_status` equals `true`

    **Result:** To access a production device as an Analyst, a user must:

    1. Be on the corporate VPN (Policy 1)
    2. Access during business hours on weekdays (Policy 2)
    3. Have MFA active (Policy 3)
  </Accordion>

  <Accordion title="Example: Regional Access Separation" icon="globe">
    **Policy 1: LATAM Team — LATAM IPs Only** (Priority: 80)

    * Effect: Deny
    * Target Roles: LATAM Analyst (custom role)
    * Condition: `source_ip` in `177.0.0.0/8`

    **Policy 2: EMEA Team — EMEA IPs Only** (Priority: 80)

    * Effect: Deny
    * Target Roles: EMEA Analyst (custom role)
    * Condition: `source_ip` in `185.0.0.0/8`

    **Result:** Each regional team can only access the platform from their respective network ranges.
  </Accordion>
</AccordionGroup>

***

## Troubleshooting

<AccordionGroup>
  <Accordion title="Users are getting 403 errors unexpectedly" icon="triangle-exclamation">
    **Diagnosis steps:**

    1. Check if a security policy is blocking the user — review all active policies targeting their role
    2. Verify the user's IP, time, and MFA status match the policy conditions
    3. Temporarily disable the suspected policy to confirm it's the cause
    4. Check policy priority — a higher-priority Deny policy may be overriding an Allow policy

    **Quick fix:** Toggle the policy to Inactive while investigating.
  </Accordion>

  <Accordion title="Policy doesn't seem to apply" icon="circle-question">
    **Check these common issues:**

    1. **Is the policy Active?** — Inactive policies are never evaluated
    2. **Does the targeting match?** — Verify the policy targets the correct permissions, roles, or devices
    3. **Is the condition value correct?** — Verify time zone (UTC), IP format (CIDR), and day spellings
    4. **Cache delay** — Policy changes may take up to 15 seconds to propagate through the cache
  </Accordion>

  <Accordion title="I locked myself out" icon="lock">
    If a policy is blocking your own access:

    1. Access the platform from a network/time that satisfies the policy conditions
    2. If completely locked out, contact another Super Admin to disable the policy
    3. As a last resort, contact [Myrmex Support](mailto:suporte@ainext.com.br)

    <Warning>
      Always test policies with a non-admin user before applying to your own role. Never create a policy that targets Super Admin without having a backup access plan.
    </Warning>
  </Accordion>
</AccordionGroup>

***

## Next Steps

<CardGroup cols={2}>
  <Card title="Policy Conditions Reference" icon="sliders" href="/es/documentation/management/security-policies/conditions">
    Explore all six condition types with syntax, operators, and examples.
  </Card>

  <Card title="Security Policies Overview" icon="gears" href="/es/documentation/management/security-policies/overview">
    Understand policy effects, targeting, priority, and the evaluation flow.
  </Card>

  <Card title="Native Roles" icon="crown" href="/es/documentation/management/rbac/native-roles">
    Review the five built-in roles to understand targeting options.
  </Card>

  <Card title="Permissions Reference" icon="list-check" href="/es/documentation/management/rbac/permissions-reference">
    Full list of 81 permissions available for policy targeting.
  </Card>
</CardGroup>