/access-admin

Access admin

Manage generated-app access through approval-gated actions. Never edit access tables, role permissions, identity memberships, or GraphJin policy directly.

Resolve exact subjects and resources

1. Call mcp_neko_user_manager_list_users to resolve the exact app_user.id or stable sso_group.id. Names and emails are display data. If multiple matches remain, ask the administrator to choose.
2. Call mcp_neko_records_browse_catalog to resolve the exact app, object, and field API names. Its output reflects the acting administrator's data access; an administrator without app-data access may need the target API names supplied from the access-management surface.
3. Never guess an ID or substitute a mutable SSO group display name for its ID.

Preserve the hierarchy

Access is allow-only and closed by default:

1. App access is required before any object grant.
2. Object read is required for create, update, or delete.
3. Field read is required for field write.
4. Field write also requires object create or update and cannot override a schema read-only field.

An app grant alone makes no object data readable. When the request says only "give access," ask which objects, operations, and fields are intended. Do not silently grant every object or field. Effective access is the union of a user's direct grants and current SSO-group grants.

The synthetic solo operator already has full access when SSO/multi-user mode is not in use; do not create fake entitlement rows for it.

Submit governed actions

Use only these installed actions with scope: internal:

• app_access_grant

{ "app": "crm", "subject_type": "group", "subject_id": "<sso_group.id>" }

• app_access_revoke — removes the app grant and all child grants.

{ "app": "crm", "subject_type": "user", "subject_id": "usr_123" }

• app_object_permission_set

{
  "app": "crm",
  "object": "activity",
  "subject_type": "group",
  "subject_id": "<sso_group.id>",
  "read": true,
  "create": true,
  "update": true,
  "delete": false
}

• app_field_permission_set

{
  "app": "crm",
  "object": "opportunity",
  "field": "amount",
  "subject_type": "group",
  "subject_id": "<sso_group.id>",
  "read": true,
  "write": false
}

Summarize the exact subject, app, object/field, and before-to-after capability being proposed. Revocation is high-impact: state that child grants are removed. Approval is not execution; report only the action's actual terminal result.

Guardrails

• Require a live administrator actor; org-admin status does not itself grant app-data access in SSO/multi-user mode.
• Never alter IdP memberships to manufacture access. Group membership is synchronized from the provider or SCIM.
• Never widen permissions to work around an absent catalog result.
• Never expose a field through a layout, export, search, reference expansion, or agent answer when its read grant is absent.
• Resolve current users/groups again before each change so deactivation and membership removals take effect promptly.