# Access policies

Canonical page: https://docs.ovok.com/access-policies

An AccessPolicy limits what a project member can do. It is the authorization layer for signed-in users: settings decide whether a flow can run, while an AccessPolicy decides which resources and operations a member can access.

Ovok uses AccessPolicies in two ways:

- **FHIR and project access:** policy rows grant interactions such as reading, searching, creating, updating, or deleting resources. Policies can also scope access with criteria.
- **Signals routes:** Ovok checks a small set of custom AccessPolicy rows for alert, configuration, and threshold operations. These rows work alongside the member's Patient access.

Start with the page that matches your question:

| If you need to… | Read |
| --- | --- |
| Understand policy rows, membership assignment, and what happens when a member has no policy | [AccessPolicy model and membership](/access-policies/policy-model) |
| Configure the policies assigned to new patients and practitioners | [Default policies](/access-policies/defaults) |
| Grant access to Signals alerts, thresholds, and settings | [Signals route policies](/access-policies/signals) |

## The key safety rule [#the-key-safety-rule]

Do not assume that a missing policy means limited access. For ordinary project and FHIR access, a project membership without a policy is not restricted by one and can access the project broadly. Assign an intentional, least-privilege policy when you create or invite a member.

Signals routes have an additional check: non-admin callers need the named Signals capability as well as the corresponding Patient access. A broad FHIR policy by itself does not grant the custom Signals capabilities.

## Related setup [#related-setup]

- [Set up your project](/authentication/project-setup)
- [Invite a team member](/invitations/team-members)
- [DEFAULT_PRACTITIONER_ACCESS_POLICY](/settings-and-features/settings/default-practitioner-access-policy)
- [Signals](/signals)