Writing Policies

Policies are the core governance rules in MITRITY. Every action an agent performs is evaluated against your policies before it executes. This guide covers policy structure, pattern matching, the priority system, and practical examples.

Policy Structure

Every policy has five components:

Field	Type	Description
name	string	A human-readable name for the policy (e.g., allow-crm-reads)
type	enum	The enforcement action: allow, deny, alert, or hold
action_pattern	string	A glob or regex pattern matching action types
priority	integer	Evaluation order — higher values are evaluated first
constraints	object	Optional conditions (time, rate, source agent, etc.)

Policy types

• Allow: The action is permitted. The gateway forwards the request and logs the event.
• Deny: The action is blocked. The gateway returns an error to the agent and logs the event. Notifications are sent if configured.
• Alert: The action is permitted, but an alert is generated. The event is flagged in the audit log and notifications are sent to configured channels (Slack, email, SIEM).
• Hold: The action is paused and queued for human approval. The gateway holds the request until an authorized user approves or denies it in the dashboard, or until the hold timeout expires.

Action Pattern Matching

Action patterns support both glob and regex syntax for matching action types.

Glob patterns

Glob patterns use * as a wildcard for simple matching:

Pattern	Matches	Does not match
read_*	read_crm_contact, read_database	write_crm_contact
*_export_*	bulk_export_contacts, data_export_csv	read_contacts
db.*	db.query, db.insert, db.delete	api.query

Regex patterns

For more complex matching, prefix the pattern with regex::

Pattern	Matches
regex:^(read|list)_crm_.*$	read_crm_contact, list_crm_deals
regex:^db\.(query|read)$	db.query, db.read
regex:^.*_(delete|drop|truncate)_.*$	Any destructive operation

Priority System

Policies are evaluated in descending priority order — the highest priority number is evaluated first. The first matching policy determines the outcome.

Priority 300: deny  bulk_export_*     (evaluated first)
Priority 200: alert write_*           (evaluated second)
Priority 100: allow read_crm_*        (evaluated third)
Priority  50: allow send_email        (evaluated fourth)
Priority   1: deny  *                 (catch-all, evaluated last)

Best practice: Use a catch-all deny policy with the lowest priority (priority: 1) as a safety net. Then add explicit allow and alert policies with higher priorities for actions you want to permit or monitor.

Constraints

Constraints add conditional logic to policies. A policy only matches if both the action pattern and all constraints are satisfied.

Time constraints

Restrict a policy to specific time windows:

{
  "name": "deny-after-hours",
  "type": "deny",
  "action_pattern": "write_*",
  "priority": 250,
  "constraints": {
    "time": {
      "after": "18:00",
      "before": "08:00",
      "timezone": "Europe/Stockholm"
    }
  }
}

Rate constraints

Limit the number of matching actions per time window:

{
  "name": "rate-limit-api-calls",
  "type": "deny",
  "action_pattern": "api.*",
  "priority": 200,
  "constraints": {
    "rate": {
      "max": 100,
      "window": "1m"
    }
  }
}

Agent constraints

Scope a policy to specific agents:

{
  "name": "allow-sales-bot-crm",
  "type": "allow",
  "action_pattern": "read_crm_*",
  "priority": 150,
  "constraints": {
    "agent_id": ["agent-sales-bot", "agent-support-bot"]
  }
}

Practical Examples

Example 1: Basic CRM governance

[
  {
    "name": "deny-bulk-export",
    "type": "deny",
    "action_pattern": "bulk_export_*",
    "priority": 300
  },
  {
    "name": "alert-write-operations",
    "type": "alert",
    "action_pattern": "write_crm_*",
    "priority": 200
  },
  {
    "name": "allow-crm-reads",
    "type": "allow",
    "action_pattern": "read_crm_*",
    "priority": 100
  },
  {
    "name": "deny-all-default",
    "type": "deny",
    "action_pattern": "*",
    "priority": 1
  }
]

Example 2: Hold for privilege escalation

{
  "name": "hold-iam-changes",
  "type": "hold",
  "action_pattern": "regex:^iam\\.(create_role|assign_role|escalate_permissions)$",
  "priority": 400,
  "constraints": {
    "hold_timeout": "15m"
  }
}

Example 3: Rate-limited database access

{
  "name": "rate-limit-db-queries",
  "type": "alert",
  "action_pattern": "db.query",
  "priority": 150,
  "constraints": {
    "rate": {
      "max": 50,
      "window": "1m"
    }
  }
}

Managing Policies

Policies can be created and managed through:

• Dashboard: Policies > Create Policy — visual editor with validation
• REST API: POST /api/v1/policies — programmatic management
• Policy-as-code: Define policies in JSON files and apply through CI/CD

For the full API reference, see the API overview.