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

# Policy Conditions

> Reference for all available condition types in security policies: source IP, time, day, MFA, device type, and user agent.

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

Security policy [conditions](/pt/documentation/management/security-policies/overview) 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:

<Tabs>
  <Tab title="Source IP">
    ### Source IP (`source_ip`)

    Evaluates the client's IP address against CIDR ranges or specific addresses.

    | Operator | Description                           | Example Value     |
    | -------- | ------------------------------------- | ----------------- |
    | `in`     | IP must be within the specified range | `203.0.113.0/24`  |
    | `not_in` | IP must NOT be in the range           | `198.51.100.0/24` |
    | `equals` | Exact IP match                        | `203.0.113.42`    |

    **Common Patterns:**

    | Use Case             | Operator | Value             |
    | -------------------- | -------- | ----------------- |
    | Corporate VPN only   | `in`     | `203.0.113.0/24`  |
    | Block specific range | `not_in` | `198.51.100.0/24` |
    | Allow single office  | `in`     | `45.227.50.0/24`  |

    <Note>
      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.
    </Note>
  </Tab>

  <Tab title="Time of Day">
    ### Time of Day (`time_of_day`)

    Restricts access to specific time windows. Evaluated against the server's timezone (UTC).

    | Operator  | Description                   | Example Value   |
    | --------- | ----------------------------- | --------------- |
    | `between` | Time must be within the range | `08:00`–`18:00` |

    **Common Patterns:**

    | Use Case       | Start   | End     |
    | -------------- | ------- | ------- |
    | Business hours | `08:00` | `18:00` |
    | Night shift    | `22:00` | `06:00` |
    | Extended hours | `06:00` | `22:00` |

    <Warning>
      Times are evaluated in **UTC**. If your team operates in BRT (UTC-3), business hours of 08:00–18:00 local time should be configured as `11:00`–`21:00` in the policy.
    </Warning>
  </Tab>

  <Tab title="Day of Week">
    ### Day of Week (`day_of_week`)

    Restricts access to specific days. Accepts multiple day selections.

    | Operator | Description                         | Example Value                                  |
    | -------- | ----------------------------------- | ---------------------------------------------- |
    | `in`     | Day must be one of the selected     | `monday, tuesday, wednesday, thursday, friday` |
    | `not_in` | Day must NOT be one of the selected | `saturday, sunday`                             |

    **Available Values:** `monday`, `tuesday`, `wednesday`, `thursday`, `friday`, `saturday`, `sunday`

    **Common Patterns:**

    | Use Case           | Operator | Days     |
    | ------------------ | -------- | -------- |
    | Weekdays only      | `in`     | Mon–Fri  |
    | Block weekends     | `not_in` | Sat, Sun |
    | Maintenance window | `in`     | Sunday   |
  </Tab>

  <Tab title="MFA Status">
    ### MFA Status (`mfa_status`)

    Checks whether the user has completed multi-factor authentication in their current session.

    | Operator | Description                         | Example Value     |
    | -------- | ----------------------------------- | ----------------- |
    | `equals` | MFA must match the specified status | `true` or `false` |

    **Common Patterns:**

    | Use Case               | Value  |
    | ---------------------- | ------ |
    | Require MFA            | `true` |
    | Block non-MFA sessions | `true` |

    <Note>
      MFA status is determined by the user's current authentication session. If MFA is required by a Deny policy, users who haven't completed MFA will receive a 403 error with a message prompting them to enable MFA.
    </Note>
  </Tab>

  <Tab title="Device Type">
    ### Device Type (`device_type`)

    Evaluates the general category of the client device based on the User-Agent header.

    | Operator | Description                | Example Value     |
    | -------- | -------------------------- | ----------------- |
    | `in`     | Device type must match     | `desktop, laptop` |
    | `not_in` | Device type must NOT match | `mobile, tablet`  |

    **Available Values:** `desktop`, `laptop`, `mobile`, `tablet`, `server`, `unknown`

    **Common Patterns:**

    | Use Case     | Operator | Types             |
    | ------------ | -------- | ----------------- |
    | Desktop only | `in`     | `desktop, laptop` |
    | Block mobile | `not_in` | `mobile, tablet`  |
  </Tab>

  <Tab title="User Agent">
    ### User Agent (`user_agent`)

    Evaluates the raw User-Agent string with regex pattern matching.

    | Operator      | Description                     | Example Value |
    | ------------- | ------------------------------- | ------------- |
    | `matches`     | User-Agent must match the regex | `.*Chrome.*`  |
    | `not_matches` | User-Agent must NOT match       | `.*curl.*`    |

    **Common Patterns:**

    | Use Case               | Operator      | Pattern                         |
    | ---------------------- | ------------- | ------------------------------- |
    | Allow only Chrome      | `matches`     | `.*Chrome.*`                    |
    | Block CLI tools        | `not_matches` | `.*(curl\|wget\|python).*`      |
    | Require modern browser | `matches`     | `.*(Chrome\|Firefox\|Safari).*` |

    <Warning>
      User-Agent strings can be spoofed. Use this condition as an additional layer, not as a primary security control.
    </Warning>
  </Tab>
</Tabs>

***

## 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:

| # | Condition     | Operator  | Value            |
| - | ------------- | --------- | ---------------- |
| 1 | `source_ip`   | `in`      | `203.0.113.0/24` |
| 2 | `time_of_day` | `between` | `08:00`–`18:00`  |
| 3 | `mfa_status`  | `equals`  | `true`           |

**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:

| Condition     | `equals` | `in` | `not_in` | `between` | `matches` | `not_matches` |
| ------------- | :------: | :--: | :------: | :-------: | :-------: | :-----------: |
| `source_ip`   |     ✅    |   ✅  |     ✅    |     -     |     -     |       -       |
| `time_of_day` |     -    |   -  |     -    |     ✅     |     -     |       -       |
| `day_of_week` |     -    |   ✅  |     ✅    |     -     |     -     |       -       |
| `mfa_status`  |     ✅    |   -  |     -    |     -     |     -     |       -       |
| `device_type` |     -    |   ✅  |     ✅    |     -     |     -     |       -       |
| `user_agent`  |     -    |   -  |     -    |     -     |     ✅     |       ✅       |

***

## Best Practices

<CardGroup cols={1}>
  <Card title="Start with Deny Policies" icon="shield-halved">
    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.
  </Card>

  <Card title="Use Specific Targeting" icon="crosshairs">
    Instead of applying policies to all permissions, target specific [permissions](/pt/documentation/management/rbac/permissions-reference) or [roles](/pt/documentation/management/rbac/native-roles). This prevents unintended lockouts and makes policies easier to audit.
  </Card>

  <Card title="Test Before Deploying" icon="flask">
    Create policies targeting a single test user or role first. Verify the behavior, then expand the targeting to production roles.
  </Card>

  <Card title="Document Your Policies" icon="file-lines">
    Use the description field to clearly explain the business reason for each policy. Future administrators will thank you.
  </Card>
</CardGroup>

***

## Next Steps

<CardGroup cols={2}>
  <Card title="Managing Policies" icon="list-check" href="/pt/documentation/management/security-policies/managing-policies">
    Step-by-step guide to creating, editing, and organizing policies in the interface.
  </Card>

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