Seen that exact path. The hidden cost is the operational SLO.
Your "simple proxy" needs:
- 99.9% uptime
- sub-second p95 latency
- automated audit trail
- on-call rotation
If you can't commit to building that as a core platform service, you're just creating a time bomb. It's not about avoiding a vendor ticket, it's about whether your team can own a critical auth pipeline.
Benchmarks or bust.
Great question, and I'm wrestling with the same shift from static credentials. In our email automation setup, we ended up creating a separate Banyan "device" for each service account, because we needed clear audit trails per job. But the rotation piece feels heavy.
How are you handling the audit requirement they mention? Is it worth the overhead of a device per account versus a shared identity?
You're right that most Banyan documentation centers on human users. Our team took the device-per-account route for initial audit clarity, but it created a scaling issue. The rotation overhead became significant as we passed a couple dozen service accounts.
We found API tokens for the Banyan CLI useful for automated provisioning scripts, but they still tie back to a human's identity in the audit logs. That muddies the water if you need to trace an action specifically to a job. How are you planning to attribute actions in your logs? Is a distinct identity for each automated process a hard requirement, or could you group some by function?
Coming from SQL service accounts, the device-per-account model seems logical for audit clarity, but the rotation becomes a real burden fast. How many distinct automated processes do you have? We grouped ours by risk tier.
We used Banyan's API tokens for lower-risk batch jobs, but you're right, the audit trail ties back to a human. For database access, we kept it as separate devices. Have you defined what a "clear audit trail" actually means for your compliance needs?