Enforcement Modes

An enforcement mode controls how MITRITY responds when an agent's action matches a policy or triggers a behavioral anomaly. There are three modes: Monitor, Alert and Enforce. You set the mode 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. Every decision is logged, and you can see it in the audit log and the 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 suits a first deployment. It lets you:

• observe how your policies interact with real agent behavior;
• identify false positives;
• tune rules before you turn on active enforcement.

Alert

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

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

Alert mode is the bridge between monitoring and enforcement. Your team sees what would be blocked, and builds 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, and 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 until the timeout expires.
• Alert policies permit the action but generate notifications.
• Allow policies permit the action silently.

Enforce mode is the mode for production. Turn it on once you are confident that your policies correctly reflect your governance requirements.

Fail modes

Fail mode decides what the edge (the MITRITY runtime beside your agents) does when an action needs an answer from the MITRITY control plane and cannot get one. It is a setting on each policy: the fail_mode field, open or closed.

Fail mode covers two cases:

• a held action, when the edge cannot open its approval or follow the approval to a decision;
• a delegation hop, when the edge cannot check the delegation chain with the control plane.

Fail mode does not switch governance on or off during an outage:

• While the edge cannot reach the control plane, it keeps enforcing the last policy it loaded for each agent, with its last-known ML models, for as long as the outage lasts. Events from that time carry the metadata key profile_stale=true, and the edge's heartbeat reports AGENT_STATUS_DEGRADED until a refresh succeeds.
• The edge does not keep events to send later. An event batch it cannot deliver to the control plane is dropped.
• A gateway or sidecar that cannot load its agent's policy when it starts does not start.
• Execution surfaces, such as the admission API, do not use fail mode. They deny when no policy was ever loaded for the agent, or when the decision pipeline itself errors.

Fail-open

With fail_mode: open, the edge lets the action through in those two cases:

• the held action goes ahead without a human decision;
• the edge decides the delegation hop with its own check of that single hop, and marks the decision as a fallback.

This puts agent availability ahead of strict governance. Use fail-open when agent uptime is critical and temporary gaps in governance are acceptable. An agent with no policy attached runs fail-open.

Fail-closed

With fail_mode: closed, the edge refuses the action in those two cases: the held action is denied, and so is the delegation hop.

This puts strict governance ahead of agent availability. Use fail-closed when your security requirements demand continuous governance coverage, even at the cost of agent downtime.

To turn it on, set the policy's Fail Mode switch to Fail Closed in the dashboard, or set fail_mode through the API:

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 '{"fail_mode": "closed"}'

POST /api/v1/policies requires fail_mode when you create a policy. In the dashboard, the New Policy form starts at Fail Closed, and a policy you create from an agent's form starts at fail-open.

There is no environment variable for fail mode. MITRITY_HOOK_FAIL_MODE is a separate setting of the hook that governs built-in tools: it decides what the hook does when it cannot reach the edge. See the admission API.

Recommended progression

We recommend that you move through the enforcement modes on a defined timeline:

1. Monitor, for 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, for the next two weeks. Turn on alerting, and set up Slack and email notifications. Review every alert and tune your policies. Add allow policies for legitimate actions that are wrongly 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, then extend to production agents.

You can shorten or lengthen this progression to suit your environment. Some teams move to Enforce mode in days. Others run in Alert mode for months while they build comprehensive policies.

Configuring enforcement mode

You set enforcement 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 override_mode like this:

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