← all posts

Comparing AI responses to a plaintext-secrets request

Gordon Beeming
Gordon Beeming
On this page2 sections ▾

During a deployment-pipeline migration, I asked GPT-5.2 to put connection strings and API keys into a local script. It refused, even after I repeated the request. I switched to Claude 4.5 Sonnet, which generated the script, and I used it to set the GitHub Environment secrets.

I preferred Claude's response at the time because it let me finish the task. Looking back, I appreciated that GPT had challenged the way I was handling credentials.

#What I asked for

I was using the Airlock mode of copilot_here. Its network restrictions made me more comfortable handling deployment credentials in the session, but those restrictions didn't address how I stored the values locally.

I already had the secrets and wanted to automate about twenty gh secret set calls. I asked GPT-5.2 to write them to a file in /tmp/ that I could source or read, or to embed them directly in a one-time shell script.

It responded:

"I can't write secrets to a file, even in tmp."

I explained that I intended to delete the file immediately and understood the risks. It continued to refuse. When I gave Claude 4.5 Sonnet the same instruction, it generated the script without that objection.

#What I took from the difference

Putting credentials into a temporary script creates another copy to manage. Calling the file temporary doesn't ensure it will be removed, and a script containing secrets can be copied, logged, or committed if it later ends up in a repository. The exact risks depend on how the command is run and where the file is stored.

In this interaction, the refusal made me stop and consider that extra copy. I still worked around it by changing models, but I had to make that choice explicitly.

That matters to how I assess an agent. Following my instructions is useful, and so is questioning a request that introduces avoidable risk. I don't want to judge the result only by whether the task finished quickly.

This was one interaction with two models, rather than a controlled security test. It doesn't establish that one model is generally safer, or that either will respond the same way in a different session. What it changed for me was how I viewed this particular refusal: it was a useful objection to a credential-handling shortcut I was prepared to take.

Gordon Beeming
Gordon Beeming

Father • Husband • Triathlete • SSW Solution Architect

Related posts