An automation team needs Prism Central API access to manage VMs only in the Finance project, without cluster-wide rights. How should you enforce least privilege?

In Prism Central, API requests are authorized through the same RBAC model as graphical users: an authenticated account receives role permissions, and project scope limits where those permissions apply. When automation must manage only VMs in Finance, the correct control is to assign a service account a role with the required VM permissions and bind that account to the Finance project. The API inherits that scope, so the account can operate within Finance but cannot perform cluster-wide administration. Granting Cluster Admin rights and relying on firewall filtering is wrong because a network boundary does not replace authorization. If the account can reach the API, the role still grants full cluster privileges, violating least privilege. Using built-in administrator credentials or a read-only admin key is wrong because administrative accounts are not project-scoped and cannot be safely reduced to a narrow automation role. Creating a separate Prism Element cluster for API automation is an infrastructure workaround, not a permission control; it adds complexity and does not define per-project API rights. Exam caveat: Do not treat API access as a separate privilege layer; API calls are governed by the authenticated account's RBAC role and scope. Operational check: Test the automation account by listing and creating a VM in Finance, then attempt a cluster configuration call or a VM operation in another project to confirm denial.