Authorization Model

Features and actions

A feature identifies the protected area, such as billing or projects.

An action identifies the operation inside that feature, such as read, write, or delete.

Together they form the unit of authorization.

Roles

Roles bundle feature-action pairs into reusable sets.

This keeps application code simple because the check endpoint does not need to know which role produced the permission. It only needs the requested pair.

Subjects

A subject is the principal being evaluated.

Most applications use a user identifier such as user_123, but a service account or machine identity works the same way.

Tenant scoping

Every decision can optionally include a tenant.

Use tenant scope when a subject may have different access across customer workspaces or organizations.

Resource scoping

Every decision can also include an optional resource.

Use resource scope when a feature/action is not specific enough on its own. For example, a secrets product can ask whether user_123 may reveal prod/api/STRIPE_SECRET_KEY, export dev/api/*, or access staging/payment-service/*.

Resources are path-style strings. Permission and override rules can use simple patterns:

• * applies to every resource
• dev/* applies under dev
• prod/api/* applies under prod/api
• prod/api/DATABASE_URL applies only to that exact resource

Permissions without a resource pattern are global for that feature/action.

Overrides

Overrides are the escape hatch.

Use them when one subject needs a targeted allow or deny without changing the shared role definition for everyone else.

Decision output

Every check returns:

• allowed: whether the request should be permitted
• reason: the evaluation result source, such as a role match or a default deny