# Policies

A **policy** is the binding that grants a subject permission to perform an action on a resource. Every resource-based access decision in Aritma resolves to one or more policies.

A policy has three components:

| Component | Description | Example |
|  --- | --- | --- |
| **Subject** | Who is being granted access | A user's `subjectId`, a client, or a group |
| **Action** | What they are allowed to do | `banking.manage`, `banking.ais.read` |
| **Scope** | Which resource the permission applies to | `/subscriptions/abc123/resource-groups/...` |


## Actions

Actions use dot-notation and form a hierarchy. Granting a parent action implicitly grants all child actions beneath it.

For example, granting `banking.manage` gives the subject access to everything under `banking.*`, including `banking.ais.read`, `banking.pis.write`, and so on.

This hierarchy lets you grant broad access with a single policy, or narrow it down to a specific operation.

## Scopes

A scope is a URI that identifies the resource a policy applies to. The same subject can have different permissions on different scopes.

For example, a user might have `banking.ais.read` on `/subscriptions/123/...` but no access to `/subscriptions/456/...`. Policies are always evaluated against both the action being requested and the scope of the resource being accessed.

## Policy inheritance through groups

When a policy is assigned to a group, all members of that group inherit it immediately. This means you can grant access to an entire team by assigning a single policy to the group, rather than managing individual policies per subject.

If a user belongs to multiple groups, they receive the union of all policies inherited from those groups plus any policies assigned to them directly.

## Policy evaluation

When a subject makes an API call, Aritma evaluates whether any of their policies — direct or inherited — grant an action that covers the requested operation on the targeted scope. If no policy matches, the request is denied.

There is no delay or caching: policies take effect the moment they are created, and access is revoked the moment a policy is deleted or a subject is removed from a group.

## Related

- [Policies guide](/apis/platform/iam/guides/policies) — create, list, and delete policies via the API
- [Subjects](/apis/platform/iam/concepts/subjects) — what can be used as the `subject` in a policy
- [Groups](/apis/platform/iam/guides/groups) — how group-level policies propagate to members