Enforcement Modes

MITRITY supports three enforcement modes that control how the platform responds when an agent action matches a policy or triggers a behavioral anomaly. The mode is set on the policy, so it applies to every agent that runs that policy — see Configuring enforcement mode.

The three modes

Monitor

In Monitor mode, the gateway evaluates every action against your policies and ML models, but takes no enforcement action. All decisions are logged and visible in the audit log and dashboard.

• Actions are never blocked or delayed
• Events are logged with what the decision would have been (allow, deny, alert, hold)
• Drift scores are calculated and tracked
• No notifications are sent

Monitor mode is ideal for initial deployment. It lets you observe how your policies interact with real agent behavior, identify false positives, and tune rules before enabling active enforcement.

Alert

In Alert mode, the gateway permits all actions but generates alerts when a policy triggers a deny, alert, or hold decision. The action proceeds, but your team is notified.

• Actions are never blocked or delayed
• Alerts are sent to configured channels: Slack, email, SIEM, or webhook
• Events are logged with the actual decision and alert status
• Drift scores above your configured threshold trigger additional alerts

Alert mode is the bridge between monitoring and enforcement. It gives your team visibility into what would be blocked while building confidence in your policy configuration.

Enforce

In Enforce mode, the gateway actively enforces policy decisions. Denied actions are blocked. Held actions are queued for human approval. Alerts are sent.

• Deny policies block the action and return an error to the agent
• Hold policies pause the action until a human approves or denies it (or the timeout expires)
• Alert policies permit the action but generate notifications
• Allow policies permit the action silently

Enforce mode is the production operating mode. Enable it once you are confident that your policies correctly reflect your governance requirements.

Fail modes

When the gateway loses connectivity to the MITRITY control plane, it continues operating with its last-known policies and ML models. The fail mode setting determines what happens to new actions during this disconnected state:

Fail-open

Actions are allowed when the control plane is unreachable. This prioritizes agent availability over governance strictness. The gateway logs all actions during the disconnection and syncs them when connectivity is restored.

• Use when: Agent uptime is critical and temporary gaps in governance are acceptable
• Default setting

Fail-closed

Actions are blocked when the control plane is unreachable. This prioritizes governance strictness over agent availability. Agents will receive errors for all actions until the gateway reconnects.

• Use when: Security requirements demand continuous governance coverage, even at the cost of agent downtime
• Configure with FAIL_MODE=closed

Recommended progression

We recommend graduating through enforcement modes over a defined timeline:

1. Monitor (the first two weeks) — Deploy the gateway and observe baseline behavior. Review the audit log daily. Identify any unexpected policy matches or false positives.

2. Alert (the next two weeks) — Enable alerting. Configure Slack and email notifications. Review every alert and tune policies. Add allow policies for legitimate actions that are incorrectly flagged.

3. Enforce (from the fifth week on) — Switch to enforce mode once your alert volume is manageable and you are confident in your policy coverage. Start with non-critical agents first, then expand to production agents.

This progression can be compressed or extended depending on your environment. Some teams move to enforce mode in days; others run in alert mode for months while building comprehensive policies.

Configuring enforcement mode

Enforcement is set on the policy an agent runs, with the policy's override_mode. The Policies page shows each policy's mode.

# Run a policy in log-only mode while you tune it
curl -X PUT https://api.mitrity.com/api/v1/policies/{policy_id} \
  -H "Authorization: Bearer mk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"override_mode": "log_only"}'

Set override_mode back to active to enforce.

The three modes map onto it as follows: Monitor and Alert both run as log_only — every action is allowed and the audit record keeps the decision the policy would have made; whether the resulting alerts reach Slack, email or a webhook is set in Settings → Notifications. Enforce is active. The policy's detectors have modes of their own — for example injection_mode, dlp_mode, threat_intel_mode and drift_guard_mode each take enforce, log or off.