?
This is definitely something we intend to address as part of our v5 roadmap; there just hasn't been a huge customer demand for automating BuildMaster using the sort of "temporary API access key" approach that has grown popular in the more consumer-facing things like Twitter, GitHub, etc.
We may add this if there' demand and similar adoption in other tools in the space, but in our experience, it's generally more complicated for administers to manage and set-up. So they just set up one "access key" and give it to everyone.
It's particular challenging for us to solve in the same manner because of the way BuildMaster scopes privileges (by application and environment), and because the Native API can work cross-application/environment.
So, if it's a requirement to give limited access to Developers, the current best approach is to wrap the native api with a permissions wrapper, and then check if that user is authorized based on the AD group they're in, etc., based on the action they want to perform.