### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### The Feature

## Summary

LiteLLM already provides excellent support for MCP:

- ✅ OAuth2 Authentication - ✅ OAuth2 Token Exchange (OBO) - ✅ Per-server header forwarding

However, there is still a gap for enterprise deployments where upstream systems do not support OAuth2.

Instead of requiring every client application to implement its own credential management layer, LiteLLM could provide a generic Credential Provider abstraction.

---

## The problem

Many enterprise systems still authenticate using:

- Personal Access Tokens (PAT) - API Keys - Bearer Tokens - Custom authentication headers

Examples include:

- Jira Data Center - Confluence Data Center - Terraform Enterprise / self-hosted - GitLab Self-Managed - Jenkins - SonarQube - Artifactory - Internal enterprise APIs

Today the recommended approach is header forwarding.

For example:

``` x-mcp-jira-authorization: Bearer <PAT> ```

While this works, every client must still implement:

- secure credential storage - encryption - user-to-credential mapping - secret retrieval - header injection

This logic e…