The secret was correct. The first byte wasn't.

The secret was correct, but the encoding was not. The API token was retrieved from production without issue, and the tool reported success. However, when the token was used, it resulted in a failure due to a byte-order mark (BOM) that had been added to the token. The BOM caused the first character after "Bearer" to have a value greater than 255, resulting in the "Cannot convert argument to a ByteString" error.

The token itself was correct, but the issue lay in the way it was being processed. The original deploy script piped the secret directly to the platform CLI, which inadvertently added the BOM to the token. This issue could not be identified through a simple dashboard check, as the variable was marked sensitive and write-only, meaning it could not be viewed or read.

The root cause of the problem was a one-character encoding quirk caused by Windows PowerShell 5.1 automatically adding a UTF-8 preamble to the string being piped. Several attempts to fix the issue by altering the encoding settings within the script itself were unsuccessful, as the problem originated from the piping process itself.

The solution came when the team stopped using the piping method and instead wrote the secret value to a controlled file, redirecting it to the process's stdin. This approach bypassed the encoding issue and allowed the CLI to correctly process the token. The incident highlights the importance of understanding and properly handling encoding, especially when dealing with sensitive information, as a write-only secret cannot be audited through traditional means.

To prevent similar issues in the future, the team emphasized the need to verify the secret's integrity through actual use and response rather than relying solely on success messages from the tool.