This is an interesting question with several facets that should be broken down.
The first question you asked is "How risky is this?" and the answer is "Very". Exposing those credentials on a 3rd-party service that you don't control and manage then you are increasing the risk. There are lots of ways your credentials could be exposed: service compromise, compromised service accounts, authorization failure in the service, network eavesdropping (if SSL/TLS isn't used to serve code), you granting access to the wrong person, etc.
Basically, consider those credentials exposed.
Sounds terrible, right? Maybe not... Now you have to ask the question "Am I comfortable with that risk?" If you have other mitigations in place then you might be okay with it. If you limit (perhaps with IP whitelisting) where those credentials can be used from then the credentials become less useful to steal. The service could also extremely low value and it doesn't make financial sense to add additional security. If the cost of recovering from a compromise is $10 and adding in extra security would cost $1,000,000 then you live with the risk. (That said, if you've made a commitment to your users about protecting them or their information, you have an ethical obligation to try to honor that commitment, regardless of the cost.)
Some additional thoughts:
"projects I am working on for my company" - You are doing this on behalf of the company you work for, they probably have policies or acceptable practices. If that's the case, those should take precedent over what you're comfortable with. The risk you're creating affects your company and it's reputation, the company gets to make the final call.
Lucas Kauffman suggests a good approach. I can't say if it will work for you but the takeaway is to find a mitigation that works for your deployment process and reduces risk to a comfortable level.