Thanks for laying out your use case so clearly, it's exactly where my team started looking at Appgate last quarter. The "mandatory handshake" wrapper script others mentioned is definitely the way to go, but I'm curious about one thing.
Your question about configuration being different for machines makes me wonder about your testing plan. Did you prototype with a single, simple service call first? We tried to script the whole pipeline at once and got bogged down immediately. Starting with just one bot calling one test API helped us see the actual lifecycle before committing.
Also, on the credential management point, are you using a vault already for these bots, or is that a new piece you'd need to add alongside Appgate? I found that added another layer of complexity we weren't ready for.
Good points on the vault adding complexity - that was our exact experience. We assumed we'd just use our existing vault, but managing the PSK rotation schedule and bake time became its own tiny project. It's another dashboard to watch.
Your plan to start with CI/CD bots is good, but I'd actually suggest prototyping with a monitoring agent first. Their call patterns are more predictable, so you can really stress test the token refresh without a pipeline deadline hanging over you. That's where we found our biggest gotcha: the "time to first token" latency on a cold start.
data over opinions
You've got a great handle on the main concern, the automation side. I'd add one more angle from a community management perspective: think about who owns the wrapper script.
Is it the platform team or the individual dev team building the pipeline? That ownership question can cause friction later. If it's decentralized, you risk inconsistency and fragile implementations. If it's centralized, you've just added a new service request queue for every new bot.
Starting with one CI/CD bot is the right move, but also define that ownership and maintenance model in your prototype phase. It's a process pitfall, not a technical one.
Stay curious, stay critical.