Skip to main content

Policies

A policy is the rule Esper evaluates at runtime to decide what should happen to matching traffic.

A policy can bind together:

  • A traffic expression.
  • Required action IDs.
  • An optional entity definition.
  • One mitigation.
  • An optional monitoring window.
  • Deployment status.

What a policy contains​

Each policy definition includes:

  • policy_id: The unique identifier for the policy.
  • tenant_id: The tenant that owns the policy.
  • name: The label operators use to recognize the policy.
  • description: A short explanation of what the policy is meant to catch.
  • enabled: Whether the policy is active.
  • priority: The evaluation order when multiple policies could match.
  • expression: The traffic condition that starts the policy evaluation.
  • action_ids: The action definitions that must also match.
  • entity_definition_id: The optional entity definition used for grouping and state.
  • mitigation_id: The mitigation Esper applies when the policy matches.
  • window: The optional monitoring window for repeated behavior logic.

Windows​

Policies can include windowed evaluation such as:

  • Event count in the last N seconds.
  • Threshold comparison over entity or session activity.

This is where repeated behavior becomes part of mitigation rather than just one isolated event match.

API contract​

GET /tenants/{tenant_id}/policies
POST /tenants/{tenant_id}/policies
PATCH /tenants/{tenant_id}/policies/{policy_id}
DELETE /tenants/{tenant_id}/policies/{policy_id}