# Architecture

<figure><img src="/files/PwW4enByWte4AJEtvvx3" alt=""><figcaption></figcaption></figure>

This section gives a **high-level view** of how Keeper EPM is built and best practices for running it.

## Architecture

### Trust and Control

Keeper EPM is designed so that **you** stay in control:

* **Dashboard:** You define policies, approvers, collections, and deployment groups in the Keeper Admin Console. No need to log into each endpoint to change policy.
* **Agent:** A local service on each endpoint enforces your policies. It talks to the backend for registration and policy sync, and runs plugins for policy evaluation, logging, and user interaction.
* **Local-first enforcement:** Policy decisions are made on the endpoint using the latest policy data. So even if the network is briefly unavailable, the agent can still enforce what it last received.

### Visibility

* **Health and status:** The agent exposes health and status endpoints so you (or your monitoring tools) can verify it’s running and responding.
* **Audit and logs:** Actions, policy matches, approvals, and denials are audited and logged. You can send this data to the Keeper backend and to your own SIEM or audit tools.
* **Plugins:** Core capabilities (policy, API, logging, client) are split into plugins so that updates and troubleshooting can be focused.

### Security

* **No standing privilege for users:** By design, users don’t need to be local admins. Elevation is granted per request, under policy.
* **Controlled elevation:** When elevation is allowed, it can be time-limited and tied to MFA, justification, or approval.
* **Secure communication:** Agents communicate with the backend over secure channels; registration uses tokens you control.

You don’t need to know implementation details—just that the system is built for **control**, **visibility**, and **security** at scale.

## Suggested Practices

* **Start with Monitor.** Use Monitor or Monitor & Notify for new policies so you can see what would be blocked or allowed before you enforce.
* **Use collections.** Group users and machines in collections so one policy applies to many endpoints without maintaining long lists.
* **Use variables and wildcards.** Keep policies simple and cross-platform with variables like `{userprofile}` and patterns like `*.exe` where supported.
* **Pilot with deployment groups.** Roll out to a small deployment group first, validate behavior, then expand.
* **Tune logging.** Use a higher log level (e.g., Information or Debug) when troubleshooting; use Warning or Error in production to reduce noise and storage.
* **Secure registration tokens.** Treat registration tokens as secrets; store and transmit them securely.
* **Review approvals and denials.** Periodically review approval requests and denial events so you can adjust policies and catch misuse.
* **Align with compliance.** Use MFA, justification, and approval where your compliance framework requires evidence of control.
* **Keep agents updated.** Deploy agent updates through your normal patch process so you get fixes and new features.

***

*You’re in control. This guide is your single place for customer-facing documentation—no internal or developer links, just what you need to run Keeper EPM with confidence.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.keeper.io/keeperpam/endpoint-privilege-manager/reference/architecture.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.