Leverage the service account feature in Octopus Deploy. Service accounts can only log in via the API/CLI/OctopusClient.dll. They do not have passwords. Their only access is provided via an API key.
Create a unique service account for each build server, external tool, or custom script. Assign that service account to a specific team which has permissions to perform a specific action only. In the event a service account’s API key is compromised, you can immediately delete the key and/or disable the account without affecting other apps or people.
For example, a build server service account only has access to push packages to Octopus and create and deploy a release to Dev. It does not have permission to promote releases to Test, Staging or Production. It does not have permission to add/remove/modify projects.
As for the storage of the API keys, it depends on the tooling/application. Most build servers provide the ability to save secrets/sensitive variables. Use the built in tooling when possible. When that is not possible, look into storing those keys in a centralized secret store (Azure Key Vault for example).
Finally, create a process to rotate the API keys. For example, once a month, have a process create a new API key, update the appropriate app. A central location makes this much easier to manage as only one spot will need to be updated.
The final point I’ll make is using API keys is okay when building/working on a script or an app or trying out something with the CLI. But once the script/app/whatever moves beyond a POC the key should be swapped out for a service account.