Point an AI coding agent at this page and it will set Enforcer up for you. The same instructions are available as markdown.

These are official instructions from Instruxi for setting up Enforcer, an identity

and authorization platform, in an AI development environment. Every command here

is verified against the live API.

Complete the steps yourself by running the commands directly. Do not ask the user

to run them. Stop and ask the user only where a step says to.

What Enforcer is, so you know when to use it

Enforcer answers "can this actor do this action on this resource" with allow or

deny, the reason, and a recorded decision. Unlike a plain policy engine it also

holds identity: tenants, roles and groups. A policy is handed the resolved caller,

so you write rules over a real user object rather than syncing a copy of your data

into a permissions store.

Use it to gate what an app or an AI agent may do: spending limits, approval before

a sensitive action, "only verified users can do X", per-tenant isolation, or an

audit trail of who was allowed to do what and why.

Step 1 — Read the documentation index


https://docs.instruxi.dev/llms.txt

It is a short index. The full documentation is one 29 KB markdown file at

https://docs.instruxi.dev/llms-full.txt which fits in a context window whole, so

fetch it once rather than crawling.

Step 2 — Get a token against the open sandbox

The sandbox tenant is open, no signup and no account needed. It sends a real

one-time code to the email address you use, so use the user's own address and ask

them to read you the code.


curl -X POST https://api.instruxi.dev/api/v1/enforcer/auth/otp/request \
  -H 'Content-Type: application/json' \
  -d '{"email":"THEIR@EMAIL","tenant_code":"DLXZ-57TL-FS75"}'

# -> { "success": true, "message": "code sent" }

Ask the user for the code that just arrived, then:


curl -X POST https://api.instruxi.dev/api/v1/enforcer/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"provider":"email_otp","email":"THEIR@EMAIL","otp":"THE_CODE","tenant_code":"DLXZ-57TL-FS75"}'

# -> data.token is the bearer, data.account.id is who they are

The field is otp, not code. Keep data.token; every call below uses it.

Step 3 — Confirm who you are


curl https://api.instruxi.dev/api/v1/enforcer/auth/me \
  -H "Authorization: Bearer $TOKEN"

Returns the account, its tenant, role, groups and verification status. This is the

object a policy sees, so read it before writing any rule.

Step 4 — Connect the MCP server


claude mcp add --transport http enforcer https://api.instruxi.dev/mcp \
  --header "X-API-Key: $ENFORCER_API_KEY"

The API key is not the token from step 2. Mint one with the bearer from step 2:


curl -X POST https://api.instruxi.dev/api/v1/enforcer/api-keys \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' -d '{"name":"agent"}'

The plaintext key is in that response only and is never retrievable again, so

store it before moving on. Any client that speaks Streamable HTTP works with the

same URL; the server is also listed in the MCP registry as

dev.instruxi.enforcer/v3.

Step 5 — Protect something in the user's own codebase

You are already in their repository, so read their routes rather than asking them

to describe their API. Treat each route as an action on a resource type: a POST

that issues a refund is action issue on resource type payment.

Rank what you find by what it costs if it happens wrongly. Moving money and

changing credentials first, then deletion, then sharing data outside the tenant,

then ordinary writes, then reads.

Propose the three or four worth protecting. State each rule back in plain English

and get an explicit yes before creating anything. A person approves a sentence,

never Rego.

Step 6 — Create the rule, switched off


curl -X POST https://api.instruxi.dev/api/v1/enforcer/policies \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"name":"refund_limit","description":"Block refunds over 500 without approval","source":"REGO","active":false}'

Create every rule with active: false. A rule that starts blocking the moment it

exists is a rule nobody dares create. Switch it on later with

PUT /policies/{id} once they have watched it.

Step 7 — Add the check where the action happens


curl -X POST https://api.instruxi.dev/api/v1/enforcer/authz/check \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"action":"issue","resource":{"type":"payment","id":"pay_123"},"contexts":{"amount":820}}'

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

Their code acts on allow. Never send the caller identity; it comes from the

token, which is what stops a caller claiming to be someone else. Surface reason

so a refusal explains itself instead of being a bare failure.

Deny is the default. An action with no rule is refused, not allowed.

When you are done

Tell the user what was created, in the plain English wording they approved, and

give them https://docs.instruxi.dev to watch decisions arrive.

Rules of thumb

Enforcer decides.

and leaving.

loosen.

They target the previous major version and will generate calls that do not

exist in v3.

Reference