OpenPages REST APIs v1/v2 should adhere to field level security to enable seamless integrations

Hi IBM Team,

Currently on the OpenPages REST APIS v1/v2, once when a user or integration between service to service gets access to CRUD operations on object types via role templates, clients via a service account have no restrictions on the apis they can use to say for example create/update records in OpenPages on any number of fields bypassing any View and also workflow setup.

For example, our grc framework requires an Incident record to be created minimum with 10 fields being required on the view using the create view route via UI but then after creation, these fields become uneditable throughout the workflow lifecycle. With the GRC APIs, I can bypass this restriction and create an Incident via API with just 1 field and therefore breaking my GRC framework. I can also then update any legacy incident records to update any uneditable fields which was set on the Task view assuming my framework states that Status = Closed is all fields are no longer editable.

Note setting fields on the object type Required checkbox cannot be applied because this will render the field to not be required based on conditions (ie. required only when status = Open).

I note also that we do have security rules but told as well that it has its limitation for performance and certain limitations as well which is not meant to be used extensively. https://www.ibm.com/docs/en/openpages/9.2.0?topic=security-rules

This limitation/gap can and will cause significant impact as the security between views/ui/apis are not aligned and therefore puts a hold on customers integration strategy as we cannot allow end users/external services to consume the out of the box apis (i.e. AI MCPs etc as there is no field level control).

My suggestion are to either:

A. have a new setting location where field level permissions can be configured properly which is applied globally (UI and APIs) and have customers migrate to this new settings and not have field level security just be on the view level.
B. Have a mechanism to replicate conditional permission setup on views to GRC APIs.
C. Have an independent security setup specifically for GRC APIs to at least give the ability to set field level restrictions on objects.