What are the core concepts in Enforgate?

Gateway

The gateway is the service your agent talks to. It exposes two surfaces: a POST /v1/check endpoint that returns a verdict for a single call, and an MCP endpoint at /mcp that proxies your upstream tool servers. Both require a Bearer API key.

API keys

An API key authenticates an agent to the gateway and selects the policy its calls are evaluated against. Keys are stored as a sha256 hash plus a short display prefix — the secret itself is shown only once, at creation.

Policies

A policy is an ordered set of rules. Each rule matches a tool name (with * / ? globs) and optional argument conditions, and yields a decision. Policies have a priority and a default decision. See writing policies.

Verdicts

Evaluating a call produces a verdict — one of three decisions:

• allow — the call proceeds (and is forwarded to the upstream in proxy mode).
• deny — the call is refused.
• require_approval — the call is held until a human approves or it times out.

If no rule matches and no default decision is set, the engine denies — Enforgate fails closed.

Upstreams

An upstream is an MCP server you register for a key. The gateway connects to it (over stdio or streamable HTTP) and re-exposes its tools namespaced as <upstream>__<tool>. See connecting MCP servers.

Audit log

Every evaluated call is recorded: the server and tool, a hashof the arguments (never the raw values), the verdict, the matching rule, and the outcome. The dashboard's live feed and overview are views over this log.

Approvals & temporary allowlists

A require_approval verdict creates an approval — a held call with a single-use token. A human approves or denies it from a notification (or the in-app inbox). On approval they can grant a temporary allowlist entry so matching calls are auto-allowed for 1, 8, or 24 hours. See setting up approvals.