> ## Documentation Index > Fetch the complete documentation index at: https://docs.usenexio.com/llms.txt > Use this file to discover all available pages before exploring further. # Access plane > Understand how each person's access comes from your own systems, how Nexio applies your rules on every read and write, and how to see what a person will see. Who may see and do what in your organization is already decided in your own systems. The access plane reads those decisions and, under the `lit` [posture](/data-services/scope#posture), applies them to every Records read and write, so a person reaches through the API exactly what your rules allow. Under the `dark` and `shadow` postures it serves your organization's identity mapping and does not enforce the seat. It reads your sources when the person asks and keeps no copy of your staff list. ## Where each answer comes from | Question | Your source | | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Who is signing in | Your identity provider. Your application signs the person in and names them on each request (see [Acting-principal headers](/data-services/scope#acting-principal-headers)). | | Who the person is | Your HR directory: the employee record, its place in your organization and how far the person's totals reach, matched to their record in your system of record. | | What the person may do and see | The person's security groups in your system of record. | | Which records the person may open | Your system of record's business-unit access and record restrictions, applied inside every read. | For example, an agency that signs in with Microsoft Entra ID and keeps its book in AMS360 has its Entra sign-in, its AMS360 security groups and business units, and its HR directory read this way. ## How your rules are applied 1. Your identity provider signs the person in, and your server names them on the request. 2. Nexio finds the person in your HR directory and your system of record. When your records do not settle who the person is, the person's requests are refused until the match is confirmed. Your organization confirms it with its own live key or through its delegated access administrator, or Nexio does when you ask. Nexio does not guess. 3. Nexio applies the mapping from your security groups and business-unit access to the platform's roles, field classes and row scopes. The inputs are yours; Nexio holds the mapping. A group the mapping does not know grants nothing. 4. The result bounds every read and write. A field the person's role may not see is blanked, and a record outside their access does not exist for them. The details are on [Authority and scope](/data-services/scope). ## Changing access Change access where your rules live: add the person to a security group, change their business-unit access, or update their HR record. Nothing needs to change on the Nexio side, unless you create or rename a security group: Nexio adds the group, or its new name, to the mapping, and until then it grants nothing. Some access has no home in your systems: a time-boxed exception for one workflow action, an assignment to one piece of work, or an added grant. Your organization sets these with its own live API key, or a person your organization has delegated as an access administrator sets them; Nexio sets them only when you ask. Each one carries a reason and is written to the audit log. An exception never widens the records a person may open. ## Seeing what a person will see A preview of a person's access, or of a change before it is made, shows the access before and after and stores nothing. Your organization runs it with its own live key or through its delegated access administrator, and Nexio runs one when you ask. The management routes for the posture, added grants, exceptions, assignments, match confirmations, previews and the access audit are provided to each customer as part of their integration reference, not on a public page. From your application, read [`GET /api/v1/records/status`](/api-reference/data-services/get-status) as the person. It reports the scope they are served at and answers the identity refusals as data, so you can explain them before the first read (see [Preflight with the status read](/data-services/completeness#preflight-with-the-status-read)). ## Audit Every access change and every refused governed action is written to an append-only audit log. Your organization reads it with its own live key. See [Security and compliance](/platform/security-and-compliance). ## Next Name the person, sign the claim, and handle every refusal. Check a person's scope before the first read.