Comparing AI responses to a plaintext-secrets request
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.