Skip to main content

Mitigation

Mitigation is the response Esper applies when a policy matches.

Current modes:

  • Monitor: Observe matching traffic without taking an active step.
  • Challenge: Ask the client to complete an additional verification step.
  • Block: Stop the matching request from continuing.

Monitoring is treated as passive mitigation, not as a separate first-class control-plane object.

Control-plane definition vs runtime decision​

Esper separates:

  • the mitigation definition you create in the control plane
  • the mitigation decision emitted after live policy evaluation

The mitigation definition is the reusable policy object. The mitigation decision is the runtime output for a specific analyzed request or tracked entity.

In brokered deployments, those runtime decisions are sent to the mitigation broker after engine evaluation.

That means mitigation is applied after analysis, not before it. A request can establish or update mitigation state for an actor, and later requests for that same actor can then receive the active mitigation response.

What a mitigation contains​

Each mitigation definition includes:

  • mitigation_id: The unique identifier for the mitigation definition.
  • tenant_id: The tenant that owns the mitigation.
  • name: The label operators see in the console.
  • description: A short explanation of when to use this mitigation.
  • enabled: Whether this mitigation is available for policy use.
  • mode: The response type Esper applies, such as monitor, challenge, or block.

API contract​

GET /tenants/{tenant_id}/mitigations
POST /tenants/{tenant_id}/mitigations
PATCH /tenants/{tenant_id}/mitigations/{mitigation_id}
DELETE /tenants/{tenant_id}/mitigations/{mitigation_id}