The name suggests they are attached to users but this would be not ideal. Employees of the company may come and go but service tokens should not be affected. So, having them account wide would be much preferable.
For web integrations it is better to use access tokens generated by the admin user, as admin email must stay for the account to remain active.
Additionally if you see the implementation of Personal Access tokens by various companies like GitHub, Gitlab, Atlassian and many more they are all linked with the users.
Gitlab has concept of deployment tokens that are not-user specific. Google Cloud has notion of service accounts. Quay.io has idea of robot accounts. All this to separate user accounts from service accounts since they have different life cycles.
I think using account owner identity for this is the most sensible workaround. However, as a feature request, I would suggest to come up with some sort of deployment tokens that can be managed by any of the administrators or better yet create tokens for a role.
Cryptlex supports OpenId Connect (OAuth 2.0), though the API is not public yet. OAuth 2.0 provides for “Client Credentials” grant type which uses a concept of applications instead of users, which does solve the problem which you are facing.
https://oauth.net/2/grant-types/client-credentials/
We will make that API public soon.