Export Control Proxy Team
The fastest way to make an access-control rollout unpopular is to make people log in twice. So the proxy doesn’t ask anyone to authenticate again. It reads the session the protected system already trusts.
Each backend gets a small identity adapter with one job: resolve_identity(request) -> UserIdentity | None. For a locally-authenticated system like Bitbucket, that means reading the existing session cookie and calling the backend’s own user API with it. For a system federated through an existing identity provider (like Okta, Microsoft Entra ID, Ping Identity, JumpCloud, or Cisco Duo), such as GitHub, it means decoding the OIDC token that’s already present from the normal federated login, with no new handshake required.
Resolved identities are cached briefly, keyed by system and session-token hash, so a revoked session or a permissions change doesn’t stay valid on the hot path any longer than necessary. If identity can’t be resolved at all, no session and no token, the request is treated as anonymous: paths that have to stay reachable without a session (like the login page itself) pass through untouched, and everything else is denied, because a denylist can’t be evaluated without a known country.
Onboarding a new backend means writing one of these adapters, plus a matching resource adapter and a routing entry. Nothing else in the pipeline changes.
