Every breach post-mortem you have read ends the same way: a credential was somewhere it should not have been, and it worked for the attacker exactly as well as it worked for you. Vaults moved the problem. They did not remove it.

What it changes for the business

A compromised application yields nothing. There is no key in it to take, so the incident is a service outage rather than a disclosure with a deadline.
Rotation stops being a fire drill. Nothing has to be redeployed when a credential changes, because nothing was holding one.
Third-party access stops being permanent. Access is granted for an action rather than issued to a system and forgotten about for two years.
You can let an agent act for a person without handing the agent that person's access, which is usually the blocker to letting it do anything useful.

How it works, briefly

The value stays with the person it belongs to, on their own device. When a call needs it, the request goes to them and the call completes with access the application never held. What comes back to you is the result, not the secret.

How this is handled elsewhere	How Squidder does it
Secret in an environment variable	Nothing to put in the environment
Vault the application reads at call time	The application never reads it
Gateway stores the key on your behalf	The gateway does not hold it either
Access issued once, valid until revoked	Access exists for the action, then it is gone
A leaked log is an incident	A leaked log contains no secret to leak

Where it fits, and where it does not

This is for calls made on a person's behalf. An overnight batch job has no person behind it, so it needs a service identity and ordinary brokered access instead. Both are supported; do not use the delegated path where there is nobody to delegate to.

Where to start

Take one integration where a third party holds a credential of yours and nobody is comfortable about it. Move that one. Then check your own logs and storage for the value: it is not there to find.