Fine-Grained Access Control and Field-Level Data Minimisation for Moveworks Data API

The Moveworks Data API currently allows API credentials to be scoped to specific data entities, but consumers retrieving an entity can receive all fields and records available within that entity. There is currently no native mechanism to restrict API consumers to an approved subset of fields or records.

For enterprise customers, particularly those using Data API data for analytics and reporting, this can result in sensitive or personally identifiable information being exposed to consumers even when it is not required for their use case.

We would like Moveworks to provide fine-grained access controls for Data API credentials, allowing administrators to control not only which entities an API credential can access, but also which fields and records can be returned.

Proposed capabilities

When creating or managing a Data API credential, administrators should be able to configure:

1. Entity-level access
   Continue supporting selection of permitted Data API entities.

2. Field/column-level access
   Define an allowlist of fields that the credential is permitted to retrieve.

3. Row-level filtering
   Optionally restrict records according to approved attributes, such as business domain, geography, department, or other supported dimensions.

4. Sensitive-field protection
   Allow selected fields to be excluded, masked, or pseudonymised before data is returned through the API.

5. Credential-specific access policies
   Different API credentials should be able to have different access profiles.

   For example:

   • Analytics credential: pseudonymised interaction data
   • Operational credential: detailed operational attributes
   • Privileged credential: full dataset for specifically authorised support/security purposes

6. Auditability
   Administrators should be able to review which API credentials have access to which entities and fields, and ideally audit changes to those permissions.

Example

Today an organisation may need interaction metrics for a Power BI dashboard but does not require employee identity or free-text conversation content.

Rather than:

Data API → full interaction dataset → downstream filtering → Power BI

the desired pattern would be:

Data API → policy enforced by Moveworks → approved fields/records only → Power BI

This ensures that sensitive information is never exposed to the API consumer in the first place.

Business value

This capability would:

• Support the principle of least privilege.
• Improve privacy by design and data minimisation.
• Reduce unnecessary exposure of PII and potentially sensitive conversational data.
• Reduce the need for customers to build middleware solely to filter or mask Data API output.
• Make the Data API more suitable for enterprise analytics and multi-consumer scenarios.
• Allow security/privacy controls to be applied consistently at the source rather than relying on every downstream consumer to implement them correctly.

Why this matters

This is more than a Power BI/reporting requirement. It becomes increasingly important as Data API information is consumed by analytics platforms, AI agents, automated processes, and multiple enterprise applications.