Skip to main content
This guide walks you through managing security policies in the Myrmex platform. Policies are configured through Organization Settings → Security Policies.
To manage security policies, you need the core.asset_groups.read permission. By default, the Super Admin and Admin roles have this permission.

Creating a Policy

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

Basic Information

Configure the policy’s identity and behavior:
FieldDescriptionRequired
NameA descriptive name (e.g., “Business Hours Only”)Yes
DescriptionExplain the business reason for this policyNo
EffectDeny or Allow — see policy effectsYes
PriorityNumeric value (higher = evaluated first)Yes
ActiveToggle to enable/disable the policyYes
Naming Convention: Use descriptive names that indicate the restriction. Examples: “VPN-Only Firewall Access”, “MFA Required for Production”, “Weekday-Only Viewer Access”.
2

Scope & Targeting

Define which requests this policy applies to. Leaving a field empty means “all”:Permissions & Roles:
  • Target Permissions — Select specific permissions this policy affects (e.g., devices.read, integrations.execute). Leave empty to apply to all permissions.
  • Target Roles — Select which 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.
3

Conditions

Add one or more 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)
Every policy must have at least one condition. The form will not allow saving without a condition defined.

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

Toggle Active

Quickly enable or disable a policy without editing it. Useful for temporary overrides or maintenance windows.

Edit Policy

Open the policy wizard to modify any field. All three steps are immediately navigable when editing.

Delete Policy

Permanently remove a policy. This action cannot be undone.

Policy Organization Tips

Priority Strategy

Organize your policies using a consistent priority scheme:
Priority RangePurposeExample
90–100Critical security (MFA, IP restrictions)“MFA Required for All Admin Actions”
50–89Operational controls (business hours, VPN)“Business Hours Only for SOC”
10–49Compliance and auditing”Weekday-Only Viewer Access”
1–9Informational / soft restrictions”Warn on Mobile Access”
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.”

Combining Policies

Policies are independent — they don’t inherit from or conflict with each other. This means you can layer policies for different dimensions:
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:0018: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)
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.

Troubleshooting

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.
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
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
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.

Next Steps