Ask any engineering organisation where its third-party credentials live and you will get an honest, uncomfortable answer. In environment variables. In a configuration file. In a secrets manager, which is better, and then read into an environment variable at startup, which is where it stays for the life of the process.
That last part is the bit that does not get said out loud. A credential in a secrets manager that is loaded into a running application is a credential in a running application. Anything that can read that process, dump its memory, print its configuration in an error, or ship its environment to a logging service has the key.
And the software holding it is usually the software you least want to change. The integration written years ago. The vendor tool. The forty services that each hold their own copy of the same key because that was the easiest thing at the time.
Move the value, not the code
The application does not actually need the credential. It needs the call to succeed.
So let it keep making the call exactly as it does now, with the same library and the same configuration shape, and supply the value somewhere else. The request leaves the application without the secret in it. The value is added on its way out, from somewhere the application cannot read, and the call succeeds.
Squidder is what holds the value and adds it on the way out.
Nothing in the application changed. It still writes the request it always wrote. What changed is that the sensitive part is no longer in it, no longer in its configuration, and no longer in whatever crash report it produces at four in the morning.
What that is worth
The blast radius shrinks. A compromised application used to mean a compromised credential and an emergency rotation across every service holding a copy. Now it means a compromised application.
Rotation stops being an event. Change the value in one place. Nothing redeploys, because nothing was holding it.
Your logs get less dangerous. The most common way a key leaks is not an attacker. It is a stack trace, a debug flag left on, or a well-meaning integration that ships environment variables to an observability vendor. A value that was never in the process cannot be in the log.
The unglamorous benefit is the one that tends to justify the work internally. Consolidating this always turns up two or three keys nobody could account for, still valid, still in something, still working. The service nobody will reopen ends up with the same credential handling as the one you shipped last week, and you finish the exercise knowing how many copies there were, which is a number nobody in the building currently has.
What this does not do
It does not make the call safe. Removing the credential from the application does not mean the application should be making every call it makes. That is a separate question about which destinations it may reach, and it deserves its own answer. Where the caller is an AI agent rather than a service you wrote, the question sharpens considerably: your agent should never hold a credential.
It is not a secrets manager. You still need somewhere authoritative for values and a process for changing them. This changes where a value is at the moment of use, which is the part a secrets manager does not solve.
Somebody still has to know the value once. It has to be provided the first time. What changes is that it is provided once, to one place, instead of distributed to every service that needs it and then forgotten about.
Where to start
Do not begin with the payment key. Begin with the most widely copied one: the credential you know exists in more places than it should, that somebody would have to grep for if you asked how many copies there are.
Take one service off it. Confirm the calls still work with the value gone from its configuration. Then count how many services are left, and you will have both a plan and a number for the security review.
The interesting part of that exercise is rarely the technical result. It is the count.