Record scope and field masking

Record access and field masking answer different questions. Record scope limits which rows a caller may receive. Field visibility limits which fields a permitted reader may receive. A visible employee record does not by itself authorize salary, bank details, or identity documents.

#Release availability

The individual record editor, department scope option, and additional employee detail access protections described here are prepared in the current source release. The matching ERP deployment and department scope migration remain required. They must not be treated as active merely because this documentation has been published.

#Supported record scope

The registered scope areas are employee profiles, tasks, expenses, and legacy attendance time off requests. The separate Time Off module and other product models are not automatically covered by this registry. Actions outside these areas use their own authorization rules.

For the updated member editor, see Users, roles, and permissions. Own record access follows the registered owner or assignee, not an arbitrary creator field. Department access uses the assigned department identifier inside the current workspace.

Record scope is not a replacement for permission to create, edit, approve, export, or delete. These operations must pass their own action checks. Administrative recovery access remains available to Super Admins and Access Rights administrators.

#Employee field visibility

Authorized Access Rights administrators configure employee field groups under Field visibility.

The employee field resolver builds an explicit selection of allowed fields. Withheld fields are omitted from supported responses, not replaced with a decorative mask while leaving their original values in the payload. An unclassified profile column is not automatically selected.

The employee list and detail action use these selections. Supported employee updates strip protected fields that the caller cannot change. Do not send placeholder values back to overwrite a field you cannot read.

#Defaults and exceptions

An unconfigured Viewer receives base employee fields only. Other roles retain the existing compatibility default when no field grants are configured, so administrators must configure restrictions deliberately.

When a person belongs to multiple groups, a field grant from any group permits that field group. Withholding it in one group does not cancel a grant from another. Review all memberships when removing access.

A person reading their own employee profile and an authorized administrator retain their applicable full field access. These field rules still do not grant a record or module that another authorization layer refuses.

#MCP identity and masking

An individual ERP MCP key acts as the user bound to that key. It does not act as whichever person happens to be typing into the external client. User headers cannot switch that identity.

MCP forwards supported requests through the ERP API. The ERP is responsible for record authorization and field selection. The bridge preserves omitted fields rather than retrieving a broader employee object to fill them back in. An administrator key can legitimately return more information than a restricted Manager key, so testing with an administrator alone cannot prove masking for ordinary users.

The dedicated operator OAuth connection represents its configured ERP actor. A shared OAuth access code is not an individual user login and must not be distributed across users who need different permissions. Use individually bound keys for those boundaries.

#Verify a restricted connection

Use an approved test workspace and synthetic employee data.

1. Configure the intended record scope and explicitly withhold the sensitive field groups from the test reader's permission groups.
2. Connect with that reader's own eligible MCP key and call erp_connection_context to confirm the actor and workspace.
3. Use discovery to locate the employee list and detail actions. Confirm permitted records remain visible and a record outside the scope is unavailable.
4. Inspect both the textual and structured tool result. Withheld salary, bank, and identity fields must be absent.
5. Test a refused action through both its named tool and the generic API tool. Discovery is not permission to bypass an execution refusal.
6. Revoke only the disposable test key and confirm the next request is refused. Do not revoke an operational key for a routine test.

A successful build or local test does not prove the configuration of a live customer workspace. Production verification requires valid credentials for the intended restricted actor and the deployed ERP release.