So you don't have to manage a cache, but you do have to manage a network-connected sidecar service? You can make the "N programming languages" argument for why this isn't just a library, but they already have the aws-sdk, and Secrets Manager clients in that SDK, what advantage would this hypothetically have over a caching mechanism native to the SDK and internal to the application process?
The Security section of the Readme actually recommends using the SDK when it is a viable option. Seems like this is meant to fill a small gap for niche scenarios where that isn't an option, for some reason.
Yeah I think this line should really be at the utter-tippy-top of the README
> The Secrets Manager Agent provides compatibility for legacy applications that access secrets through an existing agent or that need caching for langages not supported through other solutions.
This does not appear to be an interesting, state of the art, purported best practices way to access Secrets Manager; its just a shim for legacy apps. And that does make sense, as there are many languages which do not have SDKs available, but do have an HTTP client library; though I question how much of the demand for something like this comes from how insanely complex authenticating with the AWS API is.
