> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Product-level enforcement

> Understand how protected Lerian products enforce Access Manager decisions at the route level by calling Auth before business logic runs.

Product-level enforcement is the runtime integration inside each protected Lerian product. It is not a third Access Manager service. It is the route-level code that calls Auth on every incoming request and either lets the request continue or rejects it before the product handler runs.

Identity defines the access data. Auth decides whether a subject can perform an action on a resource. Product-level enforcement is where those decisions are actually applied to live traffic.

## What it does

***

On every protected request, the product:

* reads the bearer token from the `Authorization` header;
* builds a permission check with the `sub` (subject) from the token, the `resource` configured for the route, and the `action` configured for the route;
* sends that check to Auth;
* continues with the product handler when Auth returns an authorized decision;
* rejects the request with the appropriate HTTP or gRPC error when Auth denies it;
* uses trusted token claims such as `tenantId` when tenant-aware authorization is required.

For example, a Midaz route can protect `POST /transactions` with the resource `transactions` and action `post`. Auth decides whether the subject in the bearer token has that permission for the tenant carried in the same token.

<Warning>
  Product-level enforcement does not manage users, issue tokens, or store policy data. It calls Auth and acts on the response.
</Warning>

## Permission model

***

Access Manager evaluates authorization with three values:

| Value    | Meaning                                                                                                  |
| -------- | -------------------------------------------------------------------------------------------------------- |
| Subject  | The authenticated user or machine-to-machine application.                                                |
| Resource | The protected area of a product, such as `users`, `applications`, `accounts`, `reports`, or `templates`. |
| Action   | The operation being requested, such as `get`, `post`, `patch`, `delete`, `read`, or `write`.             |

Human users receive permissions through groups. Each group is tied to one or more product roles, and each role grants access to a defined set of resources and actions.

Machine-to-machine applications receive permissions through their application identity. Auth resolves the calling application and checks it against the permission set configured for that application.

### Resource and action names

Resource and action names are exact strings. They must match the values configured for the product route, and the route sends those configured values to Auth.

Most API products use HTTP-method-style actions:

| Example             | Meaning                                 |
| ------------------- | --------------------------------------- |
| `users:get`         | Read users.                             |
| `applications:post` | Create machine-to-machine applications. |
| `reports:patch`     | Update reports.                         |
| `templates:delete`  | Delete report templates.                |

Some products use semantic actions when the route is not best described by an HTTP method:

| Example              | Meaning                                  |
| -------------------- | ---------------------------------------- |
| `transfers:create`   | Create a Bank Transfer transfer.         |
| `transfers:process`  | Process a Bank Transfer transfer.        |
| `system_config:read` | Read Bank Transfer system configuration. |
| `workflows:activate` | Activate a Flowker workflow.             |

Use [Retrieve User Permissions](/en/reference/access-manager/retrieve-user-permissions) to inspect the effective resources and actions available to the authenticated user.

<Warning>
  Do not derive permission strings from endpoint paths by convention. Protected products enforce the resource and action values configured in Access Manager, not values inferred from the URL.
</Warning>

## Request flow

***

1. **Receive the request**
   * The product reads the bearer token from the `Authorization` header.
   * If the token is missing or malformed, the request is rejected before any permission check is attempted.
2. **Build the permission check**
   * The product uses the resource and action configured for the route.
   * In tenant-aware deployments, the product relies on the `tenantId` claim already present in the token rather than reading tenant identifiers from headers or payloads.
3. **Ask Auth**
   * The product calls Auth with the subject, resource, and action.
   * Auth evaluates the request against the configured Access Manager permissions and may serve the answer from cache.
4. **Apply the decision**
   * On authorized, the product continues to its handler.
   * On denied, the product returns the appropriate HTTP or gRPC error and does not invoke business logic.

<Note>
  Tenant scope is established by the token. In SaaS and multi-tenant BYOC deployments, the `tenantId` claim is resolved automatically by the platform on every API request, so you don't need to pass a tenant identifier in headers or request bodies. Learn more about [multi-tenancy](/en/multi-tenancy).
</Note>

## Where this fits

***

Product-level enforcement sits between the network and the product handler. It is the reason a valid bearer token is required on every protected route after Access Manager is enabled, and the reason an authorized subject still needs the right resource-action permission to reach a specific operation.

On the management side of this picture, see the [Identity service](/en/platform/access-manager/identity-plugin). The runtime decision side is handled by the [Auth service](/en/platform/access-manager/auth-plugin). For the day-to-day workflow against the APIs, see [Using Access Manager](/en/platform/access-manager/using-access-manager).