Hey, that thread's already got the core answer right: there's no setting to strip CAN_MANAGE from a dashboard creator, and you already found that out the hard way when the API downgrade to CAN_READ had no effect. That's expected, Databricks docs confirm creators always keep CAN_MANAGE on objects they create, and that's not something an ACL update can override. 

The thing worth separating out for your automated routine: don't waste cycles trying to touch the creator's own permission entry, that call will always be a no-op. What actually matters is who else is in the dashboard's ACL.

Sharing works by adding new principals to that list, so your enforcement job should be diffing the ACL against an allowlist (creator, admins, whatever groups you've decided are fine) and stripping anyone outside that list, rather than trying to change the creator's own entry.

GET /api/2.0/permissions/dashboards/{dashboard_id}
to pull the current ACL, then

PUT /api/2.0/permissions/dashboards/{dashboard_id} 
{
"access_control_list":
    [
      { "user_name": "creator@company.com", "permission_level": "CAN_MANAGE" },
      { "group_name": "admins", "permission_level": "CAN_MANAGE" }
    ]
}

to reset it back to just your allowed principals. PUT replaces the whole list, so anything the creator added gets dropped in one call. If you want to react faster than a polling job, check the `dashboards` service in your audit logs, worth confirming what action name actually fires on a permission change in your workspace before you build detection around it, since the documented action list for that service covers dashboard CRUD and publishing but doesn't call out a dedicated sharing/permission event name. A quick test share plus a look at `system.access.audit` right after will tell you exactly what to filter on.