Esper overview

Esper helps you monitor and respond to automated traffic without asking you to build low-level request parsing yourself.

The simplest way to think about the product is:

• Esper handles request encoding automatically.
• Your team decides what the traffic means.

Instead of defining extraction pipelines, you define the parts of your policy workflow in language that matches your business:

• Actions: Tenant-defined behaviors such as login, view_article, or checkout_complete.
• Entities: Tenant-defined identity rules such as ip + user agent, session cookie, or header + payload traits.
• Mitigation: Reusable responses such as monitor, challenge, or block.
• Policies: The rules that connect traffic conditions, actions, entities, mitigation, and optional monitoring windows.

The simple mental model

If you are new to Esper, this is the shortest useful way to understand it:

1. A source sends Esper an event.
2. Esper automatically encodes the request into a stable field model.
3. Tenant-defined actions classify meaningful behaviors.
4. Tenant-defined entities decide how traffic should be grouped for state and analysis.
5. Policies evaluate expressions, action requirements, entity bindings, and windows.
6. Matching work is sent through the runtime broker path.
7. Mitigation determines whether matching traffic is monitored, challenged, or blocked.
8. Results show policy performance and operational outcomes afterward.

Who these docs are written for

These docs are written for:

• A founder or product lead defining the operator workflow.
• An operator managing policies and reviewing outcomes.
• An engineer or AI agent integrating the control plane or Esper CLI.

Continue to Quickstart for the fastest end-to-end path.