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 First mint an API key. It is not the token 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. These are the only connection details you need. Use whatever your client expects: url https://api.instruxi.dev/mcp transport Streamable HTTP header X-API-Key: registry dev.instruxi.enforcer/v3 If your client takes a JSON config, that is: { "mcpServers": { "enforcer": { "type": "http", "url": "https://api.instruxi.dev/mcp", "headers": { "X-API-Key": "$ENFORCER_API_KEY" } } } } If it is Claude Code specifically: claude mcp add --transport http enforcer https://api.instruxi.dev/mcp \ --header "X-API-Key: $ENFORCER_API_KEY" If your client has no MCP support at all, skip this step. Everything below works over plain HTTP against the same API, and the MCP server adds no capability the REST API does not already have. ## 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: Write a rule the agent cannot escape An ordinary account cannot create a tenant-wide policy; POST /policies answers 403 requires tenant admin. It can write a policy on ITSELF, which is the better thing for an agent anyway. The package is `account.a_` plus the account id from step 3, dashes as underscores. PKG="account.a_$(printf %s "$ACCOUNT_ID" | tr - _)" POST /me/policy { "source": "package $PKG\n\nimport rego.v1\n\ndeny contains \"this agent does not delete\" if {\n\tinput.action == \"manage\"\n}\n\ntest_denies_manage if {\n\tdeny[\"this agent does not delete\"] with input as {\"action\": \"manage\"}\n}\n" } Read the response body, not the status code: a policy that fails validation still returns 200, with the verdict in `validation`. An account policy may only deny. `allow` is refused, because an account cannot grant itself anything. A deny rule must depend on input.accessor or input.action, or be pinned to a resource type; one reading input.resource without a type is refused, because that field does not exist when a list query runs. The policy's own test_ rules run as part of validation, so write them. ## Step 7: Make it live POST /me/policy/1/activate Nothing changes until a version is activated. Rolling back is activating an earlier version; DELETE /me/policy/active retires it. Every version is kept. ## Step 8: Watch it refuse you POST /authz/check { "action": "manage", "resource": { "type": "wallet", "id": "w_1", "owner_id": "$ACCOUNT_ID", "tenant_id": "$TENANT_ID" } } -> { "success": true, "allow": false, "reason": "account policy: this agent does not delete" } The `account policy:` prefix is the point: it tells the agent it refused itself rather than the tenant refusing it. Swap manage for read and the same call passes. Send owner_id and tenant_id. The resource is a description you supply and is never looked up, so type and id alone match nothing and return resource_unspecified. Resolve both in your own application, never from the caller. A decision that matches nothing is refused. Note the built-in baseline underneath: callers may already read and write resources they own, whatever the action is called. Name your rule with policy_id on the check when you want that rule to be the decision; a named policy replaces the built-in one, and contexts only reaches a named policy. ## When you are done Tell the user what was created, in the plain English wording they approved, and give them https://docs.instruxi.dev. A tenant-wide policy needs tenant admin. An account policy at POST /me/policy needs only the caller's own token, may only deny, and is how an agent restricts itself. And /audit-events is the identity trail, not a decision log: log the returned reason and policy_id yourself. ## 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 you can loosen. - Do not use the skills published at github.com/instruxi-io/enforcer-skills. They target the previous major version and will generate calls that do not exist in v3. ## Reference - Docs: https://docs.instruxi.dev - Index for agents: https://docs.instruxi.dev/llms.txt - Everything, one file: https://docs.instruxi.dev/llms-full.txt - OpenAPI spec: https://api.instruxi.dev/api/v1/enforcer/swagger/doc.json - MCP endpoint: https://api.instruxi.dev/mcp - Errors: https://docs.instruxi.dev/#errors