Mix of using API key or built-in username/password and integrated auth for nuget package pushes

Is it the case that having integrated authentication on will disable the ability to push nuget packages with an API key (either proget api key or username:password)? This seems to be the behavior I am observing.

It would be useful to be able to have a mix of authentication methods, i.e. proget could attempt to fail back to the provided api key if the windows authentication fails.

We want to be able to support a setup in our deployment tooling where teams can configure access to their feeds using a dedicated user. Integrated auth isn't a good fit here because the deployment agent runs under a windows account which would require access to every proget feed to be able to push to them. This opens a security hole. The alternative is setting up a dedicated agent for each team's feed(s) that runs under a windows account permissioned to those feeds.

It would be much nicer if we could configure the user in our metadata. Would there be any way of going about this?

Thanks

Product: ProGet
Version: 5.1.5

"Windows Authentication" is built in to Windows (web server), and is happens below the application layer (i.e. ProGet). It's by design (Microsoft), and the intention is to use domain/service accounts to control access.

I'm not sure I see the security hole to be honest, since pushing to a feed isn't that sensitive of an operation. Just don't let these users overwrite/delete packages.