# Enforcer

> Identity and authorization in one system, for applications and AI agents.
> Enforcer signs users in (email OTP, passkeys, wallet sign-in, enterprise SSO),
> holds who they are (tenants, roles, groups), and answers "can this actor do this
> action on this resource" with allow or deny, the reason, and a recorded decision.

Most authorization products are a decision layer only: you hand them a subject id
and they return true or false. Enforcer injects the resolved user or agent into
the policy, so a rule is written over a real accessor object with its roles,
tenant and group memberships already on it. Identity and authorization are one
system, which is why a group a person lands in by passing a check is the same
thing a rule reads.

Every page below is a section of the single-page field manual at
https://docs.instruxi.dev — anchors are stable. The whole thing as one markdown
file is at https://docs.instruxi.dev/llms-full.txt (17 KB, fits in context).

## Start here

- [What Enforcer is](https://docs.instruxi.dev/#what): what the product does and who it is for.
- [Core concepts](https://docs.instruxi.dev/#concepts): tenant, person vs user, groups, auth methods, modules.
- [See how it works](https://docs.instruxi.dev/#how): the walkthrough video and the front-desk analogy.

## Build

- [Quickstart](https://docs.instruxi.dev/#quickstart): sign in, get a token, create a group, flip a gate.
- [Recipes](https://docs.instruxi.dev/#recipes): common tasks as copy-paste calls.
- [Auth model](https://docs.instruxi.dev/#auth-model): which credential to use where, and what each one carries.

## Reference

- [API reference](https://docs.instruxi.dev/#api): every endpoint grouped by area.
- [Errors](https://docs.instruxi.dev/#errors): the error slugs the API returns and what to do about each.
- [Modules and pricing](https://docs.instruxi.dev/#modules): what is free and what is metered.
- [FAQ](https://docs.instruxi.dev/#faq)

## For AI agents

- [Authorization for AI agents](https://docs.instruxi.dev/#agents): giving an agent its own identity and gating what it may do.
- [MCP server authorization](https://docs.instruxi.dev/#mcp): checking every tool call against policy.

## API

Base URL for every path below:

    https://api.instruxi.dev/api/v1/enforcer

- OpenAPI spec (Swagger 2.0): https://api.instruxi.dev/api/v1/enforcer/swagger/doc.json
- Swagger UI: https://api.instruxi.dev/api/v1/enforcer/swagger/
- Health, no credential needed: GET /health

The decision call:

    POST /authz/check
    { "action": "issue",
      "resource": { "type": "payment", "id": "...", "owner_id": "...", "tenant_id": "..." },
      "contexts": { "amount": 820 } }

    -> { "allow": false, "policy_id": "...", "reason": "..." }

The caller's identity comes from the bearer token, so do not send it. Deny is the
default: a missing rule fails closed.

Rules:

    GET  /policies              list (each has `active`)
    POST /policies              create; leave `active: false` until watched
    PUT  /policies/{id}         switch `active` on or off
    GET  /audit-events          past decisions

## Tools for agents

- [MCP server](https://api.instruxi.dev/mcp): Streamable HTTP. Listed in the official MCP registry as `dev.instruxi.enforcer/v3`. Send an Enforcer API key as `X-API-Key`.

## Rules of thumb

- Never write permission logic into the application. The application asks; Enforcer decides.
- Prefer a group over a list of names in a rule. Groups survive people joining and leaving.
- Cross-tenant access is refused by the engine and is not a setting.
- Create every rule with `active: false`, watch it, then switch it on.