2026.8.2 Embedded proxy outpost authenticates as akadmin instead of its own service account, causing 403 on /api/v3/outposts/proxy/ (Not Found on all proxied apps)

Describe the bug

After deploying a fresh 2026.8.2 instance with the embedded proxy outpost and a proxy provider assigned to it, all requests to the protected application return Authentik's raw "Not found" page instead of being redirected to the login flow. The embedded outpost never learns about its assigned proxy provider. Server logs show the outpost's self-refresh call repeatedly failing with 403:

{"filename":"src/outpost/proxy/mod.rs","level":"error","event":"failed to fetch providers", "err":"...status: 403...You do not have permission to perform this action..."}

The corresponding access log for that request shows it authenticated as akadmin, not as the outpost's own service account:

{"event": "/api/v3/outposts/proxy/?page=1&page_size=100", "user": "akadmin", "user_agent": "goauthentik.io/outpost/2026.8.2", "status": 403}

AI Investigation

• The embedded outpost's dedicated service account (ak-outpost-, type=internal_service_account) exists correctly in the DB, with its own distinct token (ak-outpost--api) and correct object-level view_proxyprovider/view_outpost permissions (verified via ak shell / build_user_permissions()).
• Despite this, the live HTTP request made by the Rust authentik server process for its own outpost-config refresh is authenticated using akadmin's token, not the outpost's own token.
• ProxyOutpostConfigViewSet (/api/v3/outposts/proxy/) uses permission_classes = [IsOutpostServiceAccount], which explicitly checks user.type == INTERNAL_SERVICE_ACCOUNT and username.startswith("ak-outpost-") — akadmin fails this check regardless of superuser status, hence the 403.
• This permission restriction was added as part of the 2026.8.2 security patch for GHSA-m9h4-7j9c-55x9 ("Certain stored credentials readable with view permission alone"). Before 2026.8.2, ProxyOutpostConfigViewSet had no permission_classes restriction, so the same underlying credential mismatch existed but was silently masked (any authenticated request could read the config).
• Restarting authentik-server, deleting/recreating the embedded outpost, and re-linking the provider all reproduce the identical failure — ruling out stale state/corruption.
• authentik/rbac/tests/test_outpost_config.py::test_proxy_outpost (added in the same security patch) only verifies the endpoint accepts a manually-supplied, correct outpost token (HTTP_AUTHORIZATION=f"Bearer {outpost.token.key}") — it doesn't exercise the actual embedded-outpost Rust process's real self-authentication flow, so this wouldn't be caught by that test.

How to reproduce

1. Fresh Kubernetes deployment of authentik 2026.8.2 (Helm chart), with AUTHENTIK_BOOTSTRAP_TOKEN/AUTHENTIK_BOOTSTRAP_EMAIL/AUTHENTIK_BOOTSTRAP_PASSWORD set for akadmin bootstrap
2. Create a proxy provider + application, assign it to the embedded outpost (authentik Embedded Outpost).
3. Browse to the protected application's host.
4. Observe: raw Authentik "Not found" page instead of a login redirect.
5. Check authentik-server logs for "failed to fetch providers" / 403 on /api/v3/outposts/proxy/ with "user": "akadmin".

Expected behavior

The embedded outpost should authenticate its own config-refresh calls using its dedicated service-account token (which already exists and is correctly permissioned), not akadmin's token.

Screenshots

The embedded outpost should authenticate its own config-refresh calls using its dedicated service-account token (which already exists and is correctly permissioned), not akadmin's token.

Additional context

Reproduced on a brand-new/fresh install (not an in-place upgrade), so this is not related to the separate InconsistentMigrationHistory issue (#25996). Also distinct from #25226 (duplicate Host header on token backchannel) and #25559 (trusted-proxy-header dashboard issue), though all touch the same Rust proxy-outpost rewrite introduced in 2026.8.0.

Deployment Method

Kubernetes

Version

2026.8.2

Relevant log output