There are some actions that can ignore the Action Lock state on the client. It depends on which site contains the source fixlet for the action.
By default any fixlets from the “BES Support” site (which includes the default “Reboot” tasks) can ignore the Action Lock state. This is needed as this site also contains the “Unlock Client” tasks.
You may also specify one Custom Site for which fixlets/tasks will ignore the action lock state. That is managed using the BESAdmin tool and the selected site will be called out in your masthead file.
If your action is based on a task from the BES Support site, or a designated Custom Site, that would explain why the action is running even with the client locked.
I haven’t had a problem with this yet but have only done a few in-place upgrades (1607 to 1709). I’d suggest that if you’re working through a PMR or building your own custom installers, you might try actually disabling and stopping the BESClient service after initiating the upgrade; and use the Windows Setup scripts “setupcomplete.cmd” and “setuperror.cmd” to enable and restart the BESClient when the upgrade succeeds or fails.