Skip to main content
Security policy conditions are the environmental attributes evaluated at request time. Every policy must have at least one condition. When a policy has multiple conditions, all must pass (AND logic) for the policy to apply.

​
Condition Types

Myrmex supports six condition types, each with specific operators and value formats:

​
Source IP (source_ip)

Evaluates the client’s IP address against CIDR ranges or specific addresses.
OperatorDescriptionExample Value
inIP must be within the specified range203.0.113.0/24
not_inIP must NOT be in the range198.51.100.0/24
equalsExact IP match203.0.113.42
Common Patterns:
Use CaseOperatorValue
Corporate VPN onlyin203.0.113.0/24
Block specific rangenot_in198.51.100.0/24
Allow single officein45.227.50.0/24
IPv4 addresses are supported with standard CIDR notation. The system extracts the client IP from the X-Forwarded-For header or direct connection. Ensure your reverse proxy is properly configured for accurate IP detection.

​
Combining Conditions

When a policy has multiple conditions, all conditions must pass for the policy to apply (AND logic).

​
Example: Strict Corporate Access

A policy with these three conditions:
#ConditionOperatorValue
1source_ipin203.0.113.0/24
2time_of_daybetween08:00–18:00
3mfa_statusequalstrue
Meaning: Access is only allowed when:
  • The request comes from the corporate VPN (203.0.113.0/24), AND
  • The time is between 08:00–18:00 UTC, AND
  • The user has completed MFA
If any of these conditions fail, the policy’s effect (deny/allow) is applied.

​
Condition Compatibility Matrix

Not all operators work with all condition types. Use this matrix as a quick reference:
Conditionequalsinnot_inbetweenmatchesnot_matches
source_ip✅✅✅---
time_of_day---✅--
day_of_week-✅✅---
mfa_status✅-----
device_type-✅✅---
user_agent----✅✅

​
Best Practices

Start with Deny Policies

Deny policies are safer and more predictable. They define requirements that must be met — if not, access is blocked. Use Allow policies only for special override scenarios.

Use Specific Targeting

Instead of applying policies to all permissions, target specific permissions or roles. This prevents unintended lockouts and makes policies easier to audit.

Test Before Deploying

Create policies targeting a single test user or role first. Verify the behavior, then expand the targeting to production roles.

Document Your Policies

Use the description field to clearly explain the business reason for each policy. Future administrators will thank you.

​
Next Steps

Managing Policies

Step-by-step guide to creating, editing, and organizing policies in the interface.

Security Policies Overview

Understand policy effects, targeting, and the evaluation flow.