Repository navigation
Option to pass through external Authorization headers without replacement #1794
Description
Problem Statement
Problem
The supervisor's credential proxy intercepts the Authorization header on incoming requests and attempts to parse it as an OpenShell gateway session token. When an external JWT (e.g., from Auth0, Keycloak, or any OIDC provider) arrives in the Authorization header, the supervisor returns 500 "invalid token: token is malformed".
This prevents using standard bearer token authentication for agents that are exposed as API services to external clients.
Current Behavior
- External client sends: Authorization: Bearer
- Supervisor intercepts the header
- Supervisor tries to parse it as an OpenShell session token
- Parsing fails → 500 Internal Server Error
Proposed Design
Desired Behavior
Option A: Configurable header behavior — allow the sandbox to declare that the supervisor should not intercept Authorization headers (pass-through mode):
spec:
supervisor:
credentials:
passthroughInboundAuth: true # Don't intercept incoming Authorization headers
Option B: Graceful fallback — if the token is not a valid OpenShell session token, pass it through unchanged instead of erroring.
Option C: Separate header — use a different header for OpenShell credentials (e.g., X-OpenShell-Token) so Authorization is always available for the agent's own use.
Alternatives Considered
Use Case
Deploying agents as long-running API services where external clients authenticate with JWTs from an enterprise identity provider (Auth0, Keycloak, Okta). The agent needs to receive the user's identity for personalization, audit, or downstream delegation (On-Behalf-Of flows).
Workaround
We use an Istio ext_authz filter at the sidecar level that:
- Validates the external JWT
- Strips the Authorization header (so supervisor doesn't see it)
- Injects X-End-User-ID for identity propagation
- Injects X-Original-Token for downstream OBO flows
This works but loses the ability to have the agent itself validate/inspect the original token.
Agent Investigation
No response
Checklist
- I've reviewed existing issues and the architecture docs
- This is a design proposal, not a "please build this" request
Activity
TaylorMutch commentedon Jun 11, 2026
To clarify, is this a case where you are using
openshell service exposeto expose the service running by the agent? Or is this something else? Clarifying the architecture and network flows would be helpfulTaylorMutch commentedon Jun 11, 2026
prakashmirji commentedon Jul 15, 2026
@TaylorMutch sorry for the delayed response.
We are not using
openshell service expose, instead we create the k8s service for the agent pod and then create the istio virtual service. These agents have openai api compliant APIs like /v1/chat/completions. Our external clients make API call with Authorization header. After we validate the token, we want to propagate the same Authorization header to the agent.drew commentedon Jul 17, 2026
Cross referencing this request with the related #994.
0xbrainkid commentedon Jul 17, 2026
This is a useful place to keep the boundary explicit: gateway credentials and application/user credentials should not have to compete for the same
Authorizationslot.For exposed agent services, I would model three identities separately:
Then the routing decision can stay local to OpenShell, while the application can still inspect the original caller token for personalization, audit, or on-behalf-of flows.
The security-sensitive part is provenance. If pass-through is enabled, I would want the forwarded request to make clear whether the upstream JWT was validated by a trusted fronting proxy, passed through raw for the app to validate, or intentionally stripped. That can be a config choice, but the audit record should name it so downstream systems do not infer too much from the mere presence of a bearer token.
Two regression fixtures would be helpful:
Authorizationis preserved only for routes configured for pass-throughAuthorizationis stripped by default, with a separate OpenShell credential/header path still available for the platformThis maps closely to the AgentFolio/SATP framing we keep using: identity continuity is valuable, but authorization should remain scoped, local, and evidenced by the route/policy decision that allowed the action.
github-actions commentedon Aug 28, 2026
This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.