Having this default means you don’t have anything to block certain hosts - for which we’ll add support on the proxied services soon.

Which is a toggle in the open source AV and I think would be

--unmatched-host block

in the cli?

But it would block all requests for which you don’t have a configured proxied service

So is your setup blacklist heavy or allowlist heavy?

Because the thought process that went into this was that if the agents don’t have creds for certain hosts the external service would anyway deny them

And if they don’t that means it’s a public endpoint

Some of the things we’ll add soon to proxied services: • Allow certain HTTP methods • Deny all (so you can use the

--unmatched-host allow

but still deny certain hosts instead of all hosts) • Ability to create proxied services without the limitation of adding any header/substitution (so you can use

--unmatched-host block

but still allow certain hosts that don’t require any credentials)

For your three requirements above, it is already possible today: 1. use

--unmatched-host block

2. create proxied services with headers/substitution 3. create proxied services with impossible substitutions

could I actually ask you two more questions? Would either of these two use cases fit into the mental model of how you think about agent proxy? 1. We have individual developers talking to coding agents that today share a single vault on the self-hosted agent vault. In reality, different developers have different access to tooling. Ideally, we could configure this so that most of the services are shared, but some services are tied to an individual's credentials. It feels related to importing folders in Infisical? 2. We have a service we use for agents to talk to a shared resource where they can spin up their own little resources. There is one credential that is injected for all agents, but agents are supposed to only talk to their workspace on the service. We could enforce this with header replacement in the agent proxy, but it would need to be configured separately for every single agent/sandbox, of which there could be many running at one time. I can't really map this kind of agent-instance-specific service to the data model, but just wanted to check if I'm thinking about it correctly!

Like configure the proxied service to inject a secret in the body, and make each agent have their own override for that secret?

Also, until the personal overrides are supported, there is a workaround, similar to how you do it in Agent Vault, which is by adding redundancy: You can folders per agent and create duplicate proxied services for each. Currently, imports and references are supported for secrets but not proxied services.