Decision: Proxy auth model (upstream key passthrough vs InferShield token) #63
Description
Decision Needed
We need to decide (and document) the intended authentication model for the InferShield Proxy. Today it appears clients must supply an upstream provider key (e.g., OpenAI key) even when the proxy is acting as an interceptor/passthrough.
Options
A) BYO Upstream Key (self-host friendly)
- Client supplies provider key (env var or header)
- Proxy forwards to provider after inspection/redaction
- Pros: simple, no key custody
- Cons: worse UX for managed/enterprise; harder to unify auth
B) InferShield Token Only (managed gateway mode)
- Client authenticates with InferShield API key / JWT only
- Proxy resolves upstream credentials server-side (stored tokens/keys per org)
- Pros: best UX, enables RBAC/SSO, centralized governance
- Cons: key custody + rotation + breach blast radius
C) Hybrid
- Support both modes with an explicit config flag and clear docs
Investigation / Work Items
- Identify where upstream key is required today (code path + config).
- Define where upstream creds would live in option B (storage, encryption, rotation).
- Define how we map InferShield identity (org/user/key) -> upstream credential.
- Decide what the default mode is for OSS self-host vs managed cloud.
Acceptance Criteria
- We choose one of A/B/C and document it in 1–2 paragraphs.
- We update proxy auth behavior/docs accordingly (and create follow-on implementation issues if needed).
- Security notes included: custody model, least privilege, audit logging, revocation/rotation.