I have need for more advanced filtering (than simple host/path) before attaching credentials. One specific need is to ensure a git push is not to a protected branch. In order to do so, i will have to read the initial portion of a git pack body, then make an API request to the git repo to determine if protected, then allow credentials. This type of complex workflow/logic is not something that can easily be abstracted inside a service like yours, so i put together a PR that injects a very minimal seam to had a request off to another proxy to do more complicated processing (Implement filter proxy by lucastheisen · Pull Request #435 · Infisical/agent-vault · GitHub). This way, your application can stay smaller and focused, but you can still allow downstream consumers to do what they need. I would appreciate a review when y’all have a chance.
Hey Lucas! Thank you for your contribution!
I am passing this along to the Agent Vault team to review! We’re making a lot of updates to Agent Vault, so any insight into how you use it today is helpful!
This is my primary use case. A proxy between my agent and sensitive operations. I need a lot more control than just host/path. There is another PR that adds method to the builtin filter (feat(broker): restrict services to specific HTTP methods by cjohnhanson · Pull Request #324 · Infisical/agent-vault · GitHub). And i use that, plus my customization in this PR to provide this. In my environment, i run agent vault in a container next to a separate container where my agent lives. It is not run as a shared service, but if you merge in my PR, then it could be a shared service for the core agent vault, then each developer could simply define their own filter proxy and have the shared vault proxy the requests to the individual developers proxy.
Anyway, thats what i do.